['GET INVOLVED IN A PROJECT' AND 'ENGAGING WITH OPEN SOURCE' SOUND QUITE SIMILAR - SUGGEST CHANGING TITLE OF ONE OF THEM TO REFLECT THEIR CONTENT MORE CLOSELY?] [QUERIES AND SUGGESTIONS IN CAPS AND SQUARE BRACKETS]
The hope of all open source projects is not just to attract users, but also to encourage people to help develop the project further. This document will introduce some of the systems most commonly used by open source projects to allow contributors from all over the world to collaborate on the project. [LINK TO PARTS OF MOZILLA PROJECT'S WEBSITE TO ILLUSTRATE THESE]
First, though, it should be pointed out that most projects need more than just code. Other important contributions that can be made to a project include: helping to write documentation, how-tos, and so on; translating documentation, or even the user interface of the software, and contributing graphics, sound and other multimedia resources. Simply reporting a bug is a valuable contribution, as is spending time assisting other users, for example on a support forum. [LINK TO NEW DOCUMENT, WHEN IT'S READY, ABOUT DIFFERENT ROLES ON A PROJECT]
Contributing to a project
Most projects revolve around a presence on the web, which is the gateway to every aspect of the project. This can be a normal website, but many open source projects also have a presence on what are called 'forges', which are on-line repositories containing many open source projects. These forges provide the infrastructure that a project needs (storage for files that make up the project, and provision for communication, tracking bugs, keeping statistics about the project, and so on). One of the best known of these is SourceForge, which hosts many thousands of open source projects; visitors can browse or search there to find projects of interest.
People wanting to contribute to an open source project will usually find that projects' websites have a fairly common set of features for contributors. These include:
1. An area on the site for contributors and developers: Many projects will have a specific area on their website dedicated to explaining to potential contributors how to get involved, and some instructions about getting started. Also, they may suggest specific contributions they would like to see, and give contact details for people on the project who will advise new contributors. The developers' section will also provide access to the resources you will need to begin, and usually to the various ways of communicating with the members of the project.
2. A repository of the project code and other data: The core of the project, this repository is usually managed by a version control system (also known as a revision control system), which automatically tracks and integrates changes made to the project. Usually, a contributor would use the corresponding client software to download a copy of the code, held in the version control system, to their own computer. They would work on it on their own computer, and then send what is called a "patch" - a file describing the changes they have made, generated automatically by a software tool - back to the project. A member of the project would then review this to decide whether or not to incorporate it into the project. Although there are a number of version control systems in use, and many clients for them, the principles are all largely similar to those described in our complete walk-through of producing a patch.
Mozilla has a page explaining its version control system, Mercurial, though this particular system is unusual. A more typical example is Abiword's, where a system called Subversion is used. Many projects also allow you to look at their code on the web: Mozilla offers this facility here.
3. A system for communication between developers: Because open source projects are worked on by contributors from all over the world, the participants communicate electronically. A common method is to use email mailing lists, usually with archives of old discussions available to view; IRC channels, for real-time chat between developers, are also common. A new contributor can read these to see how the project works and what the important issues are, now and in the past, to get a sense of the personalities on the project, and of how the project conducts itself.
Mozilla gives details of its mailing lists and newsgroups here: http://www.mozilla.org/community/developer-forums.html. Additionally, it has an introduction to the etiquette used there: http://www.mozilla.org/community/etiquette.html [EXPAND DETAILS ON ETIQUETTE HERE OR IS LINK ENOUGH?]
4: A system for offering support to users: Many projects will also have forums, mailing lists or IRC channels, where users can ask for help. While project members themselves may answer questions here, most contributions come from other users, who donate their time to assist people. For example, this is Mozilla's Firefox Support Forum. Contributing in this way need not necessarily be done through the project's own system; there are also many independent support forums and so on for open source software.
5. A bug-tracking system (an issue-tracking database): Projects need a way for bug reports to be submitted to the project, and a way to keep track of them. An issue-tracking database holds information about each bug submitted, its current status, details of who is working on it, and a transcript of the discussions between the various parties involved in reporting and fixing the problem. Usually, the system will allow anyone to submit a bug report, so long as they register on the system.
Mozilla's bug database is at https://bugzilla.mozilla.org/.
[NEED SOME KIND OF SUMMARY OR CONCLUSION; ALSO, ADD USUAL DETAILS ABOUT CONTACTING OSS WATCH FOR HELP?]
An introduction to some legal issues around contributing to an open source project: Can you contribute code to an open source project? and Contributor Licence Agreements.
Some things to consider when planning your involvement: A guide to participating in an open source software community.
A discussion of the tools used in development communities.