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.<p>Who has done this before? What should we consider?<p>Legally, I think we're ok: Everyone involved is enthusiastic about open-sourcing and we've been careful with IP assignment and other paperwork.<p>I'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?
We open-sourced our startup (<a href="https://github.com/hummingbird-me/hummingbird" rel="nofollow">https://github.com/hummingbird-me/hummingbird</a>) and I think it was fairly successful.<p>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.<p>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.<p>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:<p>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.<p>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.<p>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.<p>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:<p>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.<p>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:<p><a href="https://news.ycombinator.com/item?id=8641867" rel="nofollow">https://news.ycombinator.com/item?id=8641867</a>
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.