This article is published in Feb 2008 Linux For You Magazine. The original copy can be found here.

Contributing to Open source project

Nowadays, we find at least one open source project for any given software requirement. Always someone find time to do things open source way. Isn't that cool? Who do you think they are? They are one among us who identify that the commercial tool is not affordable, or, it is a handicap in someway or the other.

When it comes to inventing a new successful open source project or, contributing to an existing one, we should agree that the contributors from APAC region is deficient compared to rest of the world. The APAC region is one of highly consumable region for open source software, but when it comes to contributing back to the community, the statistics are not impressive.

In this article, we attempt to give an introduction to what it takes to contribute to any open source software. We take Ubuntu project and Subversion project as case studies. The Ubuntu project comprises many individual teams working on various software tools around Ubuntu Linux Distribution. The Subversion is a version control system. It is a compelling replacement for CVS in the open source community.

The procedure to contribute to any other open source project should be closely similar. The article provides an overview of various teams in Ubuntu project, role of each team and other aspects considered for contributing to this project. It also provides an overview of development process, patch submission guidelines and how to write log message for Subversion project.

Ubuntu Project

There are reasons why you should contribute to Ubuntu project. There are so many teams in which you can join and contribute. Each team has well defined road map and schedule. They also concentrate on embarrassing and guiding the new contributors by conducting the mentoring program.

Depending on your exposure to technologies, you can choose one of these area for contributing to this project:

1. Programming and Packaging


2. Documentation


3. Translation and Localization


4. Ubuntu Artwork


5. Advocacy and Support


6. QA and Bug report

Depending on your exposure and interest, you can join any of these teams. When we say join, we mean to join the mailing list and designated IRC channels. You can monitor the process for few days, before pitching in with your contribution.

Desktop Team -- The foremost task of this team is to maintain GNOME packages. They are responsible to keep up to date with latest release, discuss and fix issues. You can refer to team wiki page for more details: https://wiki.ubuntu.com/DesktopTeam

MOTU -- Masters of the Universe. They spend time by adding, maintaining and supporting as many software in the Universe repository. If you are good in packaging, this should be the place to begin. You can refer to team wiki page for more details: https://wiki.ubuntu.com/MOTU

Documentation -- The team is responsible to create and maintain documents belonging to various applications for each Ubuntu release. They work on writing, editing and updating the system documentation for Ubuntu. If you think you are a good documenter, this is the place for you. You can refer to team wiki page for more details: https://wiki.ubuntu.com/DocumentationTeam

Installer Team -- The team is responsible to maintain the Ubuntu Installer. They are also responsible to keep the Ubuntu installer in sync with the Debian installer. You can refer to team wiki page for more details: https://wiki.ubuntu.com/InstallerTeam

Kernel Team -- The team is responsible to provide a Stable kernel version with every Ubuntu release. They are also responsible to maintain high-quality, consistent package across different architectures. You can refer to team wiki page for more details: https://wiki.ubuntu.com/KernelTeam

These are few teams to name. There are so many other teams which you can explore depending on your interest. Each team has a dedicated mailing list. The developers and volunteers discuss in the mailing list. The patches, code reviews and discussion over various issues are performed in the mailing list.

Ubuntu Code of Conduct

When you contribute to this project, you should adhere to the Ubuntu Code of Conduct. It defines the ground rules that each member should follow during his association with this project.

Be considerate -- You will depend on the work done by others, and in turn your work will be used by other people. Any decision you take will affect users and team members, and they expect you to take those consequences into account when making decisions.

Be respectful -- You should treat the community and its members with due respect. You should make the community a productive place. You should make the community a place where people feel comfortable and inspired by other members. You are expected to be respectful while dealing with other contributors.

Be collaborative -- Free software is about collaboration and working together. You should collaborate with other contributors and reduce the redundancy of work done in the Free software world.

When you disagree, consult others -- Each one of us tend disagree at some point in time. When disagreements happen, we should turn to the community and the process to seek advice and resolve conflicts.

When you are unsure, ask for help -- Nobody knows everything and it is impossible to be perfect always. When you are not sure, ask questions and get it clarified before forming your own assumptions. The doubts should be asked in appropriate forum and we should avoid posting unrelated and off-topic questions.

Step down considerately -- No place is permanent for anyone. People come & go and Ubuntu project is not an exception. When you leave, you should tell people and take proper steps to ensure that your successor can pick up where you leave off.

Becoming a Official Ubuntu Member

The membership role is granted based on substantial contribution to this project. You should continue to contribute to this project for few months. If you are convinced that you are eligible to become a member, you can apply for membership. You should put up a wiki page showcasing the testimonials of the work you have done so far for this project. It could be for any of these teams. The members of Ubuntu Community Council team would verify the testimonials and depending on the recommendation from other members and team leaders, they may either grant the role or defer it. If the request is deferred, you can apply again after few months making more contribution for this project.

When you become the member, you get an email address@ubuntu.com. You get the right to carry Ubuntu business cards. The artwork is supplied by the team and you can print your own cards. The membership lasts for two years and it is renewable.

Subversion

Subversion is a version control system. It is a compelling replacement for CVS in the open source community. The Subversion community is one of highly respected community in the open source world. The Subversion is written in C language. The test suites and other tools around the system is written in Python. The bindings are available for various languages including Perl, Java and Ruby.

To participate in the community, you can join "dev", "svn" and "announce" mailing lists in http://subversion.tigris.org website. The development mailing list, dev@subversion.tigris.org is where all discussion among the developers take place. You can join the development mailing list and monitor how other developers interact with each other. Before you ask a question, please ensure you search the archive and ratify that it is appropriate to be asked in this mailing list.

You can get a copy of the latest development sources of the project from the repository: http://svn.collab.net/repos/svn/trunk/. New development always take place in trunk. The new features, enhancements and bug fixes are back-ported from trunk to various release branches.

There are many ways to participate in the community, either by writing code, reviewing code, testing and/or helping to manage the bug database. Another way to help is setup automated build and test suites.

Submitting Patches

The patches can be sent to the development mailing list. A pre-defined set of guidelines are followed while submitting the patch. For instance, the email should start with the subject line "[PATCH]". This helps the corresponding component owner or the patch manager to spot patches right away. If the patch addresses a particular issue, please specify the issue number in the email subject like "[PATCH] issue #1234: ...". The developers interested in that particular issue will read and comment on the patch.

When submitting a patch, you should include the log message. A good log message helps potential reviewers understand the changes in the patch and increases the likelihood that it will be committed.

Please refer to this web page for more details on how to submit patches for this project: http://subversion.tigris.org/hacking.html#patches

Writing Log Message

It is obvious that every commit needs a log message. The log message is very important and it gives an introduction to the change. The log message not only helps the developers, but also plays well with IRC bots like CIA that echoss first line of each commit to real time forums like IRC.

The log message should name every affected function, variable, macro, grammar rule, etc.

 * subversion/libsvn_ra_pigeons/twirl.c
   (twirling_baton_fast, twirling_baton_slow): Removed these
    obsolete structures. 
   (handle_parser_warning): Pass data directly to callees, instead
    of storing in twirling_baton_*. 

   * subversion/libsvn_ra_pigeons/twirl.h: Fix indentation.

These are few guidelines to name. You can refer to the Hacker's Guide to Subversion for complete set of guidelines to be followed while participating in this community.

Glad to hear ... so what?

Always, someone asks this question. Let it be easy to contribute to a open source project. but, why should I contribute? Alright, let me try to convince them in this section!

1. We get a chance to work with international developers from whom we can gain diverse knowledge. We get to know their style of thinking and learn to groom new contributors.


2. All open source projects are developed in an open environment. The quality of the code, document and communication is reviewed instantly from someone sitting in a different continent. These kind of activities is literally impossible in most of commercial softares developed in closed doors.


3. The communication skill is tremendously improved. When we continue to communicate our thinking, our skill to articulate the idea is improved.


4. No one forgets what we did. The search engine remembers what we do and we do not need an introduction and reference to prove who we are.


5. Above all, we get complete satisfaction and pride about what we do. It is a pay back time to the open source community.


6. No need to mention, our resume looks rich!

About the Author

By: Bhuvaneswaran A. The author is currently employed in CollabNet working for their Operations Engineering group. He is an Official Member of Ubuntu Linux and a Partial Committer for Subversion project.