Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Why enterprises embrace open source

Bernard Golden | June 2, 2015
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.

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 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.


Previous Page  1  2  3  Next Page 

Sign up for Computerworld eNewsletters.