Tidelift sponsored this post, as part of a TNS sponsorship package.
Open source has become the modern application development platform. Across industries, more than 90% of professional applications today are created using open source code. Yet many of these open source components are maintained by individuals or by independent, community-led organizations — not corporations. The Babel compiler, Vue.js framework, gulp streaming build system, Active Admin framework and Beautiful Soup Python library are only a few examples of the thousands of individually maintained components widely used in modern applications.
While these open source components are critical to corporate application development, unpaid community maintainers often don’t have the time or incentive to update them, apply security fixes and address licensing concerns as quickly as corporate users would like. And an alarmingly high number of open source packages — between 10 and 20 percent by some measures — have absolutely no one keeping them maintained. These aren’t obscure components — roughly 20% of dependencies in boilerplate React, Angular and Vue applications, for example, go unmaintained.
So Who Is Keeping this Code Healthy?
The sad truth is that today most development teams manage their open source dependencies themselves. If you are a developer using open source components, you probably recognize at least a few of these time-consuming tasks:
- Adapting to bugs or breaking changes in an updated dependency.
- Moving to a new major version of a framework or library.
- Dealing with bugs, security, or licensing issues related to an unmaintained dependency.
- Dealing with issues caused by missing or unresponsive maintainers.
These issues are a constant time drag and an unwelcome diversion of developer resources. Instead of spending time and energy writing original code that benefits the business, developers spend their time wrangling open source components. In fact, our research based on the results of our 2019 professional open source survey shows that fully one-quarter of the time developers spend on code maintenance is related to maintaining open source dependencies — and it’s even higher for the largest development teams.
Outsource Complexity: A Radically Normal Idea
Handing over the management of complicated, ever-changing, non-differentiating parts of a company’s stack is a time-honored tradition in software. After all, it wasn’t that long ago when developers and infrastructure engineers predominantly operated their own data centers.
Think back to the era before cloud computing, when launching a SaaS application meant renting space at a colo facility near an Internet POP, buying and installing servers and networking gear and configuring all of the software. When something went wrong, the team might first try out-of-band management. If that failed, they would make one unlucky person get on a plane, replace the faulty gear and then reinstall and reconfigure the software.
Cloud providers have made things infinitely easier. Competition for developers’ business drives relentless improvements in provisioning speed and functionality. This means application developers can focus on developing applications, not monkeying with VMs, IO, interconnects and all the other necessary but non-differentiating plumbing that goes into infrastructure.
Which raises the question: why are we still managing our open source dependencies ourselves?
Implementing a Managed Open Source Strategy
Fortunately, there’s a revolution happening today in the way apps are built and maintained. Just as cloud computing upended the way companies approach application hosting — by turning it over to cloud hosting providers — development teams can now outsource the maintenance of the open source components their applications rely on to specialists, unlocking better outcomes at lower cost.
This effort has been dubbed “managed open source.” Just as a managed cloud service offers operational support for use of shared IT infrastructure, managed open source offers support for the open source software components commonly used to build applications.
A managed open source strategy can bring the same ease and order to this “wide middle” of most modern applications — the 70% of enterprise applications comprised of open source components.
How Does It Work?
The key to a successful managed open source strategy is finding the right people to tend to the wide middle of code that previously did not have a supported enterprise-class offering available. At Tidelift, we’ve found that those in the best position to do this work are the people who created and maintain the projects — the open source maintainers themselves.
The beautiful part of a managed open source strategy is that when maintenance work is organized in a standard way, the output can look exactly like what you might expect from a commercial software provider. You get clear, reliable promises that the open source software you are using is going to be well-maintained, both now and into the future. This helps ensure the code health of all the applications built on top of those open source components.
Companies no longer need to choose between bearing the costs of maintaining all of the open source they use or assuming the inefficiencies and risks of going without that verification. Just as cloud computing upended the way businesses approach application hosting, they can now outsource open source management to the experts.
Moving to a managed open source approach allows development teams to work on new features that drive revenue, instead of spending time wrangling open source dependencies. And over time, a managed open source strategy that pays the maintainers for their contributions in return for providing a valuable shared service makes open source work better — for everyone.
Feature image via Pixabay.