JPz'log Coin Coin and Plop da Plop

Thoughts on F/OSS (3/10): main business models

This is part of a 10 blog posts series on F/OSS thoughts, extracted from a talk that I gave recently.

Lots of people wonder what the best way to make money on top of opensource is. The answer is easy: there is no opensource business model, only one that fits your very specific case. What works for others is highly unlikely to work for you.

I think that there are three grand types of projects that share some common business models. Again, this is not a general rule, just big trends that I have observed.

If you make a wonderful framework, then you probably have a good chance of making money through services: training, consulting and support. If you opt for a dual-licensing strategy, you may also make money by selling licenses for those who (understandabily) cannot cope with the terms of a restrictive license such as the GPL (or worse, the AGPL).

You can sell services too when you make mission-critical infrastructure servers. Your web browser may crash from time to time, but your application server may not. You will also most probably want it to be fast and properly used by your teams. Another revenue stream can come from proprietary extensions and management tools.

The last case is the one of products, like OpenOffice.org. In this case, and despite what F/OSS theoricians say, forget about selling support and related services, because in most situations this is not where the money is. You have a higher chance of success by selling extensions and customizations of your product.

In any case beware that you may not fit, or you may no strictly fit in any of those cases. Again:

There is no opensource business model, only one that fits your very specific case!

Thoughts on F/OSS (2/10): why making F/OSS?

This is part of a 10 blog posts series on F/OSS thoughts, extracted from a talk that I gave recently.

Nothing is free. If you spend some of your time on a project where others can take the code, modify and redistribute, there must be a good reason. Otherwise you would probably better off spending time with friends at the pub...

When thinking about motivations for doing F/OSS work, I found 3 non-exclusive categories.

1. Having fun, developing skills and advertising yourself. The example that came to my mind was IzPack as I can only speak for myself. I know a few other projects that I suspect are in the same case, but again, I can't speak for others. Here the motivation is clear: you are investing on yourself:
   • now, because you get some fun
   • for the future: you build new engineering, management and communication skills that will help you being more attractive in the future.
2. Grab some strategic market shares. Some software market shares have lots of value, not necessarily because they are direct revenue streams, but because you are better off having them than your competitors. The web browsers market is a great example. Nobody sells web browser software licenses anymore, yet the war is fierce in this place. A few years back Microsoft had nearly no competition, and its infamous web browser was what everybody but a few geeks with beards would use to access web pages. This put Microsoft in a strong position not only to capture users to their web services, but also to develop their server-side technologies that would naturally "work best on IE". Mozilla Firefox is there mainly to take some market shares and ensure that competition exists in this field. Google Android is another great example. The company has a strong interest in people accessing the web from mobile phones, and preferably use as often as possible Google tools (mail, search, agenda, etc). Indeed, access to those tools means traffic, which means ads, which means money. Having a competitor dominating this market like MS did with IE would not be great for Google, as the said competitor would naturally favour its very own services, to the detriment of Google.
3. Make business. In many cases, doing opensource is just another mean to do business. Opensource means potentially more users. Opensource can be a powerful marketing tool, as more people can easily test a technology, and then be redirected to paid tools and services. The Spring Framework, MySQL or Talend ETL are examples of making opensource for business. If you can find a business model around your project then opensource is a wise choice.

Thoughts on F/OSS (1/10): quick facts

This is part of a 10 blog posts series on F/OSS thoughts, extracted from a talk that I gave recently.

I started IzPack back in 2001. At this time I was a freshly 20 years-old student. I started the project because:

1. I wanted to learn Java
2. I wanted to learn about this strange idea of releasing software under an opensource license, meaning that others would be able to modify it (I was influenced by this smart guy)
3. I wanted to have fun
4. honest: I wanted to get a better resume too (I saw this work as a deferred investment on myself).

I thought making an application installer in Java that would work across operating systems would be a nice idea. This is really how IzPack got started.

As such, I did not expect that IzPack would be so successful. At that time, I thought that it would be just great if a dozen people would download and enjoy it...

If you start a F/OSS projet now: do not expect any success. Tons of projects get started everyday. Tons of project creators get demotivated everyday. If your idea is great, if it is well executed, and if you actually solve others problems, then success may come to you.

The second fact that I mentioned in that talk was that you are always the very last person to know when people use your project. Why so? Simply because happy people are quiet people. You will always hear from the people that complain, either because they are right, or because they expected your project to be what it is not, or because they did not take 5 minutes to read through your documentation.

Happy people rarely tell you how much they are happy to have found your project, so you will most likely hear from them by chance, or by pro-actively doing advanced web searches.

The last point I wanted to stretch on this slide was that an opensource community does not magically appear overnight. Do not expect to see people knocking at your project doors simply because you wrote code and published it at some place on the web.

Your project needs to actually solve problems real people have in their real lives. The target of your project may be a just a small niche, but the point is that it actually has a market. People must also be aware that your project exists. Finding about what your project is must be immediate.

I'm still baffled to see how many people don't understand opensource. It's just another licensing model for publishing your work. Just because the code is open does not mean that your project community will automagically appear.

Opensource does not make your project better than other projects, just because it is opensource.

People claiming that opensource yields superior software over proprietary software are either ignorants, RMS fanatics, or liars.

Building a community is a lot of hard work, both in terms of engineering and communication. The next 9 blog posts on the matter will go through other thoughts on the topic.

Welcome for a ride