Blog

This is not a definitive guide, but just some basic rules to follow to make your Open Source contribution enjoyable for both you and the project maintainers.

Why joining an Open Source Project ?

First there is many incentive to join an Open Source project. The first one probably being the "cool" factor. You know, so you can tell your geek friends "hey I'm on XYZ project dev team ! I totally rock."

But this is not a very good reason. The first requirement to join an Open Source project is probably to use it. There is not a big incentive to use a project that has no practical use for yourself.

Some good reason to join an Open Source project would be;

• You want to have write access to the code base to push either your own feature or bug fixes
• You think you could bring significant improvements to the project
• You have too much spare time

Initial approach

Joining an Open Source project for the first time might be a little more tricky for two reason.

First there is no standard approach, there is no "Join this Project!" button. You have to contact the project owner (or maintainer) directly and talk to him.

The other thing that could make the joining process a little harder for starters is the lack of curriculum.

Before trying to join an Open Source project you should try to start your own. Even if it's a small project or just a library. Just something simple but yet useful. Then announce it on your blog and on some social sites. If you're lucky some people will also find it useful and start using it.

By doing this you will learn two things; first how to run an Open Source project and secondly you will learn what it's like having your own creation used by many others. It's quite a thrill when you realize that probably thousands of people use your code and some review it and give you feedbacks, ideas or patches.

But beyond that, you'll also see how the community works and evolve. You'll start to see you project from many point of view in many different contexts.

It will open up new perspectives.

If you either have done that or feel that you are ready to join a project anyway, there are other prerequisites;

• You must understand well the VCS that the project use. For example, if the project use Subversion, you should know how to commit, merge, revert, patch etc ..
• You should understand the importance of readable code and documentation
• You should know how to comment your code

If you feel comfortable with all this, the first step is to start playing with the project. Do a checkout and dive into the code, learn how it works and what it does. Note the programming style used as well. It's not capital to code exactly like the current project maintainers, but your code should at least bear the same style. You have to consider at all time that somebody else will read and modify your code.

Like they say; always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.

When you feel ready to join you can go for the next step, contacting the project maintainer

Initial contact

If you already ran your own Open Source project you probably have a good idea on how your email will be considered and what the guy reading it will think.

This is not rocket science;

• the guy is on many Open Source projects and has probably a full time job on top of that; be short and sweet;
• the guy don't know shit about you. And everyone that ran an Open Source project in his life knows at least one thing: Hell is paved with good intentions. Which brings me to the next point;
• show your knowledge about the project, not your excitement about it. In other words, start by proving to the project owner that you have the qualifications to be part of the project, you'll have plenty of time to show your motivation and excitement if you get access.

OK I joined, now what ?

By experience, there is two types of people who joins an Open Source project; those who make the project go forward and those who don't.

Those who don't are usually more prone to show their excitement than actual qualifications. They join the project and either never commit anything or commit too much new code and new functionnalities and therefore brings in new bugs.

When joining a project it's important to ask yourself if you have enough motivation to actually do something, but it's also important to not do too much.

A new programmer is a bit like a new manager in a workplace in a sense that it take similar qualities to be successful.

The real good manager will take a new job position carefully. Even if his ultimate goal is to turn the company upside down and optimize the whole process, he will start by emulating perfectly the previous manager.

Why ?

Put yourself on either the workers bellow him (read users) or the top management (read project owner(s)). They get a new manager which;

A: Enters the company, try to change the business upside down, break the process in the way thus preventing workers from working. But with a lot of hard work it will be so much better!

B: Enters the company, does the job perfectly down to the details and brings small incremental improvement to the work process. Eventually he drafts and present to the higher management detailed plan to optimize the throughput by turning the process upside down.

Which has more chance to succeed ?

Obviously it's B, because on the first hand he proved he was more than competent by bringing slight improvements while doing it's job and then presented a clear and detailed plan of the big changes he wanted to make before trying to implement them.

It's not impossible to bring big changes to an Open Source project, but first you have to prove you can do it.

A successful Open Source project is almost like a successful business, it's hard to change a successful recipe without ruining it.

So be careful with your big changes.

In fact the best place to start when joining an Open Source project is the very base. Start where you can only do little harm.

Improve the project documentation or the comments, add new unit tests or do some code review. It's a good opportunity to get to really know the project, its weakness and strengths. The maintainer(s) will be very happy about it, it's a good way to earn their trust and show you are serious about helping with the project.

It's also a good idea to create your own branch, this way you are sandbox-ed and it's almost impossible to break the project or do something wrong.

Just merge the trunk to your branch often to keep your code up to date with it.

The politics

I don't think there is any written rules about it, but you must know something very important about most Open Source projects;

It is NOT a democracy.

Call it what you want, but in the end there is only one authority; the project owner(s).

Don't like it ? Fork it.