Imagine that you are designing the 2017 Ford Mustang. Like all gas-powered vehicles, each one needs an exhaust muffler. Ford has already vetted and narrowed in on a preferred provider of mufflers. But imagine what would happen if the designers and factory line workers could pick from any one of 20+ past versions of that exhaust muffler from any provider for the new model year—even if that part is outdated, has lower performance, does not meet current emission standards or has a known defect.
 
The designer could order it, place it on the vehicle, then ship it.
 
We all realize this scenario would never happen. No one would select an outdated, defective or poor-performing part for the product they are manufacturing, and no organization would give each of their designers and line workers free reign on procuring, installing and shipping any one of 20+ different exhaust mufflers for a single model year. Modern manufacturing processes would not allow for this approach. Nor would consumers accept cars built this way.
 
Ford is not taking this approach, but software development teams are.

Multiple Software Versions Don’t Make a V8

Software companies sourced an average of 27 different versions of open source components that they used in development last year. To be more specific, out of the top 100 open source components these companies downloaded from the Internet in 2014, they averaged 27 versions of each component.
 
Think about it. If they only used the best and latest version, they would only be managing 100 unique components. Yet, on average, they are electively sourcing 2,700 unique components.
 
While auto manufacturers like Ford have preferred suppliers of vetted parts, the procurement of open source components is often more of a free-for-all. If an organization has 300 developers, they effectively have a procurement department of 300 for sourcing externally developed software components. If you have 4,000 developers, you have 4,000 performing procurement. And that means some major bumps in the road.
 
Organizations like Google mandate the use of no more than two versions of a given open source component across their development teams. And at the recent DevOps Enterprise Summit (DOES15), Topo Pal, director of next-generation infrastructure at Capital One, said that his organization mandates only one version of each component be made available to developers through their repository managers. This is good practice, but it is the exception rather than the rule.



Speed at Any Cost Hampers Net Innovation

What does this mean for a software development organization—especially one focused on improving its DevOps practices? First the good news: Developers are using open source components to speed time to release and improve innovation. Both good things.
 
The bad news: Organizations are building mountains of technical debt through poor software supply chain practices—impacting quality, complexity, maintainability, supportability, etc.
 
Complexity tends to be the enemy of lots of things. Using fewer and better suppliers, using the highest-quality parts from those suppliers and tracking which parts went where can dramatically lower operational costs, improve agility and accelerate prompt responses when something goes wrong.
 
Technical Debt Grows at the Expense of Innovation
 
While open source components enable “speed”—a well-worn DevOps mantra—free-for-all sourcing and use practices add to a counterproductive technical and security debt that reduces net innovation and adds to the cost of operations. As technical debt grows, net innovation and business value drop.



Source: Application Portfolio Management, Quality and improvement by joapen
 
Organizations like Google, Capital One and other DevOps leaders are able to reap major benefits from stronger controls on component versions in play, resulting in sustained competitive advantages.
 
Ford has had more than 100 years to perfect the procurement process. The software industry is young by comparison but in terms of innovation moves much more quickly.
 
The benefits of bringing software procurement under control are very real. DevOps leaders are taking note of proven practices in traditional manufacturing to improve quality and lower costs through improved management of their software supply chains. Where other modern manufacturing industries have benefited dramatically by reducing complexity to improve quality and the velocity of operations, the opportunity is ripe to apply those same principles to software development.