Tuesday, July 25, 2006
My Honest Dual Licensing
I have been an open source person for as long as I remember, at least since I met Alessandro Rubini in the late eighties. He was writing the mouse device driver for Linux and I had the fortune to spend a good amount of years in the same dorm and then lab, where he was going around with a Linux PC in a wooden box.In the last five years, I spent almost every day thinking about a business model that could allow open source to become a viable alternative to proprietary software. I do not believe the Linux model can be replicable. You cannot build a project hoping it will get big and some IBM or HP will throw in a ton of money. If you want to get a salary doing what you love, you need to come up with a better model. A sustainable model for open source. A honest way to create value for your community, while generating enough cash to make it work. With Alberto Onetti, I wrote a paper some time ago on how it works for Funambol.
The guiding principle for me has always been "Just be honest" with your open source community.
My epiphany with dual licensing happened in London some years ago. I met Marten Mickos and I decided that was the way to go. I loved the "quid pro quo" concept (albeit it means "a misunderstanding" in Italy... We would use "do ut des"): you either give back code to the project or you give back cash, so we can put it back in the project itself. That's being honest.
The problem with dual licensing starts when your product is not meant to be embedded. There, the trigger to open source everything around your code is clear. When you have an application, it gets tricky. Therefore, many open source companies decided to split open source from commercial based on features. That is, you get an open source product that does 70% of what you need. If you need the other 30%, you have to pay. The risk is that your product manager will have to think where to put every new single feature, with your investors and sales people telling him/her "close" and the community shouting "open". It creates tension in the community ("why did you put THAT feature in the commercial product? We need it! We'll build it ourselves"). When Marc Fleury says that who adds commercial extensions to open source code is not really open source, I believe he goes overboard (he likes to be controversial, I guess ;-) But he is not totally off base. Dual licensing with commercial extensions targeted to the open source crowd (all enterprises, for example) will aways create tension. In the long run, I believe it won't be sustainable for us. Many have noticed it, such as Alfresco and others, switching to a 100% service-based model and sort of giving up dual licensing (maybe because it was not working for them as it does for others ;-)
Now, how do I build My Honest Dual Licensing? How do I keep the concept of quid pro quo, without creating a gigantic bait and switch? How can I be honest to your open source community, while generating cash to sustain the project via licenses?
It is quite simple, actually: we will not segment your product based on features, we will segment our user base. On one side, we build a phenomenal open source product targeted to your open source community, pure and honest. On the other side, we build a commercial product based on the same core BUT targeted to someone else. If "someone else" is not in your open source community, you are golden. Your community grows happy giving back the code to the project, your "someone else" pays for it and gets back what it needs (quid pro quo).
Ok, now the issue is finding that someone else ;-) In the Funambol case, the community is everybody in the world, including individuals, universities AND enterprises. "Someone else" is the carriers. The carriers have totally different needs than enterprises. They target millions of users. They target consumers. It is the same core but with some different features (probably still 70% vs. 30%). Features, though, that the open source community does not care about. That's the trick. No tension when adding features. Clear separation between open source and commercial. Segmentation based on your user base, no bait and switch. My Honest Dual Licensing.
Just be honest.
Posted by Fabrizio at 09:10
5 Comments:
/mna said...
Excellent post, Fabrizio. Thanks for "just being honest" about dual licensing. I agree with you whole-heartedly.
As for Alfresco, our old model was working fine. In some ways, perhaps better. But it never felt right for us. (Some of this was my innate insecurity born of competing with Red Hat's open source message while at mixed-source Novell. I lost there, and didn't like the way we lost. I hated the message I had to say there.) So we went 100% MPL, and the results have been excellent - sales are up, downloads are up, and (most importantly) happiness is up. We really like the change, and everyone in the company and our community is happier.
Is it an infallible model? No. But I agree with you - the better we segment our customers, the better our sales/etc. will be.
Matt
Comment Posted at 10:08
Interesting post and open source has generated so much momentum that another Linux with corporate support is unlikely. But I'm not sure that I buy the heart of your argument of avoiding tension by segmenting OS and Commercial by customer type or user base, as opposed to by features.
In my opinion, there is tension no matter how you slice it, even 100% open source (where service/support is the model). And the successful companies will be the ones that manage the tension the best. In your Funambol case, while the products may be separated, the tension could (i won't presume to say does) exist at a higher level. Let's say times are a little tough and you can only hire 3 people. Does management staff them on open source or commercial? Let's say all your revenue comes from services such as implementation fees, does your board want a little more focus (people, marketing, etc.) on the service side of the house instead of development? These are questions that open source and commercial companies have struggled with in the past and may be unavoidable.
Comment Posted at 12:05
Fabrizio said...
I agree there will be tension inside the company to decide where to allocate resources, but that's quite similar to any proprietary company. You always have tension on where to put resources and you never have enough...
In our case, we go with the Funambol concept -> it is a tight-rope walk, just be balanced and do not fall....
Comment Posted at 14:30
Brij said...
Honest post Fabrizio,
It requires courage to come out and take a stand on issues like these.
Segmenting along user base definitely helps to provide clear resource/revenue separation but the challenge shifts to scalability of this model.
In many ways your model reminds me of the classic Geoffrey Moore's vertical market prescription for startups. Maybe extreme verticalization is the way out for open source "PRODUCT" companies.
How different is vertical market focus from "user base" approach?
Comment Posted at 20:02
Donald C. Kirker said...
Wow :-O Excellent post!
That is almost exactly my philosophy.
It is also my belief that an open source project/company that provides a 70%/30% model will have a very long and difficult obstacle course to go through.
With a 70%/30% company, the features that end up going into the commercial part are the features that bring value (well, that being the reason, value = $$$), and the open source part begins to become neglected and left to the community to maintain. With this, the community gets nothing in return, but they provide everything. This usually results in a dead project (and if a company is behind and funding this project, a dead company, and that is usually no good).
I guess for a project like WAPUniverse, all features matter to the user, and then the carrier would be interested in DRM (something the user would like to think nothing of). Now my only road block is since my current target audience (the mass group) is end users (I target device manufacturers and carriers as well, but, I doubt that I will get any license agreements anytime soon), is there a way to be able to make revenue? My current approach is: charge for the binary and release the source. Somehow I don't know if this is the best approach (it seems like the best at the moment). I can then turn any revenue around and re-invest it in test equipment and equipment for various other tasks.
What are your thoughts Fabrizio?
Once again, excellent post. :^D
Donald C. Kirker
"CEO"
WAPUniverse.com
