After reading Why I'm Frequently Absent from Open Source by James Long and listening the corresponding The Changelog episode, I dwelt on the idea and believe that open source maintainers...
- ... should never be ashamed if they don't have time for a project.
- ... should be honest with themselves and open with their users so that everybody can be on the same page
- ... are people and they have at one time or another responsibilities or hardships that they need to attend to which reasonably take them away from a project
- ... may also reasonbly decide that they don't like the direction of a project or that they would like to explore other things and may leave a project permanently.
Along this line of thinking I've created a set of descriptions for different levels at which a project might be maintained. A maintainer can use these to announce to their users the current ability that they have to dedicate to a project (no more "Is this project still maintained?" issues!)
- Actively Developed
- The maintainer(s) of this project are currently writing code for this project as well as responding to issues and integrating code contributions
- Actively Maintained
- The maintainer(s) of this project are responding to issues and integrating code contributions
- Inactively Maintained
- The maintainer(s) are around to answer questions, but do not currently have time to respond to issues or integrate code contributions
- Not Maintained
- The maintainer(s) are not around to work on this project and should offer to hand the project over
- Abandoned
- The maintainer(s) are not interested in spending any more time on this project. Users are welcome to fork it.
No matter your commitment to a project, it is in your user's interest to know the status of your projects (as well as in your own interest to not have to answer the question over and over). To that end I have created these easy-to-copy badges for your repo's README which can all be linked back to this page.
[](https://gist.github.com/cheerfulstoic/d107229326a01ff0f333a1d3476e068d)
[](https://gist.github.com/cheerfulstoic/d107229326a01ff0f333a1d3476e068d)
[](https://gist.github.com/cheerfulstoic/d107229326a01ff0f333a1d3476e068d)
[](https://gist.github.com/cheerfulstoic/d107229326a01ff0f333a1d3476e068d)
[](https://gist.github.com/cheerfulstoic/d107229326a01ff0f333a1d3476e068d)
Being explicit is good, but I'd prefer a solution which uses metrics to determine this. Is it maintained? ironically is no longer maintained, but it still has a high score because it doesn't have any issues, which is a bit misleading because the project has issues turned off.
Being explicit has the downside of requiring the maintainer to state their intentions. This is a problem when the maintainer is no longer able to be explicit (maybe they don't have time, or lost access, or even passed). Automatic metrics solve for that.