“Do not sell anything to your community”

Stephen Walli last week published a graphical representation of why it is important for the vendors that lead vendor-led open source projects to separate their community users from their sales pipeline.

The post graphically articulates a trend that I have identified in recent conversations with open source-related start-ups: they are less fixated on trying to convert community users into becoming paying customers compared to the previous generation of start-ups.

As Stephen notes, the conversion of community users into paying customers has long been a concern for open source-related vendors. It has also long been a source of friction, with vendors that offer proprietary extensions being accused of “bait and switch” or otherwise undermining the value of the open source software in an attempt compel community users into becoming paying customers.

In recent years the next generation of start-ups 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 Stephen notes, there has been an acceptance that “the community enables customers. It is correlative not causative.”

Thus we have Basho Technologies, the company behind Riak, the open source NoSQL database, stating 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.

Similarly while Calpont is expecting the open source InfiniDB Community to drive demand for InfiniDB Enterprise, it has also ensured that InfiniDB Community can be used stand-alone for scale-up data-warehouse use cases, albeit without formal support.

Likewise, 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.

The title of this post is taken from a comment made by Funambol CEO Fabrizio Capobianco at OSBC 2009. While many open source-related vendors at that time talked up the idea of separating open source users from paying customers they also often offered those open source users paid support. It was almost as if they saw dollar signs instead of download numbers and couldn’t help themselves.

In comparison we see newer vendors being much stricter about not offering paid support to open source 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.

There is some correlation here with Jay’s recent report on sales and marketing strategies for open source vendors and the fact that open source can enable significant savings in software sales and marketing, but it is often a case of spending differently rather than spending less.

Additionally, I think Stephen’s post highlights a fundamental difference between the strategies employed to target true organic communities compared to vendor-led captive communities.

In response to Stephen’s post Andrew Oliver stated that vendors shouldn’t make customers “differentiate out of the community for the ‘W’.” While that is very probably true for vendors targeting users of true community software, or open source software developed by another vendor, I’m not convinced it is true for vendors targeting the members of their own user communities.

The reason, as noted above, is that those vendors do want to actively differentiate between community users and paying customers in order to reduce the friction caused by trying to serve two groups with a different strategy. If community users have time but no money and customers have money but no time, then a vendor needs very different strategies to “address each group’s selfish needs,” as Stephen puts it.

However, I would also clarify that the desirability of this differentiation is specific captive, vendor-led user communities. There is a very different community/customer dynamic between vendors targeting users of true community software, or open source software developed by another vendor.

Tags: , , , , , , , , , , , , , , , , , , , ,


#1 Kim Weins on 05.10.10 at 12:49 pm

Matt – I agree with your differentiation between captive, vendor-led communities and true community software. Typically the “community” in a captive, vendor-led project is predominantly end users, since most such projects are developed mostly by employees of the vendor. In true community software, the community is actually developing code — and hence has a much stronger interest in how any vendors attempt to monetize it. Also, vendors that do not own the copyrights for an open source project must behave differently than vendors that control the copyrights.

#2 Matthew Aslett on 05.10.10 at 12:59 pm

Exactly – it’s pretty obvious when you think about it but I think the fundamental difference between targeting user and developer communities is often overlooked because people assume that “community” means developer community and vice versa. What works with a community of developers may not work with a community of users.

#3 Jack (some other "Jack") Repenning on 07.26.10 at 12:36 pm

Appreciate your attempt to clarify the language. A further complication for those of us who provide software-development tools is that our “users” (in the strict sense you use here: people who use but don’t develop the product in question) are in fact “developers” (of something else, but “developers” none the less). So when we say “a community of developers,” it’s still not clear. I try to use “contributors,” but even that’s undermined by community doctrines that encourage “contribution of any type: discussion, bug reports, patches, code.” Wish we had some clear, or at least standard, language for this distinction.

#4 James Dixon on 05.10.10 at 2:52 pm

I agree with some of your points Matt, but not all of them.

Regardless of the relationship between the code/project and the vendor, attempting to monetize the community is usually the wrong idea for this reason:

Community members are individuals. Customers are organizations. The customer contract is between the vendor and the organization, and it is not re-assignable. By contrast community members often remain active in the community as they go from job to job.

A vendor can encourage community members to persuade their organization to become a customer, but the community members are never customers. Trying to treat the community as a sales funnel is counter-productive.

I have a graphic for this in the Beekeeper Model:


Obviously the exception to this is software that is useful to individuals (games, utilities etc).

#5 451 CAOS Theory » “Do not sell anything to your community” | MoSo Blog on 05.10.10 at 5:56 pm

[…] Continue reading here: 451 CAOS Theory » “Do not sell anything to your community” […]

#6 Don’t Confuse Community with Customers « TechLedger on 05.11.10 at 12:07 am

[…] Having said that, it implies that in the spirit of open source, it is wise not to sell anything to your community. […]

#7 Andrew Aitken on 05.11.10 at 12:47 pm

Please, the only corollary in this thread is that there is none. Some communities can be monetized effectively and with their permission and support and some can’t. There is no single approach or model, we know, we’ve helped build and monetize dozens over the last eight years. The definition of an “open source” community itself has and is changing. Community members are individuals but in some communities they are buyers and at the very least influencers and can be treated as potential customers. The absolute core issue is understanding that your community will typically be made up of different constituents and correspondingly message and treat them differently. And most importantly continuing to provide real value, help them solve real problems WITHOUT them having to actually pay for something.

#8 Gerald Combs on 05.25.10 at 12:10 pm

I’m with Andrew Aitken. There is significant overlap between Wireshark’s user community and CACE Technologies’ customers. (CACE is the primary sponsor of Wireshark and WinPcap, and makes products that complement them.) I suspect the community/customer overlap is significant for Snort/SourceFire and Asterisk/Digium as well.

Keeping customers and community distinct works very well in many cases. It’s foolish to assert that it works in all cases.

N.B. I’m the lead developer of Wireshark. I’m also an employee of CACE.

#9 If you're selling to your community... you've got it backwards. | OpenLife.cc on 07.04.10 at 6:41 pm

[…] dialogue with Matthew Aslett inspired me to read more of his recent writings. An excellent piece Do not sell anything to your community is based on a blog post by Stephen […]

#10 When Freedom Clashes with Profit « TechLedger on 07.21.10 at 12:15 pm

[…] When Freedom Clashes with Profit Posted: July 21, 2010 by ibm2100 in Open Source Open source is about freedom while business is for profit. Open source software belongs to two camps: it’s either restrictive (like GPL) or permissive (like Apache). Make no mistake: GPLv2 is the groundbreaking license that gave birth to Linux. GPL is all about freedom, and that freedom is protected by reciprocal growth in terms of code enhancements and code fixes. That is why the The 451 Group advises open source developers to not sell anything to your community. […]

#11 451 CAOS Theory » ‘All that we share is not enough’ on 01.19.11 at 5:54 pm

[…] “Do not sell anything to your community” […]