Open Source Communities and Customers in Pictures

[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.

Comments

[Matt]

Excellent post Stephen - I agree with your analysis and also think we've seen some examples of recent start-ups deliberately taking the second approach, having observed that the first approach created too much friction for the previous generation. I'll blog about these when I haven't been up half the night watching the UK election and can actually remember who the examples are :-)

Thanks for the mention BTW.

Matt

[drew Roberts]

Open Core is broken on the face of it:

For the Free Software folks, it isn't Free and that's that.

For the Open Source folks, it is a self contradiction:

1. Open Source results in better code.

Therefore:

2. We give out high quality, limited functionality code libre and gratis.

3. We give out low(er) quality, code with more functionality (which we often call our enterprise version) but it is neither libre or gratis.

So, either I don't believe you that open source methods produce better code and you are in the mix with everyone. Or... I believe you and you are out of the running along with all non-open source (non-Free) solutions as why would I want to run my operations on lower quality, buggy code?

There is money to be made from enterprise / business quality Free Software, and some Free Software is not going to be implemented in some places unless the money *can* be spent in one way or another, but Open Core is a broken thought.

all the best,

drew

[James Dixon]

Nice post. Similar in many ways to the Beekeeper Model.

http://jamesdixon.wordpress.com/the-bees-and-the-trees/commercial-open-source-model/

James

[rodney]

Looking at the table of Community vs Customer, the first row has a huge chasm between them filled by those who have not enough time and won't spend any money. I've been involved with monetary test points about this. Your second row (problem solving) is what tips a portion of these people to customer. A lot of people want to be non-paying customers (zero time, zero dollars) because they feel someone else should pay for it or that they are "owed" this software.

I remember way back with SunOS administration when there was a real community -- a cohesive community. It was the newsgroups. It was the authoritive location to ask for help or read through previous discussions. There were SUN employees who regularly and expertly added to the group. This was in addition to the regular paid support that many customers had. Finding this community was easy, clear and fast.

Today there are often numerous forums with few of them able to be completely authoritive for a product. Google and the like can find most of these forums, but can't help you filter out which are a community of fellow users that will be helpful. Most people find it onerously time consuming to do the discovering/search/filtering. The ease and clarity that existed years ago to find a community continues to exist only for a (realtively) small percentage. Finding a way to address this I think would narrow the chasm (above) and, I think, help validate the (open source) community. When it's easier to find the most valid, expert community for a product then a critical mass/population can be reached. Without the critical mass getting reached people who could be part of the community (zero time, zero money at least initially) are lost to the chasm.

I guess what I'm trying to say is that there needs to be a Community Center for Open Source and other products. One that people can find like in a city for pool swim times, pottery classes, etc.