There is longstanding advice to aspiring software professionals to work on Open source projects. But the most valuable...
Open source work is still not well understood, and there are some new approaches to engaging Open source projects that deserve attention.
What not to do
Although it seems counter-intuitive, the worst way to engage with Open source is to start your own Open source project. Most Open source projects are abandoned and go nowhere. Open source projects started for no reason other than to start an Open source project are particularly prone to abandonment.
Another poor choice for engaging with Open source is to become a developer on an Open source project. Active Open source projects tend to have more contributors than they need. Many of them have implemented screening processes for contributors in order to keep code quality high.
While Open source projects ultimately do need developers, there are more than enough projects in the world already, and there are more than enough Open source developers to service those projects.
The real needs
The vast majority of Open source projects need two things, and neither of them is more coding.
The first thing Open source projects need is users. So for the aspiring software professional looking to engage with Open source projects and Open source communities, first become a user. Find an Open source project that answers a specific need that speaks to you personally. Learn to use the software, join the mail lists and user groups for the project. Start to ask questions when you run into issues. Become generally known to others in the community as a competent and interested user of the Open source software.
The second thing Open source projects need is documentation. Few Open source projects are documented well, and even those few are in need of constant updates and improvements to their documentation. Poor documentation is a barrier to new users, so the best help that an aspiring software professional can give to an Open source project is to improve the documentation for that project. Not only does better documentation improve the project, but creating the documentation is a great way for the aspiring software professional to learn the details of the system itself, maybe even down to the level of the source code.
Becoming a user of Open source software projects and creating documentation for Open source software projects are great professional exercises for anyone working in software development, but it is particularly useful for software testers. Good software testers quickly become expert users of the systems they test, and software testers are required to supply particular kinds of information to the software team. Creating documentation for Open source projects is really good training for supplying the kind of information required of software testers.
A new approach to engaging Open source
In August 2009 a group of professional testers in Mumbai, India began gathering on weekends to practice their testing skills. The Weekend Testers have since spread to Europe and Australia/New Zealand, and have participants from all over the world. A number of people in the software testing community have pointed out that the Weekend Testers are one of the most exciting developments in the testing community in some time.
Sometimes the Weekend Testers choose a commercial application to test, but often they choose an Open source application. Parimala Shankaraiah, one of the founders of the Weekend Testers, said this recently in a private forum: "A lot of products tested on the Bangalore chapter are Open source. In many cases, we have asked their permission, (and then afterward) provided a list of bugs which they promised to work on."
This is a revolutionary approach to the greater Open source community. Instead of engaging as individuals with individual Open source projects, the Weekend Testers band together to provide a particular service, and then offer that particular service to multiple Open source projects. Joining a Weekend Testing session then is not only a way to engage with the greater Open source community, but is also a way to improve one's own abilities in software testing.
Testing and only testing
The Weekend Testers point out one other thing that Open source projects need: good bug reports. An aspiring software tester might want to engage Open source projects only on this level, but in most cases that would be a mistake. Open source projects are intended to solve problems for users, and to be a user dedicated only to finding problems with the Open source software is a quick route to being persona non grata on most projects. As Ms. Shankaraia points out, the Weekend Testers are engaged directly with the principals of the Open source projects they test, and their contributions are known to be welcome before testing begins.
That said, good bug reports are critical to the health of Open source projects. And it is remarkable how rarely projects receive good bug reports. Even for Open source tools dedicated to software testing and used primarily by professional software testers, such as the web test tools Watir and Selenium, the quality of bug reports is remarkably poor.
An aspiring software tester should seriously consider becoming a user and a documentation contributor before contributing to an Open source project as a tester. That said, an expert user who has written documentation and then turns their attention to creating good bug reports would be a welcome addition to any Open source project.
Old advice and new
Be an Open source user; contribute Open source documentation; this has been good advice for many years, and following it has furthered the careers of many software professionals.
Banding together to supply a particular service like testing to Open source projects is new advice, and the field of possible services to supply is wide open. As the Weekend Testers have shown, following this advice has also furthered the careers of many software professionals, and will continue to do so long into the future.
About the author: Chris McMahon is a software tester and former professional bass player. His background in software testing is both deep and wide, having tested systems from mainframes to web apps, from the deepest telecom layers and life-critical software to the frothiest eye candy. Chris has been part of the greater public software testing community since about 2004, both writing about the industry and contributing to open source projects like Watir, Selenium, and FreeBSD. His recent work has been to start the process of prying software development from the cold, dead hands of manufacturing and engineering into the warm light of artistic performance. A dedicated agile telecommuter on distributed teams, Chris lives deep in the remote Four Corners area of the U.S. Luckily, he has email: firstname.lastname@example.org.