Eugene Eric Kim <eekim@eekim.com>, February 8, 2001, v0.9
One of the greatest potential pitfalls of this project is the "Yet Another System" dilemma. So far, we've defined the Open Hyperdocument System in rather broad terms, and we have not done a great job of differentiating it from other systems. However, before trying to identify these differences, I think it's worth examining the evolution of a system whose conceptual roots can be traced back to Doug -- the World Wide Web. 1A (02)
Tim Berners-Lee's first paper on the Web was rejected by conference organizers at Hypertext '91, because they found the Web too simple and lacking innovation. (Gillies, Cailliau 220) And they were right. Feature-wise, the Web was far less sophisticated than many of the existing hypertext systems, including Doug's NLS and Augment systems. The Web had unidirectional links without link integrity and a feeble, bandwidth-eating protocol. No wonder academics turned their noses at it. 1B (03)
It would be easy to laugh at people's lack of foresight in 1991, and to flaunt the simplicity of the Web as the ultimate reason for its success. That would be a gross oversimplification. I think there were four fundamental reasons the Web succeeded as it did: 1C (04)
This last point is important. Berners-Lee was good, but he was also lucky. Hypertext systems were relatively common, thanks largely to Windows help software and Apple's Hypercard, and the Internet was becoming viable as an international information superhighway. 1D (09)
When Berners-Lee was developing the Web, he was not aware of Doug's work, or that of Ted Nelson or Andy van Dam. (Berners-Lee, Fischetti 5) But he certainly benefitted indirectly from their work, as they helped establish the intellectual climate in which Berners-Lee was working. His ignorance of existing systems also did not hurt the Web much in the long term, as the Web created a platform on which hypermedia and structured document old-timers could bootstrap their own knowledge and experience. 1E (010)
There are many similarities to what we're trying to achieve with the OHS and with what Berners-Lee has achieved with the Web. In fact, we could view our own work as developing the next generation Web. It's somewhat ironic, because had the timing and circumstances been a little bit different, the World Wide Web might already be what we're currently trying to build. 1F (011)
Two things separate the OHS from other knowledge management efforts: scale and strategy. Our feature set alone won't result in the "wow" effect, nor should it. It's likely that every feature we are proposing has some precedent in a previous hypertext system, and that other people have already implemented or specified technology that the OHS will need. However, as with the Web, the more users there are, the more compelling the features become. And we're promising many, many, many users. 2A (013)
How can we promise such huge scale? First, the OHS will work with all types of documents and data. Other systems have granular addressability or back link management, but they only work with a limited set of applications and file formats. For example, BrowseUp, whose product resembled a Hyperscope in many ways, had a tag line that I found very compelling: Link from anywhere to anywhere. However, their product only works with HTML documents. (I'm not sure how general their addressing scheme is, because I wasn't privy to any technical details.) The OHS is promising linking from literally anywhere to literally anywhere. 2B (014)
The second reason is Doug's bootstrapping strategy. A key characteristic of this strategy is the coevolution of human systems and tool systems. The establishment of large communities using the OHS and the development of a set of best practices will help propagate the tool. The feedback from these communities will also help the tool evolve and improve. 2C (015)
One way to facilitate the evolution of the tool itself is to make it open source. Open source software enables evolution on a scale well beyond that which is possible with purely proprietary solutions. However, simply making software open source does not guarantee worldwide proliferation and a thousand person development community. Jamie Zawinski said it best: "[Y]ou can't take a dying project, sprinkle it with the magic pixie dust of 'open source,' and have everything magically work out. Software is hard. The issues aren't that simple." 2D (016)
It's important to remember that the OHS is not simply a suite of applications, but a framework for building these applications. (I recently suggested to Doug that renaming the OHS to the Open Hyperdocument Environment might be a good way of emphasizing this point.) As I stated earlier, what made the Web successful was not the free distribution of the first Web client and server, but the free distribution of the libwww toolkit. Similarly, while we will be building OHS applications, our focus should be on building a modular set of OHS services and distributing that in the form of a toolkit. 2E (017)
That's not to say that the applications we build are irrelevant. They will be extremely important, because they will demonstrate the functionality of the OHS, and they will form the starting point of the coevolution process. However, if the applications we build are the only OHS applications ever developed, then we will have failed. Our goal is to see every application OHS-enabled, and we alone are not capable of achieving that. 2F (018)
Additionally, we want to encourage the best applications to succeed, whether they come from us or not. I suspect that there are groups out there who are capable of building a better Hyperscope or even a better toolkit than our core group. If, at some point, evolution dictated that our central efforts were better focused on facilitating cooperation rather than developing software, then we'll have reached a happy point in the evolution of the OHS, and we should accept that role gladly and willingly. 2G (019)
Should the OHS project evolve in the way we think it will, a large number of applications will be OHS-enabled and a number of new applications will evolve, all of which will help generate a number of useful dynamic knowledge repositories (DKR). The question is, how can we kickstart this evolution? 3A (021)
While we can learn a lot from the Web, we cannot mimic it exactly and expect to succeed in the same way. We cannot, for example, afford to design and build things as cavalierly as the original Web, in part because the Web has raised the bar. We are not bootstrapping from scratch, as Berners-Lee was. We know the positives and negatives of existing hyperdocument systems -- including the Web and Augment -- and we need to learn from them. 3B (022)
At the same time, we can't afford to clutter the design either. Fred Brooks warned software designers of the second system effect. He explained, "The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one. The result, as Ovid says, is a 'big pile.'" (Brooks 55) 3C (023)
I think that the Hyperscope is a good choice in first application. It will force us to design and build many of the generic services the OHS will need, such as link databases and grove engines. It is also a relatively simple application, a proof of concept that could easily take advantage of already existing software such as Web browsers, proxy servers, and XML parsers. The Hyperscope may not wow people with its capabilities, but it will demonstrate the benefits of the OHS and give us insight into how to further develop the system. 3D (024)
What then? We've tossed around two main possibilities: an editor and a messaging/discussion system. Both of these candidates are worthwhile, but we must be careful about how we approach and design these systems. 3E (025)
In my (soon to be posted) technical commentary, I discuss my problem with the current design direction of the OHS editor, namely, that there is no such thing as the OHS editor. The OHS works with all document formats, and hence, all document editors, from XML editors to outliners to even plain text editors, are candidates to become OHS-enabled. At the same time, it would be useful to have an editor that simplified the creation and management of links and that had some built-in version control capabilities. 3F (026)
The question is, do we need to design and build a totally new editor from scratch to give us an editor with the desired capability? Or, is it better to bootstrap some of the OHS's capabilities onto some existing editor? 3G (027)
The same question applies to a messaging/discussion system. Some of our earliest design discussion centered around building a collaboration system that would effectively replace e-mail, newsgroups, and Web-based forums. Such a system would be a valuable and innovative OHS application, but would it be a good early candidate for development by the core group? Or, would it be better to bootstrap the OHS's features onto existing e-mail systems? 3H (028)
In both cases, I would vote for bootstrapping. Augmenting existing systems rather than looking to replace them (at these early stages) would be a superior way of demonstrating the OHS's capabilities and speeding the bootstrapping process at a later stage. It would save time on our end, because we could take advantage of preexisting code rather than write everything from scratch. It would speed the creation of DKRs, which would speed the process of coevolution. And it would gently help users overcome their initial skepticism by augmenting their favorite tools, rather than forcing them to adopt entirely new ones. Once persuaded, these users could contribute to the bootstrapping effort themselves by integrating the OHS into their own favorite tools. 3I (029)
Ultimately, we need to avoid the temptation to become too application-centric, especially in our early efforts. The OHS will make revolutionary new applications possible, but we must first focus on demonstrating the capabilities of the OHS. This may not be the sexiest approach, but it is the best way to achieve our long-term goals. 3J (030)
Berners-Lee, Tim and Mark Fischetti. Weaving the Web: The Original Design and Ultimate Destiny of the World Wide Web by Its Inventor. New York: HarperSanFrancisco, 1999. 4A (032)
Brooks, Frederick P. The Mythical Man Month (Anniversary Edition). Reading, MA: Addison-Wesley, 1995. 4B (033)
Gillies, James and Robert Cailliau. How the Web was Born. New York: Oxford University Press, 2000. 4C (034)
Document developed using Purple