The intersection between the cloud and open source is a well-discussed topic among cloud providers and users. From its earliest days, public cloud had its roots in open source, which allowed providers like Amazon to build low-cost and highly scalable services. The discussion starts to get more interesting when it shifts to the intersection of open source and enterprise infrastructure. Extrapolations from the public cloud world are made about the future of enterprise software, and these have become so intellectually appealing that they refuse to die even if the reality isn’t quite so clear. Everyone wants to believe that it is easy to build large, complex systems entirely based on open source and the cheapest, most commoditized hardware possible, and thus circumvent the IT status quo. It has been a long time since my first attempt at using open source (or free) software, but I find that, although the offerings are much broader today, the experience remains remarkably similar.
The key to understanding the experience is to understand correct usage of the word “free” in “free software.” By now, anyone who has ever had to wrestle with a piece of open or free source code in order to make it work knows that “freedom” brings with it a lot of baggage. In this case, freedom from licensing hassles and lock-in forces us to another completely different sort of bondage: rather than being an end user of software, it is easy to end up becoming its developer and maintainer. Although this may seem unpleasant if you are a developer and you suddenly have a lot of unexpected work to do, it can be a much bigger surprise if you are an IT leader and find yourself owning a massive product development initiative you may not have signed up for.
The main point to remember is that building and delivering mature technology is nearly a zero sum game. While there are some very mature and stable open source platforms out there, the bulk of what you get is actually largely incomplete or un-tested, especially for your specific use case. The result is always that the last 20% of the work – the hard stuff that no one likes doing – ends up happening in your own environment. This means that experts need to be hired or retained, and ongoing investments will be required. Moreover, depending on the license and whether your use is internal to your company, you will probably decide not to share all of your hard work with the community.
There are a couple of interesting implications of this open source/enterprise reality. First, just because other companies have developed technology using open source, it doesn’t mean that they are going to share it in the public domain-- or that you are going to get the benefits of their intellectual property or operational experience. Just like the service providers trying to build AWS competitors from Eucalyptus or OpenStack source, enterprises will always have to develop their own “secret sauce” to make open source-based projects work. More important, it’s highly likely that the cost of ownership of building and maintaining a technology out of open source vs. buying an off-the-shelf alternative might be closer than enterprises expect when the additional expenses and risks are taken into consideration. (In fact, depending on use cases, even building a technology from scratch might be comparable in cost to using open source).
The intersection between open source and enterprise infrastructure shows up most clearly when enterprise IT teams build open source-based private clouds and realize that they have taken on a much larger challenge than initially expected. Not only is it more of a serious time and money commitment upfront to get the cloud to work as planned (and to meet the demands of users who have been trained on the public clouds), but once the cloud is built, it requires a growing software development team with the deep expertise for scaling and adding features to the open source platform they have built. Cloud and open source may be many things, but free is not one of them.