I turned down offers from companies and investors to come in and "repeat the MySQL playbook" in Big Data or NoSQL or apps or whatever.  I think Open Source can be a fantastic development approach and it provides good commercial possibilities when done at scale, but I also felt that it was time to do something new.  And as important as Open Source has been in powering the last ten years of Internet companies, I felt that there was an even bigger force that would play out over the next ten years: namely the cloud.  

While some are quick to dismiss the cloud as a new buzzword for an approach that's been around for a while, I think that's missing the forest for the trees.  I believe the transition to Software-as-a-Service, Platform-as-a-Service, Infrasctructure-as-a-Service will be as profound as the introduction of the PC, client/server or even the browser.  In other words, this is a huge platform shift that will have profound effect on businesses and individuals.  It may take some years to play out, but from my perspective, cloud is where the excitement is.

When I joined Zendesk back in December it was already a strong business.  The founders Mikkel, Alex, Morten had built a phenomenal business.  They got to over 7,000 customers worldwide without a sales team!  That's the kind of adoption that makes open source guys envious.  And I don't mean just free users; these are paying customers including the likes of Cloudera, DataStax, Dropbox, Groupon, Hulu, MSNBC, Neilsen, Rogers Communications, Rockstar games, SAP, SmugMug, Zappos Insights.  Equally importantly, the company has developed a customer-oriented culture.  Zendesk enables the fastest way to great customer service.  It's not just a motto, it's a way of life at Zendesk.  And we love our customers!

In the last six months, the company has delivered tremendous innovation and is now recognized as the leader in cloud-based help desk software.  Recent innovations include: integrations with Salesforce.com, SugarCRM and Atlassian JIRA, advanced reporting and analytics with GoodData, Twitter integration, mobile versions for iPad, iPhone, Android and Blackberry, and a new open API for sharing tickets.  The NetworkedHelpDesk API allows you to share support tickets across teams, organizations or applications with support from more than two dozen software companies.  

Zendesk now has more than 10,000 customers in more than 100 countries worldwide with revenues quadrupling last year.  The company also has funding from Benchmark capital, Matrix Partners and Charles River Ventures enabling us to develop a deep bench of technical talent and a superb management team.

I'm tremendously proud of what we've been able to do over the last couple of quarters.  And I'm even more excited about all the innovations planned in engineering over the next six months.  This is the most fun I've had since the early days of MySQL!  This is one heckuva exciting time to be in the software business.

read more

This is an analyst report, available for a price that would be completely unreasonable for a private person. I was pondering whether I should go begging for a free copy to satisfy my curiosity on the topic. But that wasn't necessary, as the next day I was offered a copy by Matthew Aslett himself:

read more

*Our latest CAOS Special Report – Control and Community
*Red Hat releases RHEL 6
*Symbian and Oracle highlight community challenges
*The latest on government adoption of OSS from GOSCON
*Open core issue continues, now with Linux and evil twins

iTunes or direct download (31:02, 8.5MB)

Godwin’s law states: “As an online discussion grows longer, the probability of a comparison involving Nazis or Hitler approaches”.

An online discussion about open source-related business strategies is no exception. However, long before the Nazi comparison it is inevitable that someone will ask “is MySQL open core?”.

I updated our 2009 post “what is open core, and what isn’t” recently, and received some criticism of my statement that the MySQL strategy was not open core.

Since we have recently published a report including the results of our analysis of the open source-related business strategies of 300 vendors and subsidiaries it seems appropriate that we use this opportunity to explain how we evaluate a company’s open source-related business strategy, and specifically how our analysis led us to conclude at the time of our analysis (August/September) that the open core licensing strategy did not apply to MySQL.

Given the recent changes to MySQL pricing and licensing we have also revisited our analysis, see below.

Looking at MySQL Enterprise it is easy to see why so many people conclude that the product licensing strategy being applied to MySQL is open core, since MySQL Enterprise contains extensions for which source code is not available that are not available with MySQL Community.

However, it is important to remember that products are not open core – and companies are not open core – but that open core is a product licensing strategy applied by companies to products. Therefore the question “is MySQL open core?” is inappropriate. A more appropriate question would be, “is the product licensing being used with MySQL open core?”

It is also worth noting that a product licensing strategy is just one of five elements that we at The 451 Group use to evaluate an open source-related business strategy.

The five elements we consider are: the software license for the open source software; the development model for the open source software; copyright ownership for the open source software code; the product licensing strategy; and the revenue generator. Specifically, with regards to MySQL, our evaluation went as follows:

Software license/development model/copyright ownership:
This was a relatively straightforward process for the MySQL business. The MySQL Database software is available under the GNU GPLv2, a strong copyleft license, and although the code is available at Launchpad, clearly the software continues to be developed in the cathedral model by a core group of developers, mostly employees of a vendor: Oracle. The same vendor also owns the copyright.

Product licensing strategy:
This is where things started to get a little bit difficult. Historically MySQL AB used the dual licensing strategy, making a version of MySQL Server available under a closed source license (aka selling exceptions) for enterprises. That strategy remains in use today to enable the use of MySQL embedded in closed source software. However, the version of MySQL Server in MySQL Enterprise was not closed source, and was the same GNU GPL version as MySQL Community. This provides a good example of why it is important to assess the licensing strategy, rather than the product: the open core licensing strategy uses dual licensing and adds closed source extensions to create a closed source version that is a superset of open source software (or from another perspective, an open source version that is a subset of closed source software). Since this description did not apply to MySQL Enterprise, which saw the open source MySQL Server delivered along with closed source extensions, we concluded that Oracle did not use an open core licensing strategy with regards to MySQL.

Revenue generator
The description of MySQL Enterprise, used above (open source software with additionally capabilities delivered via subscription) is exactly what we consider a value-added subscription revenue generator. There are often many ways in which a vendor generates revenue from open source software. MySQL is just such a case: Oracle generates revenue from closed source licenses embedded in closed source software, but the largest generator is the MySQL Enterprise value-added subscription.

Conclusion:
The MySQL strategy includes a strong copyleft software license, vendor-developed software using the cathedral model, and vendor-owned copyright. That much was easy. It was also easy to identify the dominant revenue generator, which was value-added subscription. That left the product licensing strategy, for which the choices were single open source (in MySQL Enterprise) and dual licensing (for embedded usage). To select single open source would be inaccurate since we could not ignore the fact that the MySQL business uses a dual licensing strategy.

MySQL Reconsidered:
In the light of the recent licensing and pricing changes for MySQL we took the opportunity to talk to Oracle about the licensing of MySQL. What we discovered was that whereas the MySQL Database previously accompanied by the MySQL Enterprise subscription was licensed using the GNU GPL, Oracle now prefers that Standard Edition and Enterprise Edition customers enter into a commercial license agreement with the company (although they will apparently be able to negotiate subscription usage with MySQL Community). This is a licensing agreement that does not impact the functionality or code of the MySQL Database itself, although clearly there continues to be additional functionality delivered with the MySQL Standard and Enterprise subscriptions, such as MySQL Enterprise Monitor and MySQL Enterprise Backup.

This changes our perspective of the MySQL-related strategy on two levels, Firstly, with regard to the revenue generator, we can now conclude that going forward the biggest revenue generator for Oracle from MySQL will be closed source licenses. While this closed source software will still be delivered via a subscription agreement, our support subscription and value-added subscription categories are reserved for products that use an open source license. It also changes our perspective on the product licensing strategy. Specifically in that our description of open core used above, (dual licensing + closed source extensions to create a closed source version that is a superset of open source software) does now apply to MySQL Standard and MySQL Enterprise.

Godwin’s law states: “As an online discussion grows longer, the probability of a comparison involving Nazis or Hitler approaches”.

An online discussion about open source-related business strategies is no exception. However, long before the Nazi comparison it is inevitable that someone will ask “is MySQL open core?”.

I updated our 2009 post “what is open core, and what isn’t” recently, and received some criticism of my statement that the MySQL strategy was not open core.

Since we have recently published a report including the results of our analysis of the open source-related business strategies of 300 vendors and subsidiaries it seems appropriate that we use this opportunity to explain how we evaluate a company’s open source-related business strategy, and specifically how our analysis led us to conclude at the time of our analysis (August/September) that the open core licensing strategy did not apply to MySQL.

Given the recent changes to MySQL pricing and licensing we have also revisited our analysis, see below.

Looking at MySQL Enterprise it is easy to see why so many people conclude that the product licensing strategy being applied to MySQL is open core, since MySQL Enterprise contains extensions for which source code is not available that are not available with MySQL Community.

However, it is important to remember that products are not open core – and companies are not open core – but that open core is a product licensing strategy applied by companies to products. Therefore the question “is MySQL open core?” is inappropriate. A more appropriate question would be, “is the product licensing being used with MySQL open core?”

It is also worth noting that a product licensing strategy is just one of five elements that we at The 451 Group use to evaluate an open source-related business strategy.

The five elements we consider are: the software license for the open source software; the development model for the open source software; copyright ownership for the open source software code; the product licensing strategy; and the revenue generator. Specifically, with regards to MySQL, our evaluation went as follows:

Software license/development model/copyright ownership:
This was a relatively straightforward process for the MySQL business. The MySQL Database software is available under the GNU GPLv2, a strong copyleft license, and although the code is available at Launchpad, clearly the software continues to be developed in the cathedral model by a core group of developers, mostly employees of a vendor: Oracle. The same vendor also owns the copyright.

Product licensing strategy:
This is where things started to get a little bit difficult. Historically MySQL AB used the dual licensing strategy, making a version of MySQL Server available under a closed source license (aka selling exceptions) for enterprises. That strategy remains in use today to enable the use of MySQL embedded in closed source software. However, the version of MySQL Server in MySQL Enterprise was not closed source, and was the same GNU GPL version as MySQL Community. This provides a good example of why it is important to assess the licensing strategy, rather than the product: the open core licensing strategy uses dual licensing and adds closed source extensions to create a closed source version that is a superset of open source software (or from another perspective, an open source version that is a subset of closed source software). Since this description did not apply to MySQL Enterprise, which saw the open source MySQL Server delivered along with closed source extensions, we concluded that Oracle did not use an open core licensing strategy with regards to MySQL.

Revenue generator
The description of MySQL Enterprise, used above (open source software with additionally capabilities delivered via subscription) is exactly what we consider a value-added subscription revenue generator. There are often many ways in which a vendor generates revenue from open source software. MySQL is just such a case: Oracle generates revenue from closed source licenses embedded in closed source software, but the largest generator is the MySQL Enterprise value-added subscription.

Conclusion:
The MySQL strategy includes a strong copyleft software license, vendor-developed software using the cathedral model, and vendor-owned copyright. That much was easy. It was also easy to identify the dominant revenue generator, which was value-added subscription. That left the product licensing strategy, for which the choices were single open source (in MySQL Enterprise) and dual licensing (for embedded usage). To select single open source would be inaccurate since we could not ignore the fact that the MySQL business uses a dual licensing strategy.

MySQL Reconsidered:
In the light of the recent licensing and pricing changes for MySQL we took the opportunity to talk to Oracle about the licensing of MySQL. What we discovered was that whereas the MySQL Database previously accompanied by the MySQL Enterprise subscription was licensed using the GNU GPL, Oracle now prefers that Standard Edition and Enterprise Edition customers enter into a commercial license agreement with the company (although they will apparently be able to negotiate subscription usage with MySQL Community). This is a licensing agreement that does not impact the functionality or code of the MySQL Database itself, although clearly there continues to be additional functionality delivered with the MySQL Standard and Enterprise subscriptions, such as MySQL Enterprise Monitor and MySQL Enterprise Backup.

This changes our perspective of the MySQL-related strategy on two levels, Firstly, with regard to the revenue generator, we can now conclude that going forward the biggest revenue generator for Oracle from MySQL will be closed source licenses. While this closed source software will still be delivered via a subscription agreement, our support subscription and value-added subscription categories are reserved for products that use an open source license. It also changes our perspective on the product licensing strategy. Specifically in that our description of open core used above, (dual licensing + closed source extensions to create a closed source version that is a superset of open source software) does now apply to MySQL Standard and MySQL Enterprise.

Community Rights and Community Wrongs
The Launch of the Document Foundation and the Oxymoron of Corporate Controlled "Community" Projects

Andy Updegrove makes observations of the trend in hosting Open Source projects in non-profit foundations rather than one company, much boosted by Oracle's acquisition and abandonment of Sun's software assets.

Knowing that an organization is “safe” to join, and will be managed for the benefit of the many and not of the privileged few, is one of the key attributes and assurances of “openness.”

read more

There has been a significant amount of interest in the open core licensing strategy since Andrew Lampitt articulated it and its benefits for combining open source and closed source licensing.

There remains considerable confusion about exactly what the open core licensing strategy is, however, which is strange since the term arrived fully packaged with a specific definition, courtesy of Andrew. Recently I have begun to wonder whether many of the people that use the term open core regularly have even read Andrew’s post.

I feel somewhat responsible for this given that our Open Source is Not a Business Model report was partly responsible for the increased use of the term open core, and since I remembered that it was this post about commercial open source strategies that prompted Andrew to define open core in the first place.

Additionally, since business models related to open source are evolving constantly, I thought it was worth revisiting the definition of open core and putting it in some context.

What is open core?
According to Andrew’s original post it is a licensing strategy whereby a vendor combines proprietary code with open source code, where “the commercial license is a super-set of the open source product, i.e., it offers premium product features that you will not see in the GPL license”.

At first Andrew was very specific about the use of the GPL license and a development model dominated by a single vendor. However, it quickly became clear that a company like EnterpriseDB, which provides proprietary extensions on top of the community-developed, BSD-licensed PostgreSQL database, also fits the general model.

Therefore, Andrew clarified that there were Vendor Controlled (VC) and Community Controlled (CC) variants on open core.

Incidentally, Andrew did not create the open core strategy. As he himself admitted, he “invented nothing, just articulated it”. Credit goes to Barry Klawans and Paul Doscher (Jaspersoft co-founders), as Andrew noted.

In fact our research indicates that the formation of companies using the open core licensing strategy had already peaked by the time the term was coined – but more on that another day.

What isn’t open core
Sometimes it is easier to define what something is by explaining what it isn’t. Open core is a commercial open source strategy, but just as “all of Alma Cogan is dead, but only some of the class of dead people are Alma Cogan”, not all commercial open source strategies are open core (and more specifically, given recent statements, not all strategies that involve copyright agreements are open core – more on that another day as well.

So, to clear up some apparent confusion:

• Red Hat’s strategy is not open core

Red Hat reserves support and features for paying customers, but it does not do so using closed source licensing (a prerequisite of open core). Instead Red Hat gives away the source code but withholds the compiled, binary version for paying customers.

(N.B. Beware companies claiming to be following “The Red Hat model” as they invariably aren’t – most often I find they mean that they use a subscription revenue model. Very few companies have copied Red Hat’s model for a variety of reasons – a subject I’ll leave for another post.)

• Dual licensing is not open core

In fact, as Andrew Lampitt explained in his definition, open core is a variant of dual licensing (or proprietary relicesing, as some like to call it, or indeed “selling exceptions”). The important thing to note is that in the dual license strategy a single code base is available under an open source or closed license, while with open core the closed source licensed code is a superset of the open source code. Both result in closed source software, but only in the open core strategy is the closed source version functionally different from the open source version.

• The MySQL strategy is not open core (yet)

One of the reasons for the confusion is that MySQL originally started out with a dual license model but changed over time to the subscription revenue model, and flirted with open core. At this point the strategy for MySQL remains dual licensing. It remains to be seen whether the MySQL Server code for Enterprise Edition 5.5 will be different from Community Edition with the inclusion of MySQL Enterprise Backup (which would make it open core) or if the new capabilities will be delivered as a subscription service.

• Subscription strategies are not open core

Although they are a step in that direction. The subscription model provides vendors with a mechanism to distribute value-added features to paying customers. Until now the additional capabilities in MySQL Enterprise (such as Enterprise Monitor) have been delivered as a service via the MySQL Enterprise subscription. Although the code for Enterprise Monitor has not been made available, we would see this strategy as distinct from open core since open core results in a product with a different code base, where as the MySQL Server code in Enterprise and Community is the same. To differentiate from regular support subscriptions I have used the term value-added subscription to refer to this type of subscription. Other examples include Canonical’s Ubuntu Advantage and Nuxeo’s Connect. I would also put Red Hat Network and JBoss Operations Network in this category, although the source code for those value-added services was originally closed, it has now been made available as open source (as previously discussed).

• Open foundation is not open core

Vendors such as IBM, Cisco, Oracle and SAP (in fact just about every software vendor) include open source code within larger closed source software packages and hardware products. There is a fine line between the two, but as I previously explained while open core involves offering proprietary extensions targeted at a segment of the open source project user base, open foundation involves using open source software to create entirely new products, targeted at a different user base.

• Microsoft’s open source strategy is not open core

Microsoft is undoubtedly making use of more open source and encouraging open source development on its platforms, but its strategy is by definition not open core since it is extremely unlikely the core will ever be open source. In fact, as previously discussed, Microsoft’s strategy turns the open core strategy on its head by encouraging open source development around a commercial core, and has been described by Microsoft as open edge, and by Andrew Lampitt (more amusingly) as open crust. We have adopted the term open edge to describe this strategy and have seen it adopted by a small number of players beyond Microsoft.

In Microsoft 2009 published its first companywide perspective on open source, made its first contributions to the Linux kernel, and created the CodePlex Foundation, an independent entity designed to encourage its developers and other companies to contribute more to open source software projects.

Doubts have remained about Microsoft’s ongoing commitment, however, with the company being labeled opportunistic in its approach to open source, and skepticism persists – particularly in relation to software patents. We have recently published a new Open Source Strategy Spotlight report, which updates our perspective on Microsoft’s relationship with open source in the light of recent organizational changes.

One of the interesting aspects highlighted by our research for this report is the role of the Open Source Technology Center (OSTC), which consists of the Open Source Software Lab in Redmond, Washington, and the Microsoft/Novell Interoperability Lab in Cambridge, Massachusetts.

Once a part of the Windows server marketing group, the OSTC has been shifted to Windows server engineering, and now contributes directly to interoperability efforts in the development and testing of Microsoft’s platform products, including Windows and Azure.

As such, OSTC is part of the planning team for the next version of Windows Server, ensuring that interoperability principles are embedded into the next generation of the company’s operating system before a single line of code is written.

While this is not the commitment to wider open source development that I know some people would like to see from Microsoft it does signal a significant shift in Microsoft’s development effort that interoperability with open source is front and center of the development of Windows 8.

The report puts the organisational changes around interoperability in context, as well as assessing the drivers behind Microsoft’s engagement with open source (business, technological and government-mandated) and the participation in and contribution to open source projects.

The report is available here to existing 451 Group clients, while non-clients can also apply for trial access.

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.