Archive for June, 2009

The FLOSSMETRICS/OpenTTT guide in French

Just a brief update: the NTIC, CRCI Bourgogne and ARIST jointly translated our FLOSSMETRICS/OpenTTT guide for small and medium enterprises in French:

The guide is available as a pdf file. For more information: this page at AgenceNTIC Bourgogne.

, ,

No Comments

Freeriding, participation and another modest proposal

There has been in the past several articles related to “freeriding“, that is the use of OSS without any apparent form of reciprocal contribution, be it in a monetary form, or in terms of source code. I am not sympathetic to this view in general, because it masks an ill-posed question, that is “if you use someone code, are you required to give something back?”

It is in my view an ill posed question, because it mixes at the same level ethical and economic questions, and because it clearly avoids all the potential non-code contributions that are implicit in use, even in absence of back contributions. First of all, about ethical participation: open source code is available for all, without any form of implicit additional moral burden; the only rules that govern it are those that are laid out in the license itself. So, if the license for example allows for unconstrained use of a binary product derived from OSS code (for example, Eclipse) than it should not be expected from the majority of use any incremental contribution of any kind – it is simply not realistic to imagine that suddendly, all the Eclipse users should start contributing back because they are feeling guilty.

It is different when we think in economic terms, that is in terms of R&D sharing: in this frame of reference every user and potential contributors has an implicit model that gives a reason (or not) to contribute something, for example when there is an opportunity for reducing the cost of future maintenance by making it part of the official code base. This is a much more complex activity, because it requires first of all a high level of comprehension of the distributed development model that underlies most OSS projects, and then a clear and unambiguous path for contributing back something; this kind of contribution channel is clearly present only in some very high level and sophisticated projects, like the Eclipse consortium.

The second misunderstanding is related to the “hidden” role of users and non-code contributors. Most project (even our FLOSSMETRIC one) measure only code contributions – but this is just a small part of the potential contributions that may be provided. As the contributors map of shows:

OpenOffice people count area map

There are many non-code contributions, like native language support, documentation, marketing, word-of-mouth dissemination, and so on. Even the fact that the software is used is a value: it can be for example used in marketing material for an eventual monetization effort, and is indirect demonstration of quality (the more users you have, the more inherent value the software may be inferred to be valuable for at least a category of users). I understand the gripes of commercial OSS vendors that would like to monetize every use of a software product, and discover that their software is used in some large company without giving back any monetary contribution. I took as an example Alfresco: “General Electric uses Alfresco’s software throughout the company while paying us nothing…and yet we’re having a banner year.” While I am sure that Matt Asay would love to have GE as a paying customer, even the reference is a proof of quality of Alfresco, and can be considered to be a valuable asset.

Users contribute back in terms of participation in forums, in providing direct and indirect feedback, and much more. Of course only a small part of the users contribute back, a phenomenon that was apparent in most social phenomenon well before the internet, and should be no surprise to anyone.

As a side note, as a continuation of my previous hypotesis on what may be the most efficient structure for maintaining the advantages of OSS resource sharing and proprietarization, I received many comments on the fact that most projects are small, and creating a full-scale Eclipse-like consortium (or something like OW2) is not really sustainable. But it is possible to imagine a OW2-like consortia that handles under its own umbrella the back-contribution to a large number of independent project, for each one managing the three core interactions (technical, social and legal) that are prerequisite for every completely verified contribution. Think about it: imagine yourself as a developer working in a company, and after some work the CEO allows for a linux-based product to be launched. As such, you make some patches and contributions, and instead of maintaining your own branch, you try to send back your patches. To who? Is it really that easy to discover the kernel mailing list? What is the proper form? If you need to send back patches to GCC (for example, for some embedded board processor) who do you contact? Is it really that easy to do? On the side of the project, how are contributions managed?

Each question is a stumbling block for a potential contribution. Of course, the larger project to have a channel – but sometimes it is not that easy to find and manage properly. I believe that an independent structure can increase the contribution process by providing:

  • social skills: what is the proper contribution form? What groups and networks should be contacted?
  • technical skills: what is the proper form? Is the contribution fulfilling the project internal rules for contribution?
  • legal skills: has the contribution the proper legal attribution, has it been verified, has it been properly checked?
  • marketing: show that software exist, that it can be used, and how.

Such a structure may be created for a limited cost, especially by leveraging the many voluntary activities that are now scattered in many individual projects. Instead of making yet another repositry, a local government could probably spend their money better in making sure that there is a realistic feedback channel. If this effort can increase the participation probability even by a small percentage, the potential return on investment is significant.

, , ,


Horses, carriages and cars – the shifting OSS business models, and a proposal

If there is a constant in this research area, is the fact that everything is constantly changing. While we debate about whether mixed models are really that important or not, or while free software experts are fighting against brand pollution, I still find amusing the fact that most of what we debate will be probably not relevant in the future at all. Exactly like the initial car models, that resembled the horse-driven carriages that were planning to supplant, some actual OSS business models are half-hearted attempts at bridge the gap between two different worlds, with some advantages and disadvantages of each.

All OSS business models are based on the idea of monetization of a code base, and this monetization can happen in many different steps of the acquisition or use process. Monetization of services, for example, usually happens in the initial adoption step through training and set-up fees, while support monetization happens in the long-term use phase (and in large scale companies tend to be limited in time, as the internal IT staff becomes more and more expert at the infrastructure, and the need for external supports reduces with time); sometimes monetization happens elsewhere (like Mozilla and Google).

Mixed models try to leverage the R&D cost reduction that is inherent in the OSS process, while at the same time maintain the easy and clear proprietary licensing model, where there is a token-based monetization (per CPU, per user, per server, and so on) that is not related to an inherent limitation of the software, but is an artificial barrier introduced to prevent free riding. This, however, introduces the disadvantages of both models into the equation: developers working for a commercial company are reluctant to participate in a project that has a clear potential for third party exploitation, while non-employed developers may be more interested in contributing to more “libre” projects. On the adopter side, the user is not allowed to experiment with the full version of the software, and may not be interested enough in trying the OSS version if the difference in terms of stability and features is too high.

That explains why mixed-model vendors claim that basically no one contributes code to their project (thus neglecting all the non-code contributions, that in some cases are significant), while vendors that select alternative monetization approaches seem to fare better. Pure OSS products are in fact more efficient (and tend to allow for higher company competitiveness), and even vendor-backed projects like Eclipse receive significant external contributions (IBM has only 25% of the active committers, for example).

About the claims that mixed models or open core approaches are the norm, I still stand on my numbers, that shows that less than 25% of the companies use this approach to monetization. Also, the companies are adopting a more softer stance on open core; while a few years ago the code available under the non-OSS license was a substantial part of the functionality of the full product, now the vendors are using many separate non-functional product areas and put them together to create the proprietary product, like certification, stability assurance, official support and sometimes additional code for ancillary activities like monitoring and high-end features like clustering (Alfresco recently announced such a change).

As the horse, carriage and cars example I made at the beginning of this post, I believe that these are steps taken in trying to approach and adopt the optimal model; in this sense, I believe that a better approach is to clearly divide the “core” and “non-core” groups into separate legal entities, with differentiated governance models. In particular, I believe that a more efficient approach is:

  • To have a core, Eclipse-like consortia that provide clear, public, transparent management of the central open source part of the project. As for Eclipse, while initially the vendor dominates in terms of contribution, after a while (and in the presence of a healthy external ecosystem) contributions start to reduce the R&D cost – in the case of Eclipse, over 75% of the code commits are from outside IBM.
  • To have a separate, independent unit/company that provides, under a traditional proprietary license, the stabilized/extended software without any confusion about what is open source and what is not. It will not be “mixed model”, “commercial OSS” or whatever – just proprietary software. Or, if the offer is service-based, it will be a pure service contract.

I strongly believe that this model can not only put on a rest the entire “mixed model” or open core debate, but can also provide significant productization benefits, by reducing the contribution barrier that so many OSS vendors are experiencing right now. By creating an ecosystem of “development consortia” it will also be possible to increase coordination opportunities, that are sometimes stifled by OSS vendors that pursue independent agendas; it will also reduce customer confusion about what actually they buy when they receive an offer from such a vendor.

, ,