How to Contribute to an Open-Source Project

Contributing to an Open-Source Project is gratifying for a Developer, but it is also very demanding, as Michele Sciabarrà shared with us.

I’ve been thinking to become an Open-Source developer for a long time. In the past 15 years, I have tried many times to become involved in some open-source project but after some attempts, I gave up.

The main reason was generally more because I failed to follow the flow of the project and less because I had not enough time.

Let’s face it: if you really love the project, and you know the stuff good enough to contribute, or you really want to learn the related open-source technologies, you will be able to find the time to work on it.

Finally, three years ago I found a project I seriously liked, that I really wanted to be part of. And I started to contribute to it. In hindsight, I cannot really say I thought to become such an important part of it. I just wanted to contribute.

But in the end, after becoming committed, I also was invited to the Project Management Committee and then I went to work for the company that supports it commercially.

So, I can say that contributing to this project really changed my life. But it was much harder than I expected. I was seriously determined to do a significant contribution and therefore it become so important.

But here I do not want to talk of the project itself but what I learned about the process of being involved in such a project.

Be sure to have the right motivation

Let me be clear on this fact. Contributing to a serious open-source project is a serious effort. It takes time, lots of time, and requires rigorous approach and quality work.

If you want to be part of a significant open-source project, it is generally managed professionally and to be able to contribute you need to be professional.

So, if you really want to, be sure you are ready to do what it takes, or your work will simply not be included in the project itself. Learning new things and improving you CV are legitimate reasons for working on an open-source project, but sometimes are not enough to give you the motivation to do all the hard work needed.

Getting in touch with the community takes time (but it is the key)

In every open-source project, the hardest part for newcomers is to figure out what to do. Code bases of significant projects are generally large, and even if the project itself is well documented for users, you rarely find more than a few notes about how to work with the codebase.

There is plenty of information and resources on Github open-source projects, but all the relevant information will be spread in the code itself, in the issue tracker issues and in the mailing list or the forum. Be ready for that.

Put yourself in listen mode and watch what other people are talking about. Try to understand what is important for them and what are their goals, that can be very different from what you think it is.

Then, look in the issue tracker for “help wanted” issues. There are generally plenty. And finally, do not be afraid to ask.

Before starting to code you should get in touch with the community, make a proposal of improvement and hear from them what they think of your contribution ideas. So, tell them what you want to do and ask for advices.

This is important. Working alone in the dark and then popping out of the blue without anyone have ever heard of you can sometimes work… but it could also lead to a rejection of your work. So, don’t do it. Be part of the community and not an outsider that comes and go.

Do not expect someone will tell you what to do

However, while you should ask for advice, do not expect anyone will tell you what to do. Contributing to an open-source project and creating open-source operating systems, unless you are hired by a company to work on it, is totally voluntary work and no one is entitled to tell you what to do.

So do not expect someone will take the lead and give you directions. This may happen when you must merge your work but not when you decide what to do. Your contributions are ultimately on your own and your sole responsibility.

Coding will be only a fraction of the time you have to spend on it

You may think contributing to an open-source project is just a matter of writing some open code. Nothing can be farther from true.

The key is having your contributing accepted and merged in the code base. And it is generally more complicated than it looks at a first sight. Assuming the existing project team cares for the project itself and they follow best practices, you are expected to:

• Write the code of your feature
• Write tests to ensure your feature works
• Write documentation to explain users what your feature does
• Generate a patch that merges cleanly (do not expect others will resolve the conflicts for you)
• Don’t break existing tests (of course)
• Don’t break the current build.

If you fail to do all of this, very likely your contributions will not be accepted, and you are wasting your time.

And yes, it takes a lot more work than just writes the code of your feature. I would say that 10% is writing some code and 90% is preparing for inclusion in the project codebase.

If you are not prepared for this hard truth… probably your contribution won’t be included in the project just because does not play nice with the rest of the codebase.

Legalities

An important step to do before contributing is to sign the contribution agreement. While you can always write a piece of code, attach a LICENSE file and state it is open source, the reality is generally a bit more complicated than this.

What if your repository has multiple LICENSE files spread in different directories? You should really apply the license conditions to each file. But that may not be enough.

So, to contribute to an open-source project you are generally required to sign an UCLA (User Contribution Agreement).

Note that those UCLAs varies according to the maintainer of the project. Some may ask you to assign them the copyright of your contribution. This means they will own the code and you will not be able to use it on your own anymore.

However, many serious projects just ask you to sign an agreement that you release your contributions under the open-source license of the project itself. You will retain the copyright, so you will be able to use your code as you like, including in proprietary projects, and sell it (note: your code, not the code of the project!).

Your UCLA signing will simply assure the code you released is open source and everyone can use it under the terms of the open-source license itself.

Don’t waste their time (and yours)

Let me finish talking about a few things not to do, but unfortunately it is very common and always ends up in a waste of time.

The first thing is to propose technological changes only because you know that technology and the project uses a different one. “Terraforming” the project to your skill set is a temptation that everyone has, and indeed many people really think that proposing changes to their favorite stack is a smart move to do. It is not.

If the project was done in that way was because other people work and appreciate that technology stack, and it could be even better than the one you already know.

To make things worse, in those case you may even end up in religious wars saying your proposal it is “better”, hence alienating the favor of those people who choose the current stack in the first place and worked on it.

The second thing not to do is to contribute “architectures” or “requirements”, but not code, and expect other people will implement it. While in certain cases it can be useful if you act this way you are basically treating the open-source project developers as your consultants and you are the client. Except you are not paying for it.

The general rule is that if you give requirements you should also be willing to implement it.

Finally, do not contributes typo fixes… only. It is certainly useful. But you really do better to do that as part of larger and more significant work, otherwise, you will look like the school teacher that wants to correct others while you are basically unable to do anything better.

So, start from a bug fix not from typo fixes. Unless, of course, you take the task of fixing typos in the whole documentation, that is a different and significant effort.

Conclusions

Do not get me wrong, contributing to an open-source project is a great way to learn new things, meet interesting people, improve your CV and get job opportunities. At least you will always end up learning new things and it is generally never time wasted.

Use my warnings as a territory map, not as a de-motivational poster.

This article was originally published in Codemotion Magazine. Take a look for more content!