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)?
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.
However you might, of course, choose to ignore everything: bug reports, new PRs, users asking for help, everything.
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.
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.
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.
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.
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.
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.
read repo; git fetch ../$repo/ master:$repo; git push origin $repo git remote remove origin
git remote add origin <dead_repo_url>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 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.
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.