The Coming Open Source
Sustainability Crisis
By Aaron Stannard,
CEO, Petabridge
Summary
• Current and Past State of OSS
• The Real Business Risks of Open Source
• Incentives Matter
• Good and Bad Solutions
• A Warning
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.
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.
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.
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.
OSS is Now Commonplace
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
OSS IS NOT FREE
Business Risks of Adopting Open Source Software – Even in 2020
The Business Risks of OSS
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
“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
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
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
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
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
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
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
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
INCENTIVES MATTER
Risk is Created by Lack of Project + Business Alignment
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
Projects Become Victims
of Their Own Success
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
Business Alignment =
Sustainability
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
More Business Alignment, Less
Risk
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
GOOD AND BAD SOLUTIONS
Helping OSS Consumers and Producers Align Incentives
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.
Good Solution: Company OSS
Programs
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
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
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
A WARNING
“Little piggies get to live another day, hogs get slaughtered”
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”
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

The Coming OSS Sustainability Crisis

  • 1.
    The Coming OpenSource Sustainability Crisis By Aaron Stannard, CEO, Petabridge
  • 2.
    Summary • Current andPast 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 Economicsdictates proprietary vs. OSS adoption – not philosophy and not “community.” It all comes down to what solves developers’ problems most efficiently.
  • 7.
    OSS is NowCommonplace
  • 8.
    Why Do WeAdopt 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 NOTFREE Business Risks of Adopting Open Source Software – Even in 2020
  • 10.
  • 11.
    Popularity is aPoor 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 isa 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 HaveLow 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 TheseRisks 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 Typesand 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 isCreated by Lack of Project + Business Alignment
  • 21.
    Why Projects GetAbandoned • 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 ofTheir Own Success
  • 23.
    Adoption Risk isDriven 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.
  • 26.
    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
  • 27.
  • 28.
    PROBLEM OSS Users • Mostusers 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
  • 29.
    GOOD AND BADSOLUTIONS Helping OSS Consumers and Producers Align Incentives
  • 30.
    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.
  • 31.
  • 32.
    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
  • 33.
    Good Solution: BuyGoods + 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
  • 34.
    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
  • 35.
    A WARNING “Little piggiesget to live another day, hogs get slaughtered”
  • 36.
    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”
  • 37.
    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

Editor's Notes

  • #4 1950s - All software was originally released as open source in the public domain because the real mitigating factor to using the software was access to rare, bulky, and expensive hardware. 1960s – this changed in the 1960s as hardware become more widely available and the cost of developing software increased. In order to recoup the software development cost, companies like IBM began charging licensing fees for operating system code and more. Typically though, a license purchase usually included source code access. 1970s – US Commission on New Technological Uses of Copyrighted Works deems source code "copyright"-able. This creates a mechanism by which the work of software developers can now be legally protected from unauthorized duplication and distribution by third parties. This was an essential step towards creating proprietary software businesses. 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.
  • #6 1. OSS was initially defeated by proprietary alternatives – the rapid pace of innovation and high development costs through the 1970s and 80s had to be recouped through proprietary licensing. 2. This all changed in the early 1990s when decades of productivity improvements (languages, tooling, methodologies) drove down costs – plus OSS implementations, like Linux, had the benefit of learning from what worked and didn’t work with previous proprietary incarnations like UNIX as end-users. Aggressive licensing and pricing by companies like Microsoft and Oracle also gave customers a large incentive to look at lower-cost alternatives. 3. The Professionalization of OSS through foundations like Apache, companies like Red Hat, and non-profits like Mozilla all worked to make various OSS projects and models commercially viable for large, risk-averse customers such as governments, banks, healthcare companies, and more. 4. Today, it is now a bad bet to position proprietary ecosystems against OSS ones due – the wisdom of the crowds has effectively out-innovated centralized, proprietary ecosystems in many areas.
  • #8 https://github.com/todogroup/survey/tree/master/2019
  • #13 DMTK - https://www.dmtk.io/ - they even let their TLS certificate expire
  • #16 “Worse the larger and older the codebase” https://arxiv.org/pdf/1906.08058.pdf - “At the moment of the TFDDs, we found no major difference between surviving and non-surviving projects, in terms of number of developers, commits, and files. On the contrary, we found that surviving projects are younger at TFDD time compared to the non-surviving ones. “