# Why Gopher Will Fail
## May 3, 2020
### From gopher.somnolescent.net, the Gopherhole of the weird lightbulb people
Gopherspace continues to be its own worst enemy--here's why Gopher sinks
instead of swims.

---

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.** There's no
requirement that a Gopher menu has to look and act like Netscape's plain text
menus, 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.

**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.