10 Tips for an Awesome Open Source Project

pieterhpieterh wrote on 29 Apr 2013 13:53


In this article, ten top tips for making your open source project awesome! We've collected these tips by paying scientists to study the most awesome open source projects in the world. Whether you're starting a new open source project, or open sourcing your company's kind of old codebase, these tips will help you. Enjoy and retweet!

Tip #1: Choosing your language

The choice of language is more important than anything else. When people download a new project, their first question isn't going to be, "why should I spend five minutes to try this stuff?", or "what problems does this solve?" but "what language did s/he write this in, and why?" Choose a language that shows how smart you are, something few people have ever heard of. You might even write your own language for the project. If you don't have time for that, you can get pretty close in any real, modern language. Abstraction is leverage, and don't you forget it!

Tip #2: Choosing your project name

The name is going to have to be memorable. Don't choose a bland name that simply says what your project is. Choose something that will make people giggle, when they get the joke. If you can find a really spaced-out name you could even get the matching dot-com! Trust us, the stranger the name, and the harder it is to type, the more people will appreciate you.

Tip #3: Choosing your license

Many people believe that any license at all is a horrid imposition on the freedom to copy code, and they leave their open source projects without any LICENSE file. You gotta admire such boldness. We know that shorter licenses mean more freedom so obviously no license at all is the very most free of all. rm -f LICENSE my friends!

Tip #4: Defining a roadmap

Make a roadmap and stick to it, no matter how far you fall behind. People will respect you for this. Most projects just adapt to new circumstances and knowledge with no self-respect at all. Some projects don't even have roadmaps, which is clearly insane. You should make weekly promises to your users about upcoming features, on your blog, and when they make issues, mark them all as "accepted" right away. The more stuff in the pipeline, the better, and a promise is worth its weight in silver unicorns!

Tip #5: Making a website

You need a beautiful website, because people like that. Users are very sensitive creatures so put up pictures of happy people and animated graphics in the highest possible resolution. Don't forget diversity! We'd say 30% of your whole budget should go into the website. Put everything there: blogs, events, issue tracking, brochures, etc. You can add a big "Buy Now" button that takes people to your sales team.

Tip #6: Code quality

The thing about open source is the code is open, so anyone can download it for free, without paying anything. This is awesome. Even just making your project open source, it automatically becomes awesome! But the code quality is what really matters. We humans didn't invent OCD for nothing - it makes better code! When people submit patches, make sure to give them lots of feedback on every little detail and don't merge code that isn't perfect.

Tip #7: Working with others

Other people are the enemy, don't forget this. They don't share your vision, ethics, or interests in music. If you let them into your project, they'll take it over and steal your ideas. This is the only thing about open source that isn't awesome, is other people, and the way they always steal ideas. We like to use Bitbucket and Mercurial, two beautifully designed barriers to entry. Above all, don't deal with that devil GitHub and its so-called "pull requests" that make it easy for literally anyone to get involved.

Tip #8: Writing the docs

Most awesome open source developers don't bother with docs. After all, if the code is perfect, who needs docs? If you're going to write docs, make them as painful to read as possible. Use tortuous language and change your definitions arbitrarily. This is important as it keeps your readers awake, and attentive. If you really are going to write a README, usually a two-liner is enough. Line one should say, "For details, see the code". And line two should say, "Patches welcome!"

Tip #9: Attack the competitors

A good blog posting should always attack a competitor. It's important to take a feature that you do well, and that no-one really uses or cares about. This means no-one else will have implemented it. You can then attack them mercilessly, and they will have no good answer except to ignore you, which is the sure sign of a loser. If in doubt, use Wikipedia to explain why your project is so awesome. Always get the last word on any Internet thread that discusses your project.

Tip #10: Helping your users

Last but not least, when people come to your list asking for help, watch out! You can easily get drawn into endless discussions with people who just want to use your work for free. Realize that users are parasites. Our advice is to reply to every question with a link to the README (and now you see why we advised you to write one!).


Use these tips carefully, and your already awesome open source project will become more awesomer. It's simple math, and we mean that literally in the metaphorical sense. Next week, an in-depth study on editors: "Vim or Emacs, why you should care."


Add a New Comment
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License