pixelbrackets
tl;dr Moving open source projects with no active development into maintenance mode helps to satisfy expectations of both maintainers and users.
Development activity in open source projects depends on the community contributions and the commitment style of its authors/maintainers. Eventually every open source software will reach a point, when the maintainers are not able or willing to actively develop it further.
The reasons for this are manifold:
- The software is considered feature complete
- The software is no longer competitive with other products in the same field
- There is no funding anymore - means lack of development time sponsored by a company, donations, or own spare time
- The code base has accumulated too much technical debt
- All development resources are focused on a major overhaul or a fork
- The original author has changed the workspaces completely and is now into woodwork
- Loss of interest, demotivation, burnout
They are all perfectly valid and a normal part of a software life cycle. However, if the topic is not addressed, then this automatically leads to failing expectations of both the maintainers and the users.
The most obvious result is a great imbalance of open to closed issues, and abandoned pull requests. Contributors get frustrated why PRs lead to nowhere, and maintainers feel an unwarranted pressure likely to even worsen productivity.
This is particularly unfortunate for projects that are feature complete. I stumble upon this pretty often. A project fits all my needs, but lacks one or two bugfixes to be compatible with the latest OS version. A short-sighted answer are forks. Yes, its Open Source, yes, GitHub greatly supports fork workflows, but then what? I don't want to maintain the project. Maybe another fork will do, but which one of the umpteen other ones does? There is no way to recognize them.
At some point down the line the infamous question will pop up:
„Is this software still maintained?“
This is discussed in more than 205.000 issues in GitHub right now. So there is an enormous need to consider this topic in open source development.
When this question is raised, preferably before the users do, maintainers should discuss the reasons causing it. Because this decides whether there should be any further development at all or whether the software reached it's and of life and should be marked as abandoned.
If it is EOL, then the project should go straightforward into read-only mode. If available, then a recommendation for alternatives in the README is a fine move.
If there is an intention to continue development, even with much lower pace, then I recommend fellow OSS maintainers to put the project into a »maintenance mode«, make this clearly visible and explain the future development mode.
[](CONTRIBUTING.md)The future development mode should explain what kind of PRs are still welcome and accepted and which ones are very likely to be closed without a merge approval. Don't be hesitant, a clear statement about the scope is always better than vague issue statuses without feedback. Security issues should be continued to always be properly addressed.
An example may look like this:
This project is in maintenance mode currently. This means that the maintainers choose to prioritize stability and compatibility over new features for now.
- There is no active development & new major features are not planned
- New features may be added by PRs however
- New features may be proposed in issues tickets, send as Pull Requests, and the maintainers will review and presumably merge them
- PRs for bugfixes are welcome and will be reviewed & merged
- PRs to keep the software compatible with new <PHP, Ruby, Node> versions or the like are welcome and will be reviewed & merged
- Critical security concerns will be addressed
This section is also a great spot to encourage other contributors to step forward and apply as maintainer for the project. Add a contact option or a link to a dedicated issue.
The same applies when you plan to abandon the project eventually; ask the community for alternatives or an official fork.