CLJ Commons - (First project): Resurrecting unmaintained projects

Hi folks

The first CLJ Commons project that has been created is a place and set of conventions for taking over/forking maintenance of old libraries that are no longer maintained but that still provide a lot of value to the community.

There are a number of questions that need to be answered for this project, I’m interested in hearing from the community about them:

  • What is the popularity threshold for a project over which it is worth taking over maintenance? How do you measure that? You could look at things like GitHub stars, number of recent issues/PRs, Clojars downloads, how highly depended on it is, how much work went in to creating it.
  • What does it mean for a project to be ‘unmaintained’? There are lots of Clojure projects which are effectively ‘done’ in the eyes of their maintainers. Trying to fork these projects seems counterproductive.
  • What is the mechanics of offering to take over maintenance of these projects?
    • Some people may like to keep the project under their GitHub name for many reasons. How could we maintain these projects? This seems mostly workable, if it is under a personal repo, the only things that other people can’t do is update repository settings.
    • What do you do if you’d like to maintain a project that is important and unmaintained but the original author doesn’t want that?
    • Maintainers offering to transfer the project repository seems ideal as this preserves issues, watchers, stars, Google pagerank, e.t.c. Creating a fork seems generally undesirable if possible to avoid.
    • How long do you want to wait after contacting a maintainer about taking over their project?
    • Should the Group ID of the project stay the same? This means that tools like lein-ancient will be able to notify people of updated dependencies. Forking the Group ID to clj-commons would break that chain, but may be necessary if people don’t/can’t add permissions in Clojars for others to deploy to the original artifact name.
  • Do we want to set some entry requirements for people that are willing to be responsible for maintenance?
  • Should we set some exit criteria for projects that we adopt but then become superceded or no longer used? Where do those projects go?
  • I think it would be quite useful to have some number of people (more than one?) who commit to maintaining this new project under the clj-commons banner. We don’t want the new home of the project to become unmaintained as well.
  • What are the minimum requirements for maintenance of a project? Some ideas:
    • Passing continuous integration
    • Responsive to issues and pull requests
    • Documentation
    • Regularly creating releases
    • Staying up to date with new Clojure and JVM releases

Here are some general principles that I think would be good to keep in mind:

  • Respect the wishes of maintainers - If CLJ Commons goes around forking lots of projects, that is bound to create ill-will in the community. The goal of this is not empire building, it’s helping keep the Clojure ecosystem from decaying.
  • Provide value to the community - There are lots of unmaintained Clojure projects that are not that important. There are also lots of old libraries which are just stable and run fine. We only have a limited amount of time and attention, we should focus it on places where we can provide the biggest improvements.

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.