- Consumer Purchase the Hard Way
- Modern Savages
- What's the Problem with Software?
- Review Without Peer
- Bad Alternatives to Peer Review
- Preserving Our Peer Processes
Bad Alternatives to Peer Review
The value of peer review in open source is very discomforting for commercial companies. It's no wonder that vendors such as Computer Associates are starting to release their in-house products into the open source world in the hope that they'll survive. In CA's case, the recent news is of Ingres. Informix was released some time ago. Berkeley DB, mSQL, MySQL, and Postgres/PostgreSQL have all been open source for some time. Only Sybase, Oracle, SQL Server, and DB/2 remain closed among the main database vendors. At the moment, this opening of some closed source vendors has some of the spirit of the early phase of the open source movement. Don't expect that feeling to continue forever. Expect to see some vendors throwing a cloak of rhetoric over the value of open peer review. After all, from a marketing point of view, peer review is a desirable attribute for a software product. Everyone likes the idea of approval. If you can't get or can't survive genuine but potentially hostile independent peer review and the consequential public fallout, you'll have to manufacture something that seems as good. That something is a rubber stamp, and rubber stamps threaten to ruin the improved consumer outcomes that open source processes offer.
Rubber stamps appear in many forms: patents, digital rights, and intellectual property are fairly weak examples. A stronger example is legislation that tasks software development with hurdle requirements: "Jump this hurdle and we'll give you this rubber stamp that lets you vend your product." The costly process of jumping through due diligence hoops is a barrier to entry for new players, regardless of the industry. Because open source products are relatively new compared with established players such as Microsoft, Oracle, IBM, and SAP, any such playing field is deeply tilted in favor of the incumbents. Dealing with the bureaucracy of multiple national stamp-providing bodies is nearly impossible for a loose collection of programmers distributed around the world.
Imagine a scenario in which a software developer must demonstrate that his open source software is free of security infringements, or even just that due diligence has been shown in auditing the software against a laundry list of existing best practices. Given the proliferation of security special cases, many of them obscure or baroque, that's a huge amount of work. It's a ridiculous imposition to apply to many open source projects, where daily releases are the norm. Security is important, but it shouldn't stifle innovation. It merely requires correct labeling. In an environment where desktops, web browsers, databases, and office tools are rapidly maturing, such a rubber stamp is a perfect way for a commercial organization to protect market share. If only the government can be persuaded that such legislation is a good idea, market share can be preserved, and closed source software can be ennobled with a quality that substitutes for independent peer review. Stupider things have been supported in legislation before, and such stupid things are in the works now, in a government near you.
Rubber stamps are not all bad, however. Some rubber stamps are worth having—safety standards, for example, or even just compliance with public standards. Even in open source, some ratification of current defect levels is probably a good idea. The problem is that rubber stamping is a process wide open to abuse by the powerful. If such stamps are legislated and bureaucratic, lobbyists and other special interests will make the stamp a brand mark that open source projects or other competitors can't acquire. That approach works directly against consumer interests, and against competition policy.