Archive for May 19th, 2010

How to analyse an OSS business model – part five

(part five of an ongoing series. Previous parts: part one, two, three, four).

Marten Mickos (of MySQL fame) once said that “people spend time to save money, some spend money to save time“. This consideration is at the basis of one of the most important parameter for most OSS companies that use the open core or freemium model, that is the conversion rate (the percentage of people that pays for enterprise or additional functionalities, versus the total amount of users). With most OSS companies reaching less than 0.1%, and only very few capable of reaching 1%, one of the obvious goals of CEOs of said open source companies is to find a way to “convert” more users to paying for services, or to increase the monetization rate.

My goal today is to show that such effort can have only a very limited success, and may be even dangerous for the overall acceptance of the software project itself.

Let’s start with an obvious concept: everyone has a resource at his/her disposal, namely time. This resource does have some interesting properties:

  • it is universal (everyone has time)
  • it is inflexible (there are 24 hours in a day, and anything you can do will not change it)
  • efficiency (work done in the unit of time) does have a lower bound of zero, and an higher bound that depends on many factors; efficiency can vary by one order of magnitude or more.

Another important parameter is the price per hour for having something done. At this point, there is a common mistake, that is assuming that there is a fixed hourly rate, or at least a lower bound on hourly rate. This is clearly wrong, because the price per hour is the simple ratio between what someone is paying you to do the work and the amount of time required for that action; so if no-one pays you, that ratio is zero. So, let’s imagine someone working for a web company, and one of the activities requires a database. Our intrepid administrator will start learning something about MySQL, will work diligently and install it (ok, nowadays it’s nearly point-and-click. Imagine it done a few years ago, with compiles and all that stuff).

This system administrator will never pay for MySQL enterprise, or whatever, because its pay is fixed, and there is no allocated budget for him to divert money to external entities. So, whatever is done by MySQL to monetize the enterprise version, there will be simply no way to obtain money from the people that is investing time, unless you sabotage the open source edition so that you are forced to pay for the enterprise one. But what will happen then? People will be forced to look at alternatives, because in any case time is the only resource available to them.

This basic concept is valid even when companies do have budget available. Consider the fact that the average percentage of revenues invested in ICT (information and communication technology) by companies is on average around 5%, with some sectors investing slightly less (4%) up to high-tech companies investing up to 7%. This percentage is nearly fixed, valid for small to large companies and across countries and sectors; this means that the commercial OSS company is competing for small slices of budget, and its capability to win is related mainly to the perceived advantages of going “enterprise” versus investing personnel time.

Does it means that trying to increase conversion rate is useless? Not exactly. The point is that you cannot address those users that have no budget available, as those will never be able to pay for your enhanced offering; you have two different possible channels: those that are using your product and may have the potential to pay, or address the group of non-users with the same demographics. So, the reality is that mining current users is potentially counterproductive, and it is more sensible to focus on two interlocking efforts:

  • increase the number of adopters, and
  • make sure that people knows about the commercial offering.

This can be performed “virally”, that is by creating an incentive for people to share the knowledge of your project with others, which is very fast, efficient and low-cost; however, this approach does have the disadvantage that sharing will happen within a single group of peers. In fact, viral sharing happens within only homologous group, and this means that it is less effective for reaching those users that are outside the same group – for example, the non-users that we are pointing at. This means that purely viral efforts are not capable of reaching your target – you need to complement it with more traditional marketing efforts.

Next: resource and development sharing, or how to choose your license depending on your expectations of external participation.

, ,