The 2019 Tidelift managed
open source survey results
E I GH T KE Y FIND ING S ILLUSTRATI N G HOW TO MAK E O PENS OURC E WORK EV EN B ET TER FOR D EVELO PERS
September 2019

INTRO DUC TIO N

In June of 2019, Tidelift and The New Stack jointly fielded a survey ofprofessional software developers. Almost 400 people responded with thoughts
about how they use open source software today, what holds them back, andwhat tools and strategies would help them use it even more effectively.
Software developers and engineers account for 51% of respondents, with
DevOps pros an additional 12%. Company size was well represented, with 34%
of respondents working at a company with up to 50 employees and 25% atcompanies with more than 1,000 employees.
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 report, we’ll share eight of the mostinteresting findings that illustrate ways to make open source work even betterfor developers.

2 | T H E 2019 T I D E L I F T M A N AG E D O P E N S O U R C E S U R V E Y R E S U LT S

FINDING # 1

Despite its overwhelming advantages,
open source adoption is inhibited by concerns
about the availability of reliable support
In a previous survey, we learned just how pervasively open source software isused by professional developers today, with 92% of applications using open
source components. Open source has surely become the default stack formodern developers.
In this survey, developers compared open source and proprietary software
in a number of different areas. The results roundly confirm why developers
prefer open source. In every area except one—reliable support and consulting
services—open source came out ahead of proprietary software.

Comparing open source and proprietary software
PROPRIETARY IS BETTER

Technology ﬂexibility/
extensibility

3%

Developer
satisfaction

5%

OPEN SOURCE IS BETTER

86%
81%

Total cost ofownership

8%75%

Development
speed

10%

73%

Quality of
code

5%

Security

68%
13%

61%

Functionality

14%

59%

Performanceand stability

14%

52%
36%
38%

Reliable support/
consulting services
0

20

40

60

BASED ON 376 RESPONSES

3 | T H E 2019 T I D E L I F T M A N AG E D O P E N S O U R C E S U R V E Y R E S U LT S

80%

According to respondents, the number one benefit of open source istechnology flexibility and extensibility, with an astounding 86% agreeing that
open source is better. This is followed closely by developer satisfaction, where
81% say that open source is their choice.
Open source also is preferred by significant margins when it comes to total
cost of ownership (75% for open source to 8% for proprietary), development
speed (73% for open source to 10% for proprietary), quality of code (68% foropen source to 5% for proprietary), security (61% for open source to 13% forproprietary), and functionality (59% for open source to 14% for proprietary).
On performance and stability, the results are more mixed. While only 14% see
proprietary as better (compared to 52% for open source), a full 30% view thetwo as about the same.
The only area where proprietary software is seen as slightly better is in
the availability of reliable support and consulting services. Nearly 40% of
respondents report proprietary software as stronger in this category, versus
36% for open source.
Given the vast advantages of open source in all other areas the survey explored,
closing this “support gap” by creating open source support and consulting
services on par with the technology’s perceived quality represents the last
hurdle before open source completely eclipses proprietary software.
Fortunately, efforts like the movement toward managed open source are
narrowing the gap by combining the best elements of the proprietary model—
like support and maintenance under a contractual service level agreement—with all of the existing benefits of open source. The industry is making progress,
but these results show there is still more work to do!

4 | T H E 2019 T I D E L I F T M A N AG E D O P E N S O U R C E S U R V E Y R E S U LT S

The onlyarea where
proprietary
software isseen as slightly
better is in theavailability of
reliable support
and consulting
services.

FINDING # 2

Developers’ biggest concern with
open source is risk regarding how wellprojects will be maintained into the future
We asked developers to what degree a set of commonly described issues
prevents them from expanding the use of open source in their organizations.
Of the issues we highlighted, the most pressing fall into the categories ofmaintenance, security, culture, and licensing.

Obstacles to increasing use of open source
Risk about how
well thepackage will bemaintained

Identifying/
remediating
security
vulnerabilities

Concern overlicensing/compliance70%60Lack of open
source culturein theorganizaton

Difﬁculty
hiring skilledemployees

Policy about
using open
sourceprojects

Policy about
contributing toopen source
projects

76%
64%

50

63%
55%

53%

40
30
20
10
0

BASED ON 320 RESPONSES

5 | T H E 2019 T I D E L I F T M A N AG E D O P E N S O U R C E S U R V E Y R E S U LT S

45%
39%

Perhaps the clearest finding from this question is that 46% of respondents
indicated risk about how well packages will be maintained into the future iseither a major or a moderate obstacle, with another 30% indicating that it is aminor obstacle. Only 18% said that this is not an obstacle for them at all.
The next most pressing issue stopping developers from expanding theiruse of open source is concern about identifying and remediating security
vulnerabilities. More than one-third, or 37% of respondents, indicated that
this is either a major or moderate obstacle, with another 25% considering it
a minor obstacle.
The findings regarding issues with licensing and compliance match theresults from our previous surveys, where some organizations view this as a
critical obstacle, while others see it as minor. This issue comes in second
to maintenance risk as an identified obstacle, but 30% of respondents only
consider it a minor obstacle, so just not as urgent as many as the other issues
highlighted above.
The most mixed response is around the issue of open source culture in theorganization. Many people—43% of respondents—do not see this as an issue
at all, but 53% think it’s an obstacle to some degree. This finding shows thatmany organizations have embraced an open source-friendly culture and arereaping the benefits, while others are left behind.
The findings from this question highlight the opportunity for open source todevelop new strategies like managed open source to reduce maintenance,
security, and licensing risk. Companies such as Red Hat, Elastic, and Cloudera
recognized long ago that the way to help businesses deploy open source
technologies successfully was to make promises about the future that were
worth paying for in these three areas. Making these same assurances available
not just for operating systems and data stores—but for the vast array of open
source components used by application developers—represents one of themost promising opportunities for commercial open source.

6 | T H E 2019 T I D E L I F T M A N AG E D O P E N S O U R C E S U R V E Y R E S U LT S

46% ofrespondents
indicated risk
about how wellpackages will
be maintained
into the futureis either a major
or a moderateobstacle, withanother 30%
indicating that
it is a minor
obstacle.

FINDING # 3

Developers spend more time maintaining,
testing, and securing existing code thanthey do writing or improving code
We wanted to use this survey to get a detailed view of how developers spend
their time.
We gave them six categories in which to bucket their time and asked themto estimate the percentage of their work invested in each category.

How developers spend their time
Writing new code
or improving
existing code

Meetings,
management
and operations

32%
Code
maintenance23%

Testing

Security
issues

4%

Other

19%

12%

9%

BASED ON 295 RESPONSES

While this might not be surprising to developers, it is perhaps disheartening
to see that respondents spend less than one-third of their time writing newcode or improving existing code (32%). Respondents spend 35% of theirtime managing code, including code maintenance (19%), testing (12%), andresponding to security issues (4%). Another 23% is spent in meetings and on
management and operational tasks.

7 | T H E 2019 T I D E L I F T M A N AG E D O P E N S O U R C E S U R V E Y R E S U LT S

Breaking the data down by job description gives us an even clearer view.
Software developers spend 22% of their time just doing code maintenance.
They also spend a higher percentage of their time writing new code or
improving existing code (39%) and a much lower percentage of their timeon operational tasks and in meetings (14%).

How developers spend their time
SOFTWARE DEVELOPER/ENGINEER
Codemaintenance

Writing new code
or improving
existing code

39%

22%

Meetings,
management
and operations

Testing

15%

Other

7%

14%

3%
Security
issuesSOFTWARE DEVELOPMENT/ENGINEERING MANAGER
Codemaintenance

Meetings,
management
and operations

16%
30%

Testing

Other

11%

11%

Writing new code
or improving
existing code

28%

Security issues

5%

DEVOPS ENGINEER/MANAGER
Codemaintenance

Meetings,
management
and operations

18%
34%
Writing new code
or improving
existing code

Testing

Other

8%
24%

Security issues

9%
7%

BASED ON 295 RESPONSES

8 | T H E 2019 T I D E L I F T M A N AG E D O P E N S O U R C E S U R V E Y R E S U LT S

Respondents
spend 35% of
their time
managing code,
including code
maintenance(19%), testing(12%), andresponding
to security
issues (4%).

Not surprisingly, people who manage software developers spend twice asmuch time in meetings as do the people they supervise. DevOps engineers
and managers spend even more of their time in meetings (34%), partly
because they are facilitating communication between different teams. They
also spend twice as much time (7%) responding to security issues, which will
be of no surprise to those familiar with the DevSecOps trend.
We also asked respondents to share the percentage of the time they spend
on code maintenance related to their open source dependencies. The answer
is right on target with the results in a previous survey (25%). But once we lookat the data by number of developers in the organization, it presents an evenstarker picture. In organizations with over 500 developers, the percentageof time devoted to maintenance activities rises to 32%, which might bedue to maintenance issues becoming more complex as the codebase andapplications get larger.

Maintenance time
related to open source

25%

of software
maintenancetime is spenton opensourceInorganizations
with more than
500 developers
this number
jumps to32%

BASED ON 243 RESPONSES

This data makes one thing very clear: there is a huge opportunity fororganizations to find new ways to increase the percentage of time theirdevelopers spend writing code. What more can be done to makedevelopers more efficient so they can spend less time on activities likecode maintenance?

9 | T H E 2019 T I D E L I F T M A N AG E D O P E N S O U R C E S U R V E Y R E S U LT S

FINDING # 4

Time-consuming code maintenanceactivities create challenges, often due
to issues associated with poorly maintained
open source dependencies
The survey shows 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 downa bit so we could better understand exactly what sorts of maintenanceactivities caused the greatest challenge for developers. For this question,
respondents could select all of the maintenance challenges that applied totheir organization.

Biggestopen source
maintenancerelated
challenges

59%
Move to a
new major
version of aframework/
library

52%
Bugs orbreakingchanges in an
updateddependency

13%
53% ofrespondents
face lack ofmaintenanceissues

Dealingwith legal
issues39%

26%
Responding
to a security
issue in adependency

28%

Getting a feature addedin a dependency

30%

Bugs/
security issues
related to an
unmaintained
dependency

Issues caused by missing or
unreliable maintainers

BASED ON 249 RESPONSES

10 | T H E 2019 T I D E L I F T M A N AG E D O P E N S O U R C E S U R V E Y R E S U LT S

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 isfollowed 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 moreurgency, 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 thenext 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 tounmaintained open source code.
Less common issues include getting a feature added in a dependency (facedby 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 morecommon in companies with more than 1,000 employees, with double thepercentage of respondents (27%) highlighting this as an issue.
So the maintenance issues that steal time from developers—time that they’dprobably 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 orunder-maintained dependency.
It begs the question: Could we better solve some of these issues fordevelopers 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?

11 | T H E 2019 T I D E L I F T M A N AG E D O P E N S O U R C E S U R V E Y R E S U LT S

The number one
maintenancechallenge, citedby almost 60%
of respondents,
is moving to
a new versionof an open
source library orframework.

FINDING # 5

Project activity, licensing, and maintainer
responsiveness are key factors in choosing
open source projects
Given the maintenance headaches respondents described in earlier findings,
one obvious way to avoid them is to make good package choices in the firstplace. In the next part of our survey, we asked developers to tell us more about
how they make decisions regarding which open source packages to use.
The first question on the subject asked how important some key projectcharacteristics are when developers select packages.

Key factors when choosing open source packages
Unimportant

Important

Acceptable open
source license

4%

86%

Activity volume(commits, pulls, etc...)

3%

86%

Maintainer
responsiveness3%

Established policies
and documentation

80%

72%

11%

Welcomingcommunity

9%65%

Number of disclosed
vulnerabilities

8%

63%

BASED ON 320 RESPONSES

12 | T H E 2019 T I D E L I F T M A N AG E D O P E N S O U R C E S U R V E Y R E S U LT S

When it comes to choosing packages, licensing is the most crucial issue:
61% of respondents said having an acceptable software license is extremely
important. An additional 25% report licensing is somewhat important, for a
total of 86% rating open source licensing as either extremely or somewhat
important. Only 4% of respondents don’t see this as an important issue.
This is particularly meaningful for companies with more than 1,000
employees, where 78% of respondents say having an acceptable open source
license is extremely important. These findings clearly show that there aresome “dealbreaker” licenses out there that most users attempt to avoid.
While activity (e.g., recent and volume of issues, commits, and pull requests)
tied with licensing in overall importance (86%), it had a lower percentage
rating extremely important (43%) than licensing.
Also important when choosing open source packages is maintainer
responsiveness, which 80% of respondents view as either extremely importantor somewhat important when selecting an open source package to use.
This is followed by established policies and documentation (e.g., codeof conduct, contributing guide), with 72% of respondents rating thischaracteristic as important.
The last two items in order of importance were having a welcoming
community (65% rated as important) and number of disclosed vulnerabilities(63%). While neither of these ranked as high as the other options, it isinteresting to note that almost two-thirds of respondents still view these as
key factors to look at when choosing open source projects.
We wanted to dive deeper into how developers analyze project activity. So for
those who rated this as a key characteristic, we followed up by asking themwhich of the following activity metrics are most important to them.

13 | T H E 2019 T I D E L I F T M A N AG E D O P E N S O U R C E S U R V E Y R E S U LT S

When it comesto choosing
packages,
licensing is themost crucial
issue: 61% of
respondents
said having
an acceptablesoftware license
is extremely
important. An
additional 25%
report licensing
is somewhat
important, for a
total of 86% rating
open source
licensing as
either extremely
or somewhat
important.

Most important metrics for evaluating
open source projects
Days since last activity
Recommended by trusted source
Number of contributors
Maintainer reputation
Number of commits

61

%

54

25%

21%

74%

Number of clones or forks

51%%

BASED ON 303 RESPONSES

Overall, 74% consider the number of days since last activity when deciding touse an open source project. While this is a low bar for respondents to think aproject is in an active state, it does quickly eliminate many projects.
Another followup question asked what length of time since the last activity(e.g., commit, issue) would concern them when evaluating the health of anopen source project. The results plotted in an even distribution curve, withthe largest contingent of respondents falling into the “more than threemonths” category.

14 | T H E 2019 T I D E L I F T M A N AG E D O P E N S O U R C E S U R V E Y R E S U LT S

Length of inactivity considered concerning whenevaluating an open source project
More than 3 days
More than 1 week

4%
6%
19%

More than 1 monthMore than 3 months

23%
19%

More than 6 months
More than 1 year
More than 2 years

17%
6%

BASED ON 302 RESPONSES

Other important factors respondents consider when evaluating an open
source project include being recommended by someone they respect (61%),
number of contributors (54%), and the maintainer(s) having a good
reputation (51%).
Overall, these data points show that developers put a lot of thought into how
they choose their open source packages, knowing that good choices will help
them avoid maintenance, security, and licensing headaches down the road.

15 | T H E 2019 T I D E L I F T M A N AG E D O P E N S O U R C E S U R V E Y R E S U LT S

FINDING # 6

Most developers contribute toopen source projects, and many
would do even more if fairly
compensated for their work
We also wanted to learn how developers contribute to open source projects
themselves. First, we asked respondents on average how much time they
devote to open source contributions.
We were surprised to learn that most respondents (84%) view themselves
as active contributors, with only 13% saying that they contribute to an open
source project less than once a year and just 3% saying they never contributeto an open source project.

How often do developers
contribute to open source?
22%

36%

26%

13%

3%

BASED ON 286 RESPONSES

16 | T H E 2019 T I D E L I F T M A N AG E D O P E N S O U R C E S U R V E Y R E S U LT S

This high percentage is the result of sample bias—our initial qualifying
question asked whether respondents use open source software to build
applications at work, so all respondents are open source users already.
We still believe it is an interesting and useful finding just within the subset
of developers who use open source to build applications at work. It showsthat there isn’t a rigid line between users and creators of open source, butinstead perhaps more of a continuum, where most developers are bothcreators and users, with some falling closer to one end or the other of theuser-creator spectrum.
We next asked how much time they contribute to open source on a weekly
basis. As you might expect, results vary widely. The average respondent
spends over six hours a week contributing, although the majority spend
less time than that.

Time spent contributing to open source projects

31%

Less than an hour per week30%

1 to 5 hours

6 to 10 hours

14%
11 to 20 hours

5%

More than 20 hours

BASED ON 278 RESPONSES

17 | T H E 2019 T I D E L I F T M A N AG E D O P E N S O U R C E S U R V E Y R E S U LT S

13%

There isn’t arigid line
between users
and creators ofopen source,
but instead
perhaps moreof a continuum,
where mostdevelopers areboth creators
and users, withsome falling
closer to one
end or theother of theuser-creator
spectrum.

Several other questions delve into this subject for more detail. Four-fifths of
respondents would spend more time contributing outside of their day job ifthey were fairly compensated for their work, with 25% estimating they would
spend an additional 20+ hours per week. Clearly there is an appetite among
contributors to work more on open source if there was a better way for them
to be compensated.
When asked roughly what percentage of their time contributing to open
source was done as part of their job, the average response was 40%. People
who contribute less than that amount reported that they would be more likely
to spend a higher percentage of their time outside of their jobs participating inopen source projects if they were fairly compensated.
This shows that developers who contribute to open source, without it beinga significant part of their day job, might step up their open source work if theright incentives were in place. We estimate that the hours contributed per
week to open source would increase by over 40% if respondents were fairly
compensated for their non-job-related efforts.
What kind of conclusions can we draw from this data? Right now, many ofthe people writing and maintaining open source components are doing
this work without being compensated. Yet an astounding 84% of developers
using open source in their professional work consider themselves to be
active open source contributors, at least to the level of more than one
contribution a year—and fully one-third contribute code more than oncea week. If there was a better, more consistent way to pay open source
contributors for the work they do, would more of these developers become
project creators and maintainers?
We believe so. Fortunately this is a problem that the managed open source
model is well positioned to solve—putting the proper incentives in place forcreators and maintainers of open source software to do their best work—andmaybe even attracting a new class of creators and maintainers to open sourcein the process!

18 | T H E 2019 T I D E L I F T M A N AG E D O P E N S O U R C E S U R V E Y R E S U LT S

FINDING # 7

Almost half of organizations havepolicies requiring commercial
support for the software they use
It’s the age-old managerial objection to using open source: “But who are
we going to call when something breaks?” While in the early days of open
source, this was a common refrain with the suit-and-tie crowd. Now, thanks tocompanies like Red Hat, Elastic, and Cloudera, which provide enterprise-class
support and assurances for open source, this objection has become muchless common with some heavily used open source projects.
Yet, for the vast majority of open source components used to build
applications, there is no commercial organization backing them up. We
wanted to learn more about how larger organizations handle this conundrum.
Are they required to have a vendor backing up all of their open source
dependencies? Or do they self-support and take on the risk themselves?

Do organizations require commercial support
for the software they use?

29%

of 50+ employee
organizations require
support for all
software, including
open sourcecomponents

18%

require support
for software withthe exception ofopen sourcecomponents

Almost half of 50+ employee
organizations require vendor support
BASED ON 153 RESPONSES

19 | T H E 2019 T I D E L I F T M A N AG E D O P E N S O U R C E S U R V E Y R E S U LT S

Like other open source policies we asked about, many respondents are unsure
if their organization requires commercial support for software components.
A full 24% have no idea whether their organization mandates commercial
support for any type of component used in a production environment.
When we look at companies with more than 50 employees, 29% have policies
in place requiring commercial support for all software components, including
those that are open source. An additional 18% have policies in place requiring
commercial support for any components that are not open source. This meansthat almost one-half of organizations with more than 50 employees require
some sort of commercial support option for the software they use.
This raises a question: Why the gap between commercial support of open
source and proprietary components? Why would an organization that needs
commercial support for software components exclude open source?
The likely answer is that it is because developers don’t have to go througha traditional procurement process to download freely available open sourcecomponents, skipping their legal and procurement departments entirely by
installing a package at the command line. Where procurement doesn’t have amechanism to pay, they cannot limit usage.
Is this OK? At some point this lack of oversight might come back to hauntthese organizations, as it has for companies like Equifax.
One other possible explanation is that these companies aren’t yet aware of
any option that will give them support and assurances for the open sourcecomponents that aren’t backed by large commercial open source vendors.
Even if they have a checkbook in hand, they don’t know who to pay.
Fortunately, a managed open source strategy can help address this problem.
With managed open source, an organization can pay one vendor to getenterprise-grade coverage for the vast array of open source packages theyuse, across common ecosystems like JavaScript, Python, Java, Ruby, andmore. As more organizations that require support for their software understandthe benefits of managed open source, hopefully this “but who are we goingto call when something breaks?” issue for all open source components finallybecomes a thing of the past.

20 | T H E 2019 T I D E L I F T M A N AG E D O P E N S O U R C E S U R V E Y R E S U LT S

Almost one-halfof organizations
with more than
50 employees
require some
sort ofcommercial
support option
for the software
they use.

FINDING # 8

The key benefits of a managed
open source subscription involve
maintenance, security, and licensing
In our previous findings, we’ve highlighted some of the issues developers
face when using open source today. Developers love using open source, andwould like to use it even more. But several important things stand in the way.
We learned that the biggest concern they have with open source is theavailability of reliable support. The biggest reason why they don’t use
even more open source today is because of concerns about how wellcomponents are going to be maintained into the future. We learned about
how maintenance challenges are sucking up their valuable code-writing time.
And we learned about the havoc that unmaintained or undermaintained andunacceptably licensed components can wreak in an organization.
So how might developers tackle some of these challenges so they cantake advantage of the many benefits of open source, and use it even more
effectively in their organizations?
One answer is by employing a managed open source strategy. Managed
open source provides a way to help organizations better manage all of theopen source software they use, ensuring it is up to date, secure, and wellmaintained, while providing standard commercial assurances like support
under a service-level agreement and intellectual property indemnification(you can learn more about the approach to managed open source Tidelift
takes here).
We explained managed open source as a concept to our survey respondents
in order to understand which of the key benefits of a managed open source
approach were most appealing to them.

21 | T H E 2019 T I D E L I F T M A N AG E D O P E N S O U R C E S U R V E Y R E S U LT S

Key benefits of managed open source
High value

Average value

15%
75%

Low or no value

15%
74%

5%

Ensuring open source
packages are wellmaintained

59%
12%

5%

Ensuring open
source packages
are secured

26%
46%

23%

18%

Commercial service-levelagreement backed the people who
created/maintain the packages

Ensuring packages areproperly licensed withterms acceptable tothe organization

28%
37%

17%

Intellectual property
indemniﬁcation

BASED ON 278 RESPONSES

While all of the benefits were seen as worthwhile by respondents, the mostvaluable should come as no surprise because they directly address many of
the challenges developers face when using open source components.
The most valuable benefit of a managed open source subscription is that ithelps ensure that open source packages are well maintained into the future.
Three-quarters of respondents agreed that this benefit is either high value or
extremely high value.
This is followed closely by ensuring that open source packages are secure,with 74% rating this benefit as either of extremely high value or high value.
This is also the benefit with the most ratings for extremely high value (38%).

22 | T H E 2019 T I D E L I F T M A N AG E D O P E N S O U R C E S U R V E Y R E S U LT S

The most
valuable benefitof a managed
open source
subscription
is that it helps
ensure that
open source
packages arewell maintained
into the future.
Three-quartersof respondents
agreed that thisbenefit is either
high value or
extremely highvalue.

The third most valuable benefit of a managed open source subscription
is around ensuring components have a license that is acceptable to theorganization, with 59% of respondents reporting this as either extremely highvalue or high value.
Companies with more than 1,000 employees are much more likely to think allelements of a managed open source subscription are valuable, but security
stands out with 56% reporting that it is extremely valuable.
The evidence from this survey is clear. Developers are eager to make evenbetter use of open source components. But there are critical issues aroundmaintenance, security, and licensing that stand in the way and need tobe addressed.
A managed open source strategy can solve many of these issues, making iteasier than ever for developers to expand their use of open source, improvetheir confidence in the open source they use, and get time back to focus on
the important work that really drives their business.

23 | T H E 2019 T I D E L I F T M A N AG E D O P E N S O U R C E S U R V E Y R E S U LT SABOU T TH IS SU RV E Y

The 2019 Tidelift managed open source survey was conducted from June 24
through July 7, 2019. Participants were contacted via Tidelift and The New
Stack email lists and social media. We screened respondents to make sure theyuse open source to build applications at work, and the full survey sample was
369 respondents.
Thanks to The New Stack, and in particular Head of Research Lawrence Hecht,
for helping analyze and produce these findings.
ABOU T TIDE LIF T

Tidelift makes open source work better—for everyone
Through the Tidelift Subscription and in direct partnership with maintainers,
Tidelift is a single source for proactively managed open source components
and professional assurances around those components. Tidelift makes it
possible for open source projects to thrive, so we can all create even moreincredible software, even faster.

ABOU T TH E TID EL I F T S UB S C R I P T I ON

A managed open source subscription backed bycreators and maintainers
The Tidelift Subscription manages your dependencies for you, delivering all of
the capabilities you expect from commercial-grade software, for the full breadthof open source you use.
➜ We provide the tools you need to continuously catalog and understandthe open source software that your application depends on.
➜ We partner with and pay the open source community maintainersof the exact packages you use, to ensure they meet the standards
you require.
➜ We address issues proactively, not only scanning for new security, licensing,and maintenance issues, but also working with our participating open source
maintainers to resolve them on your behalf.
➜ We help you measure and improve your open source dependencies’ health—which improves your app’s health—and give you a short list of high-impact
steps your team can take to improve them even more.
➜ We add commercial assurances that don’t come for free with open source
packages, like intellectual property indemnification and support under aservice level agreement. You expect these guarantees from proprietary
software, and you should get them when using open source as well.

Request a demo and learn more: tidelift.com/subscription

24 | T H E 2019 T I D E L I F T M A N AG E D O P E N S O U R C E S U R V E Y R E S U LT S