Peer review and public acessibility makes Open Source superior

Within a day of the September 11 attacks on the World Trade Center civil engineers around the world understood why the towers fell. The analysis was carried out - or at least begun - at Sydney University, on the other side of the world from New York, by engineers with copies of the WTC designs.

It exemplified the civil engineering profession's attitude to intellectual property: designs are copyright - but they're also published.

It's an example pertinent to the debate about Open Source software. Like the office towers we inhabit, software is becoming embedded in our society's infrastructure. Software engineering wishes to become a profession; software engineers as individuals wish, rightly, to make a living.

Tony Healy's error is to assume that publication and profit can never live under the same roof.

The overriding ethic of Open Source software is not its price but its publication. Software can be sold but it must be published: the source code, like the construction drawings of the WTC (or closer to home, the Anzac Bridge) is a public document, available for peer review.

Copyright is used to achieve this: the owner of the work first asserts copyright, and then specifies the conditions under which the copyright work may be used by others. In licenses such as the GPL, these conditions specify the need for users to inherit rights downstream - if I obtain software under the GPL, I must give other users the same rights as I have.

The explicit rights regime of the GPL keeps its outputs in plain view and associates authorship with output.

To many of those in today's software industry this is a threat. Healy's argument is that nobody will pay for something they can get for free and the best engineers will have their work stolen by the worst.

Who Will Buy?

In a sense, Healy is right. If software is "free", why pay for it?

This, however, is a view which trivialises software as an engineering discipline.

In the business software market the software itself is already a shrinking component of the value of a project. Expertise is worth a lot more: the expertise to assemble different pieces of software into something that works smoothly; the expertise to customise the software to particular purpose.

Revaluing the "licence" component of a large software project to zero doesn't get rid of the software engineering needed to build the project.

In other words - returning to my original analogy between software and civil engineering - publishing the design of a bridge doesn't eliminate its value. It enhances its value: we know it will be safe not because the architect drew a nice picture but because engineers look at each others' work, criticise it, perhaps even lodge objections to the work before it's approved.

Are all the "eyes" of equal value? Of course not. Not in software, not in civil engineering. It's the "best" eyes that matter.

Nor does publication eliminate the expertise needed to build the next bridge.

It makes the next bridge safer, more efficient, and better than the last - and its publication, not secrecy, which encourages civil engineering to build projects which are best suited to circumstances.
If Lend Lease (for example) had a "black box" bridge, its economic interest would be best served by building that bridge thousands of times, selling them, and forbidding either examination or modification.

If it was required to create an original design for every component of every project, it would try and build that "black box" bridge.

It's the combination of shared techniques, publicly-available components, publication and peer review which gives us a world in which we can efficiently design projects suited to their purpose.

If a piece of software is trivial - so trivial that anybody can buy it, install it and use it without expertise - then why should it be expensive?

If software is not trivial, then publishing its designs won't eliminate the demand for expertise.

Theft of Designs

Tony argues that Open Source software encourages inadequate software developers to steal the work of their betters.

There are two flaws in this argument. The first is philosophical: "theft" of software isn't a concept which applies to Open Source software. You can't steal something when I have given you permission to use it.

However, a more profound argument is not philosophical, but practical: theft is easily discovered when the designs are public.

The application of copyright in the GPL is closely akin to how civil engineers tell me they apply copyright. Its role is not to protect future revenues from a design but to protect the public from inferior work and protect the author from "passing off".

The role of copyright is to ensure that an inferior work is not sold under the name of a superior engineer.

If works are published and available for peer review, then the dishonest or inadequate designer has lost the shield of obscurity: he or she can't hide someone else's work inside an impenetrable "black box".

As in other engineering disciplines, publication would increase the chance that second-rate work - or dishonestly-presented work - is discovered. This is an important consideration in a world where software has become embedded in our social infrastructure. If software is as important as a building, then it should be accorded similar scrutiny.

Damage to Australian Industry

A widespread adoption of Open Source software would reduce the cost of inputs to the Australian software industry, without eliminating the value of skills in large projects.

"Shrinkwrap" software vendors could suffer, certainly: the software individuals buy at retail is the sector of the industry most associated with the Microsoft "ecosystem". Even then, however, I'm not certain of the impact, because I think for most people, convenience remains important. It's easier to install software from a CD than to find, assess and download it over the Internet.

Other sectors of the Australian industry would unequivocally benefit: those companies, for example, whose business is in what's known as "embedded systems" would cut their cost of inputs in an Open Source world.

Embedded systems developers here and overseas already use Open Source software because it improves rather than diminishes their profitability. You'll find Open Source operating systems in laser printers, photocopiers, network firewalls and very soon in mobile phones. Outside the consumer field, a great many telecommunications switches, defence systems, scientific computers, and industrial control systems likewise use Open Source operating systems as the basis of their software development.

Bugs

Healy argues that Open Source software has high bug counts (all software has high bug counts); clumsy operation (again, common to all software); and unfinished functionality (ditto).

This is not intrinsic to Open Source software, it's intrinsic to all software.

The main reason is the relative youth of the software industry. It's still subject to faddism and many individuals still resist the boring disciplines of engineering (such as rigorous education, repeatable experimentation, and professional certification).

The "copying of components" Healy decries is a good example.

"With software though, once the source code is made available, freeloaders can take that source code and build similar programs without doing all the development work," Healy writes.

In no other engineering discipline would an engineer criticise another for using a standard object to perform a familiar task: the demand that every engineer create a new object or technique for a task is a demand unique to software.

Not even Microsoft believes this. A developer in the Windows environment is expected to reuse components provided by Microsoft. The reason that Windows applications resemble each other is simple: they use the same components to draw things like menus and dialog boxes on the screen. Developers "build programs without doing all the development work" in the Windows environment as they do in the Open Source environment - the difference is that in the world of Windows, you aren't allowed to know too much about the components you're using.

Healy concludes that "Open Source does not really provide protections for the best developers". I agree because that's not the role of Open Source.

Neither the platform nor the rights regime exist to protect developers. That's the job of the developers themselves: the best developers, like the best engineers, be protected not by secrecy, but by their own skills, as demonstrated by their published work.

To pretend otherwise is to belittle those skills. At bottom, Healy's assertions are founded on a lack of confidence. Software developers' fear isn't that other developers are better - but that "anyone can do this". If software is easy there might be no need for developers.

I don't believe that.