OSCON 2005: Architecting Freedomby Daniel H. Steinberg
Nick Gall began his keynote address at O'Reilly's Open Source Conference (OSCON) 2005 by reminding the audience of the four freedoms detailed in the Free Software Definition. The two freedoms that Gall stressed were the freedom to adapt a program to your needs and the freedom to improve a program and release these improvements back to the community. "It's great to be able to run a program," he said, "and it's kind of neat to be able to share them and copy them. But the really amazing thing about open source as a community is the power and freedom you have to change the software to make it fit what you want it to do."
In his fifteen minute morning address, Gall pointed to familiar examples from the internet as successes and abstracted lessons from these long-term successes. In particular, he said that the key to the evolvability of these internet applications is the freedom to interoperate, extend, and compose.
Examples of Failures and Successes
Gall asked how you would architect a system for freedom. He said that too much time is spent on ensuring a free or open legal architecture and that we wouldn't really know what will and won't hold up until these licenses are in the hands of litigators. As a second leg, we have considered different models for a free community architecture, including benevolent dictator and grass roots. Gall argued that not enough time has been spent trying to understand what is required for a free system architecture. "How do you modularize a system to enable the freedom to change in a sustainable way? It's easy to hack a system once to do what you want. Then the next person that comes along can't hack it as much because you've screwed things up. You do that ten times and now it's frozen." The system architecture must be innovated on, changed, and enhanced in ways that are both sustainable and decentralized. This bigger idea is based on subsidiary freedoms to interoperate, extend, compose, scale, and link.
In many of the systems developed over the past three and a half decades, either the user can innovate or the vendor can innovate, but not both. There is no framework for decentralized innovation. There tends to be a half-life of five years where systems go from easy-to-change to hard-to-change. Most thirty-year-old software systems that you point to are legacy difficult-to-modify systems. Supporting decentralized innovation requires that we rethink system architecture.
For all of our failures, Gall pointed to the internet for examples of successes. He argued that the "internetwork" architecture has sustained this freedom to change. "IP: the same bit patterns are still streaming over the global network that streamed over thirty years ago. There's a lot more stuffed inside them, but it's the same basic protocols." The internet has been hacked over this long time period and is still thriving. Gall asked what it is about the internet that allows people to add and modify protocols and just hack.
Consider the following four architectures: IP, email, the web, and intermodal containerized shipping. This last one isn't an example of what we think of when we open our laptops to access the internet, but Gall asserted that global shipping is an example of an internet. These each exemplify and support decentralized innovation. If you think back to how you used email twenty years ago, it may seem vastly different than the way in which you use email today. Gall explained that all of the innovations that we now use without thinking are just extensions to the original Internet Message Format.
Pages: 1, 2