Open to the core – The pragmatic freedom

open coreEveryone seems to have an opinion on the open core debate, and a popular opinion seems to inflict some sort of excommunication to anyone having a less than pure open source monetization process. Therefore I thought that I would add some unsolicited input to this matter.

Now, what is a pure open source monetization process?

The answers to that question echo the armchair soccer coaches who have been entertaining the world with their wrong predictions, while teams with less theory and more practice have advanced to better results.

A popular theory is that a project must be 100% open source, no matter what, and the ensuing monetization process must be modeled after projects X, Y, and Z, which have practiced that for ages with brilliant results.

I have two observations for the supporters of this theory:

  • It doesn’t work for all. What works for a browser might not be suitable for an operating system, and what looks good for an application server might be totally inadequate for a database.
  • Projects that don’t conform 100% to the pure open source model (the so called open core) are not bad by default. They may actually turn out to be better than some “pure” implementations.

The first observation is the hardest to come to terms with. Supporters of a popular project are appalled when they hear that (insert totally unrelated open source project name here) does not follow their business model, but they are doing something else, and especially when this something else falls into the realm of the evil open core (More about this later).

The reason why different projects do different things to make a buck is that the success of a project depends on different conditions. If project A is a browser, and project B is a web server, the strategies to monetize on them are often totally different. The choice of operating systems, user base targeting, and associated services, can be really as distinct as selling your goods at WalMart or Radio Shack. There may be some overlapping, but overlapping is usually not what brings food on your employees tables. And there may be more conditions that influence a project success, as many startups and venture capitalist have learned at their expense. Projects started successfully in Germany may be a flop in Silicon Valley, and vice versa. Models that pump money by the barrel in the server market may go bankrupt if applied to desktop products, and so on.

So, before saying “you should do like RedHat“, ask yourself if your project meets the same conditions that have made RedHat an open source commercial success. And by same conditions I mean not only the target users, but also the environment, the skilled engineers, the community, and probably the vision that put the company in the right place at the right moment.

That leaves you with the choice of pulling a business model from the basket of the non-pure business models, where you do one or more of the following:

  1. You license your code under the GPL or another free software license, and occasionally sell exceptions to the customers who ask for it (the so called dual licensing)
  2. You distribute your (fully functional) main product for free, under an open source license, and sell closed source features, as plugins or different builds.
  3. You leave your main product unchanged for all, but to your customers you give additional closed-source and not freely available software.
  4. You leave your product unchanged, and sell services that require your customers to install and use special software to get the service.

If your project uses one or more of these techniques, it will find one or more people who claim that it is not open source or not free software, or both. This makes you, your employees, and most of your project users uncomfortable, and probably angry. Of course it’s open source, and of course it’s free software! It’s released under an OSI license: what do the pundits want more?

Yet, once the anger subsides, you take stock of your project and look at the results. Your users (the ones using your product for free, a daily reminder to the world that it is open) are happy. Your customers are satisfied. Your revenues are growing, and you can guarantee a paycheck to your employees every month. Not only that, but you are hiring, because your business is expanding.

So, what’s the matter? Why do you have to suffer the indignity of being called dirty names because you didn’t make money the way that project X or Y are doing?

The answer is that you shouldn’t suffer. The market decides if your project is healthy or not. If your project is released under an open source license, the sole fact that dozens of other projects spread it around as part of their distribution will reassure you that the naysayers are outnumbered and can scream until they drop with no consequence for you.

What should you care for, then? What should guide your business in an open source project?

My answer is Pragmatism

What’s that? According to the Wiktionary pragmatism is The pursuit of practicality over aesthetic qualities; a concentration on facts rather than emotions or ideals.

And, how do we apply this principle? Look at the data around you. Go to an open source convention. Enter any conference room. Looking from the speaker’s stand point, the room is speckled with the apple logos of Macintosh laptops. Go to the back of the room, and you will spot probably more Windows than Linux screens in the audience. And yet, most of those people are enthusiastic open source adopters. It’s just that they are not fanatically splitting the world between free and non free, like someone would like them to do. Most of the free software and open source users are just pragmatic. They use open source because it works well. A large part of Firefox users don’t even know that it is open source. They only know, by their experience, that it works better than IE, and they could not care less if the source is available or not. The truth is that the open source development model, which can produce high quality software, is not necessarily coupled with a definite open source monetization process, or even with open source awareness from its users.

Pragmatic users choose their hardware and software based on user friendliness. And this could be anything, depending on the user’s level of expertise and personal wishes. It could be the number of features, the ease of customization, or the compatibility with existing software and hardware, a good environment for playing games or for coding C++ applications. The definition can be anything.

In this crowd of pragmatists, there are some who like the project also because it’s open source. But the product must be good in the first place. I doubt that users may love a project that sucks or is a pain to use, just because it is free, open and liberally distributed. So, once you have a good open source product, then you will find a core of users who like to participate in the project, by contributing code, bug reports, fixes, documentation, or by talking about it at conferences and user group meetings.

If your users are not pragmatists, I’d say you are doomed. If you make a product that only pure free software enthusiasts want to use because you discourage using it with non-free software, then you reduce your chances of doing business, and you will be serving a niche of very happy users who are oblivious of their material problems, and they will let you wonder how to solve yours.

Summing up: before asking if a project is really truly and perfectly open source according to the purest principles, ask yourself these two questions:

  • Is the product making its users happy while prospering economically?
  • Who would really benefit from forcing the product makers to embrace purer principles?

DISCLAIMER I work for MySQL at Oracle. The opinions in this  article are my own, and not necessarily those of my employer.
(Giuseppe Maxia, MySQL Community Team lead at Oracle).

Related Posts