The open source dilemma

According to Wikipedia a dilemma “is a problem offering two possibilities, neither of which is unambiguously acceptable or preferable”.  In the case of open source, this is not quite accurate. There are certainly two possibilities, which I shall get to in a moment, but at least some people will feel that one or the other of these will be distinctly preferable to the other.

The possibilities I refer to relate to the distinction between open source products provided by proprietary vendors and open source products that are based on projects from Apache or the Linux Foundation or whoever. The essential difference is that anybody – at least in principle – can contribute to the code base of the latter, while in the case of proprietary products this may be possible in theory but in practice future product developments are completely under the control of the vendor, which means that product development goes in the direction that the vendor wants rather than the community.

Actually, this description is simplistic: the support for community developers to contribute to the environment varies widely, from almost nothing to extensive, but the fundamental truth is that these companies are primarily using “open source” as a licensing model, as opposed to a model that supports community-based development.

So, here is a question: why do we call these things – which are essentially different – by the same name? The answer, of course, is that all these products or technologies are available via one or another of the open source licenses. However, we should really make a distinction here. It is typical that open source software licences mean including the source code, which you are free to modify and change. However, Apache licenses do not require companies using Apache Software to distribute any changes made to the code or to contribute that code back to the community. GPL-based licenses, on the other hand, do have such requirements. As a result, the big corporations like Apache licenses and developers prefer GPL.

Further, if you license software from Talend, say, and then modify the source code, what does this do for your support contract? I don’t think I need to answer that question. The short answer is that open source software from otherwise proprietary vendors – typically known as the “Enterprise Edition” – is not really “open” in the true sense of the word at all.

Now, this is not to decry the approach taken by proprietary suppliers: if you want your Ford garage to provide conventional warrant cover for your car, you don’t go and put a Ferrari engine in it and expect the warranty to still stand. But the proprietary approach is, essentially, different from true open source. So, shouldn’t we really have a different name for these things? Certainly, we should. But it’s not in the marketing people’s interest to invent such a term. While they are usually happy to invent new jargon and new acronyms, here they want to be tarred with the open source brush. What would really be interesting would be an “openometer”, measuring just how open different products and vendors really are. The scale could range from zero (open in name only) to one hundred percent. 

Suggestions for scores for relevant products and companies are welcome. If we get enough we’ll publish the results.