Healthy expectations in open source
Most open source projects choose licenses from a common list,[1] while support and maintenance expectations are not standardized. Usually those expectations are not stated at all.
That's a loss — not because maintainers of free software owe anyone commitments, but because the unstated status quo presumes this support. Maintainers will consciously understand that no such obligation exists, but still feel a presure to provide indefinite and unsustainable support. And that dynamic contributes to an extractive open source ecosystem.
A series of kindnesses
While open source can be funded well and sustainably maintained, it usually isn't: valuable work is created in someone's free time, given away, and used in commercial and non-commercial pursuits alike, without compensation or reciprocation.
Open source is a series of kindnesses,[2] and maintainers are under no obligation to provide support. We are not suppliers.[3] Writing software and giving it away is a kindness. Answering a question is a kindness. Fixing a bug is a kindness. Building a new feature and contributing it back to a project is a kindness. Accepting a pull request, then maintaining that code indefinitely, is a kindness.
I've been wondering: would open source work better for maintainers if expectations on support were stated up front? The clarity could directly benefit maintainers and users, and studies based on these statements could spark conversations about compensation and business models in open source.
Categories
I'm aware of few attempts to categorize open source lifecycles, and no detailed studies.[4] I have not found any formal definition of open source support, or of its varying degrees. So I've made the attempt here, for myself.
My categorization covers three areas: Maturity, Development, and Support. Each is value-neutral. We'd all prefer more support than less from projects we depend on, but can't disparage the choice to give one's time and work away, or the boundaries of the gift.
Projects that afford incentives and income to maintainers tend to provide more in all three categories. While it's not uncommon for high-quality open source projects to begin as a labor of love, sustaining development and support over a long period is difficult without meaningful support for maintainers, and these projects inevitably shift into less-active modes without support and incentives.
Maturity
Status or phase in project's lifecycle. Indicative of maturity, quality, and stability.
- Stable: Project achieves its stated goals with a high level of quality and reliability. While certain areas of the project may remain experimental, the project as a whole is more mature, and the authors have some degree of confidence in its correctness and stability.
- Experimental: Exploration, idea generation, early development, or research. May solve a particular use case for the maintainer, while remaining unstable for broader use. Creation of experimental software does not necessarily represent a commitment to bring that software to maturity.
- Deprecated: Previously stable or experimental projects may become deprecated, indicating that a project's use is no longer recommended. Deprecation usually implies inactive development and support. Causes for deprecation may include lack of time and incentives for development and support, degradation in the codebase, or wider changes in the software ecosystem.
Development
Current level of maintainer activity on the project.
- Active: Frequent contributions toward feature and maintenance goals.
- Maintenance: Bugs, compatibility issues, and security risks are addressed periodically, but new feature development is not expected. Projects may enter maintenance development due to limited developer time and incentives, or because the project is feature-complete within its intended scope.
- Unmaintained: Neither new features nor maintenance are planned. Most projects cannot remain both unmaintained and stable indefinitely, as dependencies shift and bitrot accumulates. Unmaintained status is common for older experimental projects, and implicit for archived projects.
Support
Level of support (for bug reports, feature requests, and help tickets[5]) provided to users of the project.
- Active: Project provides a place to file tickets. Maintainers welcome these discussions, and intend to read and respond regularly.[6]
- Limited: Project provides a place to file tickets. Maintainers welcome these discussions, but cannot review tickets regularly. Delays should be expected, and some tickets may not receive a response.
- Self-service: Project is provided as-is. Maintainers decline to provide support. Questions should be directed to Stack Overflow or similar websites.
There's room for exploration in Support — the three levels above are not exhaustive! Find creative ways to support open source work. Maybe reserve help tickets for noncommercial users, sponsors, and paying customers.[7] Consider selling SLAs. More experimentation on open source business models would be a healthy thing.[8]
Applying the definitions
I'm in the process of reviewing my own open source projects, and plan to categorize each project in the three areas above. Badges may be created with Shields.io, and a project's README may include details or exceptions.
Examples:
I'm curious how these definitions resonate with open source maintainers, and users of open source software. Are the categories missing something important? Is something gained — or lost[9] — in stating a support policy for an open source project? I am active on Mastodon these days, and welcome questions and ideas.
1 The Software Package Data Exchange (SPDX). I'm no longer sure whether this is a good thing. On one hand, SPDX encourages corporations to choose use open licenses, and prevents license-compatibility nightmares. On the other hand, SPDX takes away tools that could benefit indie developers, like non-commercial licenses. SPDX does not generally grant these licenses identifiers for use in package registries.
2 Setting expectations for open source participation, by Brett Cannon.
3 I am not a supplier, by Thomas Depierre.
4 Inspired by the Linux Foundation's The Life Cycles of Open Source Projects and Formidable's OSS Maintenance Levels.
5 I've intentionally avoided distinguishing between “bugs”, “feature requests”, and “support”. The difference is often known only to a project's maintainers, and accepting one kind of support ticket means dealing with them all.
6 I've intentionally avoided defining “regularly”. This is a hint about maintainer intention — not an obligation. Fixed support schedules are not a reasonable expectation, outside the context of a paid Service Level Agreement (SLA).
7 OSI's The Open Source Definition states — controversially — that licenses containing restrictions against “fields of endeavour” cannot be considered open source. Even so, maintainers can certainly be selective about time spent on support.
8 See Indie Open Source.
9 One real fear I have is that maintainers will — wanting others to choose their software — promise levels of support they cannot sustain, that users will prefer those projects until their maintainers burn out, and that the status quo will deepen. Meaningful incentives are required to sustain support, and problems of support and compensation are closely linked.