How people get started contributing to open-source? A few questions to Luca Barbato, contributor to Gentoo, MPlayer, Libav, VLC, cairo/pixman

I am hearing a lot of persons interested in open-source and giving back to the community. I think it can be an exciting experience and it can be positive in many different ways: first of all more contributors mean better open-source software being produced and that is great, but it also means that the persons involved can improve their skills and they can learn more about how successful projects get created.

So I wondered why many developers do not do the first step: what is stopping them to send the first patch or the first pull-request? I think that often they do not know where to start or they think that contributing to the big projects out there is intimidating, something to be left to an alien form of life, some breed of extra-good programmers totally separated by the common fellows writing code in the world we experience daily.

I think that hearing the stories of a few developers that have given major contributions to top level project could help to go over these misconceptions. So I asked a few questions to this dear friend of mine, Luca Barbato, who contributed among the others to Gentoo and VLC.

Let’s start from the beginning: when did you start programming?

I started dabbling stuff during high school, but I started doing something more consistent at the time I started university.

What was your first contribution to an open-source project?

I think either patching the ati-drivers to work with the 2.6 series or hacking cloop (a early kernel module for compressed loops) to use lzo instead of gzip.

What are the main projects you have been involved into?

Gentoo, MPlayer, Libav, VLC, cairo/pixman

How did you started being involved in Gentoo? Can you explain the roles you have covered?

Daniel Robbins invited me to join, I thought “why not?

During the early times I took care of PowerPC and [Altivec](, then I focused on the toolchain due the fact it gcc and binutils tended to break software in funny ways, then multimedia since altivec was mainly used there. I had been part of the Council a few times used to be a recruiter (if you want to join Gentoo feel free to contact me anyway, we love to have more people involved) and I’m involved with community relationship lately.

Note: Daniel Robbins is the creator of Gentoo, a Linux distribution. 

Are there other less famous projects you have contributed to?

I have minor contributions in quite a bit of software due. The fact is that in Gentoo we try our best to upstream our changes and I like to get back fixes to what I like to use.

What are your motivations to contribute to open-source?

Mainly because I can =)

Who helped you to start contributing? From who you have learnt the most?

Daniel Robbins surely had been one of the first asking me directly to help.

You learn from everybody so I can’t name a single person among all the great people I met.

How did you get to know Daniel Robbins? How did he helped you?

I was a gentoo user, I happened to do stuff he deemed interesting and asked me to join.

He involved me in quite a number of interesting projects, some worked (e.g. Gentoo PowerPC), some (e.g. Gentoo Games) not so much.

Do your contributions to open-source help your professional life?

In some way it does, contrary to the assumption I’m just seldom paid to improve the projects I care about the most, but at the same time having them working helps me when I need them during the professional work.

How do you face disagreement on technical solutions?

I’m a fan of informed consensus, otherwise prototypes (as in “do, test and then tell me back”) work the best.

To contribute to OSS are more important the technical skills or the diplomatic/relation skills?

Both are needed at different time, opensource is not just software, you MUST get along with people.

Have you found different way to organize projects? What works best in your opinion? What works worst?

Usually the main problem is dealing with poisonous people, doesn’t matter if it is a 10-people project or a 300+-people project. You can have a dictator, you can have a council, you can have global consensus, poisonous people are what makes your community suffer a lot. Bonus point if the poisonous people get clueless fan giving him additional voices.

Did you ever sent a patch for the Linux kernel?

Not really, I’m not fond of that coding style so usually other people correct the small bugs I stumble upon before I decide to polish my fix so it is acceptable =)

Do you have any suggestions for people looking to get started contributing to open-source?

Pick something you use, scratch your own itch first, do not assume other people are infallible or heroes.

ME: I certainly agree with that, it is one of the best advices. However if you cannot find anything suitable at the end of this post I wrote a short list of projects that could use some help.

Can you tell us about your best and your worst moments with contribution to OSS?

The best moment is recurring and it is when some user thanks you since you improved his or her life.

The worst moment for me is when some rabid fan claims I’m evil because I’m contributing to Libav and even praises FFmpeg for something originally written in Libav in the same statement, happened more than once.

What are you working on right now and what plans do you have for the future?

Libav, plaid, bmdtools, commonmark. In the future I might play a little more with [rust](

Thanks Luca! I would be extremely happy if this short post could give to someone the last push they need to contribute to an existing open-source project or start their own: I think we could all use more, better, open-source software. So let’s write it.

One thing I admire in Luca is that he is always curious and ready to jump on the next challenge. I think this is the perfect attitude to become an OSS contributor: just start play around with the things you like and talk to people, you could find more possibilities to contribute that you could imagine.

…and one final thing: Luca is also the author of open-source recipes: he created the recipes of two types of chocolate bars dedicated to Libav and VLC. You can find them on the borgodoro website.


I suggest to take a look at his blog.

A few open-source you could consider contributing to

Well, just in case you are eager to start writing some code and you are looking for some projects to contribute to here there are a few, written with different technologies. If you want to start contributing to any of those and you need directions just drop me a line (federico at tomassetti dot me) and I would be glad to help!

  • If you are interested in contributing to Libav, you can take a look at this post: there I explained how I submitted my first patch (approved in the meantime!). It is written in C.

  • You could be also interested in plaid: it is a Python web application to manage git patches sent by e-mail (there are a few projects using this model like libav or the linux kernel)

  • WorldEngine, it is a world generator written in Python

  • Plate-tectonics, it is a library for plate tectonics simulation. It is written in C++

  • JavaParser a Java parser, written in Java

  • Incremental Java parser, an incremental Java parser, written in Scala

How to contribute to Libav (VLC): just got my first patch approved

I happened to have a few hours free and I was looking for some coding to do. I thought about VLC, the media player which I have enjoyed so much using over the years and I decided that I wanted to contribute in some way.

To start helping in such a complex process there are a few steps involved. Here I describe how I got my first patched accepted. In particular I wrote a patch for libav, the library behind VLC.

The general picture

I started by reading the wiki. It is a very helpful starting point but the process to setup the environment and send a first patch was not yet 100% clear to me so I got in touch with some of the developers of libav to understand how they work and how I could start lending an hand with something simple. They explained me that the easier way to start is by solving issues reported by static analysis tools and style checkers. They use uncrustify to verify that the code is adhering to their style guidelines and they run coverity to check for potential issues like memory leaks or null deferences. So I:

  • started looking at some coverity issues
  • found something easy to address (a very simple null deference)
  • prepared the patch
  • submitted the patch

After a few minutes the patch was approved by a committer, ready to be merged. The day after it made its way to the master branch. Yeah!

Download source code, build libav and run the tests

First of all, let’s clone the git repository:

Alternatively you could use the GitHub mirror, if you want to.

At this point you may want to install all the dependencies. The instructions are platform specific, you can find them here. If you have Mac Os-X be sure to have installed yasm, because nasm does not work. If you have installed both configure will pick up yasm (correctly). Just be sure to run configure after installing yasm.

If everything goes well you can now build libav by running:

Note that it is fine to build in-tree (no need to build in a separate directory).

Now it is time to run the tests. You will have to specify one directory where to download some samples, later used by tests. Let’s assume you wanted to put your samples under ~/libav-samples:

Did everything run fine? Good! Let’s start to patch then!

Write the patch

First of all we need to find an open issue. Visit Coverity page for libav at You will have to ask for access and wait that someone grants it to you. When you will be able to login you will encounter a screen like this:

Screenshot from 2015-02-14 19:39:06

Here, this seems an easy one! The variable oggstream has been allocated by av_mallocz (basically a wrapper for malloc) but the result values has not been checked. If the allocation fails a NULL pointer is returned and when we will try to access it at the next line things are going end up unpleasantly. What we need to do is to check the return value of av_mallocz and if it is NULL we should return an error. The appropriate error to return in this case is AVERROR(ENOMEM). To get this information… you have to start reading code, getting familiar with the way of doing business of this codebase.

Libav follows strict rules about the comments in git commits: use git log to look at previous commits and try to use the same style.

Submitting the patch

I think many of you are familiar with GitHub and the whole process of submitting a patch for revision. GitHub is great because it made that process so easy. However there are some projects (notably including the Linux kernel) which adopts another approach: they receive patches by e-mail.

Git has a functionality that permits to submit a patch by e-mail with a simple command. The patch will be sent to the mailing list, discussed, and if approved the e-mail will be downloaded, processed through git and committed in the official repository. Does it sound cumbersome? Well, it sounds to me, spoiled as I am by GitHub and similar tools but, you know, if you go in Rome you should behave as the Romans do, so…

Sending patches using gmail with 2-factor authentication enabled

Now, many of you are using gmail and many of you have enable 2-factor authentication (right? If not, you should). If this is you case you will get an error along this lines:

Here you can find how to create a password for this goal: The name of the application that I had to create was smtp:// Note that I used the same name specified in the previous error message.

What if I need to correct my patch?

If things go well an e-mail with your patch will be sent to the mailing-list, someone will look at it and accept it. Most of the times you will receive suggestions about possible adjustments to be done to improve your password. When it happens you want to submit a new version of your patch in the same thread which contains your first version of the patch and the e-mails commenting it.

To do that you want to update your patch (typically using git commit –amend) and then run something like:

Of course you need to find out the message-id of the e-mail to which you want to reply. To do that in gmail select the “Show original” item from the contextual menu for the message and in the screen opened look for the Message-Id header.

Tools to manage patches sent by e-mail

There are also web applications which are used to manage the patches sent by e-mail. Libav is currently using Patchwork for managing patches. You can see it deployed at: Currently another tool has been developed to replace patchwork. It is named Plaid and I tried to help a little bit with that also 🙂


Mine has been a very small contribution, and in the future I hope to be able to do more. But being a maintainer of other open-source projects I learned that also small help is useful and appreciated, so for today I feel good.

Screenshot from 2015-02-14 22:29:48

Please, if I am missing something help me correct this post