
Ask HN: How to open-source my failed startup? - gabrielr
I was cofounder of a startup that lasted about 18 months.  We were funded entirely by friends &amp; family.  Now that the business is dead and we&#x27;ve moved on to other jobs, we&#x27;d like to release some, maybe all, of our proprietary code (currently in GitHub private repos) under a free &#x2F; open-source license.<p>Who has done this before?  What should we consider?<p>Legally, I think we&#x27;re ok: Everyone involved is enthusiastic about open-sourcing and we&#x27;ve been careful with IP assignment and other paperwork.<p>I&#x27;m more interested in the technical and social issues: attribution, reputation, how to best leave it all for posterity.<p>How much should we clean up the codebase first?  Should I re-write the git history?  Just release a single snapshot?
======
radq
We open-sourced our startup ([https://github.com/hummingbird-
me/hummingbird](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.

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

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

------
drewvolpe
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](https://news.ycombinator.com/item?id=8641867)

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

------
gabrielr
Thanks everyone -- good things to think about.

