The dilemma of open source

The author would like to thank Stephen A. Laufer, IBM Global Business Services Associate Partner, for his comments and improvements to this work.

I’m always struck when I hear great wisdom imparted succinctly; in the case of the open source dilemma, it happened when a former student remarked,

Open source has become a significant topic of conversation in the telecommunications industry as operators look to cut costs and quickly deliver new services and functionality. It offers operators a large body of freely available software developed, maintained and updated by the open source community. At first glance, this seems like an ideal way for operators to significantly cut the expenses associated with licensing and maintaining software, but, like all business decisions open source is not without its issues making it both a risk and an opportunity.

As the pressure to reduce costs while maintaining service levels increases, whether to use open source becomes a true dilemma which has many operators (and vendors) asking, “is open source a friend or foe?”.

The ‘downside’ issues can be significant and although many can be mitigated, the original questions around open source are often revisited. Is it the right direction for our business? Should open source be viewed as another software supplier, just with different policies on code development, management and monitoring? Should open source be viewed as synonymous with ‘free’, or ‘costly’? Questions such as these mean that many carriers and service providers continue to struggle with the dilemma of open source.

The bright side

The benefits of open source are as follows:

• Cost – open source is freely available to download.
• Quality – a community of people develop, test and maintain the software, ensuring it’s tested in many environments, which should ultimately result in more reliable software.
• Speed to develop and evolve – more developers add features concurrently, resulting in shorter development cycles through a more agile development method.
• Continuous improvement – a large community of developers constantly use and improve the software, theoretically contributing intellectual property and value to open source for all to share.
• No vendor lock-in – the software is used in multiple environments and developed on a variety of heterogeneous equipment.
• No license agreements – you can modify the software any way you want, without violating license agreements.

Risky business

Open source often presents the following challenges.

• Risk: Who is responsible if a piece of open source breaks a service level agreement or critical business function? You should consider everything from service failure to billing errors, fraud, traffic congestion and network outages.
• Liability: Who is liable for any losses? What if a critical function breaks or a system shuts down resulting in loss of life or other damage?
• Payback: Are you required to contribute any fixes or improvements?
• Limited strategic differentiation: With everyone using the same open source (maybe even the source code you contributed) how do you differentiate? Have you helped your competition by giving them code you developed, saving them both the time and expense of developing their own?
• Learning curve: Software developers need time to become familiar with the open source before they can adapt, modify, test and incorporate it into business functions. This means that open source may take more time than using off-the-shelf software.
• Risk of abandonment: Open source can be dropped by a community when something better comes along or if it is no longer ‘in vogue’. Many companies have corporate mantras along the lines of 'no customer left behind', but this is not true of open source communities.
• Security risk: When others can see how your systems and the corresponding source code work, they are better equipped to try and break them. Think about it – would a bank show a thief how their security systems and locks work? There is always the risk that weaknesses are exploited rather than a fix contributed to the community. Remember the CIA hacking tools released on WikiLeaks? In many cases, they exploited weaknesses in open source software, but little (or nothing) had been done to contribute any fixes back to the community.
• Version control: With many developers working on different versions of the source code, it can become difficult to keep track without some sort of centralized version control. This is why open source projects often have a person or organization ‘managing’ releases. The versions problem means that any custom or unique feature either must be contributed to the community, or added to the code with each new release.
• Release management: A solution built from multiple open source products, each with different versions that must be maintained and updated separately, can become overwhelming. The combinations of updates needed when a new version of an open source component is released quickly becomes an intractable problem. The Equifax operations team, for example, neglected to update the Apache Struts open source environment, which is used by many. This eventually led to a security breach exposing customers' data.

In a recent twist on the open source dilemma, AT&T released its Enhanced Control, Orchestration, Management & Policy (ECOMP) virtualization management software as open source. ECOMP was renamed to Open Networking Automation Platform (ONAP) when the Linux Foundation merged ECOMP with its Open-O project.

Many operators had been struggling with how to evolve their operational support systems (OSS) for a software-defined virtual environment; ONAP could be a viable option for operators that choose open source.

At first blush using open source looks like a very simple decision, it’s free to acquire and is maintained and upgraded by others for free. Nevertheless, there are risks and free may not mean free. Open source like any other piece of software has operational complexities such as security, source code control, version control and all the other issues described. Considering whether to use it at all, or having a plan in place to help offset issues is crucial to mitigate the risks and complexities that come with choosing to use open source.