dwheeler
3 days ago
> At GopherCon 1993, it was announced that Gopher servers would need to pay for the privilege of using the protocol... Well, that didn’t work out. People were angry and many felt betrayed. They weren’t quiet about any of it either.
> If one were to attempt to identify a single failure of Gopher in competition with the web, it would be the licensing costs. No such fee existed for the World Wide Web.
This, a thousand times. I watched as this happened. The instant that announcement was made, gopher was finished. Gopher might have lost later as HTML kept adding features, but by the time those features were added to HTML, gopher had already lost.
hinkley
3 days ago
Similarly, Bertrand Meyer killed Eiffel by trying to charge money for the compiler, and missing the nascent OSS movement. Java was an inferior language in a few important ways but the compiler and runtime were free. He could not compete with both C++ and Java.
A number of people in that era thought this was a fad and that business as usual would prevail.
SeenNotHeard
3 days ago
The licensing fee wasn't the sole reason, but it certainly sounded the death knell for Gopher and gave users reasons to look elsewhere.
For all the gauzy what-could-have-been speculations about Gopher, it really was more like a hierarchical wiki. WWW's freestyle document model quickly expanded to an application platform that could support all manner and style of services. Fees or not, Gopher didn't have a chance.
msla
3 days ago
To expand on this:
The Gopher standard mixes a document format with a networking protocol. The HTTP standards don't say a damn thing about HTML, but the Gopher standard defines a standard for sending directory information to a client, right down to the fixed list of file types that can occur in a directory. (MIME Type? What's that?) This is the hypertext part of Gopher, as only those directories can link to other places, so constraining that gives you a nice, simple way to have pretty plain-text sites with an enforce separation of lists of links, one one hand, and images and documents, on the other, which HTTP has no equivalent for.
(Not just file types, in fact, in that they have a special type for tn3270 telnet sessions. Yep, those IBM mainframes with block-mode terminals were quite important back then, but it's a bit out of place now. They also have a type for GIF and a generic 'client-figures-it-out' image type. How forward-thinking.)
jordanb
3 days ago
> The HTTP standards don't say a damn thing about HTML
HTTP stands for Hypertext transfer protocol. The whole thing was predicated on sending HTML documents and couldn't originally send anything else.
> (MIME Type? What's that?)
MIME is a hack to add attachments to email that was later also hacked into HTTP so you could send add "attachments" to a protocol designed only to transfer hypertext, it's a kludge added in version 1.1.
Gopher's main difference with the web was that its linking was directory-based with directory tree documents rather than embedded hyperlinks. This was inferior, strictly speaking since you can easily make a directory HTML document on the web, but you could also cross-link.
I'm sure that would have been changed though, along with additional file-types or whatever had Gopher succeeded. The web's success over Gopher was never down to technical details.
msla
3 days ago
> HTTP stands for Hypertext transfer protocol. The whole thing was predicated on sending HTML documents and couldn't originally send anything else.
OK, HTTP/0.9 was apparently like that. By HTTP/1.0 (1996) they'd learned better, and that was the growth phase:
https://www.w3.org/Protocols/HTTP/1.0/spec.html
> MIME is a hack to add attachments to email that was later also hacked into HTTP so you could send add "attachments" to a protocol designed only to transfer hypertext, it's a kludge added in version 1.1.
Like how Gopher got kludged to add other item types? All useful protocols evolve, and Gopher is no exception.
https://github.com/gopher-protocol/gopher-plus/blob/main/gop...
> Gopher's main difference with the web was that its linking was directory-based with directory tree documents rather than embedded hyperlinks. This was inferior, strictly speaking since you can easily make a directory HTML document on the web, but you could also cross-link.
Yes, that's true.
> I'm sure that would have been changed though, along with additional file-types or whatever had Gopher succeeded. The web's success over Gopher was never down to technical details.
Also true, and that New Gopher is now called Gemini.
It also defines a hypertext document format (Gemtext) but it allows HTML-style free linking and (depending on client) inline images, although that's not really what the Gemini users want. Again, this is more social than technical, and more self-consciously social because it's a deliberate reaction to existing paradigms: The Web as it is now (too invasive, too busy) and Gopher as it is now (a moribund retrocomputing exercise that can't realistically incorporate new technologies or serve new goals).
Speaking of clients:
https://gmi.skyjake.fi/lagrange/
https://thelambdalab.xyz/elpher/
Both do Gemini and Gopher.
immibis
3 days ago
As usual though, more restrictive protocols remove possible use cases from one side of the protocol, but add use cases to the other. It's like JSON versus a Turing-complete configuration language.
A design based on directories of static files makes it a lot easier to mirror the entire site, or a subtree.