How you can see the shape of emerging technologies by watching hackers and other "alpha geeks."
This is how we get most of our good ideas at O'Reilly. We look for people who appear to be doing magic, and ask them how they do it. (Remember Arthur C. Clarke's dictum: "Any sufficiently advanced technology appears to be magic.") There are always people in any field who are the most clued in to the deep trends, who seem to be playing with all the coolest stuff, and seem to have their finger in everything before most people even know about it.
. . .
Microsoft gets a lot of heat for not leaving enough on the table for others. My mother, who's English, and quite a character, once said of Bill Gates, "He sounds like someone who would come to your house for dinner and say, 'Thank you. I think I'll have all the mashed potatoes. '"
. . .
So that brings me to the third and final part of my talk. If we're building an Internet OS, what kind of OS would we like it to be?
Lessons from the Past
That's where we can learn a lot from the design of Unix and the Internet. When I'm talking about design, I'm talking at a very high level, the "architecture is politics" level. I've recently become very aware of this level since reading Larry Lessig's book, Code and Other Laws of Cyberspace.
At some level, both Unix and the Internet are loosely coupled protocol-centric systems rather than API-centric systems.
I've always loved the formulation given in Kernighan and Pike's book about Unix, The Unix Programming Environment. If you're starting to work with Unix, you should go buy it, even though it was published by AW! It describes the few simple rules that made Unix work.
Everyone talks ASCII as a common data format. Write standard output and read standard input. Write small programs that work with other programs in a pipeline. I call this an architecture of participation. It made it possible for individuals all over the world to write programs without any central coordination. More than licensing, I think that this architecture is behind the success of Unix, and ultimately Linux.
Similarly, the Internet was based on what Jon Postel, in the RFC for TCP, called "the robustness principle": Be liberal in what you accept, rigorous in what you send out. In other words, try to be interoperable. Contrast this with what happened when Netscape and Microsoft started fighting over control of HTML and what happened in the browser. We saw the exact opposite, where each was being extremely illiberal in what they accepted, and putting out all kinds of proprietary stuff that no one else knew how to render.
The Internet architecture has flourished for 25+ years because of the robustness principle, and because it has a loosely coupled architecture in which the intelligence is in the endpoints, not in some central registry. Loosely connected actors, low barriers to entry ... these matter.
The result was explained really well in a recent message that Mike O'Dell, the former CTO of UUNET, the first commercial Internet service provider, sent to Dave Farber's IP list, regarding the spread of community wireless networks:
Biology will out-innovate the centralized planning "Department of Sanctified New Ideas" approach every time if given half a chance. Once the law of large numbers kicks in, even in the presence of Sturgeon's Law ("90 percent of *everything* is crap"), enough semi-good things happen that the progeny are at least interesting and some are quite vigorous.
"Nature works by conducting a zillion experiments in parallel and *most* of them die, but enough survive to keep the game interesting." (The "most of them die" part was, alas, overlooked by rabid investors in the latter '90s).
This is how the commercial Internet took off and this remains the central value of that network.
You don't need permission to innovate.
You get an idea and you can try it quickly. If it fails, fine -- one more bad idea to not reinvent later. But if it works, it takes off and can spread like wildfire. Instant messaging is a good example, even though ultimately complicated by ego and hubris. Various "peer-to-peer" things is an even better one.
WiFi is evolving the same way. A bit of *great* enabling technology made possible by a fortuitous policy accident in years long past, a few remarkable hacks, a huge perceived-value proposition (and I don't mean "free beer"), and presto! You have a real party going on in the Petri dish.
Clarifying note: During my tenure at UUNET, I described the real business as operating a giant Petri dish -- we kept it warm, we pumped in nutrients, and we made it bigger when it filled up. And people paid us money to sit in the dish and see what happened.
And standards compliance is a key part of the magic. I sometimes think that the IETF (the Internet Engineering Task Force, the Internet standards body responsible for such standards as TCP/IP) is one of the crown jewels in all of western civilization. For all its flaws, it's demonstrated that we can develop effective standards bottom up without a lot of central control. Again, it's made possible by a few simple rules: you can't have a paper standard, you have to have implementations, and since it's about interoperability, you have to have two independent implementations. This is summed up in Dave Clark's famous line, "No kings, voting or presidents, just a rough consensus and running code."
The other thing is that "small is beautiful". Modular designs. Apache and Jakarta, Perl and CPAN. Give people a way to extend the base program, don't just build in all the functionality and close the case.
And of course, both Unix and the Internet have adopted a kind of modular documentation. Pay as you go, write a man page or an RFC. Don't wait for the massive manual or the O'Reilly book.
. . .
Mac OS X is a great platform. It's building the future into the system, in terms of the technology choices it's making. It's building on an open, extensible framework in the form of Darwin and FreeBSD. It's learning lessons from the open source community.
Now, as developers, you have to do the same thing. Think network. Think open. Think extensible. Play well with others.
http://www.macdevcenter.com/pub/a/mac/2002/05/14/oreilly_wwdc_keynote.html
This is how we get most of our good ideas at O'Reilly. We look for people who appear to be doing magic, and ask them how they do it. (Remember Arthur C. Clarke's dictum: "Any sufficiently advanced technology appears to be magic.") There are always people in any field who are the most clued in to the deep trends, who seem to be playing with all the coolest stuff, and seem to have their finger in everything before most people even know about it.
. . .
Microsoft gets a lot of heat for not leaving enough on the table for others. My mother, who's English, and quite a character, once said of Bill Gates, "He sounds like someone who would come to your house for dinner and say, 'Thank you. I think I'll have all the mashed potatoes. '"
. . .
So that brings me to the third and final part of my talk. If we're building an Internet OS, what kind of OS would we like it to be?
Lessons from the Past
That's where we can learn a lot from the design of Unix and the Internet. When I'm talking about design, I'm talking at a very high level, the "architecture is politics" level. I've recently become very aware of this level since reading Larry Lessig's book, Code and Other Laws of Cyberspace.
At some level, both Unix and the Internet are loosely coupled protocol-centric systems rather than API-centric systems.
I've always loved the formulation given in Kernighan and Pike's book about Unix, The Unix Programming Environment. If you're starting to work with Unix, you should go buy it, even though it was published by AW! It describes the few simple rules that made Unix work.
Everyone talks ASCII as a common data format. Write standard output and read standard input. Write small programs that work with other programs in a pipeline. I call this an architecture of participation. It made it possible for individuals all over the world to write programs without any central coordination. More than licensing, I think that this architecture is behind the success of Unix, and ultimately Linux.
Similarly, the Internet was based on what Jon Postel, in the RFC for TCP, called "the robustness principle": Be liberal in what you accept, rigorous in what you send out. In other words, try to be interoperable. Contrast this with what happened when Netscape and Microsoft started fighting over control of HTML and what happened in the browser. We saw the exact opposite, where each was being extremely illiberal in what they accepted, and putting out all kinds of proprietary stuff that no one else knew how to render.
The Internet architecture has flourished for 25+ years because of the robustness principle, and because it has a loosely coupled architecture in which the intelligence is in the endpoints, not in some central registry. Loosely connected actors, low barriers to entry ... these matter.
The result was explained really well in a recent message that Mike O'Dell, the former CTO of UUNET, the first commercial Internet service provider, sent to Dave Farber's IP list, regarding the spread of community wireless networks:
Biology will out-innovate the centralized planning "Department of Sanctified New Ideas" approach every time if given half a chance. Once the law of large numbers kicks in, even in the presence of Sturgeon's Law ("90 percent of *everything* is crap"), enough semi-good things happen that the progeny are at least interesting and some are quite vigorous.
"Nature works by conducting a zillion experiments in parallel and *most* of them die, but enough survive to keep the game interesting." (The "most of them die" part was, alas, overlooked by rabid investors in the latter '90s).
This is how the commercial Internet took off and this remains the central value of that network.
You don't need permission to innovate.
You get an idea and you can try it quickly. If it fails, fine -- one more bad idea to not reinvent later. But if it works, it takes off and can spread like wildfire. Instant messaging is a good example, even though ultimately complicated by ego and hubris. Various "peer-to-peer" things is an even better one.
WiFi is evolving the same way. A bit of *great* enabling technology made possible by a fortuitous policy accident in years long past, a few remarkable hacks, a huge perceived-value proposition (and I don't mean "free beer"), and presto! You have a real party going on in the Petri dish.
Clarifying note: During my tenure at UUNET, I described the real business as operating a giant Petri dish -- we kept it warm, we pumped in nutrients, and we made it bigger when it filled up. And people paid us money to sit in the dish and see what happened.
And standards compliance is a key part of the magic. I sometimes think that the IETF (the Internet Engineering Task Force, the Internet standards body responsible for such standards as TCP/IP) is one of the crown jewels in all of western civilization. For all its flaws, it's demonstrated that we can develop effective standards bottom up without a lot of central control. Again, it's made possible by a few simple rules: you can't have a paper standard, you have to have implementations, and since it's about interoperability, you have to have two independent implementations. This is summed up in Dave Clark's famous line, "No kings, voting or presidents, just a rough consensus and running code."
The other thing is that "small is beautiful". Modular designs. Apache and Jakarta, Perl and CPAN. Give people a way to extend the base program, don't just build in all the functionality and close the case.
And of course, both Unix and the Internet have adopted a kind of modular documentation. Pay as you go, write a man page or an RFC. Don't wait for the massive manual or the O'Reilly book.
. . .
Mac OS X is a great platform. It's building the future into the system, in terms of the technology choices it's making. It's building on an open, extensible framework in the form of Darwin and FreeBSD. It's learning lessons from the open source community.
Now, as developers, you have to do the same thing. Think network. Think open. Think extensible. Play well with others.
http://www.macdevcenter.com/pub/a/mac/2002/05/14/oreilly_wwdc_keynote.html
