[Update (19-Nov-2010, 15:41 GMT): Voici une traduction en Français par Philippe Scoffoni.]
[Update (11-May-2010, 10:37): Matt Aslett posted commentary on this post at the 451 Group CAOS blog.]
Debate continues on whether open core business models are a winning strategy with a capital "w" or not, and whether customers care. Matt Aslett's recent excellent posts continue the discussion. The big concern for those that criticize or express concerns is that customers are mis-lead, essentially that there's a bait-and-switch free-versus-product or a deliberate lack of clarity in the marketing around the product value.
I want to take a different approach to the discussion here. Before we had Internet-sized bandwidth on which to collaborate around software, traditional software business looked something like the first diagram. 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 you could measure the profits.
The Internet happened, dramatically removing friction from the process of collaborative software development and delivery. Developers could share the economic cost of software creation (innovation and construction) and large repositories of useful building blocks were born and made available through these project-focused communities. The Web accelerated the early Internet trend.
Companies began to form around some of the projects and for the past decade and a half there's been confusion as people debated how to make money when you give away the software, or the other side of the economic equation around variations on why people work for free. This has unfortunately led to the idea of community and customer interaction akin to the following diagram. The community is jammed into the middle of the customer pipeline. The community gives stuff to R&D which still delivers product. Marketing now messages to customers AND [worse] the community, and the company tries to "convert" the community into customers.
This probably started around the time that MySQL AB observed they had a paying customer for every thousand downloads. This mis-set expectations in a fundamental way. People assumed causality. It created false metrics around driving downloads and improving conversion rates. (We'll come back to this ....)
Marten Mickos (while CEO at MySQL) observed that the early community has time but no money while the later community has money but no time, and that his customers are in the latter bucket. This is the start of a better model for understanding community and customer. Let's use the "time is money" line as the division between community and customers because by forcing the separation of the two groups we can add clarity to both and the things a business would need to do differently with each.
Instead lets treat the community (time but no money) as a completely separate entity from the customer pipeline (money but no time). The community members engage with R&D over the
project. They engage with marketing in a conversation about project direction, and ancillary things like translations in other markets. Customers are qualified through the pipeline based upon the
product.
Indeed you can start to see how to think about these different groups of people using different well understood and documented processes for community development and sales channel management.
This allows you to clearly address each groups's selfish needs.
| Community |
Customers |
| They have time but NO money |
They have money and no time |
| They want a problem solved and look to the project |
They want a problem solved and look to the product |
| They can’t be converted |
Your Community is the litmus test of solution viability. |
They can contribute time, so:
What do you want them to do?
What do you need to enable?
What do you need to let them know? |
You manage leads through the qualification pipeline
and conversion process like any other customer-focused sales
process |
| They will not waste time, so the project needs to solve a
problem for them before they will invest themselves in it |
Product for customers is clearly differentiated from project and community. How the product is differentiated depends upon the company and the value proposition to customers. At it's simplest, the product may be a supportable and maintained collection of software, certified to run on specific supported platforms and with particular applications, and trivially installable. The product may be the support and maintenance itself. Some companies pack more "enterprise ready" marketable differentiated features or attributes into the product. Others (e.g. Red Hat, JBoss, MySQL) develop a valuable network offering that includes support, maintenance, certifications, additional warranties, monitoring, indemnifications, and the like into a single subscription model. Regardless, there is well-defined value that solves a customer's problems.
Companies like Alfresco and 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 (self-qualified) to buy product.
This visualization also clears up debate about "open source" and "community". Some companies publish their product source code under open source licenses and never try to develop a real community. There's nothing wrong here if indeed they're running a more traditional software business model and don't 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 your company and why community development is an essential ingredient in your solution pitch to customers. Communities historically anchored your customers. Communities create knowledge, expertise and experience, all necessary to provide a complete solution for your technology pitch to the customer. Communities create advocates and evangelists to spread awareness about your solution. Communities create enormous inertia in the status quo around your technology. This is why companies like Microsoft invested millions in developing the Microsoft Developer Network (MSDN). It has taken more than a decade for other Internet communities around interesting open source projects to wear down the inertia inherent in MSDN. Likewise, IBM has invested enormous amounts of money in the IBM Developer Network, incorporating free and open source software to meet their solution needs and value propositions to their customers. With open source projects relating to your company, the community is anchoring your solution.
This is the real "conversion". The community enables customers. It is correlative not causative. Community members that have solved their problems using your technology base will carry their excitement, knowledge, and commitment into new places where customers exist. With well organized open source communities, the community now fronts your technology to new customers as well as later anchoring customers once they exist.
Subscribe to the feed
