Quick Ways to Start Contributing to Open Source Projects
If you're a developer you might not sure how to get started in the open source community. Here are a few concrete ideas to get you going.
heads up: this is a pretty old post, it may be outdated.
Sometimes it's hard to know how to get involved in open source. What follows are more concrete ideas than "write some docs".
Make error messages actionable
Error messages are usually an after-thought for developers and are usually very difficult to parse. Find common errors and give user-friendly output, with options on how to fix it.
Good thing I took CS255 when I was at Stanford, otherwise I might not have understood this browser error message!
pic.twitter.com/EqtDWl6f3B
Sometimes, setup is complicated. Improve the docs for people installing the project for the first time. Do it yourself and write down all the steps. Then start using the project and write down all the options. Save people time. Redux has great docs
How to be a 10x engineer: help ten other engineers be twice as good.
If the setup docs are already awesome, make sure the rest of the readme is good too. A good readme should:
Have a simple one sentence summary.Homebrew: ":beer: The missing package manager for OS X." or jsonview: "A Firefox extension that helps you view JSON documents in the browser".
Show install instructions. There should be an step-by-step guide on how to install. This can be as simple as npm install express, or more complex for projects like Bud that might need to be compiled.
Provide a bare minimum example to use.Debug does a good job of this. It's as simple as providing a small snippet of code or command to run to get basic functionality out of your project.
Readmes are good, sites are better
Make a site for the project. gh-pages makes it easy to host a static site. The aptly-named gh-pages package makes it easier.
Sites are a good place to provide a logo and screen-shots of the project in use. You can even start with a pretty version of the readme.
Even better, give a way to try the project. Make a runnable example. If there isn't one, the project needs it. If there is one, is it easy to run? Is it easy to change options? Babel does an excellent job of this, but it's easy to setup any module with Tonic.
Add a license
If the project doesn't have a license of some kind, there are people (mostly at large corporations which have lawyers) who will not be to use the code! It can be a political debate to add a license to a project, but it's easy to do.
There are many options, but the MIT license is very popular. I prefer the Artistic License 2.0 which is a slight variant. Just copy and past the text of the license into a LICENSE file (no extension), and submit a pull request.
Add a changelog
Every project should have a changelog, but many don't. It's a bit tedious to go back through the commit history and create one, but most projects will welcome the change. Especially if you include a script to keep the changelog up-to-date in the future.
Help out on the issues
Look for an issue where someone is asking for help and see if you can reproduce the same problem. If you can, that's great! Post your error message. If you can't, that's great! Post your setup and say you can't reproduce.
In software design, these three remain: persistence, simplicity, and empathy.
If you like the project, or if you don't, the docs could always use a section listing its alternatives and why this project is better/worse. (I've done this on my own projects.)
Why you might not need Redux if you use Rx: . We told you in the docs!
