Open Hyperdocument System

The OHS Project is developing open source tools for collaborative knowledge management, building on XML and other open standards as well as Douglas Engelbart's groundbreaking NLS/Augment system.

http://www.bootstrap.org/ohs2/faqs/quick.html

http://www.dougengelbart.org/about/ohs.html

Lots of vertical-app requirements We hope evaluations of systems and tools from developers will refer to elements of this template as a way of demonstrating how closely these systems approximate a true OHS. See especially the terse listings for "end-user systems". Also see this evaluation of the Web based on Engelbart's requirements.

draft project plan (Oct'00) http://www.bootstrap.org/a2h/BI/2120.html Phase1 = HyperScope (lightly modified web browser supported by an "Intermediary Processor" (IP) which operates between the browser and the files or data bases holding existing working knowledge of a collaborative community) to build OHS features on top of legacy systems. I'm not sure that's the right approach.

Eugene Eric Kim http://www.eekim.com/ohs/

http://www.eekim.com/ohs/lc

mailing list archives: http://www.bootstrap.org/lists/ba-ohs-talk/

Lots of Wiki people.

Eric Armstrong essays inspired-by/related-to this work.

What will the outcome really be? When will it get here? Some of the Bootstrap Institute projects smell like Xanadu.

• this message doesn't sound promising (Mar'02)

I can't find a good document describing how users will behave when using OHS in the course of targeted collaborative activities. Which makes it hard to think about the designed solution.

BootStrapping book by Thierry Bardini

• http://www.com.washington.edu/rccs/bookinfo.asp?ReviewID=212&BookID=181

• http://mitpress2.mit.edu/e-journals/Leonardo/reviews/feb2002/bk_BOOTSTRAP_mosher.html

• http://www.fleabyte.org/eic-2.html

Mar27'02 thought:

If I were doing the macro planning for OHS (pardon the hubris), I'd

• document richly some potential behaviors, rooting them in useful business outcomes (User Scenarios) (e.g. this team has a vision for a new business, but they're refining their vision while trying to simultaneously execute on it, here's the kind of intellectual activities they're engaged in, and the resulting collaboration issues). I'd also hit some of the environment issues which constrain the design (some team members are contractors working offsite: they'll use the host-company's web-based tools for some things, but have their own email client and outside email account).

• pick some existing standards and open-source tools that could be the basis of collaborative behavior (e.g. SMTP/POP, HTTP/HTML; count on IMAP? Ms-Office? Wiki? BugZilla?)

• now design some collaborative behaviors for that team based on the smallest possible set of new features wrapped around those base standards/tools.

• then plan how to build those features. This could be prioritized to deliver some benefits in a relatively short period of time, increasing incrementally.

This may be a dead end, because it would require specific new servers to be installed. But HyperScope would as well, since the IP would have to be operated.

Doug's model seems to come out of the BigCo pre-Web days of companies willing to spend dollars and man-hours on projects with no coherent process to lead to ROI. I think those days have passed, because (a) even the BigCos are too busy (in some senses) and financially focused for this kind of investment, and (b) since the Web they have lots of alternatives for tools (and their working teams are less willing to be forced into some big corporate process when such tools are available).

And I think the HyperScope (an app to layer OHS features on top of legacy systems/content) could be a huge distraction, esp. given the implicit need to deal with MsOffice files, which are undocumented and subject to format change.

I think the Bootstrap Institute should (maybe in addition to their current/core approach) provide more overall direction in terms of requirements (this is probably sufficiently documented already) and architecture/protocols (e.g. use RDF? what schema?). In other words, try to define an ecosystem in which groups could develop smaller apps meeting their highest-priority narrow needs, but with an eye toward later integration with other tools.

(Comment from someone else) I see some overlap with intentions and design of the Askemos project.