Open Source
Open source software is code made publicly available for anyone to use, modify, and distribute. It powers the majority of modern software. But maintaining open source is its own discipline. Project sustainability, community governance, dependency risk, and contributor burnout are challenges that most teams never plan for until they're already affected.
Key Statistics
- • 96% of codebases contain open source components, with an average of 528 open source dependencies per application. / Synopsys OSSRA Report
- • Only 5% of open source projects are actively maintained by more than two developers. / Linux Foundation Census II
- • Open source maintainer burnout affects over 60% of contributors, with most citing lack of financial support and overwhelming demand. / Tidelift Open Source Maintainer Survey
- • The average open source vulnerability takes 68 days to fix after disclosure. / Snyk State of Open Source Security Report
Why This Matters
Your application probably has hundreds of open source dependencies. You didn't write them. You probably haven't audited them. And the people who maintain them might be one bad week away from walking away. That's not an indictment. It's just the reality of building on a foundation you don't control.
When a key dependency loses its maintainer, every application using it inherits the risk. Teams need strategies for vetting dependencies, contributing upstream, and planning for the lifecycle of their open source stack. The ones who do this well treat their dependency list like a portfolio, not a shopping cart.
On the Maintainable Software Podcast, open source maintainers and contributors share their experiences with sustaining projects, managing communities, and navigating the unique challenges of software that belongs to everyone.
Episodes on Open Source
EP-177 | July 30, 2024
Julia Ferraioli - Capturing Untold Open Source Stories
EP-127 | August 1, 2022
Marc Cornellà - Maintaining Open Source Projects
EP-167 | April 23, 2024
Martin Emde - Ruby Central and the Art of Being Tolerant to Change
EP-074 | November 9, 2020
Mark Downie: Balancing The Promises That Open Source Projects Make
EP-062 | July 13, 2020
Gianluca Arbezzano: Technical Debt Beyond Code & Your First Contributions to Open Source
EP-114 | February 7, 2022
Emily Giurleo - Maintaining Open Source vs Proprietary Software
EP-119 | April 18, 2022
Ben Halpern - Adventures In Open Sourcing Your Existing Application
EP-041 | February 3, 2020
Mike Perham: How Developers Underestimate Long-Term Costs of External Dependencies
EP-083 | January 11, 2021
Michael Springer: Vetting External Dependencies
EP-130 | September 12, 2022
Courtney Wilburn - Maintainable Software Has Good Community Around It
Frequently Asked Questions
What makes open source software maintainable?
The same things that make any software maintainable: clear documentation, consistent standards, automated testing, and responsive maintainers. Open source adds another layer. You also need well-defined governance, a clear contribution process, and transparent decision-making. Projects that depend on a single maintainer are fragile, no matter how talented that person is.
How do you sustain an open source project long-term?
Long-term sustainability requires building a community of contributors, not just users. This means writing good documentation, reviewing pull requests promptly, mentoring new contributors, and establishing governance structures. Financial sustainability through sponsorships, grants, or commercial offerings also helps prevent maintainer burnout.
What are the risks of depending on open source?
Key risks include dependency on unmaintained projects, security vulnerabilities in transitive dependencies, license compliance issues, and breaking changes in upstream updates. Mitigate these by auditing your dependency tree, pinning versions, contributing to critical dependencies, and having a plan for forking or replacing abandoned projects.
How do you vet open source dependencies?
Evaluate the project's maintenance activity (commit frequency, issue response time), community size, bus factor (how many active maintainers), test coverage, security track record, and license compatibility. Check whether the project has a clear release process and whether breaking changes are communicated well. Prefer dependencies with multiple active maintainers.
How can companies contribute back to open source?
Give engineers dedicated time for upstream contributions. Sponsor maintainers financially. Report bugs and submit fixes. Improve documentation. Open-source internal tools that solve common problems. These aren't acts of charity. They're investments. A culture of open source contribution also helps you attract and retain the developers who care most about craft.