Ask HN: How to open-source my failed startup? | Hacker News Reader

Ask HN: How to open-source my failed startup?

8 pointsgabrielr6 comments

I was cofounder of a startup that lasted about 18 months. We were funded entirely by friends & family. Now that the business is dead and we've moved on to other jobs, we'd like to release some, maybe all, of our proprietary code (currently in GitHub private repos) under a free / open-source license.

Who has done this before? What should we consider?

Legally, I think we're ok: Everyone involved is enthusiastic about open-sourcing and we've been careful with IP assignment and other paperwork.

I'm more interested in the technical and social issues: attribution, reputation, how to best leave it all for posterity.

How much should we clean up the codebase first? Should I re-write the git history? Just release a single snapshot?

View on HN

We open-sourced our startup (https://github.com/hummingbird-me/hummingbird) and I think it was fairly successful.

Personally I feel that the git history is useful so I would prefer not to release just a snapshot. Would be better to rewrite history to remove anything that should not be there.

We ended up using the Apache v2 license, mainly because it requires granting copyright and patent licenses from contributors without getting them to sign a CLA.

In terms of having a successful open source project the most critical thing is to attract contributors. Some easy things you can do towards this end:

1. Simplify your installation process. I found that for Hummingbird the biggest barrier to new contributors right now is our complicated installation, and I am working on getting something working using Docker/Fig.

2. Identify some easy potential contributions and add them to your issue tracker. When I want to contribute to a project the first thing I do is look for easy issues, and a lot of projects make this easy by specifically tagging issues that would be easy for new contributors to tackle.

3. Like arielm said, documentation is very important. Make sure you have a well written README, CONTRIBUTING etc.

If I faced such a codebase (and I have just recently) then I'm interested in (a) installation instructions, pre-requisites, possibly data dumps (b) notes what a version 2 would look like, basically a brain-dump what you think could be improved or shortcomings. Honesty (engineer to engineer) works best. I never had to check the git history for debugging so a snapshot (or depth=1 export) would have been enough.

If you own all rights to the code base I think you can ask for attribution, e.g. "if you use this in a public facing projects you need to attribute <company name, url> on your about-us page." Kind of a one-sentence licence. Some people will ignore it. I would add a "version 1 written by <company> name" as a comment to the beginning of every file just to show where the code originated.

Having only been tangentially involved in open sourcing one project (pixelwave.org) I probably can't give you everything, but I do have a few nuggets that might help:

1. Documentation: a very important part of any project is its documentation. A detailed getting started guide, installation/setup instructions, and api documentation are what gets developers interested. If they don't exist, or aren't good enough, the project wouldn't gain any traction.

2. Licensing - there are many types of open source licenses and it's important that you select the right one. Some require attribution and some don't. This is one area I leave up to the experts, but know is important.

There was a good HN post a few weeks ago from a founder who started to open source his failed startup and decided against it after he realized all of the work required:

https://news.ycombinator.com/item?id=8641867

Probably don't publish your old git repo. If you have multiple branches, add them to a new repo manually. You never know what could be in your old code.

Thanks everyone -- good things to think about.

Reply on news.ycombinator.com