17

I am wondering if forking a repo of software I use in case the owner ever decides to remove it is a silly thing to do or whether it actually makes sense.

It seems like the repo could just disappear if the author decides to delete it and if I don't have it cloned locally, I would lose access unless I had previously made a fork.

3
  • 4
    With modern source code version handling tools (like git or mercurial), just getting a copy for your use creates a clone.
    – vonbrand
    Jan 15, 2016 at 23:55
  • 6
    libpng maintains several official repos in case the provider disappears. Currently we're on SourceForge, GitHub, simplesystems, and my own machine. That helped us continue operations during the two-week outage at SourceForge last year. Over our 21-year history we've lost our repos at uu.net, cdrom.com, suny.edu, swri.edu and maybe a couple others. Although we did manage to preseve the source code, we lost our mailing lists too, so there are gaps in our mailing-list archives. Jan 16, 2016 at 13:54
  • 2
    FWIW, I routinely fork repos that I either use or find mildly interesting, rather than bookmarking or starring them. This is a cheap click in each case. As a side effect I did become the only remaining upstream fork in some cases allowing the project to be furthered... Now I have TOO many of the forks I guess: after a few years of "bookmarking" I think I have over 20K on these on GH :| May 29, 2016 at 12:51

4 Answers 4

18

Oddly enough, I just did this with two repos I wanted to ensure continued access to. So no, it's not a silly idea.

However, remember that you have now committed yourself to monitoring the upstream (original) repository, and regularly pulling any new commits to keep your fork up to date.

You may also wish to put an explanation in the Description field pointing people to the original, just as I did some time ago with my clone of json-c - otherwise people may think you are the authoritative copy (yes, I know it says "forked from ..." under your repo name, but people really don't read the fine print).

4
  • 13
    "I just did this"... "so no, it's not a silly idea" is a... non-sequitur =P
    – user541686
    Jan 16, 2016 at 1:59
  • Why are you committed to monitoring the upstream? If people clone your fork instead of the authoritative copy, then shame on them for not reading the fine print. If the new commits address issues that you don't care about, there is no need to keep up to date.
    – emory
    Jan 17, 2016 at 0:05
  • 1
    The stated purpose of the fork was to maintain a safe copy in case the original went away, not to actually 'branch' the development path. If the OP wanted that security badly enough to basically back it up, then they also probably want any future updates.
    – kdopen
    Jan 18, 2016 at 16:04
  • Oh, and how is it a non-sequitur? If I do it, it can't possibly be a silly idea :)
    – kdopen
    Jan 18, 2016 at 16:29
10

With the recent demise of Google Code, I've strived to get a lot of popular repositories that I may potentially use, and host copies of them on Github, or on my own personal computer.

I don't really do anything with them, nor do they get any activity. They're just... there. If people are interested, you can ask them to make a fork. I suppose you could put a little message in the Readme file saying that you just got this from this old project, and you're hosting the original project. Of course, you can continue it :)

In no way is it a silly idea - it's actually a smart one. Once the project is deleted, it's gone for good.

2
  • 4
    I came to post about the Google Code closing. Not only is the idea of cloning a repo not silly, it is prudent.
    – dotancohen
    Jan 16, 2016 at 10:00
  • 2
    A few days ago I've started exporting interesting but long-dead code.google.com repos to my github just so they're preserved -- I felt a bit sheepish but I also feel good about preserving open source.
    – cat
    Jan 16, 2016 at 17:24
7

It's not a silly idea. It's standard practice in open source. A simple example is Linux:

  • Debian maintains a fork of the Linux kernel
  • Ubuntu forks the Debian kernel
  • Linux Mint forks the Ubuntu kernel

While the primary use-case of these forks is to control kernel versioning and testing in each distro it does also serve as a security policy for example if Ubuntu goes bankrupt Linux Mint can still continue development.

1
  • 2
    FWIW, Google calls this practice "vendoring". It's also considered standard practice in the go programming language.
    – slebetman
    Jan 16, 2016 at 5:35
1

It seems like the repo could just disappear if the author decides to delete it and if I don't have it cloned locally, I would lose access unless I had previously made a fork.

Yes, that's correct. Then you would be scrambling to find a copy of the software somewhere, or else you'd be unable to recreate your software accurately.

If that's not OK to you, then yes, it makes sense to keep local copies of all the software you use to build your projects.

There are even projects devoted to helping developers do this. For example, in the Perl world, all the modules are stored in the CPAN. There's a project called Pinto that lets you make your own local mirror of the CPAN, using exactly the versions you specify, so that you always have correct copies of the software. That way, if the version you need gets deleted, or even if the entire CPAN is down for some reason, you'll still have copies. See http://perlmaven.com/pinto-tutorial for more about Pinto.

Your Answer

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

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