All Open Source Software is Commercial

Eric Barroca after reading Dirk Riehle‘s slides about “The Commercial Open Source Business Model” wrote an inspiring blog post, receiving a number of interesting feedback from the business open source folk.

Let me start by recommending Dirk’s presentation, it really worths reading, but beware of his definition of  “commercial open source”:

Commercial open source software projects are open source software projects that are owned by a single firm that derives a direct and significant revenue stream from the software.

David Wheeler, Dirk and I just few weeks ago had an email conversation on the definition of commercial open source. David and I sharing the same vision – basically seeing nearly all open source software as commercial software – found hard to agree on the equation:
commercial open source = single vendor open source projects.

I have already been writing that commercial and open source are still not antonyms, and David did definitely a better job in his paper  “FLOSS is commercial software” (revised earlier this year).

Many open source projects are backed by companies investing (sometimes large) amount of money, and they all have economic reasons to do so. Even limiting ourselves to the “profit-oriented” definition of “commercial”, we should consider companies like IBM, Google and now even Microsoft as part of the commercial open source world.

To limit commercial open source scope to single vendor open source projects is too much anyway, and it wouldn’t be easy at all (think of how many “commercial open source” vendors rely on others’ open source projects).

Eric Barroca”s post covers few myths of the “commercial open source” – as redefined by Dirk Riehle – raising interesting issues around what really makes a software vendor a commercial open source one. Like Boris you might not totally buy his vision, but you can probably share most of them (still not all of us may like or dislike the same points, though!).

Let’s concentrate on a very specific aspect: making money out of open source projects’ participation, building proprietary software leveraging open source ones.

Software vendors’ perspectives towards open source can vary a lot from vendor to vendor, but the promise of sharing both standards/innovation costs and R&D cost is appealing to all of them.

Let’s take Day Software, a company I have been mentioning in the recent past talking about the open source innovation backbone.

David Nüscheler, Day Software CTO, few days ago told me about what it takes to participate (or even lead) standardization processes.

It definitely depends on the level of participation in a particular standardization process. Simple participation in an expert group or a technical committee can require only a small effort such as a couple of hours of work per month or week.
An active participant in a standardization can easily rack up numerous hours per week ranging up to a couple of FTEs.  When we talk about leading a specification effort, like we did in JSR-170 or JSR-283, there are a number of subject matter experts more or less constantly involved.

The burden on editor or specification lead also varies by
standardization body.  With some standardization bodies there is no requirement to produce a testkit to certify or measure compliance of an implementation with a standard.

However, for example in the JCP the specification lead must provide a testkit (TCK) and even a reference implementation the passes 100% of the testkit to prove that the entire specification does not just look good on paper but is completely implementable.  Providing a testkit and a reference implementation certainly makes it much harder to complete a standard but it of course also makes the final result a much more solid specification.

In our specific case we did not really see the standards participation as a cost but much more as a part of a our leading edge research and development efforts that we would incur anyway. The choice that we have is whether to do that research behind closed doors and receive our first input from our customer base once the product is shipped or if we want to discuss these topics with the brightest minds in the industry by leading such a standardization.  We very much view the expert group in a specification as our extended R&D-team that we can leverage for architecture discussions that matter to the entire
industry.

Google, Microsoft and Yahoo show that technological clubs happen, sharing standards or participating to sequential innovation is a nice to have, but it definitely implies costs of membership.

Talking about production costs,  David told me about pros and cons of sharing R&D costs.

We generally feel that through developing most of our infrastructure code in public there are various benefits for us as a commercial vendor.

To ensure that we gained maximum benefit we chose to collaborate with the Apace Software Foundation.  In particular because it is renowned for its clean cut meritocracy and true-spirited open source, from its very liberal licensing to the diversity-oriented community and foundation processes.

Traditionally I think that people view community participation in terms of contributing code patches or feature donations.  In our experience the most valuable contributions from the community comes in completely unexpected forms.  These include the use of a very public active mailing list as a sounding board and self-help archive, issues reporting, the fact that the community is building the software around-the-clock, having a very agile test harness of the latest features and changes in the form of the community and ultimately the prospect of being able to then hire the brightest minds in the industry having seen their great community work on “our technology”.

Most importantly though I think that learning to develop in the
“Apache Way” has greatly improved our internal communication skills and has greatly enhanced the overall quality of our products.

We feel that only on rare occasions do we compete against “our” Apache open source projects and we have definitely been able to keep our open source projects very competitive within the open source world.

Symbiotic approaches are not for free, and to choose what has to keep secret and what is convenient to share is a strategic decision, though.

Even if Day Software is selling a proprietary product, I couldn’t tell they are not part of the commercial open source world.

Related Posts