Why Gopher Will Fail

In yesterday’s post, I wrote the following about Gopher:

Gopher is both a punchline and a flourishing internet protocol. Gopher is both inherently useful and a fashion accessory for contrarian nerds. Gopher is obvious and incredibly misunderstood all at once. What it is is lesser to its fans than what it represents.

I mean everything I said. Gopher failed in the 90s for UMN’s mismanagement and people’s desire for shiny objects–a lust that has only grown over time. Gopher, even by its diehard advocates, is referred to only in the context of it supplementing the web. Gopher’s most practical and appealing uses remain unrealized. Gopher is a fetish for a certain type of computer nerd–a type of secret internet littered with forgotten phlogs, bad ASCII art, and web paradigms awkwardly fit to Gopher as if it was all for <pre>.

Make no mistake–Gopher will fail like this.

Don’t call me a naysayer or a skeptic; I love Gopher. It stands alone as a way to distribute files, programs, media, and documents far quicker and more efficiently than the web could ever compete with. Problem is, we’re too conditioned to play in its world for Gopher to ever succeed.

Gopher will fail because what it does best remains underutilized. Gopher’s best use is in the definition–document retrieval protocol. Gopher comes from an era when “Work Offline” was a feature in every browser and internet speeds were in the kilobits. Gopher counted not because it was “low overhead”, but because it worked directly into the workflow of its users–online files downloaded for offline consumption. Thus, it does best when you’re sorting through hundreds or thousands of well-organized files and downloading a bunch.

Any collection of many files would be better served over Gopher: source code trees, binary repos, Project Gutenberg (or any collection of writing, personal or otherwise), art and photography, netlabel music, the list goes on. Despite this, and while file archives do exist in Gopherspace, its usefulness in serving downloads and documents is downplayed, never touted. Gopher will fail because people ignore what it does best.

Gopher will fail because we tout it for things the web does better. Just like Gopher is best for serving files, the web is best for locations. A web page for a person, a company, or on a specific topic makes perfect sense and can be decorated to match. You likely have a bookmarks bar full of links to forums, to the weather, to information you need regularly and apps you use regularly. For the most part, the web works.

Gopher fails miserably at all these things. A personal Gopherhole only succeeds in making the protocol look like a clunky early website rather than an excellent way to sort through a ton of files with metadata attached. A phlog is tedious to maintain (I should know, I did it) and can’t do any of the little things a blog does, namely RSS feeds. Information selectors, aside from not being supported by some clients, ruin the simplicity of a menu by putting hideous text inline with the rest of the menu, again, like a bad webpage.

Put it simply: w2krepo on Gopher would be brilliant. dcb’s personal site on Gopher would be a less pleasant version of his existing site.

And yet, even in what some in Gopherspace consider their battle cry, their manifesto, Cameron Kaiser’s “Why is Gopher Still Relevant?” utterly fails to make the case why Gopher is still relevant, not the least of which is because his touted use cases are all things Gopher simply can’t compete in.

Not simply nostalgia for the “way it used to be,” modern Gopherspace is a distinctly different population than in the mid 1990s when it flourished, yet one on which modern services can still be found, from news and weather to search engines, personal pages, “phlogs” and file archives.

We would consider the notion of an FTP weather checker or an FTP news site absurd, yet that is what’s being proposed here. This isn’t what Gopher is good at.

Gopher will fail because we talk about it in web terms. Continuing to pick apart the aforementioned Overbite Project manifesto, repeatedly, Gopher is referred to only in how it stacks up to the web.

On the other hand, people who inhabit the Web generation after Gopher’s decline only see Gopherspace as a prototype Web or a historical curiosity, not a world in its own right — and more to the point, being only such a “prototype,” there is the wide belief that Gopher plays no relevant role in today’s Internet and is therefore unnecessary.

On the Web, even if such a group of confederated webmasters existed, it requires their active and willful participation to maintain such a hierarchical style and the seamlessness of that joint interface breaks down abruptly as soon as one leaves for another page.

Finally, if Web and gopher can coexist in the client’s purview, they can also exist in the server’s.

Gopher is obscure; most people haven’t heard of it. Gopher would be seen far less as a proto-web if it wasn’t for us comparing the two, and if they truly could coexist, we’d be touting their differences instead.

Gopher will fail because its software has failed it. See how boring this is?

How Netscape renders a Gopher menu

There’s no requirement that a Gopher menu has to look and act like this, and yet, all clients render them as such. The only two examples I know of otherwise are GopherVR (which is rather difficult to get running these days), and Cyberdog, which dcb did a fantastic demo of over on the group blog a year or so back.

Given the simplicity of the protocol, there’s a real opening for Gopher clients that experiment with the way they display server data to the client that no one seems interested in exploring. Gopher could be tightly integrated into Windows Explorer, complete with drag-and-drop. We could see tree views for browsing Gopher servers. We could see GopherVR implemented using modern 3D technology, providing an LSD: Dream Emulator-like browsing experience that’s perfect for visual media served over the protocol.

Instead, every client looks the exact same as Netscape’s implementation, providing the same damn text-only list of items implemented functionally identically, and Gopher stagnates with its front end experience.

Gopher will fail because its users have failed it. Count how many Gopherholes you see on a casual browse that are nothing more than an abandoned phlog and an about, maybe. I’ve seen lots like this. Because people, even its supporters, see Gopher as a proto-web, people have even less use for it than they do a personal website. Thus, for an end user, there’s even less reason to browse.

It seems as though most people’s big ideas for what to use Gopherspace for boil down to “web things, but on Gopher”, further reinforcing the idea that Gopher is a proto-web. It’s absurd, the idea of browsing Metafilter in Gopherspace as if half the point of the site isn’t to view web pages, which by their nature, require a modern web browser that guaranteed has no native Gopher support.

Worse yet is when people lose sight of the forest and campaign for encrypting Gopher traffic through TLS, losing 30 years of software support across every platform imaginable for the peace of mind that our text files haven’t been spoofed. User data isn’t being sent over Gopher. It doesn’t need encrypting.

Gopher will fail because we value ease over efficiency. For as great as viewing art inline in a Gopher client would be, we’re too conditioned to bloated art gallery sites and social media that mangles images to care much. Both are easy, that’s all we care about. No one will actually leave DeviantART over Eclipse being junk because moving, the alternatives, God forbid doing it yourself on your own site–all take work.

Gopher, like the rest of the old internet, expects a bit of knowledge out of both its content creators and its end users. While writing a menu would be dead simple for me, the structure looks utterly daunting to everyone less technically inclined I’ve shown it to. At the very least, an HTML document is intuitive. A Gopher menu is terse and requires you to know your selectors. Even with a tool to generate a menu for you, there is no Gopher hosting like there is web hosting. At best, you’ll get tildes. At worst, you better be a little network-savvy and have access to a domain and DNS records to get things accessible.

Imagine, genuinely imagine, if a site asked users today to set a program as the default handler for a specific MIME type. Imagine the stares every zoomer and millennial, supposedly the most tech-savvy generations to date, would give that. We haven’t trained our kids to solve IRQ conflicts because that’s not needed anymore. It’s not a matter of intelligence or even skill; it’s just the current cushy, easy-to-use, bloated software design paradigm at play, and Gopher doesn’t fit in.

Aside from the technical hurdle that no modern web browser dares to add Gopher support, even if people could browse it with ease, they’d be more likely to be utterly lost at a menu or think something’s broken because of the total lack of creature comforts. We’re just not built for it anymore.

With the rant and rhetoric out of the way, I should reiterate. I like Gopher. Gopher is incredibly useful to the right kind of person, and with the rapidly increasing number of indexed servers year over year, people clearly have some interest in what it has to offer. By raw numbers and by its own standards, Gopher has flourished, not failed.

The problem now is that in order for Gopher to go from a novelty to a genuinely useful tool, a mindset shift needs to happen across its enthusiasts. Gopher’s strengths need to be leaned on more, and its weaknesses compared to the web minimized. Gopher clients need to experiment, finding new and interesting ways to reinforce its purpose and what it does best. Most importantly, Gopher needs to stop playing the web’s game, because it will lose every single time.

Comments are closed.