Why you should contribute
Linux has evolved, and continues to evolve, under the open-source philosophy of the free sharing of ideas. If not for this massive, shared, open community environment, Linux — and much of the open-source software that runs the Internet — wouldn’t be here. It’s a testament to this community and its philosophy that the creation of a powerful operating system such as Linux could come about through the interaction and cooperation of thousands of people worldwide. Linux is a symbol of what’s possible when we work together as a whole, sharing each other’s ideas and building upon each other’s work. It’s built by everybody, for everybody, and it’s free. If you’re a home user, Linux has hopefully provided you with a stack of useful applications which have helped you get your work done and have fun. It may have also provided you with an excellent insight into how your computer and modern Internet-based networks operate. If you’re in a business environment, it may have saved you thousands of dollars in license fees and saved you a great deal more by simply being a reliable server OS. You might be writing closed source applications that run on this powerful and stable platform.
You might be providing consulting services to help other businesses take advantage of the operating system. If you’re like some of the authors of this book, it may even have provided you with a career. If you’ve benefited from Linux and open-source, perhaps you’d like to contribute? As a community, every contribution helps build a better product. The more the merrier. If you want to show your appreciation for what Linux has enabled you to do, achieve, or experience, you can offer your own skills and services to improve the operating system, and through this others will benefit just as you have benefited from the work of others. This is the beauty of community. Perhaps the first thing you should know is that you don’t have to know how to program to be of help. You can help out by writing documentation, managing open source projects, hosting file space, providing information over the Web, and much more. Whatever you choose, the easiest method is to join an open-source project. Unless, of course, you’re a programmer with an ambition to have your code accepted into the kernel for the fame of having your code used by millions worldwide!
Open source projects are well coordinated and run under a meritocratic system (those who have contributed the most to the project are higher in the hierarchy) while still preserving the fun atmosphere OSS development is renowned for. They use various open-source management tools, including CVS (a revision control system), Bugzilla (a bug tracking system), GPG (a digital message signing tool), and various mailing list management applications. You’ll probably need to find out what systems your chosen project is using and read the various online guides to familiarise yourself. The quintessential guide to working within an open-source project (for programmers, documenters, or otherwise) is Eric S Raymond’s ‘The Cathedral and the Bazaar’. It is available both as a hardcover book and free online from http://www.catb.org/~esr/writings/cathedral-bazaar/. Every project contributor should read it at least once, as it is often used as a reference for guiding the development of projects.PROGRAMMINGKeep in mind that not everyone can be a kernel hacker overnight, and furthermore, there are bigger, bolder efforts underway elsewhere. So join an existing project before beginning your own open-source masterpiece. Joining an existing project will also allow a smooth transition into open source methods, and working with other people’s code.
This is important, as even if you start your own project you should avoid reinventing the wheel by basing it on libraries and code from other projects wherever possible. The best way initially to get involved in a project is to identify and fix bugs, clean up code, and so on. By reading all the information on the project’s site and chatting with the other developers, you’ll soon get an idea of where the project is headed and can nominate yourself for a specific task to help achieve that goal. It’s important to realize that not every submission or idea is a brilliant one, and that your efforts may well be rejected. If this happens, pay attention to the feedback. Many major parts of Linux (like the powerful Reiser FS) were initially rejected, then worked on in line with feedback before their eventual acceptance into the Linux kernel. If you’re a technical person but don’t desire to code full time, or don’t code at all, and you can write well, then documentation might be just your thing. In fact, open-source projects usually need documenters more than new programmers, to write FAQs, HOWTOs, UI guidelines, and much more.
Documentation
If you’ve ever found documentation to be lacking, then don’t complain — search out the appropriate parties and write it yourself! If you find your work beneficial, others will too. There are a few things you’ll need to learn, however; most open source projects are documented using SGML, a markup language specifically for structured documents. SGML lets authors create documents without having to worry about how they look. It simply requires you to pick a Document Type Descriptor (or DTD) that defines the structure of the document (how the head-ing, subheadings, images, and tables will relate to each other) and then define items in your documents as one or more of these structures. When it’s time to publish, an SGML document converts easily to HTML, PDF, and even Microsoft Word in a single, easy step. The most obvious methods of helping out open-source projects are by programming and documentation, but many projects also require artists (KDE has a whole team who simply draw and regu-late icons), Webmasters, skin designers, packagers, and more. Enquire at the Web site for a project about how you can assist.
Bug testing
All software needs good testers, and reporting helps you and other users. Take care to follow the guidelines for submitting bugs for a particular project, usually found on the project Web site or in the README file. Many open-source projects use specialized bug tracking systems, such as Bugzilla or Sourceforge, which must be adhered to if the bug is to be accepted. The more detail you can give when submitting a bug report the better. For example, is there anything you think might be causing the problem? If something stopped working, when did it last work, and what’s changed since then? Take care to follow up your bug report too — you might need to answer some extra questions to help programmers fix the bug. Some programs, and certain environments like KDE, come with built-in bug reporting facilities that make it trivial to type in a bug report and send it to the developers.
Linux Advocacy
If you love Linux, you’ll probably want to tell others about it. There are right and wrong ways of doing so; using terms like ‘Windoze’ or ‘Micro$oft’ definitely falls into the latter category. Nobody likes being told they selected their OS poorly, and it’s unlikely to endear them towards whatever you’re advocating. Refusing to acknowledge Linux’s deficiencies (yes, they do exist) is likely to invoke similar feelings. Be positive and polite: emphasize Linux’s good points rather than another operating system’s bad points. Above all, make sure that learning Linux is as easy as possible; point people to the best books and Web sites; show them where they can get help; and answer their questions if you know the answers. If you don’t, point them to somewhere which can. Don’t overwhelm them with technical jargon, and keep in mind that not every user can understand man page information. Read the advocacy HOWTO in /usr/share/doc/HOWTO for hints on successful advocacy.
Help out all Linux users online
You might remember way back in the first Linux Pocketook we mentioned that going to other Linux users — the community at large — was the single best method of seeking help. If you’ve been with us all this time you’re probably more experienced with Linux than you realize. You’re now one of those users who can help new users ease the learning curve. So if you hang around the newsgroups, mailing lists, Web site discussion forums, and IRC channels and you see someone who needs help, lends them your knowledge and experience. You might not know enough about Linux to be able to build a clustered supercomputer, but if you encounter another user online who’s having the same sound-card problem you once needed help with, give them a hand.