↓Skip to main content

How to start an open source project

·3 mins

Here’s a bitter little thing I wrote a couple of years ago, found on my hard disk during a tidy up and updated for the current zeitgeist.

How to start an open source project

  1. Set up a project on GitHub, Sourceforge, RubyForge, or wherever. Try to pick a name that’s very similar to an existing project or a commercial product. If you can’t think of one, use an unfunny recursive abbreviation.

  2. Leave the project pages empty for a year.

  3. Don’t do any up-front design, just jump in and start hacking code for a library or two.

  4. Once it compiles, upload it to your project’s version control system.

  5. Make sure the Documentation and Home page links lead to 404 errors. If you must have a home page, provide some trivia about how the code is written and how clever it is. On no account should you provide a description of what the project is, who it’s for, or what it looks like when run.

  6. When people ask where they can find the API documentation, tell them that you’re using a methodology such as Agile or eXtreme Programming, and that there is therefore no need for documentation. Instead, they should guess what the supported API is by reading through the source code for the unit tests.

  7. Code the actual application that uses the libraries and put it in version control.

  8. Once you hear that someone else has worked out how to run your code, call the result version 0.6 (or some other number between 0.1 and 1.0) and have your first stable release. Probably your last for a long time, too.

  9. Double-check that the only documentation is the README. If it seems to be informative, replace it with the generic README from GNU telling people to run the configure script and make.

  10. By now, your lack of up-front design means the whole thing is a real mess. So, start doing major refactoring. Change a few APIs, and make sure that any database schemas don’t upgrade cleanly.

  11. At this point, you might find that you still haven’t managed to dissuade everyone from using your code. You can fight off continuing calls for API documentation and design contracts by mocking the other person’s failure to use Agile or XP, but people might start suggesting that your project would benefit from end user documentation. So set up a blank wiki, with a home page saying “Please write the documentation for this project here.”

  12. Continue to hack on the code in version control, but make sure you don’t have a stable release for a year or two. This will ensure that people either have to run the hopelessly outdated stable code that’s full of security holes, or the stuff in the version control system that might not even compile and hasn’t been tested.

  13. Have another stable release, but make sure to emphasize that migration from the incredibly old previous stable release hasn’t been tested.

  14. Now is probably a good time to rename the project. Set up a new web site for the renamed project, with a new wiki. Migrate a handful of pages from the old wiki–enough to break the major documentation links findable in the first page or two of Google results, but not enough to make the new wiki actually useful.

  15. Now you can make the Sourceforge home page link point at the old home page, and give people the choice of a stable release under the old name, or an unstable release under the new name. Hopefully this will confuse them away.

These techniques have worked for many successful open source projects, ranging from Diaspora to mt-daapd.