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!
Community experts also agree that the most important community building task is to create heroes within the community. The most effective way to do this is through dedicated community managers who go through a lengthy process to nurture and reward active community members.
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.
It is important to point out that role-based pricing does not mean charging administrators for the same thing that developers get for free. It means identifying services and functionality that are of particular value to administrators and charging for those add-ons.
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.
Enterprise development software has traditionally been delivered on site. In the future, it is very likely that corporations will at a minimum want an option to deploy applications on-site or on demand (a feature already supported by WaveMaker Software, among others).
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