The reality of enterprise open source development

This post was originally published on AIIM's Expert Blogs by Serge Huber, CTO at Jahia Solutions

********

In this blog post, I talk about the reality of building open source enterprise software, at least talking from personal experience.


Open source software is, at least from an engineering point of view, possibly the best way to develop software. After all it is quite similar to other industries that also have peer review mechanisms. With open code, anybody can become a reviewer, suggest improvements, find bugs, contribute documentation or even fork it to build something different or better. While the idea seems great from an idealistic point of view, it is everyday in conflict with the realities of corporate environments.

Enterprise open source software is a little different because it adds to the equation a part that is not required in “regular” open source projects : production-ready code. Because of this constraint, doing all the quality assurance and stress testing is a time-consuming, repetitive and sometimes complicated task. Not many “free-time” developers are very interested in such tasks, and this is usually why most enterprise open source software is backed by one or more commercial companies, that have different vested interests in the development of such solutions.

Infrastructure software, such as back-end server software is a good candidate for enterprise open source software development, since different companies, even competing ones, might agree to share resources to develop the pieces they all need, and will differentiate on higher pieces of software logic. Such is the example of the Apache Jackrabbit project, an implementation of the Java Content Repository API, and that is used as the storage backend for multiple competing companies such as Adobe (formally Day), Hippo, Magnolia and of course my own : Jahia.

Collaborating on infrastructure makes a lot of sense, but what about higher pieces, closer to the UI ? Using an open source strategy for enterprise software can be a good way to promote the product, and also makes sure it is easy to get feedback from users as to what works and what doesn’t, since there is no initial cost associated with testing the product (I should mention that here I am only talking about free, as in beer, open source software). When going to production, it is usually recommended to actually purchase support and maybe even contribute back to the project by adding modules or extensions.

A lot of open source software builders hope to build communities around their open source product, but this is usually a lot easier said than done. For less-known projects, the bootstrapping of the community could take some time, simply because getting known in today’s web is not easy when competing against large players that have large marketing budgets. Another reason is that a lot of companies also sell commercial support on top of the open source product, and so they should, so they will try to avoid cannibalizing their commercial support offering by avoiding to answer community questions. This is a mistake since in a small (but growing) community, new users are often important and should be encouraged. So in reality a fine line must be found between the vendor participating in the community he is trying to grow, and the commercial support offerings, that are one of the profit areas.

It has been my experience among open source developers that there is usually a mutual respect between competing companies. I have met many developers from our competitors and we all agree on the importance of open source software, in some form or another, and like to differentiate on products and features, while sharing knowledge and experience when it makes sense.

For the enterprise customers, they gain both the potential to quickly evaluate and test an open source platform, while at the same time gain the immunity of existence that open source software offers, while also get the possibility to choose the support offering that fits them the best. It is therefore also important that they understand the business model of open source software and that they do not simply think of it as “getting something for nothing”, but rather “get something very high quality for a very interesting price”.

Serge Huber

Serge Huber
Serge Huber

Serge Huber est co-fondateur et directeur technique de Jahia. Il est membre de l'Apache Software Foundation et président du comité de gestion du projet Apache Unomi, ainsi que co-président de l'OASIS Customer Data Platform Specification.

Retour