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:
- Add notes on the README about what I have done, clearly stating code history and original copyrights
- Change organization to something I have control over, leaving the original package structure as is
- 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
- Add comments in the original repo's issues pointing to my repositories
Any suggestions? would you do anything differently?
Top comments (5)
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.
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 😊
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)I'm facing a similar issue, and am struggling with the best approach. There are a bunch of repos that were part of a youtube tutorial series, and the author is no longer involved in the programming world. His projects aren't really "abandoned", but rather archived, as the repo matches the video.
I want to update the projects to the latest framework / language, and incorporate new tools that weren't available when he did the videos. Usually I simply fork his repo, create a new branch, and apply my changes.
But there are some situations where multiple projects are within the same repo, and I want to divide those into a one-project-per-repo structure. (Sometimes this is as simple as a "start" directory and a "final" directory). My thought is to simply create new repositories and reference the original work.
The license is very open, so it's not a legal question, but rather a professional one.
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.