These days the word "sustainability" gets thrown around a lot with respect to free and open source software (FOSS). What is sustainability, and what does it mean for your project?
The concept of sustainability didn't originate in the 1980s, but it gained a lot of mindshare at that time thanks to the Brundtland Report, which was released by the United Nations in 1987 after three years of research by a cross-functional team of scientists, policy makers, and business people. The report defines sustainability as "…development that meets the needs of the present without compromising the ability of future generations to meet their own needs."
The Sustainability Spectrum
The development in question here is corporate, but this definition applies well to FOSS development also. However, across different projects the practical interpretation of the definition will look very different. At one end of the spectrum, for a small but popular Python library, sustainability may mean increasing the bus factor by doubling the number of core contributors, avoiding maintainer burnout, and thereby ensuring there will always be someone available to work on the project. Achieving this could require additional documentation, automation, and training in how to mentor new contributors, so it's not necessarily something that a project can do overnight.
At the other end of the spectrum, there are projects like Blender, Let's Encrypt, Inkscape, and Signal. Relative to the number of users of these projects (frequently counted in the millions), they have few contributors (no more than a few hundred). Bringing on more contributors could be a goal for these mega-projects, but it may be a lower priority than providing for community and financial independence, scaling up infrastructure, or contracting for key development.
Frequently, discussions of FOSS sustainability end up couched in financial terms, but as you can see from the examples above it's not that simple. Paying a maintainer is great, but it doesn't contribute to the sustainability of a project if that maintainer is still working themselves to death trying to keep up with even basic project and community maintenance.
Focusing primarily on money ignores critical sustainability elements such as project succession planning, which can provide breathing space for the maintainers of today while guaranteeing there will be maintainers to continue carrying the project into the future. This is a people problem, not necessarily a financial one, and it's complex.
4 Big Questions
In fact, upon closer inspection many projects may find that their path to sustainability involves a combination of people and financial elements that need to be balanced and prioritized. This inspection itself can be a difficult process, but it gets a little easier if the project community works its way through the Big Four Questions of FOSS sustainability:
- Where is the project now? Now, be honest…what's the real state of the project at the moment? What are its pain points and bottlenecks? How many contributors are there and how do they feel? What sort of technical debt is the project carrying, including important but frequently overlooked things like documentation, user experience, security, and accessibility?
- Where does the project want to be? Every project maintainer carries a "One day…what if…" picture of the project in their head. Share those pictures with the community—no matter how unrealistic they may seem right now. Have an open dialogue to coalesce all these pictures into one shared image that can act as an answer to "what do we want the project to be when it grows up." That image isn't a reality, and may not be for several years yet, but it can unify the community toward a common goal and help set a direction to better ensure the project evolves in a sustainable way.
- How does the project get from where it is now to where we want it to be? Here's where the prioritization and balancing act comes in. You're probably familiar with creating a roadmap for software development, listing out a plan of features to work on and in which order. In answering this question you're creating a roadmap for project development. "Double number of core contributors" is a good feature for that roadmap, but it may have prerequisites and dependencies on "add contributor documentation" and "increase test coverage." Similarly, "Reach $25000 USD in yearly donations" can help to pay for scaling infrastructure, but it has its own dependency on "create a non-profit" or "find a fiscal sponsor," since managing that amount of money and the taxes involved aren't a trivial matter. Just as with software, thinking through these dependencies in advance can make project development less frustrating and more successful.
- How does the project stay where we want it to be? Finally, this is the sustainability question. You can't answer this one—how the project can meet the needs of the present without compromising future needs—without answering the previous three questions. Thankfully, in answering the first three, most projects find that they've already been chipping away at this question. Answering it becomes a matter of sitting down and collecting all the existing thoughts, sharing them with the community, and revisiting them regularly to make sure the project is still on track toward sustainability.
Plan Your Approach
Where are we now, where are we going, how will we get there, and how will we stay there? Being able to answer these questions is very empowering and can lead to stronger, more sustainable projects and communities.
How long it takes to answer these questions will depend a lot on the project, its needs, and its culture. Some will feel comfortable with something more agile, developing minimally viable plans and then iterating on them on a regular basis. Others may prefer a waterfall approach, coming up with a detailed roadmap to impress potential sponsors and contributors. The only wrong way to do it is not to do it at all, incorrectly thinking that project sustainability is something that you can put off until later.
Comments