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.


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.


Status or phase in project's lifecycle. Indicative of maturity, quality, and stability.


Current level of maintainer activity on the project.


Level of support (for bug reports, feature requests, and help tickets[5]) provided to users of the project.

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, and a project's README may include details or exceptions.


maturity: stable maturity: experimental maturity: deprecated

development: active development: maintenance development: unmaintained

support: active support: limited support: self-service

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.