In the first part of this post I discussed the underlying division that drives the debate about open core, and the futility of arguing about what constitutes an “open source company” without any relevant definition.
Since then Monty Widenius has proposed a definition that would exclude any company that does not produce open source software (including open source support providers) and any company that does not provide access to 100% of its code (which would often exclude Red Hat as it moves to open source acquired code).
In the meantime others have declared that there is no such thing as an open source company and decided instead to discourage use of the term altogether. This is the logical conclusion of the argument that Open Source is Not a Business Model, and while this seems like a nuclear option, it does at least mean that we can hopefully avoid repeated arguments about whether company X is an open source company or not.
Since we seem to be able to move on from the theoretical argument about whether open core vendors are open source or not, it is an opportune moment to turn the debate towards a more practical assessment of the open core strategy and its strengths and weaknesses.
This second blog post turns attention to the open core strategy itself and examines some of the common criticisms. Some of them are valid, some exaggerated, and some are misunderstandings. If the debate is to progress it is important to stop fixating on issues that fit in the latter two categories and focus on those that fit in the first.
There are plenty of criticisms to choose from, and this is a complicated subject, so this is a long post. I have tried to cover all the major issues in one go in order to give a thorough representation of my views on the subject.
For an overview of the open core model itself and how it compares to other strategies for generating revenue see this post. With that in mind (deep breath) here goes:
Crippleware
Since open core relies on generating revenue from proprietary extensions to an open source core it is often asserted that the open source core will be crippled in some way to ensure that users opt for the proprietary version.
That is like claiming that open source support providers deliberately make open source projects difficult to work with in order to sell more support contracts.
Any strategy that worked like that would be flawed. That is why the open core strategy does not work that way.
Like the open source support strategy, open core relies on having a ubiquitous, fully functional, open source project.
Instead of selling support, open core vendors sell value-added features that are designed to be of value to paying customers. Of course the strategy relies on segmenting the audience for the product and delivering features that would be appropriate to each.
As Simon Phipps wrote:
“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.”
I’m sure open core vendors would dispute the reference to lock-in, but Simon’s comment makes it clear that there are two audiences for two separate products.
This distinction is important in understanding how Likewise Software can claim that customers drive open core: “The added functionality in Enterprise benefits a very specific segment of our community, and we work closely with our enterprise customers to ensure we provide value here.”
The point is that paying customers, as opposed to open source users, see value in the proprietary features and are prepared to buy the product. The strategy will fail if open source users also see value in those features but are denied them, or are forced to pay to adopt them.
The phrase “bait and switch” is often used to criticize the open core approach (indeed the term open core was promoted specifically to provide an alternative vocabulary to bait and switch) and suggests that users are either tricked or forced into taking the proprietary features. Clearly any strategy that relies on misleading potential customers is going to be short-lived.
It is true that some vendors are not great at communicating the differences between the open source core and the proprietary version in the past, but our previous transparency test indicated that they have got a lot better in that regard.
To some extent this is as a result of pressure from open source advocates. More than that though, I believe, it is the result of vendors realizing that a successfully executed open core strategy relies on transparency and in not attempting to sell anything to community users (and vastly improving the quality of their marketing communication).
While open core vendors have in the past been guilty of treating the community a sales pipeline, we have observed that the next generation of start-ups has learned that the best way to encourage a frictionless relationship between a vendor and its community is not to attempt to “convert” users at all.
It goes without saying that forcing users to use the proprietary extensions is going to be flawed – the open core strategy depends on keeping both users and paying customers happy, independently.
Managing that is not easy, as our research has confirmed. As previously noted, our CAOS report into how open source changes approaches to sales and marketing included a few choice quotes from open core vendors on its challenge:
“Number one [challenge] is differentiation between core and commercial.”
Clearly, the difficulty with open core is in deciding what features to put in which version, and what proportion of a company’s engineering effort should be focused on the open source project.
“We can compete with ourselves; i.e., our commercial product may not be purchased because our open source/core product contains sufficient functionality to solve customer problems.”
It is a significant challenge and some vendors have been better at it than others but it does not follow that because this challenge exists then the core must be crippleware. Indeed the success of the strategy depends on it not being crippleware.
“Continuing to maintain the right balance of functionality between the freely downloadable open core and the commercial extensions is both art and science. It’s critical to get that right so the model continues to grow and advance.”
Are there some open core open source projects that are lacking in quality? Of course, but that doesn’t mean that all open core open source projects are crippleware. There are some pretty crappy “fully functional” community-developed open source projects – that does not mean the community development model is flawed.
Half a product
In response to Larry Augustin’s statement that “Well over half of our engineering effort produces code that is released under an OSI approved license”, Tarus Balog commented:
“Well over half? Well, that’s pretty good, but is open source code something that can be divided? Can I say “here is the product, but you only get to use half of it under an open source license”. Who decides which half? If I look at it in binary, do I just get to use the ones or just the zeroes?”
I am assuming Tarus is deliberately misunderstanding Larry’s statement in order to be facetious/mischievous (the last line certainly suggests so) but the statement highlights another misconception of the open core strategy – that the vendor starts with a fully-featured product and then divides it into the basic core (open source) functionality and the value-added (proprietary) extensions.
As we have already stated, however, in order for the strategy to work the core project must be widely adopted. For that to happen it needs to be a complete project. As Jack Repenning notes:
“if the open parts accomplish their goal fully and well… then the open-source product deserves to be assessed on its own terms. If there are also commercially licensed, or even proprietary/closed things associated with it that together accomplish some larger goal, that’s a different product, not a betrayal of the open one.”
The biggest issue that open core has, in my opinion, is that it attempts to bypass Clayton Christensen’s law of Conservation of Attractive Profits, which states that “When attractive profits disappear at one stage in the value chain because a product becomes modular and commoditized, the opportunity to earn attractive profits with proprietary products will usually emerge at an adjacent stage.”
It is this law that explains why it is difficult for open source support vendors to generate significant profits (since they have commoditized their own stage of the value chain). The same is true of open core vendors, except that that are attempting to commoditize only a portion of their value chain – the core functionality offered by the open source version, while betting that their value added extensions are sufficiently differentiated to retain the ability to generate profits.
Christensen’s law dictates that it will always be easier to generate profit at an adjacent stage. Or, as Matt Asay explains in the context of the OpenStacks project: “The reason OpenStack may be a big winner is that Rackspace doesn’t need OpenStack to make money. At least, not directly.”
Community matters
Cloudera recently told The 451 Group that 50% of its engineering effort is focused on open source projects (specifically Hadoop and its related projects) with the other half focused on the proprietary capabilities that are delivered in Cloudera Enterprise.
No one would suggest that Apache Hadoop is a limited or crippled project, simply because Cloudera (and IBM, Karmasphere and others) are offering closed-source complementary products.
Of course the difference between Hadoop and SugarCRM community (or many other open source core projects) is that Hadoop is a community-developed project, while in vendor-led open core projects are dominated by a single vendor.
This enables accusations of lock-in and a lack of community contributions to the development process. I’ll address the first issue shortly, but with reference to community development it is undoubtedly true that the majority of vendor-led open core projects do not enjoy the benefits of a collaborative development process.
Carlo Daffara explains how the strategy is a tradeoff between monetization and contributions, noting that “it is simply not possible to get something like Linux or Apache with open core”.
That is true, but then that is also not the aim of open core. Vendor-led open source projects are invariably more focused on creating ubiquitous platform and lowering barriers to adoption than they are on creating ubiquitous platforms for collaborative development.
Not all open source software projects are collaboratively developed. Whether this is a concern is very much a matter of personal opinion – is it enough that software is under and open source license, or does it also have to be developed collaboratively?
It is a problem, of course, if a company actively avoids contributions from elsewhere on the grounds that that doing so would impact their proprietary extensions. Simon Phipps notes that one of the reasons NASA involved itself in the OpenStacks cloud projects was due to frustration with Eucalyptus Systems’ reluctance to accept contributions that competed with its closed extensions.
Clearly this highlights a potential problem for open core vendors, but it is one that actually contradicts the accusation that open core users have no choice but to accept the proprietary extensions. While there is lock-in associated with any software choice, one of the weaknesses of the open core approach is users could decide to fork and/or develop open source versions of the proprietary features.
Similarly, Dana Blankenhorn reports that SplendidCRM has already replicated the user interface delivered in SugarCRM’s paid-for versions and made it available in its own community edition.
It is important to note, however, that while issues related to the community contributions are a symptom of the open core licensing strategy, they are by no means exclusive to open core.
The recent debate about open core was kicked off my this post by former Compiere CEO Jorg Janke about the apparent failure of Compiere’s strategy in putting too much emphasis on the closed extensions (as well as mistakes related to the partnership model).
In a follow-up post Jorg turned his attention to the project’s lack of external contribution. While it is clear that this was an issue that was exacerbated by the open core strategy it is important to note that the development model was dictated by a decision that was taken prior to the open core strategy being adopted.
Similarly the vast majority of the developers of the MySQL database have always been employees of its owner (first MySQL, then Sun and now Oracle). The shift towards open core (and it hasn’t got there yet) came much later than the decisions that prompted the development model.
Development costs
One area in which the lack of community does matter, of course, is in the R&D costs of open core vendors. The greater a proportion of employees that you have focused on development (of open source or proprietary code) the greater your development costs are going to be. This is undoubtedly a valid criticism of the open core model as the company is failing to benefit from R&D cost savings in terms of both the open source core and closed source extensions.
Arguably, the company is also impacted by higher development and testing costs since the closed source extensions do not benefit from exposure to the open source user community. How significant this additional cost might be depends on the significance of the extensions and the relative size of the community (since the vendor will still go through the traditional alpha/beta testing with its paying customers).
Another cost, arguably, is the loss of quality in the proprietary extensions resulting from the smaller testing group and the lack of open source code review. Again this is a valid criticism, but it is one that belongs in a much larger debate about the relative benefits of open source and proprietary development strategies.
Venture-capitalist tool
Jorg’s initial post also discussed how VC investors had pushed Compiere towards the open core approach, and another criticism is that it is the chosen OSS-related business strategy of VCs. Again this is a valid argument. There is no doubt that VCs are attracted to the open core strategy and have encouraged its wider adoption.
However, it is also worth noting that there are exceptions to the rule. OpenLogic is a VC-backed company that has been vocally critical of open core, while xTuple is a self-funded open core vendor (there are other examples).
I would also point out that VCs are also fully aware that for the strategy to be successful it depends on a ubiquitous, full-functional open source core, and that attempts at crippleware will fail.
Lock-in and other problems
Perhaps the most obvious criticism of open core, from an open source perspective, is that it perpetuates the use of proprietary software. Again this is valid, and I have previously covered why I think open core vendors are limiting their opportunities by focusing on product-led strategies and leaving themselves open to accusations of lock-in.
Again these are really issues for a larger debate about the relative merits of proprietary and open source licensing.
Finally (one hopes) the other major criticism of open core vendors is that they are misusing the term open source to describe themselves (or as Henrik Ingo put it “So if I don’t call myself ‘open source vendor’, then everything is fine? (yes)”
Assuming the decision to avoid using terms like “open source company” are maintained, this becomes less of an issue, but it is worth noting that the attempts at policing the term have been counter-productive.
The point is this: if you want open core vendors to refer to themselves as “open core companies” rather than “open source companies” then demonizing the open core strategy is not the way to go about it. Is it any wonder that Larry Augustin does not want SugarCRM to be seen as open core when accusations of crippleware are being thrown around?
Previously, Redmonk’s Stephen O’Grady noted that there is the potential for serious collateral damage in the way the debate about open core licensing is progressing.
Henrik Ingo notes that companies like CollabNet (which is not open core) is “concerned about the negative image now attached to open core and worried that his company would then be suffering from the negative image too.“
There are many ways in which an open core strategy could fail, but that does not mean that all open core strategies will fail. Open core is just the strategy -how you execute that strategy determines whether you succeed or fail.
I agree with CollabNet’s Jack Repenning that the conversation needs to move “a bit towards how to do it right, and away from confrontation”.
That was my aim with these two posts. I am sure there are plenty of people who will disagree with plenty of the things that have been written above. My intention is not to be confrontational but to take a balanced view of the potential problems related to the open core strategy.
We will be writing more about other strategies for generating revenue from open source software, in a follow-up to our Open Source is Not a Business Model report, which is due to be published latter this year. It will provide more context for the economic motivators and issues involved in the various models, as well as updated research on which vendors are following which strategies, and why, as well as a survey to uncover what software users make of it all. The report will be freely available to CAOS subscribers. For more details of the CAOS research practice, and to apply for trial access, click here.
PlanetMySQL Voting: Vote UP / Vote DOWN