Skip to content

Instantly share code, notes, and snippets.

@cheerfulstoic
Last active October 31, 2024 10:28
Show Gist options
  • Save cheerfulstoic/d107229326a01ff0f333a1d3476e068d to your computer and use it in GitHub Desktop.
Save cheerfulstoic/d107229326a01ff0f333a1d3476e068d to your computer and use it in GitHub Desktop.
Repository Maintenance Levels

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.

[![Active Development](https://img.shields.io/badge/Maintenance%20Level-Actively%20Developed-brightgreen.svg)](https://gist.github.com/cheerfulstoic/d107229326a01ff0f333a1d3476e068d)

Active Development

[![Actively Maintained](https://img.shields.io/badge/Maintenance%20Level-Actively%20Maintained-green.svg)](https://gist.github.com/cheerfulstoic/d107229326a01ff0f333a1d3476e068d)

Actively Maintained

[![Inactively Maintained](https://img.shields.io/badge/Maintenance%20Level-Inactively%20Maintained-yellowgreen.svg)](https://gist.github.com/cheerfulstoic/d107229326a01ff0f333a1d3476e068d)

Inactively Maintained

[![Not Maintained](https://img.shields.io/badge/Maintenance%20Level-Not%20Maintained-yellow.svg)](https://gist.github.com/cheerfulstoic/d107229326a01ff0f333a1d3476e068d)

Not Maintained

[![Not Maintained](https://img.shields.io/badge/Maintenance%20Level-Abandoned-orange.svg)](https://gist.github.com/cheerfulstoic/d107229326a01ff0f333a1d3476e068d)

Not Maintained

@hisaac
Copy link

hisaac commented Mar 28, 2017

Thanks for this! I like the idea. I've used one of your badges on a project that I uploaded to GitHub, but am not the maintainer of. Hopefully this will help visitors to the project's page understand the state of the project.

@Exr0n
Copy link

Exr0n commented May 4, 2020

Great idea! I'm going to go slap it on all my repos.

By the way, should the alt text for the Actively Developed snippet say Actively Developed and the Abandoned snippet say Abandoned instead of Not Maintained?

@kingthorin
Copy link

@Exr0n yes there are a few discrepancies.

@gregsdennis
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment