Submitting a Project to Branch? GitHub Best Practices

A couple nights ago, I had the opportunity to attend my local JavaScript Meetup here in Ottawa. Our second speaker was Simon MacDonald giving a talk entitled Maintaining Open Source while Maintaining Your Sanity. I enjoyed the talk so much I thought DZone users may benefit from some of the points Simon laid out.

Now, I'm not in any way saying these practices are a requirement in order to submit your project for approval. These are simply suggestions that will make it easier for other developers to navigate your project, and possibly even help make it better.

Include a README

Including a README file in your project is pretty essential. It should give developers looking at your project the essential information they need, including:

• An overview of the project. This will give the developer a good idea what exactly your project is trying to accomplish.
• A getting started section. This should be a simple set of instructions that will get the developer up-and-running with the project as quickly as possible.
• An invitation to contribute. One of the great benefits of open source is the ability to collaborate, so if you would like other developers to help you improve your project this section will encourage that.

Include a LICENSE

While this is never mandatory, it is incredibly important in the open source community. To quote a GitHub article regarding open source licensing:

"Generally speaking, the absence of a license means that the default copyright laws apply. This means that you retain all rights to your source code and that nobody else may reproduce, distribute, or create derivative works from your work."

The absence of a license is kind of the opposite effect we try to accomplish with open source, so including an open source LICENSE is key. You can use pretty much any open source license you wish and GitHub gives you a bunch of different options when creating a repository, so have a look.

There's plenty of more information in Simon's slides about handling collaboration when you have an open source project, but I just wanted to point out the main setup points here. Feel free to have a look at the entire presentation if you want to know more about keeping your hair when maintaining open source.