"Free and open source software business won’t work unless you serve both those who spend time to save money and those who spend money to save time."
When software companies using free/libre open source software (F/LOSS) in their product and service offerings attempt to manage the customer pipeline and develop a community, problems may arise. Project communities and customer pipelines are not the same thing, although some participants belong to both groups. This creates confusion in the business and tension with the community.
F/LOSS communities have been on the rise for the past two decades. Companies began to form around F/LOSS projects in the early 1990s, with some creating their own F/LOSS projects and some wrapping themselves around existing projects. This has created tension between company managers who are trying to earn profits from software that is "available for free," and from developers in communities that do not necessarily want to create software for someone else's corporate gain. This happens regardless of whether the company created the F/LOSS-licensed project itself, or participates in external communities around other projects, or both.
This article demonstrates that separating the concepts of community and customer, and of project and product, allows a business to manage clearly both challenges of developing an engaged community and maximizing profits.
Before there was Internet-sized bandwidth on which to collaborate around software, the traditional software business looked something like Figure 1: research and development (R&D) delivered product, marketing delivered messages, sales and marketing managed and qualified leads through a pipeline, and, if the product solved a customer problem properly, a market was made and profits could be measured.
Figure 1. The Traditional Software Business Pipeline
The Internet dramatically removed friction from the process of collaborative software development and delivery. Developers could share the economic cost of software creation (innovation and construction). Large repositories of useful building blocks were created and made available through these project-focused communities. The World Wide Web accelerated this early Internet trend.
Companies began to form around projects. This unfortunately led to the idea of community and customer interaction akin to Figure 2. The community is jammed into the middle of the customer pipeline. The community gives to R&D, which still delivers product. Marketing now delivers messages to customers and (unfortunately) the community, and sales tries to "convert" the community into customers.
The misconception that the community can be converted into customers, or worse that they are a primary source of leads in an F/LOSS-enabled company, causes no end of problems for a company. The company's expectations are incorrectly set as they try to garner sales from a community that is not interested in buying. The company can easily put off the very community it wants to grow and lose the advantages a strong community brings. Perceived attempts to convert community users into paying customers has long been a source of friction with vendors that offer proprietary extensions. They have being accused of "bait and switch" practices or otherwise undermining the value of the open source software in an attempt to compel community users into becoming paying customers.
A company should recognize that, while they cannot sell to their community, this is an enormously helpful group of people who will anchor their business if supported properly. Even if a developer's employer has money to buy the software, internal bureaucracy and the need to persuade management can present a substantial barrier that developers are often keen to avoid. Instead, they may be quite happy to join the community and invest their time. This latter example is often lost on the management of the supplying company because they are convinced that they have a great product that meets the needs of this potential customer, who should be convinced to buy it. Alternatively, sales teams view this individual as a "lead" to improve their pipeline and reach financial decision-makers higher up the food chain. These tactics often alienate a potentially valuable community member.
Figure 2. Misconceptions of How Community and Customers Interact
Community and Customers
The conversion misconception began when MySQL AB observed in the early part of the past decade that they had a paying customer for every thousand downloads. This incorrectly set expectations in a fundamental way. People assumed causality between downloads in a community and customer conversions. It created false metrics designed to increase downloads and improve conversion rates.
While CEO at MySQL, Mårten Mickos observed that the early community has more time than money, while the later community has more money than time. He also realized that most of his customers were late community members and therefore have money, but little time. This is the start of a better model for understanding the relationship between community and customers. Using the "time vs. money" tipping point as the dividing line between community and customers forces the separation of the two groups. Treating the community (whose members have more time than money) as a completely separate entity from the customer pipeline (whose members have more money than time) allows a business to engage them differently using well-understood processes for community development and sales channel management to suit each group. Although the underlying time-money continuum suggests that it might be difficult to identify the tipping point, in reality these groups tend to polarize and are relatively easy to spot. For example, a large number of communities members may have time and no money and many customers may have money, but no time.
Based on this separation of community and customer, we propose a model for managing community and customer pipelines (Figure 3). In this model, the community members engage with R&D over the project. They engage with marketing in a conversation about project direction and ancillary activities, such as translations in other markets. Only customers are qualified through the pipeline based upon the product.
Figure 3. A Model for Managing Community and Customer Pipelines
Each group engages with the company according to its own selfish needs. While both groups seek solutions, community members look to the project to solve their problems, whereas customers look to the product to solve their problems. Community members build awareness, evangelize, provide expertise and trial support, demonstrate solution viability, and give inertia to the solution. Community members cannot be converted, but provide the litmus test of solution viability. On the customer side, leads are managed through the qualification pipeline and conversion process like any other customer-focused sales process. Figure 4 details the processes for managing community and customer pipelines with this model.
Although community members usually do not contribute money, they can contribute time. However, they will not waste time, so the project needs to solve a problem for them before they will invest themselves in it. The project should also consider what it would like community members to do, how to communicate this to the community, and how these contributions can be enabled.
Figure 4. Detailing the Processes for Community and Pipeline Management
Projects and Products
A useful first step in the process of separating the ideas of a company’s customers from a project’s community is to separate the idea of a F/LOSS project from the company’s product or service.
A project, regardless of whether it is run by a company, a foundation, or a collaborative community in the wild, is the keeper of the software. It consists of the software, the people developing it, and the F/LOSS license under which it is developed and distributed. The project solves a particular problem well, but may require a certain investment from its users to solve that problem, whether in its executable or source-code form. These users would rather spend their time than their money to get a solution and indeed they may have no money to spend in the particular circumstance. For developers, using the software in a F/LOSS project as a ready-made building block can provide extraordinary savings in time.
A product is something that is sold by a company to a customer to solve a problem. Money changes hands and, in that transaction, expectations are set. Products are more than simply the software. They may include the ease and convenience of bullet-proof installation, tutorials and documentation, services to install or configure the product, support, maintenance, upgrades, and all the other things in the product’s ecosystem. Customers would rather spend money than time for the solution; the time to reach the solution is also an important consideration.
For customers, product is clearly differentiated from project and community. How the product is differentiated depends upon the company and the value proposition to customers. At its simplest, the product may be a supported and maintained collection of software, certified to run on specific, supported platforms and with particular applications, and with trivial installation requirements. The product may be the support and maintenance itself. Some companies may add "enterprise-ready" differentiated features or attributes that can be marketed. Others, such as Red Hat, JBoss, and MySQL, developed a valuable network offering that includes support, maintenance, certifications, additional warranties, monitoring, and indemnifications into a single subscription model. Regardless, there is well-defined value that solves a customer's problems.
Many newer companies using F/LOSS are also clear in how they approach the difference between customers and their communities. For example:
Basho Technologies, the company behind Riak, the open source NoSQL database, has stated that it has no intention of trying to up-sell Riak open source users to EnterpriseDS, its value-added subscription product. The company fully expects open source users to be attracted by the additional features and support; it is not trying to qualify them via Riak.
Calpont is expecting the open source InfiniDB Community to drive demand for InfiniDB Enterprise, but it has ensured that InfiniDB Community can be used on its own for scalable data-warehouse use cases, albeit without formal support.
Neo Technology does not offer support services for the open source Neo4J, other than through the community mailing list, and primarily sees the open source model as a means of growing interest in graph databases and its Neo Basic Server, Advanced Server, and Enterprise Server products.
Conversions and Community
Community users are not converted into customers, but there is a correlation between well-run communities and the customer pipeline. Companies like Alfresco, Hyperic, and JBoss all saw conversions in the pipeline because potential customers came to the web site, learned what they needed to learn, downloaded the appropriate things to try, and used the community as a litmus test of the solution before returning, as self-qualified leads, to buy product.
The process shown in Figure 4 can also clear up debate about "open source" and "community" and conversions. Some companies publish their product source code under open source licenses and never try to develop a real community. There is nothing wrong with this approach if they are running a more traditional software business model and do not care specifically about enabling the community to directly engage with the project. Publishing the software is a sign of strength and confidence in their product and their ability as a company to satisfy customers with a valuable solution that is more than just the software.
Some companies also develop large successful communities without ever publishing their product software. This is why community building is so important for a company and why community development is an essential ingredient in any pitch of a solution to customers. Communities historically anchor customers:
Communities create knowledge, expertise, and experience, which are all necessary to provide a complete solution for a technology pitch to the customer.
Communities create advocates and evangelists to spread awareness about the solution.
Communities create enormous inertia in the status quo around a company’s technology.
The role of communities in anchoring customers explains why companies like Microsoft invested millions in developing the Microsoft Developer Network (MSDN). It has taken more than a decade for other Internet communities contributing to interesting F/LOSS projects to wear down the inertia inherent in MSDN. Likewise, IBM has invested enormous amounts of money in developerWorks, incorporating free and open source software to meet their solution needs and value propositions to their customers.
This is the real "conversion." The community enables customers. It is correlative, not causative. Community members that have solved their problems using a company’s technology base will carry their excitement, knowledge, and commitment into new places where customers exist. With well-organized and supported F/LOSS communities, the community now brings the technology to new customers and then later anchors those customers. In recent years, the next generation of startups has learned that the best way to encourage a frictionless relationship between a vendor and its community is not to attempt to convert users at all.
As recently as the past few years, many F/LOSS-related vendors discussed the idea of separating open source users from paying customers, but they still often offered those F/LOSS users paid support. It was almost as if they saw dollar signs instead of download numbers and could not help themselves. In comparison, we see newer vendors being much stricter about not offering paid support to F/LOSS users, while still investing in support forums and other resources that enable the vendor to support users and track the user-profiling statistics that enable them to identify those likely to enter the customer pipeline. Vendors using F/LOSS can enable significant savings in software sales and marketing, but it is often a case of spending differently rather than spending less.
To this point, we have focused on strategies a company needs to consider when delivering product and services around a F/LOSS community that the vendor best controls. There would rightly need to be a difference between the strategies employed to target true external communities compared to vendor-led, captive communities. Vendors targeting members of their own user and developer communities have more flexibility in how they define community. For example, a vendor might develop an active community of users without necessarily encouraging developers around their own F/LOSS-licensed offering depending upon what problems they solve for what customer profile. Developing products and services for externally led, community-developed F/LOSS requires a company to participate deeply in the external community to demonstrate credibility and best differentiate their own offerings.
The desire to differentiate between project users and product customers is specific to captive, vendor-led user communities. Vendors attempting to generate revenue from open source software developed by collaborative communities have to be careful to enable would-be customers to be both product users and project contributors at the same time. The last thing they want to do is force users out of that community.
For the reasons noted above, however, vendors attempting to generate revenue from vendor-led open source software have much to gain by actively differentiating between community users and paying customers in order to reduce the friction caused by trying to serve two groups with the same strategy.
If community users have more time than money and customers have more money than time, then a vendor needs very different strategies to address each group’s selfish needs. Vendors must ensure that they are not wasting time and resources attempting to convert those users who will happily support themselves and modify the software to save time, while also ensuring that the products and services they offer will appeal to those potential customers that might be prepared to spend money.
Identifying the services, products, and features that will appeal to each group is the essential problem that lies at the heart of attempting to generate revenue from open source software-based solutions.
Community development process: Jono Bacon, Community Director for Ubuntu Linux, and an employee at Canonical Ltd., wrote The Art of Community, which contains all the processes and policies used in developing the very successful broad-based community around Ubuntu Linux.
Sales channel management: David Skok wrote "Lessons from Leaders: How JBoss Did It" (9 Nov., 2009) describing his time as a board member at JBoss Inc., and the processes used in detail to manage the sales pipeline and grow revenues.
Sales and marketing: The 451 Group report, "Closing The Deal With Community," written by Jay Lyman, Open Source Analyst, and published in March 2010, examines how open source software vendors spend and invest in sales and marketing.