
Ask HN: How do you close your side projects? - andrewgrossi
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.<p>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)?
======
Cyphase
> 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.

~~~
adtac
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.

~~~
mikekchar
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.

------
MaulingMonkey
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](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.

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

------
nfriedly
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.

------
amenghra
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.

------
chvid
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.

~~~
chvid
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.

------
everdev
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.

------
cyberferret
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!

------
Falkon1313
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.

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

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

~~~
ozim
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?

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

------
Mz
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).

------
stewbrew
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.

~~~
TAForObvReasons
> 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.

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

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

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

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

[https://www.szatkus.pl/oki/](https://www.szatkus.pl/oki/)
[https://github.com/szatkus/oki](https://github.com/szatkus/oki)

------
strin
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.

------
dyeje
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.

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

------
exception_e
Archive folder works. Disc space is cheap and plentiful!

