The Bug in OSI Approved Licenses
Updated below. Updated again.
There’s been some conflict regarding commercial open source, aka the SugarCRM model, and whether it is truly open source. Last month, Michael Tiemann, President of the Open Source Initiative, said on his blog:
…THESE LICENSES [SugarCRM, SplendidCRM, Centric] ARE NOT OPEN SOURCE LICENSES. This flagrant abuse of labeling is not unlike sweetening a mild abrasive with ethylene glycol and calling the substance Toothpaste. If the market is clamouring for open source CRM solutions, why are some companies delivering open source in name only and not in substance? I think the answer is simple: they think they can get away with it.
I don’t think it’s fair to say that these companies are just trying to get away with something, but I’ll let that go for now. Tiemann continues with a call to action:
So here’s what I propose: let’s all agree–vendors, press, analysts, and others who identify themselves as community members–to use the term ‘open source’ to refer to software licensed under an OSI-approved license. If no company can be successful by selling a CRM solution licensed under an OSI-approved license, then OSI (and the open source movement) should take the heat for promoting a model that is not sustainable in a free market economy. We can treat that case as a bug, and together we can work (with many eyes) to discern what it is about the existing open source definition or open source licenses made CRM a failure when so many other applications are flourishing.
So fair enough. Let’s take the many “open source-lite” companies like SugarCRM and ask why they (and their VCs) feel a pure OSI-approved license won’t work for them as it has for Red Hat, mySQL, Apache and so many others.
The first “bug”, if you will, in the OSI approved model is that it doesn’t reflect in any way the natural lifecycle of application development. Getting from release 0.0 to 1.0 requires a significant capital outlay, much more so than to get from release 1.0 to 2.0. There are several reasons for this. First, building on top of and refining a stable, working application, as OpenOffice has done for example, is far less work than creating a stable, working application to start with. Developing the initial application architecture and getting it to the point that it can be used by a naive end-user is a huge step. Secondly, this initial development has to be done in the absence of any paying customers, so none of the effort can be funded out of revenues. And lastly, it is much harder to get community participation in a fledgling project, especially when it is not an application that hackers have any use for themselves. Community contributors typically scratch their own itches, and not many of them have a CRM itch.
Compare SugarCRM’s situation with a typical mature open source project. More often than not, successful open source projects were building on top of an existing and fairly large code base. These code bases were made available under varying circumstances: Linux reached version 1.0 through academic interest and participation, and OpenOffice was the commercially failed StarOffice system donated by Sun, just as Firefox inherited the (albeit ugly) code base from Netscape. Regardless of how the initial code bases were open-sourced, they allowed the project to start with a stable release and to avoid the big upfront capital outlays required to get there.
SendMail, Apache, mySQL Samba and Linux are all applications hackers use themselves, and they therefore have an incentive to help extend them to meet their own needs. Corporate contributors like Red Hat, IBM and Novell have huge, strategic stakes in seeing Linux stacks succeed, so they are willing to pay the salaries of community developers, and to fund organization such as the Linux Foundation. But individual and corporate contributors have no such stake in the success of open source end-user applications. Without them, development all falls to the start-up itself.
Given the size of the required capital outlay, and the lack of corporate funding, start-up open source companies have to rely on private capital, particularly VCs. The VCs invest for only one reason: so that their equity position will grow and become liquid so they can exit in seven years. We can decry VCs for being short-sighted capitalists (although I certainly wouldn’t) but the fact is they are the only source for capital for start-ups, and so they get to set the terms under which they will agree to invest. Don’t like VCs? Find someone else willing to invest $20 million in a software start-up.
The fact that these CRM start-ups have elected to go with a hybrid open source/proprietary licensing scheme demonstrates that OSI-approved licenses would not provide the financial results they (or their VCs) require. Given that customers and the open source community would, to some extent, prefer to license software under an OSI-approved license, there must be a reason these companies have chosen a different license. I can only assume they have determined that an OSI license would not allow them to generate the revenue required to obtain financing for the application’s initial development.
Once a stable, usable version of an end-user application has been released and achieved some measure of market acceptance, this picture changes however. Customer IT departments and third party software vendors now have an incentive to develop extensions to the initial release and contribute them back to the project. Even individual hackers would find it far more enticing to contribute.
While initial revenues would be consumed just to grow the software start-up to keep pace with demand, eventually revenues will turn into net income and market value. Through the maturing of the application and the contribution of community members, the investment required by the software company itself drops. It’s at this point that the VCs are able to exit, and the public equity markets are able to meet any ongoing needs for capital.
In a competitive market, an OSI-approved license would not only be feasible for a maturing project, but most likely required for the sponsoring software company to maintain market leadership. Customer and community members would be able to demand a more open licensing scheme, where they weren’t able to before. In this maturing phase, the software start-up would become what we all recognize as a true open source software company.
The “bug” in the OSI licensing model is that it does not account for this lifecycle view of software development, and does not provide a viable way for start-ups, particularly start-ups developing end-user applications without an existing code based to build upon, to attract the capital required to reach maturity. I would like to see the OSI talk to start-ups and VCs and find a way to accommodate the needs of start-ups. My concern is that, if they stick to their current stance, the current wave of software start-ups will end up reinforcing the view that open source is not economically viable for end-user applications, but only applies to commodity OSes and middleware.
Update: Events have put a lie to much of my thesis here. SugarCRM has announced they will be adopting GPLv3 for the community edition of their CRM software. They will still have a two-tiered licensing system (well, actually, three-tiered), with paying customers getting a richer, more functional application than the GPLed application. Perhaps that’s the important monetizing strategy here, not whether the community version is released under GPL vs. a Mozilla type license.
What’s interesting is that the change is attributed to pressure from customers. Although I assume we’re talking about customers of the free (as in beer) community edition, not the paying customers of the fuller versions, since they won’t be affected by this change. Makes me think it’s really because good standing in the eyes of the broader open source community really does matter to SugarCRM, and they see this as a small price to pay.
Regardless, the OSI and Michael Tiemann have won the battle — congrats!
Update 2: What’s more, Microsoft is now jumping on the OSI bandwagon:
Microsoft will submit its Shared Source licenses to the Open Source Initiative for review and approval as open-source licenses.
Bill Hilf, general manager of platform strategy at Microsoft, used his keynote address at the annual O’Reilly Open Source Conference in Portland, Ore. on July 26 to discuss Microsoft’s evolving open-source strategy.
As part of that, he highlighted a new Microsoft Web site designed to provide additional transparency into the company’s position on open source, and announced the company’s intent to submit its Shared Source licenses to the OSI for approval.
“Microsoft and the OSI are currently in active discussion on this and additional details will be made available in the coming weeks,” Hilf said.
A Microsoft spokesperson declined to give any additional specifics and, when asked what had changed to make this the right time for Microsoft to seek open-source approval for its licenses, the spokesperson would only say that “things continue to evolve when it comes to open source at Microsoft.”
(Emphasis mine.)
I’ll say.
I don’t see the relevance of the facts you’ve presented to the need to keep source proprietary. You have certainly not spelled it out. You enumerate problems that exist for startups quite independently of source licensing. And the traditional fears about theft of product exist independently of the distinctions you have made. When it comes to the actual substance, all you say is “I can only assume they have determined that an OSI license would not allow them to generate the revenue required to obtain financing for the application’s initial development.” But that’s the very case you need to make to be saying anything of interest.
Jim -
Economists often assume that when one company does something, it’s just a random decision, but when an entire industry, or segment of an industry is doing something, especially when it’s in a competitive market, that there is an economic force at work driving them all to that decision. Of course a sample size of three (SugarCRM, SplendidCRM and Centric) is a pretty weak data set, so you have a point. But my assumption isn’t that much of a leap either.
I don’t see any “bug”, honestly, besides OSI’s approval process trasparency. You say that
. But getting from release 0.0 to 1.0 is not a license issue, and all “pretending to be” CRM Open Source licenses were just addressing, or at least trying to, the attribution issue (Vtiger CRM is the risk SugarCRM wanted to countermeasure).
In other words, I agree with you that in the application arena it is tough to get external contributions, especially at the very beginning, but it is a VC problem, not an OSI one.
VCs could start thinking differently, and eventually financing only start-ups able to manage technological clubs, i.e. communities of firms, a non trivial skill, indeed.