GitHub’s Archive function preserves old repos for future forks
It’s time to do your best Indiana Jones impression: brush off the dust and carefully file that long-forgotten artifact away. GitHub now allows users to archive disused repositories to preserve projects that are no longer actively maintained.
It’s a common sight across the internet. Things move so fast, it’s not hard to see old code fall by the wayside. Whether it’s a lack of interest in maintaining old repositories or a change in priorities, things fall into disuse. But sometimes, things that should not have been forgotten were lost. Which begs the question, what happens to your code after you move on?
Until now, there have only been two options: developers could either delete their project, potentially leaving users all over the internet in a sudden bind, or let it gather digital dust and decay. But thanks to GitHub’s latest feature, it is now possible to archive repositories as read-only.
How does the archive function work?
There comes a time in every repository owners’ life when they are done with a project and no longer want to deal with additional contributions and pull requests. Instead of deleting all that hard work, the archive function makes it read-only to everyone, including the repository owner.
No more editing. No more issues. And no more pull requests, labels, milestones, projects, wiki, releases, commits, tags, branches, reactions, or comments. In an archived repository, no one can create new issues or pull requests or comments.
The positives, however, mean that projects using the archived code continue to work. There are no sudden blackouts and no sudden code failures. Links and dependencies continue to work, regardless of the repo’s status. It’s probably the neatest way to move on from a project without causing downstream effects.
If you’re interested in closing down a repository like this, it’s polite to wipe down all the tables, mop the floors, and turn off the lights on your way out. In this case, it would be doing things like changing settings and closing open issues and pull requests. As a courtesy, maybe update the README and description to make it clear to future visitors that this project is archived. But that’s just a suggestion.
On the positive side, all is not lost with archived repositories. Unlike deleted repos, developers can still fork archived repositories, making it possible for development to happen elsewhere. Plus, archiving isn’t a permanent decision like deletion. If a repo owner decides to change their mind, it’s simple to unarchive the repository with the click of a few buttons.
What happens to your code after you move on?
Surprisingly, there aren’t a lot of options for when a developer moves on from a project or dies. Orphaned projects are vulnerable to both security issues and general maintenance problems. And it’s a bigger problem than you’d think.
Large open source projects like Linux or Eclipse are run by teams of programmers. However, those projects often depend on smaller libraries, which may be run by a few people or by one heroic volunteer in their spare time. Because of time constraints, security testing and general maintenance can be pushed down the to-do list. And then we get things like Heartbleed.
According to Libraries.io, an open source project that maps dependencies across different libraries and package managers, nearly 3,000 open source libraries are heavily used but lightly maintained. This is the unseen infrastructure of the internet, the “libraries that are heavily depended upon by the community but don’t receive much recognition or attention”.
The fewer people that have ownership or contribute to a project, the more likely it is that this specific project could be orphaned. The black humor version of this truism is the bus factor, i.e. how many people have to be hit by a bus before there’s no one to maintain a project. In some cases, that number is one.
What can developers do? Taking the time to create a transition plan and a will is something of a downer, but it’s necessary. After all, no one expects to get hit by a bus. But naming others as a code repository owner can save a repository from being orphaned should the worst happen.
Developers also need to do something they absolutely hate: document, document, document. Having all the code in one person’s head is a recipe for disaster. But it’s necessary, should a transition be needed. Plus, sharing the load ahead of time prevents early burnout.
GitHub’s latest feature to enable code owners to archive repositories is a great step forward. Archiving makes it possible for future development, while letting the original code owners step away from a project they may be finished with.
However, the best way to deal with orphaned repos may require more collaboration and coordination. Only time will tell.