loading...

I'm thinking about taking over an abandoned GitHub project: what is your advice?

michelemauro profile image michelemauro ・2 min read

I'm asking for the collective DEV wisdom about how to proceed in a situation I'm getting into.

At work, I may be interested in using a small tool to add it to the development toolset (I won't be more specific for now; it's not that important). We are talking about a little library, a port from a similar library in another language; nothing fancy. The project is a Java/Groovy mix (with a bit of Kotlin for fun 🤔), and is Apache licensed.

The original GitHub project seem to be abandoned: no updates in 2 years, no answer to issues. Moreover, the project is actually broken (even for a 0.2 release): since a critical subproject is not properly published, you can't depend on this tool altoghether without downloading it and compiling it yourself. So, in this current state, the tool is not even readily usable.

I've spent a few hours on the repository, breaking it into subprojects, clearing up and updating dependencies, build scripts and tests. Now I have more or less the same code (I may have added an obvious missing piece, too) splitted in four repos, with clean builds and passing test, and with current dependencies. What now?

The plan I had in mind was like this:

  1. Add notes on the README about what I have done, clearly stating code history and original copyrights
  2. Change organization to something I have control over, leaving the original package structure as is
  3. Publish a 0.3 release, with the original name but in the new organization, so it's clear that the code is mostly the same, but doesn't come from the same author
  4. Add comments in the original repo's issues pointing to my repositories

Any suggestions? would you do anything differently?

Discussion

pic
Editor guide
Collapse
sebbdk profile image
Sebastian Vargr

I would try to ask the creator to become a maintainer first.
A PR would be good leverage. :)

Depending on the license, you can also just fork it under a new name.

Collapse
michelemauro profile image
michelemauro Author

A PR is really a good idea.

I can file a PR modifying the README (what I did can't be expressed in a single PR: I made 4 indipendent repos from one) pointing to the new repository: the author (and all the people asking for help in the issues) can read the PR and respond; the other users can make their choice.

I'll still publish on a different organization to avoid clashes; if the author doesn't respond, and I need to change the code further, I'll rewrite the packages and make it an indipendent project.

Thank you 😊

Collapse
fluffynuts profile image
Davyd McColl

I'd also mention in the PR that you're happy to take over maintenance, if the repo owner is too busy. I recently did this with gulp-msbuild. If you get no response from the original owner (properly abandoned), I suggest a fork, coming up with a good name, including the original repo in a link in the readme & credits and publishing. I did something similar for the javascript package cnfg, after fixing a bug, whilst the original maintainer was hesitent to update from a PR (he did, after a while, and I marked my fork as obsolete)

Collapse
siy profile image
Sergiy Yevtushenko

I think that cloning original repo might be a good initial step. This way you will keep link to original project. They apply steps 1-4.