Thanks -- the paper is currently in its final form for publication in the
conference proceedings, but I'll likely turn it into a journal article in
the future, and any comments will help improve this future paper.
> There are a few places in the introduction where readers and writers
> are conflated.
Could you be more specific here? I tend to think they're fairly clearly
separated.
> 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.
I wasn't able to access www.kosmic.org, and hence view your counter-example.
Since there aren't any statistics I know of for how many authors there are
on the Web, it's hard to directly refute you. However, it seems to me the
burden of evidence is on you to show that the increasing number of web
pages, sales of HTML books, increasing number of Web servers, etc. aren't
strongly indicative of an increase in authors. Also, there are many
professional authors on the Web who are not directly paid for by readers --
most corporate sites fall in this category, and movie sites also come to
mind. These types of sites wouldn't exist if there wasn't a large set of
potential readers of the material.
> 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.
I actually mean both control by the architect of the system, and also
control by the content providers, assuming the architect has left them any
control at all (for example, Gopher does not give content providers much
control over the user interface at all).
> 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".
Control by the readers wasn't something I had particularly focused on --
user interface features between Web browsers don't seem to be a primary
motivator for readers to choose one or the other. Most readers tend to use
whatever browser is installed on their system. Brand loyalty seems to be
the next biggest determinant. I've personally never heard anyone choose a
Web browser simply for user interface features (except, perhaps, for Rohit
who used to use a NeXT-based browser -- and since Rohit is in the 3%, he's
automatically an outlier :-).
> It could be argued that control over the hypermedia structure actually
> improves scalability to large numbers of readers if done right.
I have yet to see a demonstration of how this can be done scalably with a
corpus the current size of the Web, and with the large number of authors
currently on the Web.
> 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. :)
I carefully avoided stating the exact nature of the relationship -- this is
definitely future research. In my book, a direct relationship doesn't imply
a linear relationship -- I was more imply that other variables were not a
dominant factor in the relationship.
> 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.
Yeah -- The Gopher section was added later, and isn't as well integrated
into the paper as I would have liked. On the other hand, doing the Gopher
vs. Web story justice might require another paper-length essay.
> 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.
I'm not sure I suggested this. A hardware/software system is a generic term
for a system where there are compatible goods, specifically software which
is compatible to a particular piece of hardware.
> 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.
Again, since HyperCard stacks are compatible only with the HyperCard player,
they comprise a hardware/software system.
> 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.)
They certainly don't make such distribution easy, and wide-scale
distribution over the Internet of a corpus the current size of the Web would
require new infrastructure (or a lot of people running a lot of FTP
sessions).
> 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.
I had wondered about this. Unfortunately, when I wrote the article, I
didn't have access to any information about how a typical Gopher
installation was managed. Is this information all implicit, held by former
Gopher admins, or is there a server installation manual someplace?
> - 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?
Yeah, I wasn't trying to hyperlink the references section -- I just wanted
to get the paper on the Web with minimum effort.
- Jim