Starting to maintain an unmaintained but popular repository

Question

I came across a Python package that was rather popular (2000 or so GitHub stars), but most recently committed to two years ago. In addition, the module version in the Python Packaging Index is an outdated one. There are loads of pull requests waiting to be merged, many of them trivial or small improvements.

The code is rather poor in style, but works for what it was intended to do. I would be interested in maintaining such a package, but after a brief consideration and some refactoring my initial best attempt at a new package doesn't have much in common with the original. But I feel it's a huge step in the right direction, cleaner and easier to understand.

I struggled with the package when I was trying to use it. What should I do to create a better tool for everyone to enjoy and actively contribute to?

• Contact the maintainer? He might be interested in handing the torch over, but if not... (in my case the maintainer's email does not exist anymore)
• Create a competing repository?

A new repository would allow for a fresh start, but as the current one is clearly an established tool and downloaded quite often, I would need to inform potential users of this new repository.

• Is commenting on the open pull requests and issues (effectively advertising another project) considered rude? As I used the old code in my own version, I could go through the pull requests and inform that the issue has been taken care of in the new version.
• What other options do I potentially have?

This is the first open source issue I've taken to heart and one that I might have a valuable contribution to make to. Any tips would be greatly appreciated.

---

The Python Packaging Index does define abandoned packages, allowing for some contesting of e.g. the name of a package.

Answer 1

As you have stated, since the project seems to be abandoned, and you have made efforts to ensure that this is really the case, the next step would be to fork the project.

The article Forking Protocol: Why, When, and How to Fork an Open Source Project, provides a good answer to this problem,

Why Fork?

Answer – Because you cannot get the software to meet your needs any other way.

To further answer your questions,

Is commenting on the open pull requests and issues (effectively advertising another project) considered rude? As I used the old code in my own version, I could go through the pull requests and inform that the issue has been taken care of in the new version.

Using PRs and issues to advertise a competing project would be considered rude, however, it doesn't appear that you are trying to do that.

What other options do I potentially have?

You could write a completely new package from scratch and have a completely separate name. As you have stated, then you wouldn't benefit from the familiarity that users have with the other package.

To summarize,

• Try to reach out to the original author if possible.

• Open an issue stating the need for the updates.

• Fork the project, keeping the name intact.

• Reference the original repository, and state the need for the fork.