Even if you have no ability to modify the code yourself (and I speak as one who can barely cobble together a "Hello, world" script with help), the right is still potentially useful. After all, you may not immediately need the right to freedom of expression, either, but the right's existence still protects you and prevents problems if certain situations arise.

In the case of FOSS, accessible source code means that, even if you can't do more than shrug at it, others can act on your behalf. When the members of FOSS projects fix a bug or enhance a feature, they are acting as representatives of all users. And, in fact, many are more or less aware of this role; I've seen project members book off work to fix a major security problem because they take their responsibilities to users so seriously. Compare such turnaround time to the weeks that elapse before many proprietary software sellers even acknowledge a problem, and the advantage of accessible source code to the average user becomes immediately obvious.

Moreover, if you need a specific feature, you can hire someone to write it, either keeping the modified version for your own private use or redistributing it back to the community. As Bob Young, the former CEO of Red Hat, used to point out, you wouldn't accept a car whose hood was welded shut, so that the engine could only be modified by the manufacturers. So why should you accept a similar limitation in your software? In almost any other consumer product, users expect to have the right to alter or fix it. By sharing the source code, FOSS simply extends this right to your software.

Next: Restoring Consumer Rights »