A blog for the enterprise open source community
The open core issue (part one)Matthew Aslett, July 15, 2010 @ 10:53 am ET
The debate about the open core licensing strategy continued last week while I was enjoying a week off.
However, like Carlo Daffara, I was unable to keep my mind completely off the topic and as I dug the allotment one afternoon I found myself pondering why it is that the topic continues to be such a controversial issue.
On the face of it the answer is obvious – open core involves the mixing of open source and proprietary licensing strategies as vendors offer an open source core, as well as a closed version with additional extensions, and opponents are concerned that the “open source brand” is tarnished by companies like SugarCRM claiming to be “an open source company”.
I believe the answer is deeper than that, however. The open core strategy highlights many of the major issues that divide attitudes when it comes to software licensing and development. Alongside “open vs closed” it also triggers discussions around “control vs community”, “customers vs users”, “pragmatism vs idealism”, “freedom vs lock-in”, “venture capital vs self-funding” and “product vs service”, among other things.
I intend to address many of those issues in the second part of this post, and the issue of “open source companies” below, but first I wanted to turn attention to what, for me, is the underlying division highlighted by open core: whether free and open source software (and its associated software freedoms) is considered a means to an end, or an end in itself.
During the ongoing debate before my week off Henrik Ingo stated “open core goes against the values of the open source community”.
I’m not sure that’s necessarily true. Or, to put it another way: I think it is undoubtedly true if you consider FOSS to be an end in itself but not if you consider FOSS to be a means to an end – for example, if you are establishing or maintaining a VC-backed/public software company, in which case the end is likely to be maximizing profit through lowering software development costs in the case of an open complement strategy (see Motorola, below) or barriers to adoption, in the case of the open core strategy.
Neither position is truly representative of the values of the open source community. But the difference between the two is at the heart of the debate about open core and, more broadly, the use of open source software in the creation of closed products.
A great example of this tension was provided by Bradley M Kuhn this morning as he criticised Motorola’s “opposition to software freedom” based on its decision not to deliver unlocked Android phones for system development and re-flashing, a decision that it is perfectly entitled to take while remaining in compliance with the relevant licenses.
The difference between Motorola and many vendors with open core strategies, of course, is that Motorola doesn’t claim to be an “open source company”, which brings us back to the issue of the “open source brand”.
If you believe open source to be an end in itself then that open source brand is something to be protected, whereas if you believe open source is a means to an end then there is no open source brand to protect – just a description of a set of licenses that meet certain conditions.
That description, the Open Source Definition, is the closest thing we have to an articulation of the values of the open source community but – as I have previously noted – it is a functional document that is concerned only with licenses, not the business strategies associated with how they are used. It is certainly not a definition of an open source company.
As a result people on both sides are able to apply their own values to their interpretation of the OSD in the context of open source-related business strategies. Henrik Ingo is therefore justified when he writes “open core does not qualify as open source, as per the definition. It is closed source. It is the opposite of open source” as is Mark Radcliffe when he writes “the open core model does not violate the Open Source Definition, either literally or in spirit.”
It could be argued that Mark’s opinion carries a little more weight than others when it comes to the Open Source Definition, although it should be noted that he was providing his own personal opinion, rather than that of the General Counsel of the Open Source Initiative.
This is why I described the debate around open core as tedious and futile, because unless personal interpretation is removed from the equation there is no hope of resolution. (Incidentally, anyone who thinks there is an agreed definition of “open source” should probably avoid the comments on this Slashdot post discussing SugarCRM). In short, if you want to police the term “open source company” then you have to have a definition for it first.
An “open source company definition” was adopted by the OSI as a standard definition for an open source company In August 2009, although the definition itself has never been published, while in October last year Simon Phipps proposed building a Scorecard for Open Source that wold also have taken the conversation forward, but nothing much has been heard of that since.
That is why I welcomed Henrik Ingo’s list of the business practices he believes are unacceptable, because it at least it attempts to progress the conversation. At this stage, of course, Henrik’s list is still Henrik’s list, and a matter of personal opinion. The hard part will be reaching some sort of consensus on acceptability. Then there is the matter of how it could be enforced, and by whom.
Comments (18) Categories: Software