The following are some basic steps to consider when one decides to contribute to a FOSS project:

• Find the correct home page/development wiki page: Almost all the OSS projects have their own home pages with 'developer' corners or wikis. They typically also have sections on news, FAQs, documentation, downloads and the three most important links, namely, the mainline svn (or the relevant repository), the bugs (or 'known issues') section and the mailing list. This is all one needs to start with. The popular projects (like GCC) have IRC links and contributors could be reached there as well.

• Join and work in the correct mailing list: It is actually a good idea to stay subscribed to these
mailing lists before actually starting off with your own development. Don't be surprised if you start getting hundreds of mails a day, once you join one of these lists. As long as we behave ourselves on these mailing lists, people are pretty friendly and helpful.

• The repositories and version control: Typically, CVS, SVN, or GIT is selected as the version control system for most of the ass projects. Take a while and familiarise yourself with the relevant one.

• Follow the conventions: All the development communities follow some conventions regarding:

Name:  Some basic common steps toa FOSS project.jpg
Views: 34
Size:  44.0 KB

a) Error handling

b) Project specific abstractions and encapsulations

c) Scalability

d) Portability and platform

e) Commenting/coding conventions

The documentation regarding them is available in 'one form or the other with the project and has to be given due respect.

• Bugzilla: It is a great value addition-not directly in the development, but this is where users of your application file bugs. Bugzillas are maintained by almost all ass projects and the project developers/maintainers respond to any bugs filed as long as the bugs are qualified with relevant data.

• Documentation and FAQs: Although this looks very trivial, it is an important p'art of any project-both for r '
users and otper deyelopers.

• Licensing policy: Last but not the least, most ass projects are governed by pretty strict licences.

There are a number of open source licences out of which GPL is perhaps the most pop~lar. Although the licences could contain a lot of legal jargon difficult for a developer to understand, you can always ask the project maintainers and mentors to explain to you the terms and conditions so that you can best adhere to the project licence as a contributor to a project.