Ask HN: How do you close your side projects? | Hacker News Reader

Ask HN: How do you close your side projects?

98 pointsandrewgrossi31 comments

I have worked on various side projects involving design, development, music, etc. over time and generally kept the remnants living on somewhere (DropBox folders, word docs, random repositories). I like to have reference for nostalgia or to reflect on the lessons learned before my next pursuit. Recently, I have been considering creating a blog or documenting the key parts like screenshots along with a write up recap in an Archive folder somewhere and then purging the content such as code, mockups, assets, etc. I would partially like to write a post-mortem about a side startup but the rest are not as valued.

I was just curious if you have any personal examples or practices for closing out your cancelled or completed projects (Archive - Purge - Blog Post - Open Source - viking send-off)?

View on HN

> and then purging the content such as code, mockups, assets, etc.

Why? I would never destroy anything I'd created like that. Unless you're doing it for some sort of closure, the way people throw things into the ocean in books and movies, I don't see the benefit. On the con side, you never know when you might start it back up, or just have some use for it. More than once I've gone back to a project I hadn't touched in years and either used it again (e.g. a "one-off" utility script), or just copied pieces of it to use in something current.

I think open sourcing something you're done with (that wasn't already open source) is a great idea in general.

Although bear in mind that open sourcing it might require you to spend some time on the project answering to bug reports and stuff. You might not even intend to add any new features, but if someone else comes in with a new PR, you'll probably (atleast I will) be inclined to review it out of courtesy. Do this for enough projects and you'll be spending a considerable chunk of your time on the weekends on this.

However you might, of course, choose to ignore everything: bug reports, new PRs, users asking for help, everything.

I wouldn't worry about it. I have tons of free software projects that nobody has ever asked about :-) My one project that had a significant number of users (a Japanese language drill program) I recommended that people move to Anki. I occasionally get people asking about various things, but it is never more than I can handle in an adhoc way. I suspect most other people will be the same. Wildly successful side projects are the exception, not the norm.

Just mention in README that there will be no further updates, and "please fork it yourself".

You can disable issue trackers and PRs and let them know in the README.

My original method was to just move my project to I:\home\projects\dead.

After accumulating a few hundred of these, I started going back and reviewing what I'd accumulated - a short one-line description, and a screenshots folder, following a naming convention under a ".projnfo" folder (description.txt, visibility.txt, screenshots\*.png, etc.), with a quick program to accumulate these into a single HTML page overview. My latest iteration of this actually adds shortcut links to launch VS, git shells, etc. and dynamically updates, but ditched the screenshots (for now): http://i.imgur.com/gbj1Cr5.png . I keep telling myself I'll eventually spin off a public version of that page, but so far I haven't. But a common goal: Make it absolutely trivial/low friction to give something a quick summary.

Most recently, I'm now also trying to embrace the idea of "always be shipped (tm)" as a means of combating my tendency to get hung up on perfectionism - in the most extreme form, this means a public github project and an empty initial commit is my first push, the second commit maybe adds something that's actually usable, and the third commit is a .nuspec so I can package it and reuse it at a whim (completely ignoring the question of if it's even worth reusing.) This also encourages me to pick up an old project against instead of rewriting a whole "new and improved" version - easier to just fix the old one than go through all the effort of .nuspec s and new github projects etc etc etc... and in this state, "closing" a project is a simple matter of no longer committing to it. No cleanup necessary before making it public - it already was public!

I still have some projects that I never make public, or only make a github page public for though.

Cool, always had a smiliar idea, just didn't do it yet.

I usually push things to GitHub. When I replace my laptop every 3-5 years, I'll download the things I want to work on and leave the rest.

I also try to always put up a paragraph or two and maybe a screenshot on nfriedly.com/portfolio.

My projects are rarely "done", but "good enough to include in my portfolio" is a major milestone that often coincides with when I stop working on it so much.

For code: create a readme (for your future self) that documents the state of things and dump the whole folder/project on github.

Often times, you'll have a hard time running old stuff you wrote (finding the same versions of the compiler/libraries/tools/etc.) so try to vendor your dependencies if that's an option. Even if you can't run your code down there road, having the source file can be a fun read or useful.

For non-code stuff: convert to a plain file, PDF or screenshot and file it away in your Dropbox/Google drive/whatever.

It takes work to prevent things not just die due to oblivion and inactivity.

I had a bunch of Java applet computer games that ran for more than a decade but eventually were killed by applets becoming obsolete.

I ended doing the following:

1. Putting all code on github.

2. Making a series of youtube videos of the gameplay.

3. Writing a blog post.

Obviously this was a lot of work; but so was creating the games.

It felt good doing the "archive" of them even though no one else cares. I suppose it is a bit organising a box of old photos; makes you think about what you have been doing.

And also: Publish it.

Eventhough no-one will use it; this forces you (at least that's how I work) to make things look decent. Make sure you code actually compiles and it is complete.

Keep all the code, mockups, assets, etc. Running a web dev/design shop for 6 years, many clients have come back even years later asking for a specific file, or a small variation in an old asset. I kept the code on GitHub and the assets on Google Drive. If you want to delete things, send the client the .zip archive first so the ball is in their court when they need something from the past. I didn't put too much value in post mortems or recaps.

I am a digital hoarder... I have folders on my hard drive with stuff I created 25 years ago still on there... AND backed up on multiple cloud locations too!

I don't. Mine just lapse into torpor, sometimes indefinitely, but more often I end up cycling back when my interests cycle back around to whatever they were about. They seem to be roughly seasonal. So if I look at created/modified dates on one of my old unfinished projects I'll see something like:

file_a 2014-05-04

file_b 2015-04-17

file_c 2016-03-23

Clearly that's something that my mind gets interested in around springtime (for no consciously apparent reason). I wrote it in one language in 2014, redesigned it in 2015, and rewrote it in a different language last year. Who knows what I'll do with it this year or next?

I don't purge because I know I'm likely to want to take it up again, or at least pluck part of it out to use in something new.

I personally have a repo full of old code and move projects there once I'm done with them: https://github.com/Xe/code

Why'd you want to do that? You loose your history etc.

I don't understand that fixation on "history", it was helpful couple of times to find who did change and if there is ticketing system with attached ticket then I get some context. But bunch of diffs does not matter and for side project that I am doing on my own what I care for is current state not that I changed name of class and then changed it again two days later. Maybe I am missing something?

Not necessarily - there's multiple ways to collapse at least one branch's history into another repo e.g. from https://github.com/arkie/proto

  read repo; git fetch ../$repo/ master:$repo; git push origin $repo

    git remote remove origin

    git remote add origin <dead_repo_url>

Do film directors delete their old films? Musicians delete their old music? Photographers delete their old photos? Why would you delete your old code?

When I was a homeschooling parent, it occurred to me that kids in public school were "done" when the school year ended, even if they had not read every page of every textbook issued to them. Up until then, we had been struggling with this sense of failure or something for not finishing all textbooks or whatever. After that, I began deciding on certain metrics for "done" and then coming up with small rituals to give us all closure. When they were no longer below grade level, I had them pack up the phonics program they hated so I could mail it to their cousin. That way they knew they were "done" and could be happy with it.

You can do whatever floats your boat here. You are probably the best judge of which pieces have residual value worth preserving in some manner and which things are just basically leeching your time, energy, mental space and hard drive space (or whatever).

I like the idea of creating a memorial blog post.

I don't understand though why you mention "open source" as a method. Although some people do this, I don't think github etc. should become graveyards of abandoned projects. Open source should rather be a method of developing a project. (When you're done with it put a note at the top of your README.)

WRT to (digital) archiving etc., I'd like to take a slightly different take on that topic: Every project is of limited interest. Sooner or later your interest will wane. Let's organize projects (or rather their digital artifacts) in a way that incorporates this fact. E.g. put all files related to project X, you created this year, into "Projects/2017/X" and create a symlink to that folder in "Projects/now", where you keep your references to projects that you're working on now. No need to archive anything later on. Just remove the symlink.

> I don't think github etc. should become graveyards of abandoned projects. Open source should rather be a method of developing a project.

Ending a project by releasing it as open source is a reasonable form of "closure" for the developer. For future viewers, a reasonably well-documented-but-abandoned project still offers insights for future developers to draw from.

I don't understand why should you delete any piece of your work. Disk is so cheap you can keep it forewer.

Depends on the situation, but generally some fairly bad ideas... "node.js left-pad" and "Mark Pilgrim 410"

I zip it up (makes it easy to manage, especially with node.js) and throw it onto my backup server (With mirroring to B2).

I still keep my high school project online. It's not a lot of effort.

https://www.szatkus.pl/oki/ https://github.com/szatkus/oki

I put code, data and other files on trusted cloud services like Dropbox or Google Drive. I also make a copy on a external hard drive in case any of these cloud services go down one day. A README.md is the essential index to organize the files.

When I finish a side project I check it off my to do list and then put it on my public portfolio. The process is very gratifying.

I keep the landing page up but show an alert that the project is discontinued.

Archive folder works. Disc space is cheap and plentiful!

Reply on news.ycombinator.com