The Paradox of Open Source Lock-In

Publicado el miércoles, 29 de agosto de 2012

How open is Open Source, and how free is Free Software?

Making decisions about the implementation of Open Source software in an organization is not easy, and misconceptions still abound to this day. The security that is offered by support contracts, often seem to be worth the money. However, for many small and medium enterprises the licence and support costs can be prohibitive, and it is most often these companies that either dare step into the open source field, or would be well advised to look into it.

There are many companies that target small to medium enterprises using business model where companies are enticed to try out their wares under a “community edition” of the software, and are offered the possibility to opt into paid support models later on. Prime examples that use this model to this day are SugarCRM [1], and OpenERP [2]. However, these models sometimes change. Alfresco [3] is an example of a company that once touted their community edition on their website, but has since been hiding their open source source further and further back in their documentation [4].

There are some risks involved when you opt for “community editions”. Below I will list three examples of what can go wrong, but also what the open source community is doing to remedy the situation. The cases studies include three levels of lock in: Customer Lock-In, Developer Lock-In, and Community Lock-in.

Customer Lock-In: OpenERP vs Tryton

Enterprise Resource Planning was all the rage in the 1990’s and companies like Microsoft, Oracle and SAP made made huge amounts of money for themselves, and for their implementation partners, and continue to do so to this day. For small business commercial ERP implementations seem prohibitively expensive, and there are a number of alternatives available.

One company that caters to small business with ERP software and implementation is OpenERP [2]. In step with many companies who use this model, they have a free Community Edition, a paid for Enterprise Edition with additional functionality and support, and a Software as a Service (SAAS) edition. This approach offers a hybrid model to both create and maintain software, while at the same time ensuring a steady source of income from it.

The problem is that the implementation of an ERP system is usually a hefty investment, often several times what would be paid for a licence. This is so because it requires a setup that is specific for your company and the way you work. And as you enter your business process data, invoicing, customer information etcetera to the system you will quickly reach a point where it is not easy to move to other software and you will at the very lease start to depend on updates.

And this is exactly where OpenERP has decided to suddenly leave you in the cold. For the update to the new 6.x version, the required update scripts for the database were not made available to the Community Edition users [5] [6].

A group of programmers decided that the way OpenERP was managed, and increasingly hazy licensing of the OpenERP code was more than enough reason to go their own way. They chose for a different approach and brought their fork under a consortium model, where no one participant owns the source code, but instead of consortium of developers and implementers manage the project together. This project is called Tryton [7].

In the talks that the founder Cedric Krier gave last year [8] the one thing that struck me most was the quality improvements that they managed to do as a small team. Unit tests, consistency in model separation, security – all items that you would like to audit as a company before you chose and ERP are shockingly behind what you would asume is there in something with a history as long as that of OpenERP [9].

The fork of OpenERP to Tryton is and example where getting locked in by Free Software can be undone by the development community using the product. But main question is how to avoid getting trapped in a customer lock-in in the first place. We will look at that after reviewing another example.

Developer Lock-In: MySQL vs MariaDB

Customers or users can get locked-in indirectly. And this seems to be a very possible outcome for the immensely popular MySQL [10] database. Even though the extensive use of MySQL might suggest that it is a Free and Open Source (FOSS) project, it is not. The owner of MySQL is Oracle, and recent development suggests that they are making it more difficult for developers to rely on the free Community edition, but instead may need at least the Standard Edition (that costs USD 2000,- per year) [11].

What is happening? Well, much like upgrade scripts are essential to end-users or their system maintainers, documentation and test-cases are essential for developers. And Oracle seems to have embarked on a drive towards withholding key documentation from the community [12]. And MySQL has a huge community of users, and many, many open source project based on it.

What this could potentially mean is that your vendor of Software as a Service will increase their fees, or that your vendor of an application that you have installed on your own hardware confronts you with the need to add a licence from Oracle to continue using his product.

The interesting thing is that the community of developers using (and a few contributing to) MySQL stepped in to remedy this problem and forked MySQL into MariaDB, in other words, they started out with the code MySQL code that was available under the GPL licence and continued to develop it as they saw fit under a different name. And they have been successful, MariaDB [13] is a “drop-in replacement” for MySQL that is maintained by a community of developers as a project, not as a product. This might even be an interesting tidbit should one of your suppliers claim to need to increase the bill because of MySQL licensing issues.

Concluding remarks

Making decisions about what technology to use is difficult. It is not necessarily true that any thing that is “open source” is free, nor that it is owned by anyone who downloads the source code. Free and Open Source Software (FOSS) comes in many different flavours, and if you have never looked into software licences, then it may be useful to get outside help. This is not only a problem of FOSS. Reading the Terms of Service of many software products and online services can be a scary thing to do (just a few: Dropbox has a “small number of employees who must be able to access user data”[14]; you never actually “buy” software from Microsoft (and many others) and “you must return it to Microsoft promptly upon request”[15]).

If you have time and then an excellent introduction to the world of FOSS is Producing OSS by Karl Fogel [16]. Especially the chapters on licensing models will give you some bearings to make an informed decision (chapter 9 – Licences, Copyrights and Patents) [17].

A basic check-list for the options you are considering is the following:

  1. Who owns the copyright to the software?
  2. What is the licensing model?
  3. Can you download the source code? If so, what copyright and licence notice do I see on top of each file? Is it the same as what they mention on their website and in their documentation?
  4. How many companies offer support for the software? Are any of them nearby? Are they affordable?
  5. What are my migration options? Are there paths to export-import my data from this application to another?
  6. Are there any current feuds in the developer/user community about this product? (use an online search engine)
  7. If there is a supplier who is selling a solution to me, does he focus on functionality (short term) or on the long-term availability and extensibility of the solution.

As I was writing I realized that it would take many pages to fully describe the arguments even for these few examples. There are many considerations and intricacies. And there is usually a good business case to be made for both proprietary software or FOSS. And there are risks to be evaluated in both cases.


[2] (1, 2)