Live data from Hacker News

Ask HN: How do you close your side projects?

news.ycombinator.com

11–20 of 33 posts

Re: Ask HN: How do you close your side projects?

#11
post #9

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 differen…

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

Re: Ask HN: How do you close your side projects?

#12
post #8
post #4

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.

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

Re: Ask HN: How do you close your side projects?

#13
post #2

> 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 i…

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.

Re: Ask HN: How do you close your side projects?

#14
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.

Re: Ask HN: How do you close your side projects?

#15
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.

Re: Ask HN: How do you close your side projects?

#16
post #14

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…

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.

Re: Ask HN: How do you close your side projects?

#17
post #13
post #2

> 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 i…

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…

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.

Re: Ask HN: How do you close your side projects?

#18
post #8
post #4

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?

Re: Ask HN: How do you close your side projects?

#19
post #13
post #2

> 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 i…

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…

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

Re: Ask HN: How do you close your side projects?

#20
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.

Post reply on HN