looking east

Getting started with open source development is not as easy as one would think after all. In chapter 5 of her thesis, Evangelina Berdou explains the entry barriers which have to be overcome by newbies. As she explains very well, there are several aspects which should not be underestimated:

“Despite their open collaborative character, F/OS communities are characterized by significant barriers to entry. The stumbling blocks to participation can be categorized into three broad categories. First, there are difficulties associated with the technical aspects and tools of F/OS development, such as the use of CVS. Secondly, there are conceptual difficulties related to understanding the development process and the architecture of the program, how they are set up, how things fit and how they are expected to be put together. Thirdly, there are difficulties related to how newbies situate themselves in the development process, where they start and what are the tasks most appropriate to their skill levels.”

To contribute to an open source project, newbies will first have to learn how to check out the newest code (often referred to as trunk) from the code repository (like SVN, CVS, or GIT), and how to build it from source with all the necessary compilers, dependencies, and tools. For someone who is not familiar with these processes and methods, this is very often far from straightforward.

Once they have been able to build the software, they will need to find an appropriate task to work on. In most cases, the first task will be a simple bug fix and result in a patch that can be submitted to the codebase. However, finding a task is not as easy as one might think. It often involves reading the mailing list archives, following discussions on IRC, as well as reading bug reports, find out who is working on which bug, and which bugs are yet to be solved. An easier way to get started with development is, to first start working on the non-coding parts of the project as a way to learn more about the project’s community organisation and technical details. Starting off with documentation, bug reporting, bug reproduction, and translation work is often cited as a very good way to make a first step towards contribution. Some projects offer mentoring for new developers which is another great way to get started.

While writing code for contribution, a newbie has to learn about the coding guidelines of the community. What is best practice for customizing the software’s view? Does this code really belong in the core? Where do I define my constants? How do I document my code? Where do I place my files? Once a patch has been written, the newbie will have to learn how to submit it to the community. I have quite often seen people entering an IRC channel and saying that they have implemented some code that they would like to contribute to the project, so this seems to be a real issue. Depending on the project, the process of contribution might be only poorly documented. As a matter of fact, Evangelina Berdou has cited the fragmented nature of documentation as one of the main difficulties for newcomers.

After submitting the patch, the developer can do nothing much but wait for the verdict of the community. Although in most cases, the contribution is very much appreciated, it might happen that the code is being publicly criticised or not accepted into the trunk. Depending on the project, the contributor might simply never get any feedback from the community. Most communities, however, tend to stress the importance of giving feedback to its contributors.

Now, having committed a first patch is a good start. However, developers who occasionally submit a piece of code, will always depend on other people to add the code to the project’s trunk. In most open source projects, only core developers and a few selected individuals have direct commit access to the code repository.