With the success of companies like MySQL, JBoss, Cygnus and SleepyCat, open source software has introduced major changes to the way corporate IT adopts new technology. Yet open source business practices have a long way to go before the industry as a whole is fully embraced by CIOs.At the Open Source Think Tank, a panel of ten CIOs declared that the patchwork quilt of licenses and business practices among open-source vendors is a major barrier to enterprise adoption of open source. CIOS believe that vendor standardization on a simple and commercially attractive business model will help drive broad corporate acceptance of open source software.
After attending the Open Source Think Tank held in February, 2008 at the Silverado resort, I am convinced that a best-practices model is emerging for enterprise open-source software vendors. In honor of the think tank event, I am dubbing these practices the Silverado Rules for Open Source Success:
The Silverado Rules for Open Source Success
Open-source vendors should adopt the following best practices to optimize community participation while developing a viable commercial business:1. Fix the last mile problem
2. Optimize for community and commercial growth
3. Play by the community rules
4. Implement role-based pricing
5. Enable on-site and on-demand deployment
6. Adopt a dual license strategy based on GPL + Commercial License
Following these rules may not lead to guaranteed business success, but ignoring them may well lead to failure!
Please feel free to enter comments and criticisms on my blog.
Fix the "last mile" problem
Open Source Software (OSS) communities are outstanding at solving hard framework problems, but not so good at producing user-friendly solutions. Once the community has solved the hard problem, it tends to lose interest in solving more mundane problems like documentation, management and monitoring.CIOs need open-source vendors to be more like commercial vendors in "putting a bow on the package. Corporate users are looking for open source products to have commercial-grade documentation, usability, installation and support.
Optimize for commercial and community growth
The first generation of open source companies were project-driven. Companies like MySQL, JBoss and SleepyCat created large communities and then struggled to evolve business models that commercialized that community. Often, they faced significant resistance from early community members, particularly on introducing more restrictive licenses that forced users to pay for things they had previously gotten for free.The newer, second generation of open source companies is following the opposite process. Venture-backed companies like Alfresco, Mindtouch and Wavemaker started with a commercial focus and are now working to create vibrant communities.
These second generation OSS companies have a completely different set of challenges than the first generation. They have much more control over intellectual property and choice of licensing, but much more work to do on the community-building side.
Open source companies should see themselves as part of a larger supply chain, determine how to add upstream and downstream value. At WaveMaker, we are a major consumer of open source - our product is based on Spring, Hibernate, Json, Dojo.
We get value from their communities and in turn we add value to their communities by providing an open source framework for visual AJAX web development. Our goal is to broaden the overall size of all of our communities by democratizing the development web applications - essentially an open-source version of Visual Basic.
Play by the community rules
Communities are the life-blood of open source companies. Yet the process of creating a community is still more of a black art than science. Experts in community have developed a simple set of three rules for building successful community:- Set the rules early: spell out the role of the community in developing, extending and supporting the product. For example, define the ideal participants of the community, and the benefits they would expect to receive to entice them into membership in the community.
- Play by the rules: once companies set the rules for the community, they should enforce those rules scrupulously, through active community management. Hell hath no fury like an open-source community member scorned!
- Don't change the rules: as the business of the company evolves, there will be pressure to change how the community operates. For example, companies may decide that they want to take more support business from the community. Not a good idea - see rule #2!
Implement role-based pricing
I have written before that David Skok feels the success of JBoss lay in their ability to give developers a free product while charging commercial IT operations for support and management tools. CEOs of open-source enterprise software companies believe that a key element of any enterprise open-source company is realizing that there are no scalable dollars in selling to developers.The role-based pricing approach can be summarized as follows:
- Developer use open source tools for free: making a product free for developers creates a "frictionless" entry path for new technology into an organization. Small scale, "under the desktop" deployments are also free, making it easy for IT architects to prove out a technology with small pilot projects. Developers should be able to use all the development capabilities of the product without restrictions (everyone hates crippleware!)
- Administrators pay for commercial support: when a project built with an open source tool is deployed into a business-critical environment, operations people will require commercial-grade support, including updates, patches and upgrades. Operations roles will also value management and monitoring capabilities that enhance the security, reliability and performance of the deployed application.
The revenue opportunities in enterprise open source lie in selling support and value-added functionality for operations and production. Free development tools are the on-ramp to production revenue. This also ties the vendor's success to the successful deployment of the customer - the ultimate win-win for enterprise software.
Enable on-site and on-demand deployment
Moving forward, it is likely that the open source world will continue to migrate towards on-demand offerings, even for enterprise development platforms. Software as a service (SaaS) pricing is easier for business applications like Sugar CRM, but it will increasingly make sense for infrastructure software as well.There are three drivers for this movement:
- Low start-up cost for customer: with nothing to deploy on site, customer adoption is as easy as creating an online login.
- Higher rate of conversion to paying customers: for vendors, SaaS customers often convert more quickly paying customers, a big improvement over the single digit conversion rates more common to traditional open-source communities.
- Business model fit: subscription payments for on-demand services fit naturally with the existing open-source subscription licensing model.
Adopt a dual license strategy
Over the last ten years, the open-source community has matured greatly. Although the GPL remains the most popular open source license (~70% of open source projects use GPL, according to Freshmeat), the most commonly used version was released in 1991. Much has changed since then, and to reflect these changes, the new Gnu Public License (GPL) v3 offers- among other things - greater compatibility with the Apache license while ensuring that open source contributors receive public acknowledgement for their contributions.There are a number of other popular open source licenses, each with its strengths and drawbacks. For example, Apache allows big companies to "expropriate" the work of smaller open-source companies without even acknowledging that contribution, making many open-source startups are leary of adopting the Apache license.
In addition, traditional licenses like GPL v2 and Apache do not provide explicitly for SaaS distribution. To get SaaS companies to participate in the open source movement, the best solution today is to adopt the newer GPL v3 license with the Affero extension for SaaS usage.
The combination of GPL v3 with the Affero extension is new, but seems to have momentum. I spoke with a dozen CEOs at the Open Source Think Tank conference who indicated that they would be adopting this license over the next year.
WaveMaker Case Study
WaveMaker is an open-source framework for visual AJAX web development. WaveMaker uses drag and drop assembly to create database-driven web applications. WaveMaker applications are pure Java WAR files based on standard open-source components, including Spring, Hibernate, JSON and Dojo.WaveMaker Software has adopted a dual-license model: open source users are free to use the GPL license; while commercial users who want support can use the subscription-based license. This allows WaveMaker faces to build a vibrant open-source community while simultaneously establishing a viable commercial business.
The WaveMaker download is available here.
Summary
For new open-source companies who do not have an existing user community, there is a great deal of flexibility in setting up the licensing model. For these companies, a dual license model along the lines pioneered by companies like MySQL, JBoss and SleepyCat is emerging as the standard business model.I take full responsibility for any bad ideas in this document, but I also want to acknowledge the contributions of the following people who helped me evolve my thinking: Larry Augustin, Brian Gentile of Jaspersoft, Clint Oram of SugarCRM, Neelan Choksi of SpringSource and Raven Zachary of the 451 Group
4 comments:
Great blog posting! I found myself however disagreeing with a number of statements. :-)
Here we go:
* You say "the industry as a whole" but I happen to think that "open source" is not an industry, but a production and distribution method.
My analogy is IKEA. They have an innovative production model and they have an innovative distribution model - both of which give them better quality AND lower costs. Just like open source. But they are still categorised as a furniture company.
Events like the think tank exist because we are still innovating around production and distribution, but not (in my mind) because we would be an industry. LinuxWorld, as an example, used to be a highly popular event, but today it seems like it is shrinking, because open source vendors go to industry-specific events (like 3GSM) rather than to production-method-specific events.
* You talk about "patchwork quilt of licenses and business practices" as a barrier to enterprise adoption. Perhaps it is so, because any new scheme will feel foreign to start with. It took time for DELL to gain acceptance among enterprises as well. But I think it is not the multitude of licences and business practices that is the barrier, but just the fact that all of them are new to CIOs. Even if we could all agree on just one licence and one business practice, I bet CIOs would still hesitate essentially as much as today.
1. Fix the last mile problem" - is that really the problem? I am not sure. Many open source products initially gained acceptance because they were so fantastically easy to take into use. It didn't have all featuers, but it had ease of
use.
2. Optimize for community and commercial growth" - again I am not sure I agree with your logic. As for terminology conventions, I have usually put JBoss, Zend and us in the category of "second generation" with Linux, Red Hat, Apache, old Covalent and such in the category of "first generation". So I would call WaveMaker et co. "third generation. But that's of course just a terminology question.
3. Play by the community rules" - I continue to disagree. :-)
I wholeheartedly agree with "Set the rules early". But I also think that we should *serve* the community but not necessarily *please* it. And I think "community" is as homogeneous as "India" - i.e. not at all. For that reason, I don't see a unified set of community rules, and I don't see how you can succeed without upsetting some sub-section of the community. When you meet resistance somewhere, it may on the contrary be a sign of popularity so immense that some small group is just bound to be upset.
"Don't change the rules" - well, I would say nearly the opposite: "Have courage to experiment, because no one gets it right on the first attempt."
"the most important community building task is to create heroes within the community" - perhaps. It is an important task. But my experience is that the most important task is to be open to input from everyone, and to give recognition for whatever input you receive. In essence, to be a masterful listener.
I very much agree that "the process of creating a community is still more of a black art than science".
4. Implement role-based pricing" - Yep, I agree. I would add as a vital observation that organisations may include a multitude of roles, and an individual holding one role today may hold another one tomorrow.
They way I describe it is that some people are ready to spend time to save money. Others are ready to spend money to save time. That's in my experience the main distinction between community and commercial customers. Relatively few people and organisations go from one to the other, and most never do.
5. Enable on-site and on-demand deployment" - Yep, but I would say that this is a generic observation that is true for all software companies today. Some years from now, we may have so much on-demand business that it is an exception to provide on-site as well.
6. Adopt a dual license strategy based on AGPL (GPLv3 + affero)" - I can agree that AGPL is an interesting licence, and it may well be the licence of choice in the future.
At the same time, we are moving towards a model where as little as possible is dependent on the licence. This goes back to the fearful CIOs. We don't want to upset them with licensing intricacies, so instead we try to build a simple model that shows what extra value they get if they pay.
In summary, it seems to me that you have made a good choice of licensing and business model for WaveMaker, but I somehow felt that your Silverado rules were not a 1-to-1 framework for how you built your own model.
Wow! That's a great response. Here are my comments:
Open Source Industry
I agree that we are not a vertical industry like IKEA, but we are a "temporary" horizontal industry in the sense that we share an open-source business model, much like the e-commerce vendors in the late 90s. I agree with you that once the open source business model is more accepted, this distinction will go away, just as it did once e-commerce became mainstream.
Patchwork Quilt
I think the licenses are less confusing to the CIO than the different business practices. With every company, the CIO must parse out what they are going to have to pay for and when. Again you are right that much of this hesitation has to do with newness as well.
Fix the Last Mile
Ease of use is really only one part of this problem. I think the point here is that because open source projects tend to bootstrap their functionality, they usually have only a fraction of the "completeness" of their commercial competitors.
Optimize for Community and Commercial
The optimization really means constantly adjusting the value proposition so that the community is a strong as possible while also enabling a sound commercial value. Changing licensing and pricing strategies are good examples of this.
Play by Community Rules
Here I think I was unclear. I agree with you that experimentation is the key to success with any entrepreneurial endeavor. The rule changes that are damaging are when the company "takes over" part of the community value chain. For example, there may be an incentive for the company to bring more prof svcs work in house at the expense of the community. So really what I should say is "don't change the rules in a way which penalizes the community users for their contributions."
Role-Based Licensing
I like your distinction of people who have more time than money. I think I'll steal it (with attribution of course, GPL not APL ;-)
Adopt a dual source license
AGPL makes sense for companies starting from scratch today. For companies with other licenses, it is probably harder to get to.
- chris
Some comments on your article;
Fix the "last mile" problem; I agree that we need to put the ribbion on the box, the documentation, management and monitoring are critical to the sucess of all projects regardless of the licencing model. In my experiance many opensorce projetcs are outstanding in this area ubuntu, mozilla, redhat, susi, smeserver all spring to mind, but sucess is all about selling the sizzle not the saussage.
Optimize for commercial and community growth; any model that reuirqers you to pay for what you used to be for free is destined to have a high failure rate (marraiage is a good example). At best paying for something that used to be for free leaves you with the feeling of being ripped off. In our free market economies we are prepared to pay for something new, somwthing extra, the promise something better even if it is just something preityer. but we won't pay (happily) for something that we once enjoyed for free. As you say later in your coments it is all about the value add! Of couse anyone with cokeacola shares will think we are wrong, they are happily making millions selling us plebs water that has always been delivered free from the sky.
Set the rules early; I agree
Don't change the rules: I agree
Implement role-based pricing; I agree with this precurser; distributing software is a bit like distributing smack/heroin, give em plenty of free dope early, then lots of cheep dope, right up until they are hooked & then you can really charge them.... this is the business model of drug lord worldwide & it is possibly even the business moddle of some very large software companies. Yes once the admins are hooked on the junk, they will pay for support!
Enable on-site and on-demand deployment; I agree
Adopt a dual license strategy- I'm not qulified to coment other than to say licencing needs to be simple to understand, the code freely avilabe & able to be modified & the propritors need to be able to feed their kids without being screwed by big players.
Again i'm not qualified comment but the WaveMaker model does sound worth of consideration.
@anon
"Last Mile" problem: this is both a sizzle and a steak issue. You have to have great out of box experience (sizzle) as well as real depth in tutorials, docs, usability (steak).
"Optimize for community/commercial growth": the point here is to avoid making people pay for something they can otherwise get for free. Instead, make it possible to succeed with the free model but make it faster/safer to succeed with the commercial model. Marten Mickos calls this differentiating based on how people value there time. If you value time more than money, you should get a subscription. If you have lots of time and little money, you should be able to do anything you want with the open source version.
Post a Comment