This week I've been thinking about ways in which GitHub could do a better job with projects and code as they age. Unfortunately, since technology is fundamentally about innovation, growth, and development, we don't tend (or want) to talk about decline, neglect, or endings. GitHub has some great docs on how to create a new repo, how to fork an existing repo, and how to file bugs, make PRs, etc. What they don't have is any advice for what you should do when you're done.
GitHub isn't alone in this. Long ago I wrote about the Ethics of Virtual Endings, and how the game WebKinz failed my daughter when she was done wanting to play. It turned out to be impossible to properly say goodbye to a virtual pet, whose neglect would go on indefinitely, and lead to sickness and suffering. I wrote then that "endings are, nevertheless, as real as beginnings, and need great care," and nothing has changed. Today, instead of dealing with a child and her virtual pets, I'm thinking about adults and their software projects.
It's important to establish the fact that every repo on GitHub is going to stop getting updated, cease being maintained, drift into the past, and die. I don't think people realize this. It can be hard to see it, since absence is difficult to observe unless you know what used to be. Our attention is drawn to what's new and hot. GitHub directs our attention to repos that are Trending. To be clear, I love this page, because I too love seeing what's new, who is doing great work (side note: my friend Kate Hudson is currently at the top of what's trending today for git-flight-rules), and what's happening around me. I've had my own repos there in the past, and it's a nice feeling.
Without taking anything away from the phenomenal growth at GitHub, let me also show you a contribution graph:
This is the graph of every project on GitHub. The years might not line up, the contribution levels might be different, and the duration of activity might be wider; but make no mistake: the longest stretch in every project is going to be the flat-line that follows its final commit. Before you tell me that natural selection simply weeds out failed projects, and good ones go on, this was a very successful project.
Software solves a problem for a group of people at a given time in a given context. At some point, it's over. Either the money runs out, or the problem goes away, or the people lose interest, or the language dies, or any number of other things happens. But at some point, it's done. And that's OK. That's actually how it's always been. I've been programming non-stop for 35 years, and I could tell you all kinds of nostalgia-filled tales of software from another time, software that can't be used today.
I say used intentionally. You can't use most software from the past. As a binary, as a product, as a project, they have died. But we can do much more with software than just use it. I spend more time reading code than I do writing it. Often I need to fix a bug, and doing so involves studying parallel implementations to see what they do and don't share in common. Other times I'm trying to learn how to approach a problem, and want to see how someone else did it. Still other times I'm interested in picking up patterns and practices from developers I admire. There are lots of reasons that one might want to read vs. run a piece of code, and having access to it is important.
Which brings me back to GitHub. If we can agree that software projects are all going to end a some point, it seems logical to plan for it. As a community we over-plan and over-engineer every aspect of our work, with continuous, automated processes running 24x7 for every semi-colon insertion and removal. You'd think we'd have some kind of "best practice" or process ready to deploy when it's time to call it a day. However, if we do, I'm not aware of it.
What I see instead are people trying to cope with the lack of such a process. GitHub is overflowing with abandoned repos that have been forked and forgotten. I've seen people add a note in their README file to indicate the project is no longer maintained. I've seen other people do a similar thing, but point to some new repo and suggest people go there. The more typical thing you see is that PRs and Issues start to pile up without an answer. Meanwhile, maintainers take to Medium to write long essays about burnout and the impossibilities of maintaining projects on their own. It's a hard problem.
I think GitHub could help to improve things systematically by addressing the end of a project as a first-class thing worthy of some design and engineering effort. For example, I would argue that after a certain point of in activity, it's no longer useful to have Issues and PRs open for a dead repository. After the developers have moved on to other things, the code, however, continues to be useful. Long before GitHub existed, we all dealt with source tarballs, or random code archives on the web. We didn't worry about the age of the code, if it did what we needed. By always forcing a project-management-lense on a repo, GitHub misses the opportunity to also be a great archive.
Another thing I'd like to see is some better UX for repos changing hands. GitHub does make it possible to move a repo to a new org or account. However, since everything in git is a clone, there's no reason that we shouldn't make cloning a dead project a bit easier. This week I've been working on a project that needed to do HLS live video streaming from nginx. The repo you get when you search for this is https://github.com/arut/nginx-rtmp-module. This makes sense, since this is where the work began. However, what you don't see when you go there is that you should actually probably use https://github.com/sergey-dryabzhinsky/nginx-rtmp-module, which is now quite a bit ahead. It would be great if GitHub offered to help me find this info from a project page: given that a fork on GitHub has gone further than this original repo, why not point me to it?
Bound up in this problem are the often unspoken and conflicting expectations of maintainers, downstream developers, and users. We love surprise: the release of something great, a demo, a hack, a new thing in the world that you didn't see coming. We hate the opposite: the end of a thing we love, the lack of updates, the disappearance without explanation. I think GitHub makes this worse by pretending that everything is always, or about to be, worked on. Commits, Issues, Pull Requests, Insight graphs, contributions--things are happening here! The truth is, lots and lots of what's there will never be touched again, and we should be honest about that so that no one is led to believe something that isn't true. Sure, the lights are still on, but nobody lives here anymore.