A lot has been written for and against open core now. Yet in the end, a couple tweets can catch all that is needed:
scurryn @h_ingo -- So as long as 'an open core vendor' doesn't call themselves 'an open source vendor' then everything's fine?
h_ingo @scurryn: pretty much. I think I owe everyone one more blog post to answer that question with a few more details.
(Twitter)
This is that blog post.
I'm fully aware that what I'm about to write will sound like someone is trying to tell you how to live your life. Like the pope, say. This is not the point of this post, but I know I will be blamed for that. Even so, I think it is a fair question to ask: So you complain a lot that open core is unacceptable, please rather define what is acceptable?
The below is an attempt to answer that question. It is my first attempt at doing so, and in general I believe it is anyone's first attempt at writing it up in public. I hope this can be a useful starting point for instance in the assumed scenario that the OSI needs to articulate some points in opposition against open core. Also, I will be aiming for completeness, so the list may contain some points which I may not even personally feel strongly about.
Comparing Apache vs MySQL brands with a User Story
Before going to the actual guidelines, I will introduce a useful tool from software develepment methodology: the concept of a User Story.
Let's consider a user that has heard about open source software and wants to find some, download it and use it. It is useful to compare Apache and MySQL software here, both well known open source brands, yet one is a fully open source community project (non-profit foundation) and the other a commercial company that in recent years developed into an open core vendor.
So here goes...
1. If you sell (mainly) closed source software, then you are not an open source vendor
...and if you're not a real open source vendor, don't market yourself as one. Don't call yourself "open source vendor", "leading open source vendor" or "open source company".
The open source community, both the individual activists and commercial companies who are true open source vendors have spent more than a decade of time and marketing dollars promoting open source. This has been very successful so that today open source software has a good reputation among IT users and customers and seen to have many unique benefits. In fact, the commercial companies benefit from the goodwill and evangelization done by individual volunteers who want to help promote open source vendors. It should be no surprise that these individuals and companies have an incentive to protect this valuable brand. In this case we want to protect the open source brand from being watered down by accepting that an 'open source vendor' could also be a company that (mostly) sells closed source software - the direct anti-thesis of what open source is all about.
The user who wants to perhaps purchase commercial support for his open source software, would of course look for open source vendors to do so. From the users point of view it amounts to deceit if after purchasing such a support subscription, from a company claiming to be the world leading open source vendor in its field, the user suddenly realizes he is being offered closed source software again.
It seems that the inventor of the term "open core", Andrew Lampitt, actually had exactly this solution in mind when he coined the term. Unfortunately, his idea did not materialize, rather open core vendors still today continue to market themselves as open source companies. (Presumably this is because they want to associate themselves with the open source brand to enjoy the same benefits and value as true open source companies get from it.)
2. Don't mix closed source software and open source software into the same product name or brand
...or if you do, the end result of the mix is closed source, not open source, so don't call it open source.
Here again, the user story is instructive. Suppose the user asked me: Is Apache open source? Then the answer would be: Yes, it is.
Then ask: Is MySQL open source? Unfortunately the answer here is ambiguous at best: No, unfortunately not everything known as "MySQL" is open source, only some parts are.
To compare, a closed source software which includes also code from the Apache project - such as IBM's Websphere - has a different name, so it is never confused with actual Apache software, and nobody has ever erroneously claimed it to be open source.
To continue the user story... if the user goes to apache.org to download software, he is guaranteed to find only open source software there. By contrast, when he goes to mysql.com, he will actively be offered closed source software which is also called "MySQL Something". Thus, for an open source activist, it is questionable if he even wants to recommend his friends to visit mysql.com website.
As with the previous point, if the vendor markets his open core product as open source, it adds up to deceit and it waters down the open source brand in general.
I fully expect this point to be met with furious resistance. The main value in the open core model is precisely that the vendor builds a strong and ubiquitous brand with the open source part, which he then wants to monetize by selling closed source products under the same brand. Even so, it is this practice that is a threat to the open source brand in general, since the user gets the impression that also closed source can be open source. (From here an interesting further study could be made into companies that have been essentially open core, but did separate the open and closed parts into separate brands, such as PHP and Zend, OpenOffice and StarOffice, or PostgreSQL and EnterpriseDB.)
3. Don't call "open core" an "open source business model"
This point is in line with the two previous ones, but targets the analysts and bloggers such as myself who like to categorize different models. I have the impression that management at least in many of the recent startups believes they are following an open source business model with open core, after all "[we] are just doing what MySQL did". For educational purposes it would be important to clean up our language so it becomes clear that this is not an open source business model.
This shouldn't be confused with the fact that nowadays also proprietary software companies all use open source. It is certainly useful to analyze and categorize how companies such as Google, IBM or Microsoft use open source in their products. This just shouldn't be confused to imply that Microsoft has an open source business model.
I'm personally also guilty of this point (even in this blog post I'm calling MySQL an open source company, which it of course once truly was, before going open core). I also don't have a good suggestion what to call it instead, possibly something like "open source strategy". (-> "Our strategy is to tactically use open source in our proprietary products when it gives us savings in R&D.")
4. Don't take an open source project and then drive it into a closed source direction
Many of the best known open core brands started as pure open source projects and were then "taken over" by investors and management that started driving it into a closed source direction (making it open core).
It can be argued that we have no right to make this kind of claim. After all, we all agree that the copyright owner has the right to license his software as he wishes, including taking it closed source. Even so, from an open source perspective, it is of course sad when that actually happens. I suggest here it is reasonable that the open source community at least not encourage and idolize such behavior. (More drastic measures would of course be things like forking the project just to change the name.)
(By comparison, it is usually met with rejoicement and positive commentary, if a product that was previously closed source, is made even partially open source. Of this there are many examples.)
5. Linux distributions and download sites (such as Sourceforge) shouldn't promote the open core brand by distributing the open part
The 3 main Linux distributions (Red Hat, Ubuntu, Debian) are all fully open source enterprises as are many smaller distributions. Hence it is in their interest to defend the open source brand against attempts to water it down to include also closed source software. (Being "more open" is a competitive edge for these companies and projects.)
The main Linux distributions are perhaps the most important channel also for an open core vendor. If distributions wanted to actively combat the open core trend, they could forcefully do so by shutting out the open core brands. (This would make sense especially in the scenario that I don't expect open core vendors to pick up on my advice from point 2. above.)
There is some precedent for distributions doing this. Red Hat has always been very strict in keeping its distribution free from closed source kernel modules and other software. It is obvious that by strongly promoting only open source software, Red Hat also gains an advantage as they cannot be held hostage by, say, a closed source nVidia module. Debian has taken a stance against Mozilla's restrictive trademark policies and simply renamed Firefox to make the issue go away. This is what could be done with open core packages too, we obviously want to continue using and promoting the software that is open source, but it would be technically quite easy to rename packages to use only "truly open source" names and trademarks. Like one commenter said: I don't see that Canonical would keep pushing Eucalyptus crippleware for long.
I personally think this is a very radical though perfectly realistic step, and it is not yet necessary to go this far. At this point the wider FOSS community is still waking up to the realization of what open core is. (The discussion on groklaw can probably be taken as a good estimate for what the average FOSS enthusiast currently thinks: "I started reading and had no idea what "Open Core" meant.")
So what needs to be done now is to educate the community to first know what open core is, then identify the vendors that are doing it. Probably many executives of the smaller startups don't even know their business model doesn't qualify as open source, they are just copying what MySQL and others did before them. Once people know about this issue, it will already have some effect as open core vendors need to reconsider if the closed source software is so valuable to them that it offsets the loss of community goodwill. Some will probably start rethinking their business model (it's not difficult, after all, if you just choose to care), and there will perhaps not be a need for the big artillery.
Epilogue: So if I do all the above, then it's actually ok to do open core?
Well, yes. I mean, there is still plenty of proprietary software in the world. User and customers for the most part continue to use and buy it. Nobody will hate you if you do it too.
What's better, most of us in the open source community will still feel positively about the fact that you publish part of your software as open source, even if you are not prepared to go all the way with it. Big software companies like IBM, Oracle and Microsoft all contribute to some open source projects, and their collaboration is well appreciated, even if their main software business is proprietary. So if you feel that open core is a good model for you, then by all means try it out, just understand that it is not an open source model.
Or, like I said in my next tweet:
h_ingo @scurryn: Then of course I also don't recommend proprietary software just in general, but that's a completely different discussion.
- Log in to post comments
- 35451 views
time for a new topic
I think it is time for a new topic. Write about the good work that MariaDB is doing in terms of work in progress, future progress and community building. Write about the Open Database Alliance. Write about how MPAB and its partners are solving problems for customers.
ODBA will do
Hi Mark
I'm on leave, I have no idea about MariaDB :-) (But you're right, I don't see anyone blogging about MariaDB since I left... they deserve to be kicked in their behinds.)
I will actually write about the ODBA, but the weather is too nice right now.
For what it's worth, I already intended to leave out planetmysql from this one, but since I ended up using MySQL as the example, I dutifully tagged it MySQL still. I personally believe this topic brings nothing new to the MySQL community, nor will it change anything about MySQL. But it is important to the general open source community and will continue to stir up discussion for a year or two. Most in the open source community are only now hearing about open core and learning what it means. So this post was not particularly targeted at anyone in MySQL, sorry for disturbing.
Good stuff
Glad to see someone progressing the conversation beyond "open core is bad because I say so". Hopefully this list can at least act as a starting point for reaching some sort of consensus about what is "acceptable".
Even assuming there was a significant consensus, the big question is whether it would be in any way enforceable, and by who. But that's a whole other matter.
As for the list itself, it seems to me (5) is throwing the baby out with the bathwater, while I'm not sure that the statement "Many of the best known open core brands started as pure open source projects..." is actually true, but that's just that's just me.
Personally I have tried to avoid using the terms "open source business/vendor/company" or "open source business model" in our research for some time, although old habits die hard. My view is that very few companies (if any) have an "open source business model" while every technology company in the world has an open source strategy (whether they know it or not).
Matt
Thanks
Good if you feel it can be useful.
I think we actually agree on most things, once the details are straightened out. For instance, it is obviously true that "the market" will decide what kind of software it wants to buy. This is true in general for open source vs closed source too. But the open source community has all the rights to define what is open source and what isn't. These two statements are not contradictory.
But "enforceable" is of course a good question. Like O'Grady already wrote, the enforcement to a large extent amounts up to "bitching about it", but the effect of this should not be underestimated. For instance Sun had to give up on closed source backup because of community badwill.
(5) would indeed be more like a nuclear weapon. Analogous to Firefox/IceWeasel, it's something Debian could presumably do, but other distros are likely to resolve this issue more amicably. (And it's not even something I'm advocating any time soon anyway, it's there for completeness.)
What about proprietary code delivered as a service?
Agree with all the above.
One thing that is not clear to me is how proprietary features/functionality delivered as a service (e.g. Canonical Landscape, Nuxeo Studio) is apparently exempt.
While they are not, according to the definition, open core, it seems to me they are just as much stretching what is "acceptable". If you are going to draw a line, why stop at open core?
Matt
Why is "proprietary web service" better than open core?
This is an interesting question and I can give many answers. Before that I think we should first just agree that open core defined as a model where proprietary software gets distributed to customer premises is a well defined concept, and the reasons why the open source community would object to it are elaborated in the parent blog post. The border between open core and "proprietary web service" should be apparent to anyone (distributed sw vs web service). So the question is just "why is the other one not objectionable too", one should not infer (like Mårten and other open core proponents want to do) that open core should be acceptable as open source too, since the other category is.
So, to actually answer the question then...
I should clarify that when writing about values of the open source community, I always approach the subject as something I observe to be de facto values around myself. The process of explaining why something is or isn't accebtable/ethical/etc is then reverse engineered onto that observation. By no means have I ever tried to write anything where I promote my own values as something others should affect. (I of course typically share the values of the FOSS community, but my approach to writing about the is as laid out here, not just "becuase I say so".)
To also explain by analogue: I don't think there is an absolute truth to whether being a vegetarian is more ethical than not being one, but we can clearly observe that a group (or many different groups) of people believe so and we can construct arguments in the domain of ethics as to why it might be so.
So for instance in this case, we can observe that Red Hat Network is a "proprietary web service" business model around an open source product, and the open source community has not objected to it and Red Hat is still considered an open source company.
To then answer why this is... may or may not be possible at all (since a community could have developed purely irrational and inconsistent values) but I'm happy to try and make guesses...
My first answer is that since you can easily distinguish open core from "proprietary web service", then one can conclude that "it may be debatable how strictly the line should be drawn, but it can at least be drawn here". By this I mean that the open core practice of distributing closed source software is what we easily recognize as the traditional proprietary software business, and this is clearly what open source and the OSD challenges. If there should be some form of open core where distributing "only a little" proprietary software should be seen as beneficial to open source, then there is no clear line to draw anymore. And the experience from MySQL tells us the vendor will just continue to add more proprietary modules, essentially "as much as they can get away with".
At the same time web services kind of are "just a website", no code is distributed, so it is kind of a different space and unaddressed by the OSD. In a sense, you could say that for purposes of OSD, a web service is something that has "not yet been distributed to anyone" so you cannot yet determine if it is open source or not (which is silly, but underlines the point of different problem space). Btw, the more high level "four freedoms" of RMS could easily be applied to scrutinize services too and the verdict would probably come out negative...
Hence, the first answer is that "proprietary web services" have historically been acceptable because they couldn't be easily identified as apparently objectionable.
I think a more enlightening explanation is that there are natural limits to what is practical to provide a customer as a web service, and therefore "only allowing" web services as a pure open source business model sets an effective limit on how much lock-in or degradation of user freedom can happen. As a clear example, one can guess that all of the biggest Red Hat customers do not use Red Hat Network, but rather install a Red Hat Satellite instance in their own premises. So for this reason Red Hat had to actually distribute the code for Red Hat Network to the customer and for many years actually was not fully open source. Some years ago they then published the Satellite code to stay true to their original commitment that everything they do will be open source. It is notable that a) the community "looked away" from this practice of Red Hat and b) it doesn't seem to have in any way risked Red Hat's business that they published the Satellite code as open source. (Since the value eventually is not in the code, it is in the software updates provided through the system.)
I believe Canonical's Landscape has a similar onsite version, and again the community seems to be "giving some slack" to Canonical by looking away from this anomaly. If one wanted to be strict, one could use this to categorize Canonical as the objectionable kind of open core. The few cases I have seen this brought up fit the theme of competing by being more open: it is brough up by Fedora/Red Hat proponents, and otoh Canonical employees will tell you Red Hat only open sourced Satellite to highlight the fact that Landscape is not open.
Your example of Titanium Appcelerator is another great reason to be carefully optimistic about web services. At best, these vendors end up innovating new services that truly provide some genuine value to the customer, where the value is somehow inherent in the being a service. (Such as compute cycles of a cloud, or data or statistics provided from the cloud, etc...) Of course, one could then argue that the code to such services should still be open source. Even so, even with closed source such services are at least "less annoying" than closed source feature in the distributed product, since there is some genuine value to feel good about, whereas witholding source from some software the customer installs on his own premises is more "in your face".
Finally, it could be that the community's reaction can be explained to a large extent by such semi-irrational feelings as the desire to allow these companies to make money, as long as they commit to a vague Google-like "do no evil" mantra, in essence that they are good and friendly enough. For instance I can observe from myself and friends at MySQL AB, that we resisted MySQL Enterprise Monitor with lesser passion, because you could argue that monitoring is not really crucial to running your database (and monitoring can be seen to fit into the theme of a support subscription, it kind of allows the customer to do some self help and avoid support incidents), whereas we strongly fought against the closed source online backup, which we saw as a standard and core database server feature. This was also the only incident that caused public outrage, the opposition against the monitor remained internal. (Which in hindsight is regrettable, there is so much MySQL discussion hidden from the wider community, which seems to be emblematic to open core.)
In line with this, my shorter answers to this same question usually end with something like: But this is an interesting trend to follow, and if it at some point seems like these services are becoming a threat to user and developer freedoms, then maybe the FOSS community will start objecting to those models too, and fighting them with tools like adopting the Affero GPL license more aggressively.