Re: Control choices and network effects in hypertext systems

Kragen Sitaker (kragen@pobox.com)
Wed, 6 Jan 1999 18:10:24 -0500 (EST)


On Tue, 5 Jan 1999, Jim Whitehead wrote:
> http://www.ics.uci.edu/~ejw/papers/whitehead_ht99.pdf
> http://www.ics.uci.edu/~ejw/papers/whitehead_ht99.html

Very interesting paper with many insights. I am hoping you were
offering your paper for comment; I wrote some comments on it.

There are a few places in the introduction where readers and writers
are conflated.

I agree that more writers tends to produce more readers. The converse
is probably true, but the Web's infrastructure has a certain amount of
difficulty with lots of readers; often, more readers means fewer
writers. (See www.kosmic.org's current front page for an example of
why.) When readers are paying writers, more readers means more
writers, but this is an exception, not the rule.

You say that "control over the user interface is a key
contributor . . .", but it's not clear whether you mean control by the
readers (e.g., don't load images, user-controlled CSS stylesheets,
Opera's nifty "turn the damn colors off" button) or control by the
writers. Control by the readers provides a more pleasant experience
for readers; control by the writers provides a more, um, variable
experience for readers, and allows more control over the presentation
by "content providers".

Reading the rest of the paper suggests that you might mean control over
the user interface by the architects of the hypertext system, as well.

It could be argued that control over the hypermedia structure actually
improves scalability to large numbers of readers if done right.

It's debatable whether the utility of the Web is *directly* related to
the amount of information and services available on it. I suspect it's
more likely to be directly related to the logarithm of that amount.
But I'm not an economist. :)

Same comment applies to what you said about telephones.

Your discussion of lock-in doesn't mention the existing gopher
infrastructure the Web supplanted, partly because Web browsers could
access gopherable files -- although you *do* mention gopher at length
later.

I don't think the amount of available software is directly related to
the number of hardware units sold, and the number sold is not the same
as the number in use. I suspect the relationship is nonlinear.

The hardware-software argument is nearly specious applied to HyperCard;
it's nearly as easy to include a copy of HyperCard along with every
stack you publish (on disk or whatever). There are people doing
exactly this with askSam; nobody had to do it with HyperCard because
Apple included it with MacOS.

Monolithic hypertext systems do not inherently prevent distribution of
their data across a wide-area network, although I'm not aware of anyone
actually doing this. (I haven't read the KMS papers.)

Gopher made slightly different control choices than the Web: typically,
only the person who ran the gopher server could put data on it. CERN
httpd and then NCSA httpd allowed any user to put data on a web
server. I suspect this may have a lot to do with why the Web killed
Gopher -- although the other things you mention are probably important,
too.

- footnote [1] appears to have a "citation page" at
<URL:http://www.acm.org/pubs/toc/Abstracts/0001-0782/48513.html>
- footnote [2] is at <URL:http://www.ics.uci.edu/pub/kanderso/ECHT/>
- none of the RFCs have URLs; perhaps this is intentional?

-- 
<kragen@pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
[around 1998-12-23], it is amazing to watch fear and loathing and greed at
play with the more speculative Internet stocks.  To call this a tulip
craze would be a vast understatement. -- Adam Rifkin, <adam@cs.caltech.edu>