There was some rapid reaction to my post arguing why open core vendors should consider opening up their core code, either under a more permissive license than the GPL, or (and perhaps and) to an independent foundation.
The most interesting response, for me, came from Savio Rodrigues since he questioned whether the theory would work in reality. specifically Savio questioned whether commercial software vendors would join a community development project created by an established open core vendor. Using an example of a middleware vendor called ABC as the company giving up control Savio wrote:
“XYZ would not have the established user base or associated brand that ABC does; two key elements needed to sell the proprietary extensions. Also, since ABC has a head start on the proprietary extensions, and has likely chosen to develop higher value extensions first, XYZ has little opportunity to differentiate by delivering valuable proprietary extensions. It’s hard to envision the business case for XYZ to enter the community around ABC’s community edition project.”
This is a valid point, and clearly not all projects are going to be suitable for the transition I have suggested but I do think that Savio’s example is limited by an assumption that there is only one way to monetize an open source project. Consider another example involving a database vendor called – I don’t know – MyXYZ.
MyXYZ managed to create a new market opportunity with its open source database by differentiating from the established proprietary vendors. The company started off with a dual license model but once the open source version became ubiquitous shifted its strategy to providing additional features via a managed service to paying customers only, and has flirted with proprietary extensions. The company has continued to differentiate its database from proprietary rivals allowing an ecosystem of vendors to emerge building their own extensions to the core database products to take it into new areas not targeted by MyXYZ itself. At the same time the core open source database has become so ubiquitous that an ecosystem of support providers and consultants has also emerged. Because MyXYZ continues to dominate the development of the core database as well as its own extensions there is an amount of duplicated effort while the ecosystem around the core database has also begun to fragment based on frustration about the progress of the database under MyXYZ’s control (we will ignore for a moment the rumour that MyXYZ might even be acquired by a larger rival).
It would be better, I would argue, for MyXYZ to open up the process of contributing to the core database as this would avoid duplication of effort, and enable the database to evolve in response to the multiple interested parties. MyXYZ could continue to contribute to, and in all likelihood lead, the project, while focusing its development effort on the features that best suit its paying customers.
Now that’s an isolated example, clearly, and undoubtedly it’s a lot easier in theory than it is in practice but I believe in certain circumstances the opportunity to take the community route remains even after a vendor has established itself.
One of the issues I didn’t cover in my post is the impact such a shift would have on users of the open core version. I had intended to tackle that in a second post, but Carlo Daffara beat me to it with his explanation of why COMmunity+COMpany is a winning COMbination. Rather than repeat what Carlo had to say I shall simply point you in the direction of his post with the following excerpt:
“the current structure is not the most efficient to enable participation from outside groups- if you look at the various open core offerings, the majority of the code is developed from in-house developers, while on community-managed consortia the code may be originated by a single company, but is taken up by more entities… Having then a pure proprietary company that sells services or add-ons also removes any possibility of misunderstanding about what is offered to the customer.”
The issue of customer satisfaction was at the heart of Bradley M Kuhn’s response, which was entitled. “Open Core Is the New Shareware”. With regard to the title, I disagree that open core equals shareware. I agree, however, that open core done badly might equal shareware. Done properly open core enables a full and complete core open source project that is of value to its users, as well as proprietary extensions that are of value to users that are prepared to pay for additional features. If the core is “crippleware” then the strategy is wrong.
That said, Bradley makes some interesting points, including the suggestion that the current venture capital model is unsuited to monetizing open source. This is an issue I nearly deviated into in my previous post, and is a subject that we addressed in our report into VC investment for open source earlier this year. Arguably, though, is not unique to open source as the costs of starting up and running a company – whether it is based on open source or SaaS have dropped rapidly in recent years while the demands of VCs for levels of investment and returns have increased.
Bradley may well be right that “the best Free Software companies are the small ones, 5-10 employees, that do consulting work and license all their improvements back to a shared codebase” but his suggestion that this should be the vision of future monetization of FOSS is completely detached from commercial reality and would actually limit the adoption of free and open source software. Even if it were possible to somehow block proprietary and open core vendors from commercializing free and open source software the move would effectively isolate FOSS from making any further commercial impact.