Jul
13
Written by:
Stephen
7/13/2010 8:57 PM
The past few weeks have seen a resurgence in the debate over whether or not open core is a valid open source business model or not. There has been a lot of passionate and pragmatic discourse from lots of knowledgeable people (Phipps, Ingo, Mickos, Aker, Aslett, Proffitt, O'Grady).
I believe part of the confusion is between the FOSS projects with their attendant communities, and products in the market that incorporate the project. One doesn't know when the governance discussion stops and the market discussion begins. Community development and governance are interesting edges around which to have the discussion.
- There are FOSS projects around which individuals and companies participate as equals (e.g. Linux, Apache). The economics of shared collaborative development are well understood and compelling regardless of the size of the participating organization (all the way down to the individual). Companies still happily include the project in their products and services (e.g. Red Hat, Novell, Google, and Nokia with Linux or IBM with Apache) but no single company defines nor controls the governance structure. The governance and ownership may be as formal as a foundation (e.g. Apache, Linux) or as informal as the project leader (e.g. all the scripting languages).
- There are FOSS projects that are owned and controlled by a single company in the marketplace (e.g. MySQL, Alfresco, SugarCRM) and who completely define the project's community governance. I think this is where much confusion reigns.
- Publishing software under a FOSS license provides one set of benefits to a company. N.B. I said publishing software — I haven't yet said what software.
- Developing a community requires an investment providing different benefits.
For a moment, let's talk about business. Customers buy solutions to problems. Typically they're buying time (possibly as expertise), convenience (ability to do something previously undone), security (the removal of risk), or some combination of the three. They will always pay for value. It's a simple economic decision based on how they use/exchange their own time and skills. It doesn't matter whether you're discussing individuals or corporations with staff and budgets. It's why markets form and as Drucker best observed: companies don't exist to make money, but to create markets — money is simply a yardstick for measuring success.
Software isn't what customers are buying. This is the old (but invaluable) observation from Theodore Levitt that "a customer didn't want to buy a 1/4 inch drill, they needed a 1/4 inch hole." Customers buy solutions. As Geoffrey Moore observed, the more complete a solution one appears to be, the more likely one is to succeed. It's the "whole product" idea he espoused. The solution the customer is buying means more to the customer than the "software". (This also explains why some customers are very unimpressed with all the hard work a vendor put into their next release — the new software release didn't solve a new problem or better solve the old one.) If you look at the sum of the costs of the parts a company sells providing a solution to a customer versus the sum of the revenues they receive, as long as they spend less than they earn they're profitable and different industries cluster around different margins.
FOSS projects make great buckets of technology out of which to assemble new solutions. As Christensen observed, disruptive business models come from companies that assemble off-the-shelf parts to satisfy new needs, that then evolve themselves into existing markets with very different margins.
No company, new or otherwise, lasts long if they treat their customers or channel badly or fail to execute on the making-more-than-they-spend equation. Bait-and-switch generally doesn't go down well. Customers complain. In an Internet age complaints have a way of travelling. Indeed there are lots of ways a company can fail in its execution.
So rather than having a discussion about whether open core is or isn't a good open source business model, let's talk about how the company runs it's FOSS community. Remember we're not discussing FOSS projects with external governance. We're discussing companies that (i.) promote FOSS, (ii.) build a community around their own FOSS project, and (iii.) use their own FOSS project as a basis of their product solution they sell to customers.
It's easy to judge if they publish a FOSS project. We have the free software definition and the open source definition. The software license either meets the definition and enables users around the project or not. That's the simple bit.
Let's talk about the FOSS community development. The company needs to invest to reap the benefits a community brings. I wrote at length (with pictures) on the differences between communities engaged with projects and customers engaged with products in early May. The simple idea that applies nicely to open core is that customers have money, community members have time but no money, and the community can't be "converted" in any simple way into customers. Communities are incredibly valuable. Communities bring innovation and real world usage, entrench a technology against competition, create experience and expertise (needed for the whole product), evangelism and advocacy (needed to get the word out), and provide a much needed litmus test for potential customers of your product. But community members must get a solution to their problems in community or there's no reason for them to participate. There are many ways a company can fail to develop a FOSS community:
- Some companies don't invest in community at all, taking an "if we publish it, they will come" attitude. They think curious downloads must be "leads" in "community" and try to chase them down. This is a failure to execute. At best it's an old school try-before-you-buy strategy and probably won't be particularly successful. It conflicts with the "we like FOSS" message. Throwing source code over the wall under a FOSS license without build and test harnesses and no binaries doesn't encourage clever programmers to share their ideas. No community forms to fall for a bait-and-switch. There is no community.
- If you don't provide a viable solution to your community that meets their needs, they won't participate. That's a failure to execute. It's not because you were practicing "open core", but rather your open core provided no value to attract a community.
- If you spend a lot of time "selling" your community, you'll upset them and they will leave. That's a failure to execute. Bait-and-switch will certainly destroy a company's reputation with its customers (i.e. people that paid money), but trying to sell people that don't want to be sold just upsets them. For everyone complaining about "open core" bait-and-switch tactics, I would respectfully ask you to name names of companies that sold you one thing, then provided you something else.
- If you dabble in open source, then close the project and essentially leave with the open source contributed work, you are angering the very people you want to get the word out and provide the experience around and entrench your technology. That's a failure to execute. Indeed to escape this perception, some companies have created and evolved external foundations (Eclipse, Mozilla, and the CodePlex Foundation are all variations on this theme) to get away from the perception of a land grab on externally contributed work, opting instead to share asset development in an externally governed organization to everyone's benefit.
- Of course one can always upset one's community badly enough that they fork the FOSS project and move on.
None of these failures to execute are because the company used an "open core" business model. These are all failures to understand the community's value versus its needs, how to develop a community, or what customers want and how to sell it to them in the Internet age. In the first case of externally governed FOSS projects described above, every participant is very clear on why they participate to their own selfish economic needs and why the collaboration is greater than the sum of its parts. In the second case, where a company publishes a FOSS project, develops the community and controls the governance, and then sells a product based on the FOSS project, the onus is very much on the company to clarify what's in it for the community and the role of FOSS licensing.