Don't try to upsell your community (Fabrizio)
I had dinner with Fabrizio, a good friend and CEO of Funambol, the leading mobile open source company. He was in Salt Lake to ski and was kind enough to call me so that we could hang out.
Fabrizio said some things about open source that rang true with me, which I had not considered before. I'll list two principles he mentioned, and will discuss each in turn:
- Don't upsell your community, and
- Sell open source to those who don't like/trust open source.
Fabrizio's first principle - "Don't upsell your community" - basically means that there are multiple markets for open source, and the developers who download your product will not be an important source of revenues. They yield many other benefits - product extensions, product feedback, bug fixes, etc. - but don't expect them to fund your development.
You can see companies making mistakes in this regard all the time. They set up models that are designed to goad "free-riding" developers (or, "the community") to pay. Hence, the now ubiquitous "Community" vs. "Professional" or "Enterprise" versions of products, with the hope that Community users will become Professional or Enterprise buyers.
They won't. Give it up.
This is not to say that product segmentation is wrong, but it means that we need to be clear about how and why we segment an open source project.
In Fabrizio's case, he recognized that consumers aren't going to pay him money, and the enterprise market might not be fertile ground yet either. So he's focused on mobile operators, and finding a great market there (especially in developing geographies). He gets a huge amount of value from his user/development community (fast approaching 1 million downloads), and doesn't confuse his goals with the operators with those of his user community.
This has meant two things for Funambol:
- They don't write code that enterprises may want. They write code that their mobile operators will want, and let the community extend Funambol to meet enterprise-y needs (like Exchange connectors - operators and consumers don't care about Exchange, so why should Funambol spend its development dollars there?).
- Funambol's licensing is designed to maximize code reuse and utility for its developers (i.e., GPL), while not harming the mobile operators (who simply want to buy their way out an open source license, anyway).
So, they like the benefits of open source. But their lawyers don't want to be bothered with thinking through the implications of possibly (though this possibility is remote) having to share their code, or figuring out support, etc. So, they buy a commercial license to Fabrizio's code to get the benefits of open source without the so-called risks of open source. They want commercial open source. They want a company behind the community, but they definitely want the community, too.
I think Fabrizio has it right. In my content management/collaboration world, my primary customers are enterprises. They want open source, but they don't want to lose the commercial relationship with a vendor. Enter Alfresco.
But they also don't want a lopsided entity that is mostly commercial, and very little community, open source. I personally feel that the GPL (and other free software licenses) is the best way to ensure maximum community input while retaining the ability to give enterprises a way out. It won't always be like this - I assume in a few years enterprises won't be so keen to buy their way out of the obligations of open source (because they'll recognize that the obligations lead to greater and greater benefits), but while the world is as it is...it's a great model.
Look at what MySQL has done with its Enterprise offering, coupled with their Network. MySQL took nothing away from its community, but added to what companies wanted (better support, more QA, etc.). Its development/user community gets the freedom of GPL (v2) so that they don't really have to care that there is a company behind the project. Enterprise customers, for their parts, get the commercial license so that they don't really have to care that there is a community behind the product.
Everyone wins.
This is as close to "The Right Model" as we currently have in open source, in my opinion. It's community-maximizing without being overly reliant on support dollars. (If your business depends on selling support exclusively, you're going to find that you may successfully pull in five-figure deals, but you'll always strain and struggle to get the six- or seven-figure deals. Those require something beyond vanilla support - not proprietary software, but rather "proprietary" service (meaning the code is free, the services around it are not).
Thoughts?

2 comments:
Two points in reply to the principles offered by Fabrizio and Matt . . .
1. Making inexpensive add-on products and services available to the community, at price points that they can easily consume, provides additional value and should not been confused with "up-selling". Examples of these might include inexpensive web-based training and useful utilities that make the core open source product even more useful. If offered at very low price points, these commercial offerings can add real value to any customer (community or commercial). Fundamentally, I believe that Matt and Fabrizio are right in that if an open source company expects to sell a lot of pricey things to the community, it will disappoint itself and its investors. But, by focusing on delivering VALUE to the community in the form of great open source core product code and very inexpensive add-on services, the overall community experience and loyalty can actually be enhanced.
2. To be successful selling open source to those "who don't like or trust open source" is to focus on building capabilities (in open source software) that don't merely recreate the functionality of the past. This concept has been talked about in Matt's blog and other open source forums. The reality is that if the products of commercial open source software companies only mimic the functional capabilities of the proprietary vendors which they are perceived to disrupt, then only some value is created. If, in open source instead, we genuinely focus on harnessing the remarkable strengths of modern tools, architectures and technologies, we will create far more elegant software that better solves business problems in the categories in which we compete. The fact that we do this through an open source model provides advantages in product development cycle times, reduced sales and marketing costs, and even more efficient customer support infrastructures. But the primary point is delivering game-changing, jaw-dropping capabilities that cannot be replicated by the aged, complicated code bases of the proprietary, closed-source competitors. To do this well leverages the distributed development value of the community and the market foresight that comes from dealing with a commercial customer base. Voila! A successful commercial open source business model.
Fabrizio needs to blog about his two rules, so we can start citing them directly!
Post a Comment