They are in the rest of the paper. I'll go back and look.
> I wasn't able to access www.kosmic.org, and hence view your counter-example.
They had a live front page a couple of days ago; perhaps I'll mail it
to you.
> 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.
I believe you are correct, but the situation is more complex than you
describe.
For a person whose web pages are of interest to only a few people, the
more people on the web, the more likely they are to write those web
pages.
For a company who is paid somehow for every pageview, then the more
people on the web, the more likely they are to write those pages. This
means that advertising material, stuff with banner ads, online
catalogs, FTP sites by CD-ROM publishers, etc., can be expected to
become more and more extensive as the number of readers grows.
However, for a person whose web pages are of interest to a wide
audience, but who does not get paid for each hit, the more people who
want to read their web pages, the more expensive it gets!
What exactly constitutes a "wide audience" depends on things like
server hardware, server software, file size, frequency of update (thus
frequency of visits), and available bandwidth.
I believe that this dynamic is the real reason why the Web has become
less and less personal and more and more commercial. It's not because
ordinary people can't write good web pages. It's because when ordinary
people write good web pages, they can't afford to serve them to the
world.
This is not an inherent property of document distribution systems.
> 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.
Right.
> > 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.
Well, MSIE and Netscape are essentially identical in their UI. I
prefer Opera largely because of the extra control I have over the UI --
I can turn off colors, zoom in and out, etc.
> 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
NeXT-based browsers are not an option for most people. Perhaps if they
were, more people would tend to use browsers with better UIs -- but the
current choice for most people is between TweedleClintonScapeDee and
TweedleBushPlorerDum.
> > 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.
I don't believe it can. I was saying it improved scalability to more
*readers* -- not more *writers*.
> In my book, a direct relationship doesn't imply a linear relationship --
That's what I read it as.
> > 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.
The point is that it's possible to circumvent lock-in with compatibility.
> > 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.
"the number sold (e.g. the number of VCRs in use)" IIRC.
The nonlinear part is a response to another "direct relationship",
which we've already been over.
> 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.
Yes, I understand.
> > 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.
The economic argument does not apply here; it's not substantially more
difficult or expensive to distribute a HyperCard viewer with every
HyperCard stack than it is to just distribute the stacks, in the age of
the floppy, anyway. Things are probably different today.
> > 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).
I'm not claiming they scale; I'm just claiming they don't exclude being
distributed over a WAN.
> > 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?
I'm afraid I don't know.
I just remember that I never saw a document on Gopher that clearly
hadn't been put there by the server maintainer.
> > - 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.
Perhaps it depends on the conference conventions -- but when I read a
paper, I'm very happy when all the footnotes have URLs, whether the
paper is on paper or in my browser.
Sorry to be so argumentative :)
-- <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>