In June of 2019, Tidelift and The New Stack jointly fielded a survey of professional software developers. Almost 400 people responded with thoughts about how they use open source software today, what holds them back, and what tools and strategies would help them use it even more effectively. In particular, with this survey, we were interested in learning how a managed open source strategy might help developers reclaim time, speed up development, and reduce risk.
In this post, we share the fourth of eight key findings. If you don’t want to wait for the rest of the results, you can download the full survey report right now at the link below.
In a previous post, we saw that code maintenance activities like refactoring, debugging, rewriting functionality, and fixing technical debt take up about one-fifth of respondents’ work week. We wanted to break this time down a bit so we could better understand exactly what sorts of maintenance activities caused the greatest challenge for developers. For this question, respondents could select all of the maintenance challenges that applied to their organization.
The number one maintenance challenge, cited by almost 60% of respondents, is moving to a new version of an open source library or framework. This is followed closely by adapting to bugs or breaking changes in an updated dependency, which 52% of respondents cited. But unlike moving to a new major version, this maintenance challenge can sometimes have even more urgency, since it isn’t always an activity that developers can anticipate.
After these first two common challenges, there is a bit of a dropoff before the next two, which both relate to either unmaintained open source packages or unreliable maintainers. Looking at the data more closely, if we analyze how many people selected one of these two choices, more than half (53%) of respondents report dealing with at least one of these issues related to unmaintained open source code.
The number one maintenance challenge, cited by almost 60% of respondents, is moving to a new version of an open source library or framework. This is followed closely by adapting to bugs or breaking changes in an updated dependency, which 52% of respondents cited.
Less common issues include getting a feature added in a dependency (faced by 28% of respondents), responding to a security issue in a dependency (26%, meaning it isn’t the biggest draw on time, but probably critical when it does happen) and providing the legal team with licensing information or responding to legal-related questions (13%). Legal challenges are much more common in companies with more than 1,000 employees, with double the percentage of respondents (27%) highlighting this as an issue.
So the maintenance issues that steal time from developers—time that they’d probably rather spend writing or improving code—usually stem from either moving to a new major version of a framework, adapting to bugs or breaking changes caused by an updated dependency (including the dreaded dependency hell!), and dealing with issues related to an unmaintained or under-maintained dependency.
It begs the question: Could we better solve some of these issues for developers by taking the maintenance tasks off of their plate? And at the same time create the incentives that lead to a world with fewer unmaintained or under-maintained dependencies causing security issues and other headaches?
This is exactly what a managed open source strategy is designed to do. With managed open source, developers offload some of this time-consuming maintenance work directly to the project maintainers, who in return are compensated for tackling some of the thornier maintenance issues in a proactive way. The more organizations that employ this sort of managed open source approach, the better our open source software infrastructure will become.
Want the full survey results in one report? Get them here now.