Commercial Open Source: The Naming Confusion Remains

In 2004, SugarCRM coined the termcommercial open source“. This term was intend to separate the commercially-oriented open source projects of venture-capital-backed startups from the then dominant community open source projects. The term was picked up quickly, by many. I (as well as others) define it the following way:

“A commercial open source firm is a software firm that provides most or all of its product as open source while maintaining the relicensing rights to the source code.” (Maintaining the rights has the purpose of being able to sell the product to customers under a commercial license.)

This type of software firm has quickly become important and stands to gain even more ground. According to Gartner Group:

“By 2012, at least 50% of direct commercial revenue attributed to open-source products or services will come from projects under a single vendor’s patronage.” From: Mark Driver. “Predicts 2009: The Evolving Open-Source Software Model.” Gartner Inc, 2009.

These firms employ various models and strategies, for example, the open core model (local copy) or the dual-license strategy. We understand a lot about them, but what we don’t have is a good category name. Calling these firms “commercial open source firms” suggests that other companies like Red Hat are not commercial open source firms. Also, selling services for a community project like Linux makes you what if not commercial.

One solution is to disambiguate by prefixing the term. For example, we could start calling SugarCRM, Alfresco, Jaspersoft, etc. “commercial single-vendor open source”. I think this is my preferred solution. We might even drop the “commercial” part as it is implied in “single-vendor” open source.

The most correct term to capture “single vendor patronage” would be proprietary. That’s because there is only one proprietor, as Christof Wittig, former CEO of db4objects, suggested. While technically correct, I fear talking about “proprietary open source” will create only more confusion.

I’m curious: Did anyone solve that naming problem? For now I’ll go with single-vendor open source.

UPDATE

I noticed that James Dixon uses the term “single-vendor commercial open source” in his Beekeeper model, so this makes at least two of us who are unhappy with the use of “commercial open source” to mean the category that SugarCRM was originally trying to identify. In James’ case, the term seems to have been introduced to distinguish single-vendor open source firms from firms providing support to community-owned open source projects.

2 Replies to “Commercial Open Source: The Naming Confusion Remains”

  1. Single vendor open source does seem to explain it a bit better. Of course, the term will be more likely to gain traction if the companies practicing that business model are willing to refer to themselves this way. Any sense if they are willing to make that switch?

  2. Good point, and I wonder. The term “single-vendor open source” seems neutral enough. It may actually beneficial to the vendor because the worry is (or at least used to be) that someone uses your code to compete with you. So single-vendor signals to customers that there is only one place for products and services…

Leave a Reply