The .NET ecosystem has radically transformed over the past 10 years; in the distant past, Microsoft actively discouraged and dismissed the possibility and viability of OSS categorically. Now, everything is open source and Microsoft is one of the single biggest contributors of open source globally. That same trend is strongly reflected in the .NET community - large companies include banks, insurers, airlines, manufacturers, and health care giants all feel increasingly comfortable using OSS products in the core of applications that generate billions of dollars a year in capital.
In this talk, we're going to cover the scope of the sustainability crisis, how it may affect you, and how to help prevent it both as an OSS user or as a contributor.
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.
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
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
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
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
28. 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
29. GOOD AND BAD SOLUTIONS
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.
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: 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
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
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
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.
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.
DMTK - https://www.dmtk.io/ - they even let their TLS certificate expire
“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. “