In today’s rapidly evolving markets, companies that consistently innovate, most quickly and at the least cost, will win. And, as you’ve seen in our ongoing series, using Open Source Software (OSS) enables rapid, low-cost innovation. But it can also introduce operational challenges and legal risks.
We’re at a point now that OSS has become such a mainstream phenomenon that not using open source almost certainly places your organization at a disadvantage. So you must learn how to navigate the challenges and risks in order to remain competitive.
“Open source is ubiquitous, it’s unavoidable… having a policy against open source is impractical and places you at a competitive disadvantage.” — Gartner.
In this post, we’ll explore how open source became the de facto way to build software. Then we’ll cover the challenges this new method of software development has introduced for organizations. You can download the entire series now in our Fundamentals of Professional Open Source Management sample chapter.
The open source development revolution
From innovative beginnings in academic research and the GNU tools project started roughly four decades ago, OSS has grown into a major phenomenon that has reshaped multiple industries. Today, there are more than 1.5 million unique open source projects offering terabytes of working code to software developers. The availability of these resources and the trends toward modular software and software reuse have radically changed the way most companies develop software.
Not so long ago, we developed most of our software products in-house. We might have used a few third-party components for connectivity to other systems or some specialized processing, but these were acquired through a carefully controlled procurement process.
Today, we develop more complicated software faster by using open source components freely available on the Internet. Most of our activity has shifted from specifying and implementing our own custom software to integrating already available working pieces. We only code the parts that are truly unique to our application.
But now, instead of a few carefully controlled code acquisitions, we are repeatedly downloading code from the Internet to evaluate, prototype, and integrate. Although this approach speeds up development, it has created some significant new challenges.
6 OSS operational challenges
While using OSS brings many advantages, it can introduce risks and additional operational complexity to software development lifecycles.
● Organizations must deal with many new software sources, including commercial and noncommercial suppliers – some use OSS acquired from hundreds of different sources.
● The cornucopia of available open source components drives a higher volume of third-party software acquisition decisions. Where are these decisions being made? Many developers are not qualified to consider all of the necessary aspects including software license analysis, but a heavy-weight process like the old procurement approach is too expensive and time consuming to apply to the new volume of acquisitions.
● Integration of a large number of third party components can create complexity. One area of complexity is software version consistency across multiple interdependent stacks of code.
● Open source projects run the gamut from amateur exercises to professionally developed and tested releases. Your organization must ensure that appropriate levels of quality are chosen for each application.
● How will your organization obtain technical support and updates for all of these different open source components? Healthy open source communities provide excellent support and maintenance, but the self-service model of open source requires consistent participation on the part of your developers.
● Commercial relationships can reinforce your requirements with suppliers by adding a financial incentive, but influencing open source project direction is dependent upon multiple aspects of participation.
In our final article, we’ll discuss the legal issues and risks that come when companies incorporate OSS into their own software projects. And we’ll introduce the spectrum of open source license types with which organizations should become familiar.