As reported by Fake Steve Jobs, an article recently penned by Jaron Lanier makes an argument in favor of closed source development. This is not necessarily an anti-open source stance, as Lanier claims it has its place, but…

…a politically correct dogma holds that open source is automatically the best path to creativity and innovation, and that claim is not borne out by the facts.

Why are so many of the more sophisticated examples of code in the online world—like the page-rank algorithms in the top search engines or like Adobe’s Flash—the results of proprietary development? Why did the adored iPhone come out of what many regard as the most closed, tyrannically managed software-development shop on Earth? An honest empiricist must conclude that while the open approach has been able to create lovely, polished copies, it hasn’t been so good at creating notable originals. Even though the open-source movement has a stinging countercultural rhetoric, it has in practice been a conservative force.

A couple of years ago, my friend MV mentioned another, more encapsulated example of how closed source can build better solutions. I haven’t seen it mentioned much, so will repeat it here.

The example comes from the very early days of the graphical user interface. Once you start to build a system that has “windows” that can move around, you have to contend with the idea that these windows overlap. Even if each window is a rectangle, it doesn’t take many windows to make some complicated shapes. Even two windows can do so. Consider this image of an early Mac desktop from the Apple Museum:

Mac desktop

The “System Folder” window is easy enough to represent, but how do you describe the shape of the visible portion of the “Mac System Software” window? What about the visible portion of the gray background? It’s just a collection of intersecting rectangles, but think about it for a second: how would you describe such shapes to a computer? Oh, and you only have 128K of Memory and an 8MHz, 16-bit processor. When building a GUI, you have to deal with this issue at some level. For example, something is painting the desktop background; how does it know not to paint over the windows? (For those that know a bit about graphics, double buffering doesn’t help you here, because a) you don’t have the memory and b) it is too slow on chips like this.)

The general concept for describing such shapes became known as “regions”. There are a number of different ways to implement regions. It was clear that Xerox PARC had one when the Apple team famously visited. It wasn’t at all clear what that implementation was, however, as it was closed source. Lacking access to Xerox’ methods, engineer Bill Atkinson took a look at the problem, figured out how they must have done it, and coded his version into the drawing system that would become QuickDraw.

It turns out, however, that Atkinson’s region code wasn’t really anything like Xerox’ code. It was much better. Better, in fact, than most other systems that came along, particularly the implementation used later by Windows. In an anecdote about Atkinson and regions, Andy Hertzfeld says that Apple “considered QuickDraw’s speed and deftness at region handling to be the most significant ‘crown jewel’ in Apple’s entire arsenal.”

This brilliant system (now supplanted by code that takes better advantage of modern hardware, particularly video cards) probably wouldn’t have happened if the Xerox code had been open source. Atkinson most likely would have started with their solution and refined it, and a bit of genius would have never been born.