A guide to participating in an open source software community

1. Prepare

Play to your strengths

Not everyone has the same skills, and there are many roles outside writing code in open source projects. These include

• documentation writers
• translators
• website designers
• GUI designers, and
• communications people

Projects also need people to maintain the build and test machines, people to support new users, and beta-testers.

Estimate your time commitment

Decide whether you want (and are able) to commit a small amount of time every day or a more substantial amount of time periodically. Be careful to only offer to take on as much as you can realistically deliver, people respect completed work far more than hollow offers of help. Think carefully about where the time for your efforts will come from. If you are working on the project as part of paid work, as most people do, you'll need to justify that time to your boss. On the other hand, if you are spending some personal time on a project be sure to allow time for your family and friends.

Check your employment contract

It is vital to check your employment contract for intellectual property rights (IPR) clauses to ensure that you are permitted to participate in an open source project. Since software code is copyright protected, only the owner of that code may legally license it for others to use. Many employers recognize the value of staff participating in the development of software that is used within the firm. Others are slowly beginning to mark this recognition within institutional IPR policies and/or employment contracts. If you are an educator planning to involve students in an open source project you should also check that their enrolment contract permits this type of involvement and that the students understand the implications.

2. Get to know your community

Understand the entrance conditions

Most communities have an accepted way of engaging with the community. This can be as simple as joining a developers' email list, and/or adopting a particular code of practice. Most important, perhaps, is to learn how questions are asked and answered in this particular development community. The paper How To Ask Questions The Smart Way by Eric Raymond and Rick Moen is an excellent guide. It is worth spending some time getting to know your community before you participate in it.

Understand the structure of the community

Some communities, for example, that of the Linux kernel, are hierarchies with clear chains of command. Others, such as the community around the Debian distribution, are flat democracies. These different types of communities require different styles of participation. Some development communities, of course, are very small. But they are still likely to have a distinct and emerging structure.

Understand the role of constructive criticism

Most communities have lively discussions in which a range of individuals frankly express their opinions. The cut and thrust of some such discussions can be surprising. Do not let it put you off. If one particular development community is not to your taste, rest assured that there are others out there with more like-minded developers.

Get to know the people

Large open source projects have a wide range of participants and the first or loudest answer to a query is not always the correct answer. By following the project for a short time you can gain useful knowledge of the people involved and their roles. Not all open source communities are wholly virtual. Many of the big projects have face-to-face get togethers to discuss future plans, or run code fests, and these events can be used to establish personal relationships which will aid online discussion.

Understand the communications channels

Open source projects typically use chat sessions (typically IRC or jabber), mailing lists, websites, blogs, wikis, and version control repositories as their primary means of communication. Get to know your project's communication style and preferred communications tool.

Learn about 'Poisonous People'

Some behaviours in open source communities are seen as anti-patterns¹ in that they obstruct constructive activity. Most people will inadvertently engage in one or more of these activities from time to time, usually with good intention. We strongly recommend you spend fifty five minutes watching 'How To Protect Your Open Source Project From Poisonous People' by Ben Collins-Sussman and Brain W. Fitzpatrick. This video will not only show you which activities are not constructive, but also help you understand how to limit their impact when you see them in others.

3. Be a team player

Communicate what you are working on

If you work completely on your own to re-develop part of a project, by the time you finish someone will almost certainly have either duplicated your effort or the project may have made other changes that render your work obsolete. A corollary of the lack of central planning and coordination in open source projects is a need for everyone to bear at least a portion of the burden of communication.

Acknowledge resources you use and their creators

It is important to acknowledge the resources you use. This increases the likelihood that others will also find the resource and provides positive feedback to the creators encouraging them to maintain existing resources and develop new ones.

Give back

A healthy community depends upon the principle of individuals giving back to that community. So, if you have received support from the community the best way to make sure that situation continues is to reciprocate by providing support to another community member when you can.

Plan an exit strategy

Have a plan for what happens to your contributions to the open source project when your commitment to the project changes. If you are a educator planning to involve students in an open source project, have a plan for the end of the course when the students move on. Bug fixes, well-integrated modules, additional translations, generic documentation, and publicity material tend to survive the creators leaving the community. Local hardware, radical restructuring, and poorly integrated modules tend not to.

Retire gracefully

If your open source participation is waning due to work, family or other commitments, inform other community members of the problem, so that they can take up the slack and/or take steps to lower your workload.

4. Summary

For most people, their first foray into an open source project can be both difficult and scary. However, most quickly realise that it is well worth the effort. The rewards are higher quality software, reduced costs of development and an opportunity to learn from the best. Finding a starting point can often be quite hard, but learning about the structure of a sustainable community project is a useful step towards understanding how one can contribute to a community.

5. Further reading