51

I've recently been trying to get into open source collaboration in GitHub and have run into a situation for which I am curious what is the preferred way to proceed.

About a month ago, I found a project on GitHub for a library that I had already been using for a while and in which I had found (and fixed) a few bugs.

As an initial foray into GitHub collaboration, I found the repo that seemed to have the highest volume of recent activity, fixed one bug, added unit tests, pushed up to GitHub, and made a pull request. Within a few hours, the maintainer of the repo that I forked had accepted the PR and merged in a few other PRs from other people that had been waiting as well.

Spurred on by this, I fixed three more bugs that I had found, each in a separate branch of my own repo, and filed an issue and pull request for each one separately.

That was just over a month ago, and the pull requests have been sitting there, untouched, ever since. The user whose repo I had forked doesn't seem to be very active, having only made 7 total contributions on GitHub in the past year, and that repo hasn't had any commits since that first pull request I made.

So my question:

How does one proceed in this situation? Ideally, I would like to avoid creating fragmentation of the library by going off and making a whole bunch of changes in my own repo that are not merged into the parent repo. Nonetheless, I would like to continue making bug fixes and adding features, but if I merge everything into my master branch and base all new fixes off of that branch, then if the maintainer of the repo that I forked ever does come back, I won't be able to split all of the changes into separate pull requests for each feature/bug fix (I've read that pull requests should generally be one pull request per feature or bug fix).

Should I keep one branch that is in step with the original repo, base all of my new branches off of that one, and then keep all the commits merged in my master branch? It seems like that would leave me with a whole ton of branches and an increasingly burdensome task every time I need to merge new changes into my master branch.

What is the typical way that one would approach a situation like this? It seems to be fairly common that a project will just become abandoned with the original contributors not around to review new pull requests. Is this a situation where somebody should just take up the helm and run with it? It seems like it would create fragmentation if the original contributors ever come back and want to work on the project again.

Improve this question
4
  • 4
    When you find this question interesting, you might also be interested in the proposal for a new open source stackexchange site.
    – Philipp
    Feb 16, 2015 at 0:34
  • Care to share what came out of the email conversation just for us curious onlookers? :)
    – winkbrace
    Feb 20, 2015 at 10:33
  • 1
    @winkbrace So far, nothing. I haven't received a response, but I only sent the e-mail two days ago. I will let you all know if something develops.
    – JLRishe
    Feb 20, 2015 at 10:35
  • It's really frustrating when projects are abandoned and result in fork hell like this. I wish GitHub handled this scenario better. github.community/t/… There's a browser add-on to at least hint that a fork is the de facto successor: github.com/musically-ut/lovely-forks
    – endolith
    May 1, 2021 at 14:13

3 Answers 3

Reset to default
42

I haven't had this situation yet, but that's what I would try:

Try contacting the owner

Maybe they really lost interest, but are willing to transfer the project to somebody else, in particular someone who has already shown considerate commitment.

But perhaps they are just occupied with something else (work, vacations, illness, other projects) and didn't have time to handle your PR, but plan to do so later.

Or maybe they have really stopped work on the project permanently for whatever reason.

Without asking, you won't find it out.

Get in touch with the community

Surely there are other people who have contributed to, or at least used the project. Check who has forked the project (even if they haven't made any change, they might still be interested in seeing this project thriving); check who has reported issues, or commented upon them. Maybe there's also a community outside GitHub, e.g a mailing list, forum, or StackOverflow members.

I'm you eventually really take over the project, you might want their support. And they need to know where the new master repository is.

Continue to make good pull requests

This shows both the owner and the community that you are serious about it, and let's them judge your contributions.

Improve this answer
2
  • 1
    Thank you. After a bit more searching, it looks like this advice is similar to the guidelines available for this kind of situation with npm packages. I have just e-mailed the owner and will see what s/he replies.
    – JLRishe
    Feb 18, 2015 at 18:38
  • It's very difficult to find someone with the ability to approve PRs for a particular repo when the "owner" of the repo is actually an organization with dozens of users.
    – cowlinator
    Jul 9, 2018 at 18:44
16

If the owner of the original repo is not found anywhere and absent for a considerable, I would publish my own repository as a different version of the project.

With this, you take over the lead of development of the library, and don't leave it to die in a corner without being updated ever again. If the original owner ever closes the repo, the world still can use the forked version.

Improve this answer
8
  • 1
    Yes, simply fork the project and in the README.md, leave a reference and "thanks" to the original owner.
    – Jared Burrows
    Feb 14, 2015 at 7:14
  • Thank you for your answer (+1). You definitely make some good points. I may ultimately resort to this, but for now, I'll follow oefe's advice and see if I can get in touch with the repo's owner via e-mail.
    – JLRishe
    Feb 18, 2015 at 18:40
  • 1
    I'm in a similar situation and may need to take this option - the original owner of a project hasn't responded to repeated contact attempts. Is it kosher to keep the name of the project and continue incrementing the version number from the last official version? I worry that if I change the name, it'll be harder for existing users of the project to find.
    – pericynthion
    Mar 17, 2015 at 18:58
  • 1
    I may be in that situation too. But the original project is already registered with Bower. Keeping the name would mean having to get the original author to un-register it for you, or contacting Bower maintainers and asking them to intervene. I don't much care to do the latter, though. Renaming might be the best option.
    – Lawrence I. Siden
    Dec 29, 2015 at 12:22
  • 1
    I have a similar situation with a repo that has been inactive for over 2 years now, with no response from the original developers. I would think that github would have a process for this kind of takeover. If someone wants to take over maintenance, and reasonable attempts have been made to contact the contributors, shouldn't they allow it?
    – Mikkel
    Apr 14, 2018 at 6:34
2

As most small to mid-size Free and Open Source projects nowadays are hosted on github, gitlab or similar, it would be possible to automate some of the process, using their Web APIs.

Assuming the original repo is at https://github.com/someUserX/projectY/, the process could look like this:

  1. ("manual") Contact the original author in different ways, at least through his git committer email and an issue (if enabled).

    In case of a received permission or no response within some weeks, one could run a script which would use the hosters Web API to perform steps like these:

  2. create a new (GitHub) organization called projectY, and therein fork the original repo -> https://github.com/projectY/projectY/

  3. add the original author and all authors of pull requests (already merged and still open) as organization administrators
  4. re-create all (open) pull-requests from the original repo in the new fork
  5. do the same with the (open) issues
  6. notifies all the admins of the new repo
  7. create a last pull request to the old repo, adding an "abandonned"/"archived" notice and link to the new repo on top of the README
Improve this answer
1
  • The main issue I see with this approach, is that some "bad" contributors might get admin access, but as the Free Software evangelist Pieter Hintjens explains (for example in this talk), bad commits can simply be reverted, and pose no thread to a project that is alive, and might help the bad committer to become a good one, over time.
    – hoijui
    Jun 16, 2019 at 18:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.