Ask HN: What are the guidelines to follow while opensourcing a project I'm opensourcing an ecommerce solution for B2B sellers. It was our startup, that we are shutting down.
Would really appreciate any guidelines and pointers on how I should go about opensourcing the entire project? |
It's important to accept that this isn't a one-time task: you (or others) must invest time and effort to transition the product, and that process will take at least a year, and likely much longer.
If that's ok, then I think the most important thing in trying to develop a community for an open-sourced product is removing barriers to entry. There's no guarantees of success, but making it hard to understand, use, or contribute can easily doom your efforts.
So ...
Put it on GitHub. You could use GitLab, or BitBucket, or something else, but ... GitHub is almost always the best option in 2018.
Give it an MIT or 2-clause BSD license. You could do Apache 2.0, or GPL, or AGPL, or Commons Clause, or whatever, but ... MIT/BSD2 will cause the fewest issues. Put a LICENSE file in the root dir of the module, and a copyright notice in every file, so it's 100% clear that it's not encumbered by anything that'll be a problem later. This assumes you can legally do it, of course (and if not, you need to sort that out first).
Add a new README. You'll need to explain what the application is and does and why it's better at it than other things that people might use instead. Some of that you might have, but the competitors are often different now, and the audience is more technical, so it probably needs to be rewritten. An incredibly high proportion of open source software fails here: you cannot assume that people know what this thing is and does!
Also in the README, explain how you'd like people to contact you and/or communicate. Gitter? IRC? Issues/PRs? Mailing list?
Set your GitHub keywords and description. They're a good way of helping people to find your project.
You now have two (probably overlapping) audiences: users and developers. You need to help them both.
Add a DEVELOPERS (or maybe INSTALLING) file as well, and in here explain everything a developer needs to know to go from a git clone to a running system. Dependencies, build configuration, running the build scripts, what and where the artifacts are, how to configure them, how to run them.
Set up Travis and/or Appveyor to build from GitHub. Add a code coverage check and linter. Put the badges for these into the top of your README so they show up above the fold in GitHub. Make sure they're green :-)
For users, consider generating a Docker (or VM) image, so that people can easily try it out. A demo system is also a good tool for allowing people to easily figure out if this project is of interest to them.
Obviously, users will need documentation as well. How to install, setup, and maintain the software. And maybe end-user guides or notes as well.
Add known bugs and roadmap features to GitHub's issues. You're going to have to look after this, answering questions, removing duplicates, explaining workarounds, and (hopefully) fixing actual problems. It's important that this happens frequently -- looking "dead" will turn away both potential users and developers.
And then, your quest for adoption begins. Getting stars, forks, and followers help to make the project look successful, so if you can get a few of your cofounders or former employees to help out, that'd be good.
Getting code contributions from your former team is good too. Going through the process of creating an issue, submitting a PR, and accepting it shows your commitment to process, keeps the project "alive", and adds a contributor: all good things from a potential user or developer's point of view.
You might want to blog about the project, write Medium articles, or post stuff on HN -- your next task is finding, attracting, and keeping a community which is a whole other post :-)
We have the product on a live server now, so we'll probably keep it up and running for people to get a feel of it without having to put in the effort to set it up.