This page is intended to replace the published OSS Watch document A guide to participating in an open source software community

Engaging with open source

[CHANGE TITLE TO DIFFERENTIATE FROM 'GET INVOLVED ...'? - FROM THEIR TITLES, THEY SEEM VERY SIMILAR]

Participating in an open source software community can, initially, seem an intimidating prospect. However, such communities are ultimately composed of people, with all the virtues and foibles of people everywhere. Pre-conceptions should be avoided: Open source software communities are rarely populated entirely by highly technical individuals proud to call themselves hackers, nor are they composed entirely of certified software engineers. You will get along better by simply engaging with the community as you find it, leaving any pre-conceptions at the door.

Remember that everyone working on the project is working towards a common goal, and that useful skills and a bit of effort will almost always be welcome. Equally, taking the time to plan your involvement and get to know the community will smooth the path to a successful collaboration.

Here are some tips that may make your progress a little easier.

Prepare

Play to your strengths

• You do not need to be a software developer to participate in an open source project. Think about your skills and what form your contribution to the project might take. Possible roles include:

[ET TO CREATE NEW DOCUMENT DETAILING THESE ROLES MORE FULLY AND ADD LINK]

• documentation writers
• translators
• website designers
• GUI designers
• communications people
• people to maintain the build and test machines
• people to support new users
• people to report and/or fix bugs [ADD THIS?]
• people to market the project [ADD THIS?]
• beta-testers to test products before release.

Estimate your time commitment

• Whatever your role, your contribution to the project will be ultimately more useful, and your experience more positive, if you decide beforehand 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 offer only as much as you can realistically deliver; people appreciate 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 also allow time for your family and friends.

Check your employment contract

• Before you become involved in an open source project, it is vital to ensure that you are permitted to do so by checking your employment contract for intellectual property rights (IPR) clauses. 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, and some are slowly beginning to mark this recognition within institutional IPR policies and/or employment contracts. [ET TO SMOOTH LINKS IN THIS PARA AND FLESH IT OUT]

If you are an educator planning to involve students in an open source project, you should check that their enrolment contract permits this type of involvement and that the students understand the implications. [FLESH OUT WHAT THESE MIGHT BE OR PROVIDE LINK?]

Get to know your community

Understand the entrance conditions

• It is worth spending some time getting to know your community before you participate in it. 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. It is most important, perhaps, 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.

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 Debian distribution, are flat democracies. These different types of communities require different styles of participation. [CAN WE GIVE EXAMPLES OF DIFFERENT STYLES OF COMMUNICATION - PERHAPS IN CONTEXT OF LINUX KERNEL AND DEBIAN DISTRIBUTION IN PREVIOUS SENTENCE?] Some development communities, of course, are very small. But they are still likely to have a distinct and emerging structure [WHY 'EMERGING'].

Understand the role of constructive criticism

• Most communities have lively discussions, in which a range of individuals express their opinions frankly. 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 contributors.

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 that will form a good basis for online discussion.

Understand the communications channels

• Open source projects typically use chat sessions (usually 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.

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 typical of open source projects is the 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 them, and provides positive feedback to the creators, encouraging them to maintain existing resources and develop new ones.

Terminating your involvement

[HAVE ADDED THIS HEADING TO CREATE THREE DISTINCT PHASES - NOT SURE STRICTLY NECESSARY AND NOT SURE IT'S THE BEST WORDING!]

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 reduce your workload.

Plan an exit strategy

• Have a plan for what happens to your contributions to the open source project when your priorities change or you move jobs. [MENTION SOME OF THE OPTIONS?] If you are an educator planning to involve students in an open source project, have a plan for the end of the course, when the students will move on. Bug-fixes, well-integrated modules, additional translations, generic documentation and publicity material tend to survive after their creators have left the community. Local hardware, radical restructuring and poorly integrated modules tend not to.

Further reading

Links

• How To Ask Questions The Smart Way by Eric Raymond and Rick Moen

Related information from OSS Watch:

• Can you contribute code to an open source project?
• Contributor licence agreements
• What is a software patch?
• Building open source communities
• Top tips for selecting open source software

The content of this wiki is licensed under the Creative Commons Attribution-ShareAlike 2.0 England & Wales Licence.

OSS Watch is funded by the Joint Information Systems Committee (JISC) and is situated within the Research Technologies Service (RTS) of the University of Oxford.