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).

Be Sociable, Share!

9 thoughts on “Open to the core – The pragmatic freedom

  1. Hi Giuseppe

    You already have at least 2 blogs, why write here? Anyway, I won’t spend energy on much discussion here, since your article doesn’t seem to bring much to the table that wasn’t argued and counter-argued already. But I’d like to make one correction, hopefully you’ll find this helpful:

    quote:
    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:

    a. 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)

    :end quote

    Option a is not correctly classified. I’m not aware of anyone arguing that dual licensing wouldn’t be a “pure” and fully acceptable open source / OSD compliant business model. (It would be an interesting separate discussion to explore why this is, but the opinion here seems to be unanimous.) This is not to be confused with the critics who say dual licensing is a bad business model for making lots of money, or bad for having a really thriving community, but nobody is arguing it is not “pure” open source. (The OSD does not require you to make X amount of money or even to develop code efficiently.)

  2. This is the classic Eric Raymond v Richard Stallman debate that has been going on for over a decade now. In the real world the realist trumps the idealist every time.

  3. Very well written. Good stuff.

    You’re right- the absolutely zealous approach to having extremist purity from the FLOSS community is a little confusing. It really is something that people should think twice about before speaking.

    However there is one extremely significant point that was omitted here… There is a problem when there is an open source/free counterpart to a software suite (or application, etc etc) but is incredulously limited (to the point where it’s no better than a demo) and the company providing it takes more from the community than it gives. I know such a case is rare, but it does happen. Luckily most open source devs are smart enough to not invest into a project after they realize the company they are dealing with is basically using them.

    I mean, the Qualcomm 2D/3D kernel-side driver being open sourced is a prime example to this. David A from Redhat himself felt the insult of this himself. I know this does not -directly- compare to what you’re talking about, but the idea is the same.

    A lot of the community is pissed off at the ‘open core’ approach that attempts to explot the community rather than work with it. This is a fundamental difference that can be seen in much of the FLOSS folks’ outrage.

  4. it’s one thing to simply not open source something in it’s entirety, it’s another to prevent people from being able to program to it or hinder it. Really, how hard is that to figure out?

    Additionally, pragmatism? Your argument for pragmatism is full of anything but. I’d say it’s more an emotional argument than a logical one, honestly.

  5. >> In the real world the realist trumps the idealist every time.

    In the real world idealists trump practicals every time, over the course of hundreds of years. Look at the Levellers, look at Tom Paine, they might have gotten beaten back but most of their ideals came to be implemented. Just wait and see.

    What is interesting is that most extreme pragmatists actually get angry and upset that idealists have any sort of voice. They seem to think that we should shut up and be quite and stop rocking the boat. Idealists tend to ask hard questions that are not easily answered.

    Well there is a time for strategic compromise and there is a time for dialectic problem solving. The problem with most pundits is that they’re not able to do either and instead must worrble on inaccurately with no added thoughts to the conflict at hand. The author here isn’t a pragmatist, he’s just a pundit.

  6. Pragmatism does not always trump freedom. Free software has not lost to open source. Both are still here thriving nicely.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>