Open Source Principle 0. With many eyes, all bugs are shallow.

Preview
Visual Notes by Giulia Forsythe, released under creative commons: https://www.flickr.com/photos/gforsythe/7985992388/

0. With many eyes, all bugs are shallow.

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. Another 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. 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.

photo credit: https://upload.wikimedia.org/wikipedia/commons/2/2a/Laboratorio_pos_Infnet.jpg

To get the highest quality observations and contributions from your user base, a project must 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 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.”

To cultivate this 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.

When you start community-building, what you need to be able to present is a plausible promise. Your program doesn’t have to work particularly well. It can be crude, buggy, incomplete, and poorly documented. What it must not fail to do is (a) run, and (b) convince potential co-developers that it can be evolved into something really neat in the foreseeable future.

If you treat your beta-testers as if they’re your most valuable resource, they will respond by becoming your most valuable resource.

The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.”

Back to: WordPress Community Deputy Training > The values of the WordPress project: theory and practice