Another way to say this is: Given a large enough beta-tester and co-developer base, almost every problem will be identified quickly, and the fix will be obvious to someone.

Open source depends on that large group of vocal users. Because the project can rely on “many eyes,” one person can report a problem and someone else can suggest or provide a fix. A third person, or set of people, can test the fix and give feedback. With a large number of people using, testing, and fixing the product, improvements happen more quickly and benefit a broader set of users.

The more perspectives and use cases you have on a project or product, the more bugs you can find/fix — and the better features you can design. As Raymond says, “The next best thing to having good ideas is recognizing good ideas from your users.”  A large contributor base also means that if someone loses interest in working on something, it’s possible and more likely that other motivated people will step up to work on it.

To get the highest quality observations and contributions from your user base, a software project must make it easy to access its source code and be transparent about progress and challenges. If people can’t read the source code, they won’t understand why the program does something a certain way, and they won’t be able to suggest better methods or useful bug fixes.

Raymond put it another way: “Non-source-aware users tend to report only surface symptoms; they take their environment for granted, so they (a) omit critical background data, and (b) seldom include a reliable recipe for reproducing the bug.” 

While it is certainly true that you don’t need to be a developer to make a good bug report, it’s also true that lack of familiarity with a product’s intended behavior can result in more noise than signal when it comes to critiques. This can result in the growth of an “us vs them” mentality between developers and the user base.

To cultivate a large user base, Raymond gives this advice: “Avoid perfection like a plague. Consider lack of perfection not as a problem but as an opportunity for improvements in future versions. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.”

Raymond suggests that, when building a contributor community, the most important ingredient is “a plausible promise.” He comments that as long as the program runs and “convince(s) potential co-developers that it can be evolved into something really neat in the foreseeable future,” then it doesn’t matter if the code has bugs or needs refinement.

Back to: Open Source Basics and WordPress