Doing it right: Your first open source project
I do frequent rounds to Github to contribute to small projects or libraries I find useful. Generally my contributions come from issues I have had with the project, and identified a fix. Last year I made my first attempt to write my own jQuery library. Not meaning to make anything big, this was just something I would like to use for myself and thought about hosting it on github to feed my self-worth. It played pretty decently, and I noticed a few people using it as well. But something didn’t feel quite right.
Recently, I made another attempt. This time I wanted to keep things organized. I had realized that there is a difference between an Open Source project, and a well maintained Open Source project. As a developer, I would hate to rely on a project that is being least cared about the original author; unless I’m using it for a garage project. So what is it that makes a project well maintained?
I started working on Jello a few weeks ago. And here are the few things I made sure I followed. I might be stating the obvious here, in which case you are free to fly over to some more interesting stuff on the internet.
Here is a quick checklist:
- Add every feature you wish to implement as an enhancement in the issue list.
This helps you and your audience keep track of your progress, and you don’t miss out on crucials. Remember, people looking at your half-baked project can easily take a look at reported enhancements to know where your project is heading.
- Create project milestones, and add issues to milestones.
Milestones can be scheduled. This gives your audience a clear idea about what to expect, and when. Once milestones are closed, these can be easily referred to create change logs.
- Close or Fix issues with commits.
This leaves less ambiguity in your commits. Your audience now knows what just got fixed and how.
- Assign yourself on any open issues you are planning to address.
This develops a sense of responsibility among contributors. Unallocated issues are bound to remain on the backburner, esp. when there is a volume of issues coming up. This also prevents any parallel planning during development.
- Isolate the master branch from your development branch.
Agree or not, there can be a lot of half baked commits, reverts that you would not want on your master. It would just confuse your audience. A dev branch will make it easy for contributors. They can remain care free with their commits.
- Mark releases.
Your audience might prefer to have the luxury of choosing an older build, as opposed to the latest one. Marking releases makes your development more reliable.
- Go through some pain to write a contributor guideline.
A good project will demand more than one contributors, and to make the on-boarding easy make sure you put a readme for your prospective contributors. Contributors should be instructed to describe their commits in details for pull requests to be merged.
I will be trying to update this checklist as I proceed. Feel free to get back to be on twitter @omtalk, with any feedback, suggestions or rants.