A Small Handbook on How to Join Open Source Projects

2011-04-13 npcomet Posted in Open Source Development | 3 Comments »

Participating in open source projects can quickly improve your technical skills and teach you many valuable techniques that are not taught in school but are extremely helpful in the workplace. A resume that includes open source project contributions is also increasingly valued by employers. Therefore, in recent years, tech enthusiasts have been paying more and more attention to open source projects. However, many students who are interested and passionate about open source projects still use incorrect methods, preventing them from getting involved. I have specifically organized my experiences during this period for enthusiasts to reference.

Phase One: Observe and Learn

In my interactions with some open source enthusiasts, I've found that many lack a technical understanding of the projects they follow. Whether it's the functionality, code, or design direction of the project, their understanding is often vague; most haven't even downloaded and compiled the code. I want to remind enthusiasts that participating in open source projects is not a process driven by a simple desire. Reading the project code and understanding its design principles are essential!

Start Small: Try Fixing Bugs/Issues

Most open source projects that are publicly accessible have an issue tracker or bug tracker. An issue tracker is essentially a compilation of problems. For enthusiasts interested in a project, instead of starting aimlessly, it's better to first find a small issue or bug that interests them, set it as their first goal, and try to resolve it.

Creating Patches

A patch is a text file used to fix code. A typical patch file looks like this:

--- clinkcc.orig/configure.in 2005-11-14 18:08:07.000000000 +0100 +++ clinkcc/configure.in 2005-11-14 18:08:13.000000000 +0100 @@ -150,6 +150,7 @@ AC_CHECK_FUNCS([iconv]) +AM_ICONV

As you can see, a patch file compares the file before and after modification and records the differences. For example, a patch created using the command-line tool diff:

diff -u oldFile newFile > mods.diff

Many graphical version control tools also come with patch creation functionality.
With a concise patch, project maintainers can quickly review and evaluate the proposed changes. Without a patch, it's difficult for maintainers to determine if the modifications are usable. Therefore, to avoid wasting everyone's time, mastering the professional skill of creating patches is essential.

Familiarize Yourself with Version Control Systems

The variety of version control systems used in open source projects is growing. Besides the deprecated CVS and the traditional mainstream SVN, new version control systems like Git and Mercurial (Hg) are becoming increasingly popular. While the proliferation of systems does increase the learning curve for developers, mastering a version control system is crucial for parallel development and friendly collaboration with other project contributors. Therefore, the stage of completing your first issue is an excellent opportunity to become proficient with version control tools; make sure to seize it.

Coding Standards

Major modern open source projects are increasingly strict about coding standards. In projects with dozens of contributors and nearly a million lines of code, coding standards are essential to ensure code readability. Therefore, when writing code, always pay attention to whether it complies with the project's coding standard requirements to avoid having your contributions rejected.

Adhere to Rules

In some large projects, there might be project-specific rules in addition to coding standards. Always read the relevant instructions on the homepage or in the developer community carefully to avoid unnecessary disputes.

Going Further

Contact Project Maintainers

When you have ideas that might lead to significant changes, it's crucial to first maintain good communication with the project maintainers. Clearly describe your ideas via email, mailing lists, or IRC. Gaining the approval and help of project maintainers and other developers is key. As a side note, when making initial contact, always remember to introduce yourself; this is not just a matter of politeness, but a fundamental basis for building trust.

Becoming a Regular Contributor

After accumulating patches and building trust, maintainers will usually proactively invite you to become a regular development member. My advice on this matter is to maintain a positive mindset; what's meant to be will happen naturally.

Creating a New Branch or Fork

Fork is a word I find difficult to translate. The original meaning of 'fork' is a utensil, with no positive or negative connotations. In the developer's world, it can be understood as several tines originating from the same source. When you have a 'wild' idea for a project, project maintainers might not want to see such an experimental branch within the main project. At this point, you can fork a sub-project to implement your idea. Especially with the widespread popularity of Git and Hg, forking and then merging back has become very easy, thus reducing the maintenance burden of forks and making them more acceptable.

Time Management

Most developers who participate in open source projects write code in their spare time. Therefore, good time management is essential to effectively achieve your goals. In recent years, the technical specifications of open source projects have become increasingly demanding. Having a pre-planned schedule can better help you maintain a positive mindset and avoid giving up halfway. With dedication and perseverance, you will gain attention and respect, and even re-evaluation and commendation from employers.

I hope this small handbook helps more developers easily participate in more international open source projects. You are also welcome to follow Splayer's open source project at http://hg.splayer.org/splayer/

Source: Splayer Blog