✭ On the term “open source business”

Hunter and HuntedI’ve been having a number of conversations in e-mail on the subject of open core business models. The problem that keeps coming up is that there are a range of behaviours exhibited, some of which are acceptable to pragmatists and some of which cross the line into abusing the term “open source”. Where should we draw the line in? When is it acceptable for a company to call itself “an open source business” and when is it not?

An example is a hypothetical  business with an open source “Community Edition” of their software product which lacks many features of the commercial versions. It is indeed freely available under an open source license and fully functional. I am sure there are happy deployers of this version. If this was the only version available, I would have no issues.

The commercial versions are significantly different from the community version, with both user interface differences and functional differences. While paid licensees are entitled to source access to this version, the commercial licence is not perpetual, meaning that if the customer ends their relationship with the vendor, they lose the right to use this version. Since this version significantly differs from the community version, there is no fall-back plan and while the customer may have access to their data (if the vendor is sufficiently enlightened about open data), there’s no software they can continue to use. They are unable to trade “time” for “money”, to use Mårten Mickos’ famous explanation – they are locked in and the open source core of the proprietary version delivers no freedom to them.

If this latter situation was described as “proprietary” (or avoided association with open source, as for example IBM’s WebSphere does in its embedding of Apache HTTPD) I would have no issues either.

The fact is, the community edition and the commercial editions have disjoint user bases. The community edition is used by a group of people who have the time and skills to deploy by themselves and who have no need of the many differences of the commercial versions. The commercial versions are feature-rich and effectively lock their users into a traditional commercial ISV relationship with the vendor.  If these two were kept distinct, there would probably be no pragmatic issue (naturally Free Software purists would still protest the existence of closed code, but that’s not a part of this particular argument).

But a vendor which mixes these two encourages exactly the market confusion that OSI was designed to minimise. If they claim to be “an open source business” and use the presence of the community edition as a credential to sell the proprietary versions, they wrap themselves in the open source flag and their actions are exactly the gaming of the maturity of the Open Source Initiative that I believe should be challenged.

The question is how. As Matthew Aslett points out,

In short, if you want to police the term “open source company” then you have to have a definition for it first.

That’s true. Defining an “open source company” will be impossibly subjective, since most companies have open source in their source code mix these days. Given “open source” can only refer to software, I think is far smarter to discourage use of the term all together.

%d bloggers like this: