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

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.

Be Sociable, Share!

9 thoughts on “All Open Source Software is Commercial

  1. Thanks for continuing the discussion! Just a short note on the term “commercial open source”. As far as I understand, it was coined by SugarCRM to distinguish Sugar from say GIMP or other open source software that had no primary profit motive in mind.

    I’m actually not saying that the only commercial open source out there follows the single-vendor open source model. Acquia is a good example of a commercial company that is based on community software, so is TWiki. RedHat is commercial for sure too.

    Because of this possible confusion that you are also pointing out, I have been moving away from “commercial open source” to “single-vendor open source”. From today’s perspective, SugarCRM overreached when coining this term.

  2. Including multiply-sponsored projects in “commercial open source” is a good thing, I won’t argue with you there. But I’m still not convinced that “all” open-source work is “commercial.” There are loads of projects on Tigris.Org, SourceForge.Net, github, and all the other community sites that have no sponsorship at all.

  3. @Dirk thank you to rejoin this conversation!

    I believe you’re right, SugarCRM was probably at the forefront with naming it commercial open source, but I am not sure they want to exclude open source vendors like Acquia or Sonatype.

    I appreciate your decision to move away from “commercial open source” to “single-vendor open source”, really.

    @jrep I am following the definition of commercial reported by David Wheeler in his paper:

    Commercial means either (a) “oriented to profit-making”, or more generally (b) “of, pertaining to, or suitable for commerce”, where commerce means “intercourse, dealings, the buying and selling of commodities, or trade” So we’re talking about something (a) oriented toward profit, or at least (b) something pertaining to public trade or dealings.

    I must agree with David saying that “when we include the second meaning (which some people forget), nearly all FLOSS programs are commercial”.

  4. Roberto,

    At least the open source supporters are doing their coming out (thanks to Eric!)

    Your analysis is perfectly correct (as well as Dirk’s one), but I’d like to moderate it on one single point :
    I think that there is some open source initiatives that are not commercials!
    Some open source initiatives, driven by (non profit) foundations (FSF, Mozilla, Apache…), are mainly motivated by altruism, openness and sharing (as well as by the ego of some of the contributors). Indeed, within thoose foundations, they are not equal : some are using licenses (GPL to name it) with very strong constraints about commercial use : the code developed from a GPL-licensed source code must be given back to the community with the same license!!

    This is really the original (and in some way utopian) vision of Richard Stallman.

    This is why I mostly agree with you. I even think that everything else is commercial (and marketing tactic)….

    By the way, I’ve just read an awesome post from Vishal Vasu ( that reminds us (from a user perspective) that, what is important, is that your software needs to support (useful) open standards!


  5. Hi Alain,

    I know you are right saying that some – maybe even many – open source initiatives are mainly motivated by altruism, openness and sharing. Those motivations do not prevent commercial activities around those projects.

    Via twitter I was pointing you to Mitchell’s blog post about Mozilla’s sustainability (courtesy of the WayBack machine) because it is a great example of the so-called second meaning of “commercial” (see my previous comment).

    About GPL strictness I’m not so sure, not in a web world at least, but I didn’t cover (yet) licensing and open source commerce.

    Last but not least, I totally agree with you and Vishal, I am struggling to make open standards compliance more relevant here in Europe, the next ODF Plugfest will be a step in this direction.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>