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.



Monday, July 17, 2006

Middleware can protect your company's e-mail

Last week I wrote an article for CommsDesign around mobile security and how using a middleware would solve some of the issues. I hope you will find it interesting.

Monday, July 10, 2006

Podcast about Funambol

Mobile Computing Authority interviewed me just an hour after the last penalty kick on Sunday. I was almost out of voice but they were nice enough to listen.
If you are interested, here you have the podcast.

Sunday, July 09, 2006

Off topic: a-la-matt

My friend Matt writes an off-topic post on soccer once in a while. He is a real soccer fan, who grew up in the wrong country. Therefore, he chose to root for an English team (Arsenal) and France (where he spent some of his life) as his national team. He often writes analogies between open source companies (mainly Alfresco lately ;-) and soccer.
Matt was the reason for me to start this blog and I like him. Unfortunately for him, he is just bad at picking soccer teams. His Arsenal was crashed in the Champions League final (nobody remembers who you beat to get there, people just remember the winner), France was crashed today in the World Cup final by Italy.
This is a day for some analogy for me as well, I guess. Italy won showing passion, creativity and talent. A phenomenal defense, beat only by a penalty kick and an own goal. Lots of goals, still. What I would call smart playing. Fabio Grosso is the image of this team. A not-so-young guy who played for Perugia and Palermo (not really top teams) so far, but who was instrumental for us to get to the semifinal with a great run on the left that ended in a penalty kick, who scored in the semifinal against Germany and shot the last penalty kick today. Heart and talent, but mostly passion and a never-give-up attitude.
I guess you know which open source company I feel looks like Italy... so I will leave the analogy for Matt's next post.

Tuesday, July 04, 2006

How do you create a successful open source company?

This is a question I hear quite often: how did you manage to bring Funambol to profitability, push the open source project to 500,000 downloads and get your company included in the Red Herring 100? I have no clue, really, so my standard answer is: "I am a lucky guy"...
Since my answer usually ignites another question ("no, really...") and I usually look stupid, I decided to put together a few ideas on what I would do if I had to start an open source company from scratch. Here they are.
1. Think BIG: open source is a game of volumes. You need a BIG community for all the positive effects to show (quality, support, contribution, viral marketing, quick sales cycles, international reach, ...). The only way to get a big community is to attack a large market. If you build an open source project for a niche, your community will never get really big and your company will always stay small. I know I am killing half of the open source companies that VCs have funded in the last year or so, but ...
2. Think STANDARDS: standards have been key for a lot of successful open source projects. HTTP for Apache, SQL for MySQL, J2EE for JBoss, SyncML for Funambol (not in that league yet, but we are working on it...). I am not saying that being the open source implementation of an open standard is the only way to create a big open source project (I feel SugarCRM might make it without it), but it certainly helps. A lot. In particular, if the standard is successful.
3. Think COMMODITY: this goes with the BIG argument above. Open source is the winning strategy for commodity markets. It is a game of volumes. Price is key in commodity markets. If you choose something that will become a commodity, at the end you will come on top because nobody can compete with open source companies on price. Not because it is free (it is not), but because our companies are built on different cost structures than proprietary companies. Our marketing, sales, business development and QA costs are a fraction of those of proprietary companies. In a commodity market, it really matters.
4. Think PRICE CUSHION: if you want to create a big open source project, you do not need it. If you want to create a big open source company, you need a price cushion. You have to go after some big proprietary company which set a very high price. Being open source, the price for your product will always be perceived as a little bit more than zero. How much over zero makes all the difference. If you have someone big that set a high price, you'll crash that price slowly until the market becomes a commodity and volumes are there. If you are thinking about attacking a large market where there is no price cushion and no big player charging a ton, you are going to create a big open source project but zero dollars for your shareholders. Think MySQL with Oracle, JBoss with BEA, SugarCRM with Salesforce.com, Funambol with RIM (that's $50/user/month...). Once again, I know I am killing the other half of the open source companies that VCs have funded in the last year or so, but ...
5. Think IRONMAN: most people that went public with a proprietary company will tell you "it was a marathon". Open source companies are in the Ironman category. That is "SWIM 2.4 MILES! BIKE 112 MILES! RUN 26.2 MILES". The race ends with a marathon, but you have to swim a lot and bike a ton before you even start the marathon. Aggregating a large community takes years, there is nothing money can do to accelerate the process. It is a natural long process with phenomenal fruits at the end. But you have to be patient. MySQL was first released internally on May 23, 1995... That's eleven years ago and they might go public this year or next (go Marten!). Do not think starting an open source company will be a quick race, gear up for the long long haul. The Funambol project was started in 2001 as Sync4j, and we reached 500,000 downloads in 2006. The Ironman cap was the first company gift we ever produced. One of our key employee is an Ironman competitor (just won the 12 hours of Cesate, go Daniele!). When people ask me where do you think your company is in its life, I answer "we just got out of the water after the swim fraction, we are biking downhill, but I am bit worried about the marathon that we'll have to start in a few years".
 
I hope I finally answered the question: it is really tough and I AM a lucky guy.