August 31, 2009, 3:45 am
I’m currently managing and facilitating the Validos-collaboration ‚Äì it’s an open collaboration of companies for open source compliance. Validos does the basic validation of open source software packages and shares the results with every participating company/entity. Thus the basic work is done only once. I have introduced the idea and our law firm provides the compliance work. Validos is essentially a collaboration between our customers and new customers.
From our customers’ perspective the business model is great. They get the traditional outsourcing benefits (expertise and scale) and most importantly, they do not need to redo work done by some other company. With a growing number of members and a growing database, the work needed per customer becomes smaller all the time.¬†
From our law firm’s perspective the business model is equally great. We have done open source compliance work for almost 10 years, but to be honest, it wasn’t a business, as such. Before Validos, it was a part of some M&A work and otherwise it was the occasional questions, such as “can we use this package and what should we do when we redistribute” os “does the license fit our business model”. With Validos, this has changed. Now we (a 12 lawyer firm) have a person dedicated to open source compliance work and two other lawyers working intermittently on something related. Validos-members refer new companies that might be interested to join ‚Äì it’s in their interest, since that way the amount of members grow and so does the database on validated packages.
Validos is actually an association and our law firm is a service provider of the association. The database is owned by the association and our law firm has no exclusivity. I saw this as an important element to encourage participation and I do not see the risk of losing this client as very relevant, as long as we are able to deliver what is needed. (And if we aren’t, then we should go.)
The Business Model
The Validos-project has resulted in a growing number of other similar projects, i.e. projects that involve customer collaboration. In addition to service offerings by our law firm some of our customers are planning customer collaboration in their businesses. I am now starting to see that businesses/vendors can leverage collaboration of their customers as a means to (i) offer considerably more value to their existing and new customers, (ii) become closer with their customers both as an increasing customer commitment and by carrying out projects that go deeper and (iii) get more contacts/customers. For all this to happen, the vendor must adopt an open and active role in proposing and supporting the collaboration.
The customers won’t become committed, if they are bound to one single vendor (negative lock-in). But if one vendor allows them to change vendor and take everything with them, the customers are more likely to put their own effort into the collaboration. Looking from the perspective of the vendor, the fact that a customer has it easy to change vendor, becomes a lot less important, if the vendor manages a collaborative effort that produces value that is very difficult to compete with: the customer can change vendor, but the customer doesn’t want to and such a move would be irrational (positive lock-in).¬†
How Does this Business Model Relate to Open Source?
First, the basic thinking under this idea is that whatever you do, do it openly, and get more. 
Second, there is a good application of this business model to one (or two) traditional open source business models.
The model can be applied to the so called “expert approach”, i.e. a fully open, company driven open source project with an aim to promote the company as the leading expert for implementations of that software. The down-side of the expert-approach is that competitors can rather easily offer projects with the same software. Well, this down-side can be limited by building a collaborative community of existing and new customers. The customers get more value and new customers would rather join the community, instead of starting from a lower level with another vendor with no or small collaborative possibilities.
Collaborative elements could range from information exchanges to joint implementation and even joint development projects, not to mention scale benefits. In some cases (e.g. for the public sector) the customers can engage into deeper collaboration regarding the production of their services with the help of a collaborative experience and similar IT-systems (which are based on the same platform and may even be jointly developed). Of course, it may happen that some customers wish to develop an add-on to the open source project and share it only with those who participate in costs Рall just fine, but in the long term such development should be placed into the open source project.
