By Bernard Golden, CIO contributor
I just finished attending two conferences: the Cloud Foundry Summit and the OpenStack Summit. Both were hives of activity, with attendance well up on the previous event. Most striking to me was the significant presence of large enterprise IT decision-makers — architects, directors of applications and operations, and even a sprinkling of CIOs.
And, despite the fact that both events were held in good-weather locations (Cloud Foundry in Santa Clara and OpenStack in a spectacular Vancouver waterfront convention center), these enterprise IT attendees were on no corporate boondoggle — they were attending to evaluate how these open source products could help them meet their organization’s responsibilities.
These examples illustrate something I’ve been seeing for a while — enterprise IT has a large and growing commitment to open source products in preference to proprietary alternatives.
The advantages of open source
This is an interesting and (from my perspective) welcome development. Enterprises appreciate the advantages of open source-licensed products because they offer:
- Greater transparency. Not only is the source code available, all of the design deliberations, etc., are out in the open, in contrast to the secretive processes of proprietary vendors. It’s easy to assess the product and its community and determine if using the product is a good decision.
- Greater innovation. Open source development reflects Bill Joy’s law: No matter who you are, most of the smartest people work for someone else. That’s true for all software vendors, so using a product with a potentially much larger developer base enables access to greater innovation. There’s another way this is true, however: By allowing anyone to contribute code, it allows an open source product to incorporate unusual use cases, which a proprietary vendor would either ignore or dismiss.
- Greater ability to affect product direction. It’s a cliché of the software industry: those who spend the gold get to steer the boat (bit of a mixed metaphor there, I admit). If you’re a small customer of a significant proprietary software vendor, you better hope your product objectives align with the vendor or its large users; otherwise, your feature requests will get tossed in the circular file. With open source, you can directly interact with developers to present your use cases; if important enough, you can contribute code that implements your desired functionality.
A good fit for containers
Moreover, open source licensing models are a much better fit for Third Platform applications. Their inherent load variability means that new instances/containers are being started and stopped all the time. This presents an enormous challenge to proprietary code products, as they are typically licensed on a perpetual basis per instance/container. If an application has extremely high use over 10 percent of its lifespan, that means buying a lot of licenses that are rarely used. Proprietary licenses are a good fit for static applications with stable use profiles.
By contrast, open source licenses are a much better fit for the Third Platform world. With no per-server/container cost, applications can be designed to support high load variability with no cost constraints.
My belief is that Third Platform applications will come to represent the majority of applications, which means that open source will come to dominate new applications; in fact, I would go so far as to say that the heyday of the proprietary infrastructure independent software vendors (ISV) is over.
Considering open source for your enterprise?
Given that open source will be a key feature of enterprise IT going forward, here are some key items to keep in mind:
- Identify your key open source components. While open source will be spread throughout your applications, certain components will represent critical dependencies. Those are ones you need to be certain about regarding their maturity, community size and robustness, and openness to code contributions and feature suggestions. For those components that represent dependencies, understand that you are, in effect, getting married. You can be just as locked-in to an open source product as one that is proprietary, so keep your eyes open. Before going whole-hog on a critical component, decide if you are willing to live with it for a long time.
- Build open source skills. Being fully engaged in open source is much more than downloading and installing a software component for an application. Understanding the development pace, likely sparseness of documentation, and need for self-reliance is all part of adopting an open source product. You need staff that are more willing to be engaged with a product and its community; people who expect a traditional vendor “pick up the phone and call support” relationship are unlikely to be successful in an open source-based environment.
- Decide what to contribute and what to keep internal. For any code you write, make a decision about where to place it. If you contribute it to the product (and go through what may be a challenging contribution process, depending upon the product), your code will become part of the product and be present in future releases. You’ll be expected to keep it current, which means an ongoing commitment — which is far less than the work you’ll take on if you don’t contribute your code, which requires re-integration with every release.
- Watch out for the new legacy. Many IT organizations leverage open source components to build new applications, forgetting that those applications become an ongoing engineering commitment. I see this in the Docker space, where many IT organizations, excited by the potential of Docker, have built home-grown DevOps toolchains that string together open source components. Three years from now, when the original engineers are long-gone and the undocumented system is a hot mess, you’ll learn that open source can result in legacy just fine. Just because it’s free and malleable doesn’t mean that you should automatically decide you’re in the open source-based application business. Every line of code you write becomes an ongoing responsibility. Decide where you want to take on that responsibility and, in areas that don’t provide functionality or business differentiation unique to your company, look to a commercial offering that takes responsibility for integrating and updating the application and all its open source components.
The state of affairs of enterprise IT is changing quickly. Open source will become a much higher percentage of every IT organization’s environment, given its advantages in terms of cost, control, and innovation. Likewise, open source skills will soon become a critical requirement, both for using open source wisely, but also in attracting the kind of talent necessary to compete in a Third Platform world.
This article was written by Bernard Golden from CIO and was legally licensed through the NewsCred publisher network.