Old Repositories

Anyone that does design or development (or even writing, really) as either a hobby or for a living knows that feeling of going back and looking at their old work – and cringing.

We know that we’re making progress in our work when we look at something we once did and think “What was I doing?”

The funny thing is, whatever we’re designing, developing, or writing today is going to be treated that way sometime in the not-so-distant future, right?

I digress on that point.

Anyway, for me, one of the things that I find myself debating is how long I should keep some of my open source code repositories around.

Delete Old Repositories Or No?

Here’s the thing: Open repositories serve as a bit of a paper trail of the work that we’ve done, and they also give us a place to help others out by showing how we’ve solved problems that they’re likely encountering.

Unfortunately, much of what we do can become outdated either because we’ve gotten better as developers (and the work in embarrassing), or the foundation on which we were building the project has changed such that the code doesn’t work any more.

Repositories

On top of that, there’s the mindshare that’s occupied by knowing you’ve got these rotting projects available sitting there being viewed and/or used by who knows who, right?

I mean, on top of being embarrassed by our own work, or keeping work that’s publicly outdated for others to stumble across and potentially mistake for something current, what’s the advantage to keep it around?

For what it’s worth, I actually think it’s a better idea to delete old repositories if they are out of date or no longer being updated, but some do say there’s something to be said for keeping your old work on display.

What Are We To Do?

Periodically, I go make sure to go through certain files, applications, and project that I have and archive them because they’re no longer useful or applicable; however, some people tend to have a different attitude as it relates to publicly available source code.

So, in short, I’m a fan of removing old repositories that are no longer being used or referenced, but where do you stand, and why?

Category:
Articles

Join the conversation! 21 Comments

  1. Old crappy code serves a purpose if it’s well documented as such. If not, people will copy and paste it into something and the crappy code multiples. I’d rather delete it, and have, and will continue to. Another option is making the repo private, so we can examine our own code and remind ourselves of our progress. Also sometimes parts of the repo have good code, and I hate tossing out good code with the bad.

  2. For me, I deleted a couple of plugins from WP repo just because I had no time or incentive to update or keep supporting the plugin.

    Basically, If the project is stable and there are no bug reports then I guess deleting the repo would not be a good idea. If there are bugs being reported and you don’t have any time or incentive to fix them, I would consider making the repo inactive.

    • For me, I deleted a couple of plugins from WP repo just because I had no time or incentive to update or keep supporting the plugin.

      Yep – I’ve done this with a few plugins. Still trying to decide on what I want to do with some of the ones that I have available right now.

  3. It’s hard to stop people from copying and pasting code, lazy developers are going to do that regardless. Still, like John mentioned if your code is potentially damaging or completely wasteful it’s best to get rid of it. Otherwise, stick a big fat DEPRECATED label at the top and let developers know this is an old project that is no longer maintained, so proceed at their own risk maybe?

    • Otherwise, stick a big fat DEPRECATED label at the top and let developers know this is an old project that is no longer maintained, so proceed at their own risk maybe?

      Agreed – this seems to be the direction that others have shared and one that I’m actually partial to doing myself.

  4. IMHO, if it was useful enough to open source in the first place others will probably still find value even when you do not.

    I have a moderately popular wordpress repo (69 Watchers, 360 Stars, 171 Forks) and even at that level I have found a few folks that have become repo champions, jumping in and resolving issues before I even see them. I believe if I no longer wanted to maintain the repo that I could easily pass it on, and thats most likely what I would do.

    The only real issue with this on GitHub is repo ownership. GitHub has become sort of a programmers resume, so you wouldn’t want code you don’t maintain under your name.

    With tutorial repos (such as your work for Envato) I believe they should be created under an organization for that site to begin. Then again tutorial archiving is a whole other topic haha.

    • I have a moderately popular wordpress repo (69 Watchers, 360 Stars, 171 Forks) and even at that level I have found a few folks that have become repo champions, jumping in and resolving issues before I even see them. I believe if I no longer wanted to maintain the repo that I could easily pass it on, and thats most likely what I would do.

      The beauty of open source, right there.

      The only real issue with this on GitHub is repo ownership. GitHub has become sort of a programmers resume, so you wouldn’t want code you don’t maintain under your name.

      This is true – and I’ve mixed feelings about this as it is; however, I do think that providing some type of notification that it’s deprecated, no longer used, or it links to a more updated version of the code.

      With tutorial repos (such as your work for Envato) I believe they should be created under an organization for that site to begin. Then again tutorial archiving is a whole other topic haha.

      Yeah – this is something that I need to get around to doing. It’s just a matter of taking the time to do so :).

  5. I created organizations and put code in there so it doesn’t clutter up my main repos but I still have them tucked away somewhere.

    I also did that for my js-utilities and env-utilities so I could keep projects that weren’t components front and center.

    Best of both worlds.

  6. Old code is often helpful to people if there is no better alternative. Currently we’re working on a project with a PHP library that hasn’t been maintained in 9 years but there is no alternative so it’s our only option. And we often struggle with links in forums and blog posts that are no longer active, and we suffer miserably.

    Additionally, since people who browse that code are normally developers, they could see when the latest versions/commits have been released and assess how maintained or compatible a solution is, roughly.

    • I think you hit on some good points especially with respect to developers using the dated code – if they are finding it on a place like GitHub, then they should know what their up against should the latest release be of some time in the past.

  7. I’d rather it be archived, so that I don’t find it and use it.

  8. Thanks for bringing up the topic, Tom. There are definitely two sides to the coin here.

    I’ve always admired the principles behind Archive.org and their “Wayback Machine” to be an Internet library for researchers, historians, scholars and the general public. To me, it embodies the spirit of the open and free web.

    I can’t help but think of our outdated code in this way, too. Every line of code has the potential to provide learning. Even my most embarrassing and downright terrible code could help someone learn. If anything, what NOT to do :-) Old logic should not be forgotten. Perhaps even one day our “outdated techniques” will have a chance to be revisited, forked and brought back to life again.

    However, I do think there is more that could be done to designating what is to be considered “unsafe code” in our repos. When WordPress.org started the warning message on repos not updated in 2 years, I think that was a step in the right direction. They could potentially do even more by requiring those plugins to be manually installed and taken out of the streamlined process of installing directly via the WP Admin.

    To me, no code that was once publicly released should ever be deleted from the web. I see that as my responsibility as a software engineer. Deleting code because it’s old seems like throwing the baby out with the bathwater. We just need to improve they way we designate what code has been “abandoned”.

    • To me, no code that was once publicly released should ever be deleted from the web. I see that as my responsibility as a software engineer. Deleting code because it’s old seems like throwing the baby out with the bathwater. We just need to improve they way we designate what code has been “abandoned”.

      I think you hit the nail on the head with this. The thing is, for me at least, is that I don’t want to leave something around that will provide a poor solution for someone else while they are searching for something especially in the case of if I’ve something better already released.

      Perhaps the best thing to do is to provide a huge notice at the top of a `README` file noting that it’s deprecated and that it’s no longer maintained, and/or linking to a better solution.

  9. You can keep old stuff, as long as it is not in the public domain :)

  10. I recently started going through and deleting old repos in GitHub that I once forked to play with, or ones that I used to create a PR that was accepted. Since they weren’t my original projects I figure I can always go back to the “real” one and fork it again if needed.

    Original code that I’ve put into production somewhere (even if it’s only used by me) stays up as a reference for me and others who may be searching for a solution to solve a problem. Perhaps my code, even if not updated or maintained often, can serve either as a jumping-off point or a warning for someone else.

    • Perhaps my code, even if not updated or maintained often, can serve either as a jumping-off point or a warning for someone else.

      Yep – and that seems to be the one of the largest reasons to leave it around even if it’s not being maintained (and if there’s a disclaimer around weaker points of the code).

      Thanks Morgan!

  11. Delete old code? No matter how old my stuff is, I still keep it around. I even start working on old projects from back in University occasionally.

    One of my Github repos is RearViewMirror, an old open source Windows C# project that I had to covert over from CVS! It’s revision history is literally older than Github! I don’t even use Windows anymore (except in a VM) and looked at the project recently. Someone forked it and added a lot of new features. (I’ll probably pull them in when I get a windows box again).

    Even all my old classroom assignments from University are still only; converted from CVS and posted on Github.

    Sure some of the code is far from how I’d write it today, but my memory is based on my old code; looking at it and using the same concepts for future projects (attempting to improve it on each implementation of course).

    • Delete old code? No matter how old my stuff is, I still keep it around. I even start working on old projects from back in University occasionally.

      Same. And I still have my old notebooks and other material from when I was in college in a box in the room in which I’m sitting.

      Have I used this since I graduated? Nope. Do I ever look back at it? Sometimes. The code has been the one consistent thing that’s kind of neat to review, but the content in the notebooks haven’t been so great.

      Someone forked it and added a lot of new features. (I’ll probably pull them in when I get a windows box again).

      That’s so neat when that happens, isn’t it?

      Sure some of the code is far from how I’d write it today, but my memory is based on my old code; looking at it and using the same concepts for future projects (attempting to improve it on each implementation of course).

      Totally understand that :). I don’t have mine shared anyway – it’s just on a local drive – but that’s cool that you have it publicly available.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.