It's not shaping up to be a great week for the open core model.
First, it seems that we're finally seeing some official responses from the Open Source Initiative (OSI) regarding open core. Predictably, they're Not Happy.
Clearly, individual OSI directors have been less than thrilled with the open core business model. Simon Phipps, in particular, made a pretty strong argument that open core was just plain bad for business. But, though Phipps is an OSI director, he wasn't speaking in any official capacity on behalf of the OSI with these statements.
This weekend, Russ Nelson, another OSI director and License Approval Chair posted an entry on the OSI Board Blog sharply criticizing open core. This falls under my definition of official response.
Unfortunately, Nelson's criticisms had a very telling error.
"The Open Core (most notably SugarCRM) folks have a problem. They'd like to convince people that they can achieve the open source effect by having two versions of their code: an open source version, and a proprietary version," Nelson wrote.
The problem with this statement is that Nelson seems to be describing a dual-license business plan, not open core. SugarCRM, as has been indicated to me by SugarCRM CEO Larry Augustin, is not an open-core company. Nor is having an open source version and a proprietary version of an application the definition of open core. Open core describes a central open source product (the "core"), with proprietary add-ons.
This is a nuanced difference, but one I would expect the License Approval Chair of the OSI to understand, given the complexity of the dozens of licenses the OSI reviews and approves.
Luckily, OSI Assistant Treasurer and fellow Director Andrew Oliver has posted his own entry that directly addresses the issue of open core. In his "simple declaration," Oliver called it as he sees it.
"'Open Core' has NOTHING to do with 'Open Source'. Nearly all proprietary software, at this point, has various degrees of open source-licensed source code in its core," Oliver stated. "'Open Core' has none of the advantages of open source to the user and is merely a proprietary software company."
That's a pretty clear statement to me.
Actually, this is about the only kind of statement the OSI folks can make. There is nothing in open core that violates the open source license definition, so the most they can do is try to separate the notion of open core from open source and hope that people are paying attention to their warnings about the open core business model.
People may be re-thinking the open core model anyway. The other knock on open core this week may have come from a big open core customer.
This week, amid much hoopla, Rackspace announced the OpenStack infrastructure program. Rackspace is making the whole thing open source under the Apache 2 license, based on code from Rackspace and NASA.
NASA is no stranger to open source, of course, and when they were building their Nebula infrastructure cloud, NASA opted to work with Eucalyptus, the open core maker of cloud infrastructure software.
But it wasn't a smooth fit. In an interview with the Register, NASA Chief Technology Officer Chris Kemp, stated "that the scalability of the product and other issues with Eucalyptus (including the inability by NASA to get some of its enhancements into the Eucalyptus code base) compelled Kemp to take the entire Nebula team and dedicate it--for the past six months--to creating a new fabric controller, called Nova, from scratch."
Nova would eventually become a component withing the new OpenStack platform announced this week. NASA is currently still working with the Eucalyptus toolset, but plans to fully adopt the OpenStack moving forward.
That line about not getting its enhancements into Eucalyptus code base is interesting: according to Phipps, NASA's contributions were too close to the functionality of Eucalyptus' commercial add-ons, and were thus rejected.
If true, this reveals a pretty big flaw in the open core business plan. If you have customers who expect to play by open source rules with your open source product, you can't take your ball home when the game doesn't go your way. Smaller customers might fold under the pressure to buy the commercial add-ons, but larger customers with their own open source savvy like NASA will simply refuse to go along with it. In this case, it was even worse than not getting a paid customer: refusing NASA's code contributions led to what could be a nightmare scenario for Eucalyptus, the formation of a pure-play open source competitor.
Though I have concerns about the semantics of Nelson's arguments, he does make a good illustration that this will be what open core companies will have to contend with as they move forward: a "tightrope" between the world of open source and proprietary business models, where just the tiniest slip could lead to a big fall.