1.
The Coming Open Source
Sustainability Crisis
By Aaron Stannard,
CEO, Petabridge

2.
Summary
• Current and Past State of OSS
• The Real Business Risks of Open Source
• Incentives Matter
• Good and Bad Solutions
• A Warning

3.
OSS over Time
• 1950s – virtually all software is public domain
• 1960s – first proprietary software
• 1974 - US Commission on New Technological Uses of
Copyrighted Works deems source code "copyright"-able
• Late 1970s-1983 – commercial software boom. Practice
of shipping source code along with purchased software
largely ends. OSS relegated to academia and prior
public domain art.
• 1983 – Apple vs. Franklin determines that object code is
also copyrightable. GNU and Free Software Movement
starts. Shareware and OSS distributed via BBS systems.
• 1991 – first release of Linux.

4.
OSS over Time
• Mid 1990s – Apache HTTP Server, Perl, PHP, MySQL,
and more OSSed. Internet startups adopt heavily.
• Late 1990s – Microsoft recognizes threat of OSS;
engages in campaign of FUD, litigation, and embrace-
extend-extinguish.
• 2000s – OSS breaches into enterprise.
• 2010s – NoSQL movement, Docker, and mainstreaming
of OSS.
• 2020 – Present Day. Everyone uses OSS regularly even
in critical systems.

5.
Takeaways from History
• Open Source was initially defeated by
proprietary alternatives.
• Tide began to shift in the 1990s because
the economics changed.
• Professionalization of OSS in 2000s
sealed the deal.
• Today, most proprietary ecosystems can’t
outcompete the innovation from OSS.

6.
The Biggest Takeaway
Economics dictates proprietary vs.
OSS adoption – not philosophy and not
“community.” It all comes down to what
solves developers’ problems most
efficiently.

7.
OSS is Now Commonplace

8.
Why Do We Adopt OSS?
• Reduce costs – we can focus on our
business, not infrastructure
• Security – we can look at the code, see
what it does, and even fork our own
version if needed
• Agility – we benefit from bug fixes and
updates from other contributors and the
maintainers

9.
OSS IS NOT FREE
Business Risks of Adopting Open Source Software – Even in 2020

10.
The Business Risks of OSS

11.
Popularity is a Poor Measure for
Assessing OSS Risk
“16% of [popular OSS] projects faced at
least one TFDD; 66% of these TFDDs
happened in systems with TF=1, which are
55% of the projects.”
“On the abandonment and survival of open
source projects: An empirical investigation"
https://arxiv.org/pdf/1906.08058.pdf

12.
“Made by Microsoft” isn’t a
Great Health Metric Either
Project Name Url Github Stars Last Updated
Distributed
Machine Learning
Toolkit
https://github.com/micros
oft/DMTK
2.8k 07/24/2017
VS Tools for AI https://github.com/micros
oft/vs-tools-for-ai
317 09/03/2018
LightLDA https://github.com/Micros
oft/lightlda
808 12/18/2017
YAMS (Yet Another
Microservices Solution)
https://github.com/micros
oft/Yams
201 07/06/2018
CodeContracts https://github.com/micros
oft/CodeContracts
833 03/11/2017
Xunit-performance https://github.com/micros
oft/xunit-performance
173 07/23/2018

13.
Truck Factor is a Better
Measure
“Truck Factor” for Angular.JS Releases, Circa 2016
https://medium.com/@aserg.ufmg/what-is-the-truck-factor-of-
github-projects-bb0d5f019a6f

14.
Most Projects Have Low Truck
Factor
“Most open source projects have low TFs. In
a sample of 1,932 [popular OSS] projects,
57% have TF = 1 and 25% have TF = 2. The
highest TF in our sample is 26 developers.”
“On the abandonment and survival of open source projects:
An empirical investigation"
https://arxiv.org/pdf/1906.08058.pdf

15.
Why Do These Risks Occur?
• OSS projects are driven by a small
number of individuals (low truck factor)
– Core developers and maintainers are very
expensive to replace
– Worse the larger and older the codebase
• OSS developers are largely free
volunteers
– “You get what you pay for”
– The more successful an OSS project is, the
more expensive it is to maintain

16.
OSS Project Types and Risk
Level
Project Type Description Risk Level
Hobbyist Done solely at the pleasure of the original creators. Use
at your own risk
Highest
Side Gig Project was created to support original developer’s paid
work. Will be maintained so long as original developer’s
work does not change.
High
Ancillary Project Project was originally created as a component of a paid
product or service, but OSSed separately in order to
benefit from community adoption, maintenance, and
contribution.
Medium
Professional OSS
Project
The OSS project is, itself, a product that generates
income to support a business.
Low

17.
Abandonment Case Study:
DotNetty
https://github.com/Azure/DotNetty
- Originally developed by Azure IoT group
- Still used inside Azure IOT protocol gateway
- Project effectively abandoned as of October, 2019; Last NuGet Release:
2018. 1,500+ daily NuGet installs.
- Rumor: team switched to using Rust internally
- Used by Akka.NET and others, but can’t push updates without forking

18.
Abandonment Case Study:
DotNetty
• DotNetty was an Ancillary Project.
• Risk profile looked good – still included in
Microsoft’s own products.
• Looks like internal project and time
priorities changed inside company.
• Since October 2019:
– No issue triage from maintainers
– Unmerged PRs
– Can’t get ahold of maintainers via email

19.
Akka.NET: DotNetty
Replacement Options
• [High Uncertainty] Rewrite networking engine using
System.IO.Pipelines, BedRock, Etc
– Have to recreate functionality we already have
– Have to make upgrade seamless for end-users
– Re-benchmark everything
• Fork DotNetty, create new NuGet packages, new OSS
organization
– Very expensive to do without finding partners in rest of OSS
ecosystem
– Take on the burden of support for ourselves
– Becomes ancillary technology

20.
INCENTIVES MATTER
Risk is Created by Lack of Project + Business Alignment

21.
Why Projects Get Abandoned
• Maintainer Burnout & Detachment
– Project maintenance was done unpaid in
spare time, which is a limited resource
• Loss of Interest
– Project no longer brought personal
satisfaction to key developers
– More interesting opportunities arose
• Change in Business Priorities
– Maintainers now working in different
technologies, areas

22.
Projects Become Victims
of Their Own Success

23.
Adoption Risk is Driven by Lack
of Project + Business Alignment
• The lower the returns to the maintainers,
the less:
– Issue triage
– Professional product management (i.e.
backwards compatibility, SemVer guarantees)
– Application of engineering best practices
– Documentation
– Regular updates / CI
– Communication with consumers and
contributors

24.
Business Alignment =
Sustainability

25.
Petabridge OSS + Business
Alignment
NBench Akka.NET
- Ancillary project
- Sporadic updates
- Low truck factor
- 0% of revenue
- Professional OSS Project
- Frequent updates
- Higher truck factor
(employees)
- 95% of revenue

26.
More Business Alignment, Less
Risk

27.
PROBLEM
OSS Users
• Most users are “free
riders”
– Don’t contribute
– Don’t pay
• Companies don’t budget
for OSS
– Don’t budget developer
time for contributing
– Have legal barriers
preventing it in some cases
– Don’t budget $$ for support
OSS Maintainers
• Most maintainers have
nothing users can buy
– No support plans
– No proprietary add-ons
• Expensive to create
infrastructure / plans
• Risky – you’re basically
starting a business

28.
GOOD AND BAD SOLUTIONS
Helping OSS Consumers and Producers Align Incentives

29.
Bad Solution: Donations
• OpenSSL Heartbleed Bug in
2014
• Global infrastructure exposed
to security vulnerabilities.
Facebook, Amazon, and many
others exposed.
• Prior to 2014, OpenSSL
received ~$2,000 / yr in
donations.
• After Heartbleed…
• $9,000 / yr in donations.
• Few projects will ever be as
important or popular as
OpenSSL.

30.
Good Solution: Company OSS
Programs

31.
Company OSS Programs
• Allocate developer time to contribute to
OSS used by the company
– Company developers learn the code base
– Learn best practices & patterns from
maintainers
– Learn new tools (CI/CD, testing, automation)
• Allocate $$ towards OSS foundations,
organizations, specific projects
– Not all foundations are equally effective

32.
Good Solution: Buy Goods +
Services from OSS Maintainers
• Get additional value from adopted OSS
• Improve time to market
• Get support plans with service level
agreements
• Get patch priority on OSS updates
• Ensures longevity and higher truck factor
of adopted OSS

33.
Maintainers: Start Selling
Services
• Start with support
plans that include
SLAs and patch
priority
• Sell live training via
webinar
• Build “open core”
products on top of
OSS
• Use a platform like
https://sdkbin.com/ to

34.
A WARNING
“Little piggies get to live another day, hogs get slaughtered”

35.
Adapt or Disrupt
• OSS maintainers are starting to realize they
wield a lot of influence over corporate software
systems.
• Start shifting the culture in your organization to
stop free riding.
• Because OSS comes and goes with economics.
• If you like the status quo, make it sustainable by
raising truck factor (with contribution or $$)
• Otherwise, watch OSS change into a movement
with more draconian licensing and a lot less
“free”

36.
Further Reading
• https://aaronstannard.com/ - my blog
• https://sdkbin.com/ - NuGet + App Store
• https://arxiv.org/pdf/1906.08058.pdf - On
the abandonment and survival of open
source projects: An empirical investigation
• https://github.com/todogroup/survey/tree/
master/2019 - TODO Group’s OSS
program surveys