Free software debugging

Chapter 2 of Andreas Zeller's book "Why Programs Fail" describes the following life cycle for a software problem that involves a bug fix:

1. The user informs the vendor about the problem.
2. The vendor reproduces the problem.
3. The vendor isolates the problem circumstances.
4. The vendor locates and fixes the defect locally.
5. The vendor delivers the fix to the user.
6. [implicitly] The vendor delivers the fix to other users.

One of the advantages of free software is that it often allows the following lifecycle instead:

1. The user reproduces the problem.
2. The user isolates the problem circumstances.
3. The user locates and fixes the defect locally.
4. The user publishes the fix so that other users can use it.
5. The user informs the maintainer about the problem.
6. The maintainer delivers the fix to other users.

When the problem is sufficiently important to the user, this is much preferable to the traditional cycle described above; the time from step #1 to step #3 can often be minutes or hours instead of weeks, months, or years --- and many problems never get fixed, either because they're put in place deliberately by vendors, or because they're not important to the vendor.

In addition to giving the user their bug fix more quickly, it also often reduces the total amount of work involved. Zeller's steps #1 and #2 often involve a lot of communication back and forth between the vendor and the user, as the user tries to supply enough information for the vendor to reproduce the problem, perhaps weeks or months after the fact, but without including any confidential information. An omitted step (in both sequences) is prioritization of the problem, which is dependent (in Zeller's sequence) on the information provided by the user; if it appears to be a problem that doesn't affect many people, the vendor is likely not to bother to reproduce and isolate it quickly.