What was Gopher?

stuff works dot com. But this week's listener mail episode comes to us from Ryan, who says, please do an episode about the Gopher protocol, such a different approach to utilizing the Internet that no one knows today. And so today we're gonna walk back in Internet history and learn all about the Gopher protocol. But first it kind of benefits us to remember what exactly the Internet is. And trust me, this is important in the grand scheme of things.

But I'll be nice and high level and brief about it. So when you get down to it, the Internet is essentially just a bunch of computing devices that are all connected to each other, and that's it. Really. There's a lot of infrastructure there that allows this to happen. But ultimately it's a bunch of computers that are talking to each other. It's a network of networks using various types

of connections and protocols to send and receive communications. But when you just break it down to its simplest of terms, you're really talking about a bunch of interconnected machines. Now, broadly speaking, we can classify most of these machines as either servers or clients. Now there are other machines as well, like routers and switches and stuff, but I'm mostly talking about the devices that are directly communicating with each other

rather than the ones that facilitate that communication. So as a server, well, it does exactly what it sounds like. It does. It serves information. Clients request information. So your smartphone or your computer or your tablet that you use to serve the Internet or read email or whatever it is you do online, that is a client. The servers are the machines that contain all the information you're looking at and serve it up to you. And the Internet is older than the World Wide Web. A lot of people,

probably not as many today as we're around. For like the late nineties, but a lot of people would equate the World Wide Web with the Internet, like the two are synonymous, and that's not really true. The Web is really just a layer on top of the Internet. It's it's an interface that makes it easy to access and interact with information. But it's just one part of the Internet. And before it came along, people were facing a bit of a challenge. So imagine you've got this network of networks.

Information is on thousands of servers around the world. You want to get access to some specific information, like a very particular file. There's one file that you want to get, But how do you track down that file? How do you know which computer out there in this vast network of networks, How do you know which one actually holds the file you want. You can't just scream out, hey, I need this one text file. You've got to know

where it is in order to retrieve it. So the way this would work normally is that you'd send a message from your computer across the network to the specific server in question. So ideally you would know what computer hosts your file, and you would use some method of

connecting to that server. Maybe you're using tell neet, maybe you're using FTP file transfer protocol, but you're using something to send a message to that server, and in return, the server responds to you, and then you request access to that file. It's really just that the message you send is just a request for information stored on that server. And if you have access authorized access to the information.

In other words, if it's not protected by like a password or something that you don't have, the server would send that information back across the internet to you. But what happens if you don't know which computer holds the information you want? How do you get access to it? Back in the old days, this would be kind of like picking up a telephone to call somebody. Let's say you're trying to call me, only you don't have my phone number. I never gave it to you. I'm not

listed anywhere, So how do you call me? There are millions of phone numbers out there. If you knew my phone number, everything would be just fine because you could just dial it directly. But since you don't know my number and there's no directory to consult, you're faced with a nearly impossible task. What do you do? Just start randomly hitting button until the right person picks up. Well, that was the problem facing the Internet. It arose because

the network became more complicated. Just as in the old days you might have very few telephones in a single town. Like I'm talking the real old days. When telephones first became popular, you didn't need to worry about phone numbers. Maybe three people in town had a phone. These days you gotta worry about it because millions of people iPhones. Well,

same thing was true with the network of networks. As more computers came online, as more systems joined the Internet, it became more difficult to track very specific stuff down. So before the Internet, there was a sort of a precursor, not really the Internet. Before there was an Internet, but it was a system of networked computers called ARPA Net

now the ARPA Net. That was a project from the Department of Defense in the United States, and it was something that that required a bunch of computers scientists to sit down and work out protocols. Uh. It was essentially a big, but relatively simple network of computers. Now I say simple because if you look at the Internet by comparison as a network of networks, it is far more complex than what Urbanet was. But I am not casting

aspersions on our bonnet. It was still incredibly sophisticated, particularly for its time. It allowed people working on different computers that used different operating systems, different languages, the ability to communicate with each other. And that's phenomenal because usually you know this, these are like computers that if you were to connect directly to one another, they would not be able to communicate with each other. They were fundamentally different.

So the designers of the Urbanet had to figure out a set of rules that all these different types of computers could follow in order to exchange information with one another. So that that required a lot of work to create these protocols or sets of rules to facilitate communication. And I've talked about ARBONETT before. If you want to hear a lot more about it, you can track down the classic episode. It originally published in two thousand and twelve.

It was titled Happy Fathers of the Internet Day and then it Chris Pallette and I talked a lot about the people who designed the various protocols that allow Internet communication to happen. Well. Anyway, two of the protocols in question during the days of Arbonet were the Transmission Control Protocol or TCP developed in ninety and the Internet Protocol

or i P, in ninety eight. These are almost always grouped together whenever anyone talks about Internet protocols, they'll say t C P i P, But they're technically two different sets of rules that together uh end up guiding the computers on how to communicate across this network of networks. These are the rules that gave Arponette that ability to

create global communication across various different computers. The two protocols were officially adopted by Arpanett in Night three, So while they were developed in the seventies, it wasn't officially adopted until Night three. Now, they were being used before that, but you know, Arpanet was a government thing, and just like you would suspect it moves super fast because it's government. Well,

the following year a lot of things happen. We got that really killer Apple Mac commercial that was like the Orwellian nineteen eighty four that was phenomenal. But also Sun micro Systems unveiled a system called the Network Filing System or NFS that was sort of like a file directory and storage system for networked computers running on a heterogeneous

Unix environment. So you had to have a bunch of computers running the same Unix implementation essentially, or same version I guess I should say not implementation, but the same version of Unix across all these different machines. And it was kind of like your basic file management system you'd have on a personal computer. So if you've ever used a computer that had a variation of this, like Windows file Explorer is a good example. You typically have a

hierarchy of files. You'll have like a top level selection of files. If you go into one of those, you might see folders, like subfolders underneath that main heading. Go into that one, you'll see more subfolders, maybe some files, that kind of stuff. Well, it was essentially that, but for an entire network of computers. So you can share information between different computers on the system by saving files to this network drive, something that's very familiar to most

of us today, but back then was really new. And then obviously you could retrieve files from the appropriate directory on that same system. Also, in a team over at Carnegie Melon University released the Andrew File System or a f S now. Originally, the a f S provided Carnegie Melon students a campus wide file directory system and later on, a company called trans Arc sort of spun off and

turned this into a commercial product. Now, these file systems allowed users to access files on other computers, but they also came with a really steep learning curve. If you weren't particularly computer savvy, it was really challenging to navigate through these file directories. It would be kind of like taking someone to a computer and it has all line commands, and the person had never really worked with a line command interface. They only worked with graphics by line command.

I mean, you have to type in the command and file names you want in order to access stuff. Well, if that's what you've been doing the whole time, it's not so bad. You start to pick up on it. Even as new systems are brought on, you can kind of adapt to it pretty quickly because you already have that basic level of knowledge. But for someone brand new

to computers, it was really intimidating. It felt like you needed to have a lexicon of different commands at your disposal all the time, and a lot of people would have to use cheat sheets and take a look at those constantly so that they can figure out just how to navigate a computer. It wasn't very user friendly, and it was really hard to find what you were looking for if you didn't already know where to start from the beginning. The trick with filing systems is that you

have to understand the organizational strategy. So not only do you have to understand the language to navigate the system, you also have to understand the person who set it

up in the first place. So there's there's a bit of machine savvy you have to have, but there's also how well do I know the person who set up this filing system, and how does that person's brain work, Because maybe they'll set things up in a different way then I would set it up, and if I were to try and navigate using my common sense, I might find it frustrating. So here's an example of what I mean.

Back in the day, I used to organize all of my DVDs by genre and then by alphabetical order by title. So at all my action films in one place, I had all my horror movies in another place, all my Tim Curry movies were together, all that kind of thing. You know, Tim Curry is a genre unto himself National treasure. But if you didn't know that, I did that and you didn't know where one section began or ended, you could have trouble finding a specific title. Maybe you would

have had a totally different approach. Maybe you would have organized everything alphabetically from the start, so it didn't matter what genres and you would know, all right, well, the title I'm looking for it starts with a D, so I need to find the D S and it's going to be there. Or maybe you would even have a more crazy organizational strategy, maybe you would organize everything chronologically by release date, which would confound everyone but the geekiest

of film buffs. The point is that these file systems back in the day, with these network drives, they weren't always intuitive. Even if you weren't immediately put off by the interface, you might still not be able to find what you're looking for. Now. Later still came alan em Taj's Archie tool, and he was a University of Montreal employee student. You know, he had gone from one to the other really when he when he invented this tool to search for files on the Internet that would be

transferred via f t P file transfer protocol. So instead of requiring the user to know a direct path, you just had to know the name of the file, how was the file named? Now, that still isn't ideal, because I'm sure you've encountered files that had weird or nonintuitive names that may have had nothing to do with what the file actually was about. So you had to know precisely how the file was named or else it really

didn't do you any good. But at least it didn't require you to also know the full path name of where a file was, and it allowed you to actually do a search across the internet. Now, once the Web came along, and I'll talk a lot more about the World Wide Web later on in this episode, and once programmers began building search engines, this probably became less difficult. Right. Search engines started to make things much easier for people.

The Web made navigation more intuitive. It made it more accessible to people who weren't experienced with computers or had inside knowledge of directory organization. But in those in between times before the web, but after the Internet came online, that's when Gopher emerged. Now, there were several developers behind go for really six people in total, and one of the more important ones I shouldn't even say it that way, one of the leads I should say, because all six

were important. Uh. One of the leads was Mark McHale, and Michael attended the University of Minnesota. Actually they were all part of the University of Minnesota, but he had attended as a student, earning a bachelor's degree in chemistry

in nineteen seventy nine. But while he earned his degree in chemistry, he would actually go on to join the campus micro computer Center as a programmer, and by the late nineteen eighties he was leading a team of programmers and together they built an email client called pop mail, first for the Macintosh computer and then later on for the PC platform. The POP in pop mail stands for post Office Protocol. So the way it worked was that you had a server that would kind of act like

a virtual post office. You would whenever you were checking email or sending email, it would involve a virtual visit to this post office. You could drop off and receive mail there. So if you want to send a message through your popmail client, the client, as in your computer the workstation you are using, would relay the message through the post office server, which would then direct the message

onto your destination. When retreating messages, you would actually be going to this popmail server to pull the emails off of it in order to read them. So they were the ones who developed this, and it was a very popular type of way of getting hold of email. The next big project that this team tackled was creating an interface for navigating the university's local network. So the question was,

how can we find whatever we're looking for? How do we organize all this information we have in a way that makes sense because they could see that the Internet was creating this incredible opportunity to share information, but it was getting increasingly difficult to find stuff and to organize stuff properly because there were more and more computers coming onto the system and it just made things even more complicated.

So together Mikhail, Bob Alberti, far Aud, Ankle, Saria, Paul Linda, and Daniel Torry began to work to develop a solution, and as it turned out, their solution had applications far beyond the campus they worked on. In fact, it would turn out their solution had applications outside of the campus they worked on before it actually was implemented by the campus itself. It would work across the Internet in general. Now I'm gonna jump into what they did in just

a second. But before I do that, let's take a quick break to thank our sponsor. So the team got to work in They knew that they wanted a system that could organize information in an intuitive way, giving users an opportunity to navigate the information they needed quickly. They wanted it to be a client server system. This was really important to them. What they perhaps the biggest decision they made, the most important one to them, was to

not go a centralized mainframe organizational strategy. They wanted to get away from mainframe computers. They saw that the future was in desktops. But desktop machines, especially in ninety one, were slow, they had relatively limited capabilities, so whatever system they created had to be optimized for these less powerful machines. They also wanted to make this system scalable, with options to have various departments register servers with a top level servers.

So in other words, you could have different departments having their own networks, but have them linked to the main network so that you can navigate throughout all of these different systems. And that way, if you're connected to that top level server, you could navigate to any lower department through a master menu. They also wanted the tool to be efficient and lightweight, meaning they didn't want to tax

those normal PCs and workstations. They didn't want a tool that would move into Snail's pace, and that was one of the reasons that they really focused on text based communications because it's doesn't require a whole lot of data to send text, and it meant that it could be relatively fast and informative. They also decided that the server would not retain states. Now that means that the server wouldn't need to keep a record of all the different

information requests from multiple clients. Once a connection closed, the state was white, and it would close the connect after every transaction. Essentially, so together they worked on this tool and they decided to call it Gopher. The name, by the way, serves many purposes. For one, the mascot of the University of Minnesota as the Golden Gopher, Minnesota is the Gopher state. Also, the idea of a metaphorical Gopher appealed to them. Gophers tunnel, and in a way, the

Gopher protocol kind of tunnels through networks. They also started to refer to the networks that we're using Gopher as Gopher space. And finally, gophers also the term for someone who runs errands and fetches things because the gopher will gopher like coffee or you know, uh, you can gopher snacks that kind of stuff. The Classic Muppet Show series had Scooter who was a gopher. Uh. There were a lot of jokes about that, about how Scooter was a gopher by job, but he wasn't a gopher by critter,

like he was not the actual animal gopher. Anyway, here's the weird thing. So the team knew they were onto something when they designed Gopher, but it didn't get a lot of traction right out of the gate despite its utility, because the University of Minnesota they just didn't see how this would be useful. They didn't see the value in it, so they didn't really put any support behind it, and

they didn't implement it at all. So the team decided to sidestep all that red tape, and one of the team members uploaded the software to an FTP server and then posted a message on an Internet mailing list saying, hey, guys, we developed this kind of cool tool. We think it is a great way to organize information on networks and

allow people to find stuff. Give it a try. So people began to download it and put use and not long after that it started to take off a lot of places we're using it, and they decided that it made a whole lot of sense, and eventually the University of Minnesota administration relented and implemented Gopher as well on their campus. Now, let's go ahead and talk about Gopher implementations and what it was actually like. So there were two main ways you could interact with Gopher. One of

them was to install software on your computer. And uh, this is looking at interacting with Gopher as a user as opposed to as an administrator. So you want to use Gopher, Well, one thing you could do is install software on your computer, and this was a client side Gopher application, which really is not that different from a web browser like Firefox or Chrome or Safari. It's essentially a similar thing. It's a it's a program that runs

on your computer that acts as the interface for this protocol. Uh. Those are all clients side applications, just like the Gopher one was. But you didn't have to do that. What you could do instead is use a tell net application. Telling Net was another old protocol that's still used in some places. Uh tell net would allow you to virtually log into another terminal, and you just had to have the correct address, import number and everything in order to

tell Net into that that room. So you could use tell neet to log onto a remote server and use the server side Gopher client to access directories, and in that case, all the work is being done by the server and you don't have to actually have a client based application on your side. The style of the Gopher client really dependent upon its implementation. The team wanted to make sure that it was it was customizable, but it

was always simple. It's always text based. It could be extremely simple where all you have our text options under a menu, or it could have some very primitive kind of of graphic user interface elements in it. Graphic user interface also known as gooey, but less less um what's the right word, less impressive or extensive as what you would find in the Worldwide Web later. And there were two worlds in the Gopher verse, the world the client

could see and the world the server worked with. So on the server side, every item within a Gopher directory would have certain elements to it, and that included a client visible name, a selector, which was usually something that used the path name that would connect the server for location purposes. Then there would be a host name which would tell the top level server which computer actually contained

the file in question, and an IP port number. Ports are kind of like telephone lines, so a computer had to know which port it should use when contacting other computers. Now on the client side, on the user side, only those client visible names would show up. Everything else would be hidden. And to use an analogy, imagine that you go to a party and it's one of those super hip, geeky tech parties that I assume happened but I never

get invited to anyway. Everyone gets a little name tag, and the name tag just has the person's name on it. That's it. That's the only information about the person that is visible to the average attendee. So when you walk around the party, you can see each person's name, but

that's it. But let's say you're a super duper awesome v I P at this party, and all the super duper awesome v I P s at this particular party get a little swag bag that has a pair of smart glasses in them, and if you put the smart glasses on, you see projected above the name tag of each person more information, and it tells you where that person lives, what their phone or is, tells you about

their favorite lunch spots. In other words, you know a few different ways you could reach those people if you needed to. Well, in the gover verse, that sort of same approach was applying, but only two files, not to people, so there wasn't anything creepy going on. But Michale and his group decided that users didn't need to see all the extra information. They don't need to know where a

file is on a network. They don't care. They don't care if the file they want is on computer A or computer B. They just want access to that file. So they decided that all of that excess information would be invisible to the user. It would still be there for the servers because the servers would need to know where everything was in order to direct users to the right location, But to the users themselves, they don't care, So get rid of it, and UH ended up being

a much more elegant system that way. So let's say you've blogged into a college campus Gopher server, because the tool was originally developed for colleges, So what would you actually see if you did this, well, you'd start off with a menu of options. It's kind of like a table of contents, and that would allow you to explore

different areas of the Gopher verse more thoroughly. A typical top level menu might include and by the way, I'm taking this largely from a request for comments that Michale and his group created in order to discuss what Gopher is, what it was meant for, and how it works. The first item might be something like about Internet Gopher, and it would literally just be that little phrase, and if you selected that one, it would open up something that

would allow you to learn more about Internet Gopher. It would pull the files that could tell you about the versions and Gopher in use and how best to navigate it. It may even tell you about the site administrator. And in fact, in that original request for comments, they suggested that every administrator for a Gopher server include his or her name, email address, and phone number so that you could get in contact with them should something go wrong. Yikes.

Obviously this was in the days when very few people, comparatively speaking, we're using an Internet tool. Because you could just imagine how much you know traffic you would get from various emails and phone numbers. If you just put your actual address out on a major website, that would be tough. The next UH element on this Gopher list might be something like around the campus, and that could include more directories that give you links to files about

various areas of campus. You might get sub menus of different options. For example, at University of Georgia, if I saw around the campus on a Gopher site and I clicked on that, it might take me to a couple of different sub menus, one for North campus and one for South campus, because the University of Georgia, at least at the time when I was attending it was roughly

divided into North and South campuses. Another option might say courses, schedules and calendars, which would obviously take you to information about the classes offered by that college and when they happen, as well as a list of campus events throughout the year, and so on and so forth. Those are just the kind of basic table of content stuff you wuld see,

and again it's all text based. Typically the options on any list, we have indicators to let you know if you were looking at the name of a file or if you were looking at the name of another directory. So again, in an example given from that RFC paper that was written back in nineteen, they the group showed directories as being followed by an ellipses and files were not.

So if it said campus schedule with no ellipses, then you knew that clicking on that would give you a file with the schedule on it if you chose that option. But if it if you were looking at a list that said college activities dot dot dot, you knew that the dot dot dot at ellipses indicated that it was a link to another directory. So if you clicked on college activities, you would get another menu that would subdivide up college activities. Maybe it would be sports, after school activities,

it might be extracurricular student groups, that kind of thing. Now, Gopher's design allows other servers to interact with a top level servers, so it didn't have to just be a single computer running all of this information. In fact, that was beside the point. The The whole purpose of this was to allow multiple servers to connect with each other and create an an UH overall strategy for navigation to

allow students or other users to learn more information. So you could have say the computer science department server registered under a top level option for the entire university, and the English department could have its own server, and the Math department could have its own server, and so on and so on. So each departmental server would further point down the chain to specific files relevant to that department.

And Gopher also included the ability to stack, meaning that you could actually retrace your steps, which is kind of like hitting the backbar or the back button rather on a browser. So if you went down one path and then decided, hey, I need to see something else that was further back in my browsing, you could back up the pathway until you got to that specific fork and then take the other fork. And that was actually pretty

innovative in the early nineties. It wasn't like it was, you know, something that they were copying from other people. Unlike today's websites. The information on Gopher pages tended to remain fairly static, which actually was also a huge help for Gopher space. You didn't have to update things quite

so frequently. Occasionally you might need to update a file, or you might need to add a file to a server, but that didn't happen at the frequency we see today On the web, there weren't a lot of dynamic pages out there. It was important for Gopher to be able to adapt to change is and evolving conditions, So the team designed a system that it would allow them to update files and path names in pieces, so that you didn't have to do a full update of the whole

system regularly. You could just focus on whichever sections had new information and just update those bits. Everything else could remain the same. That sped everything else up, Like if you are only making changes to two percent of your network, then there's no reason to update all They could save time by just updating that two They also made another

very clever choice. They recommended that all top level servers have a clone and that way, if one server were to fail for whatever reason, another one could take over the job. Also, if you had a really busy network, you could have both servers acting at the same time, sharing the load. So some users are using server A, some users are using server B, but both of them

are identical. They have complete navigational tools to go through the whole network, and so it doesn't really matter which one you land on as a user, it's going to be the same experience. And since most of the files remain static. You didn't really have to worry about the two top level servers getting out of sync. They would be pretty much ready to go all the time. I mean, occasionally you don't have to update at least parts of the system. But it was pretty manageable, especially in those

early days before things got super complicated now. The team also suggested that all registered servers in a system have an alias that the Gopher A client could use to locate those servers, and this way the client would know each registered server by its alias, rather than the server's primary name, which was more or less unchangeable. Now why would you want to have an alias, Well, the reason

was to improve portability. So if as an administrator you decided that you needed to move files from one server to another server, that could be a huge headache because we mean having to update all these different path names so that your top level machine knows where everything is now, right, if if you had to say, oh, well, instead of being on this machine, it needs to be on this machine.

I've got to update all these different files and these different path names so that people navigating the system will get to where they need to go. Using the alias was actually a very clever idea to get around this. Clients wouldn't require an update or any alteration. They don't need to know that computer one, which used to be known as Bob, has gone offline and now computer two has all of Computer one stuff. Instead, the administrator would

just name computer to Bob. They would give computer to the alias of the old computer one, and then the clients would just end up going to computer two because they're not looking at one or two. They're just looking for Bob. And if computer two is Bob, now that's where they go. It was an elegant solution, particularly once network's got really complex. Now, the brilliant thing behind Gopher is that the end user didn't need to know any of this. That didn't matter to them. They they just

needed to have a simple interface to interact with. They needed to be able to see the choices they wanted to make a choice and follow that pathway, and it was very similar to kind of a choose your own adventure book. As long as the directories were clear and organization of the information made sense, it was easy to use. And then there was the killer app, the ability to search. So so to search on Gopher you had to set

up an actual go Gopher search server. It would be its own purpose was to to essentially have all the different files that are connected to that particular Gopher space UH indexed, and these servers could perform full text searches in all the files on all the registered servers in that Gopher space. So, by default, search queries assumed that if you were to type in multiple words, the spaces

between those words were an and in boolean logic. In other words, if you typed in Spanish dance in the query field, so you just have Spanish space dance, the search would actually assume what you are saying is give me all the files that have both the words Spanish and dance in them. Files that didn't meet that criteria would not be returned. So if there was a file that had the word Spanish in it, but dance never

appeared in that file, you wouldn't get it. Same thing if it were dance but Spanish was never there, you wouldn't get it. Now, this structure only worked with servers that were registered to the same system, So these Gopher spaces were kind of like islands in the ocean. You could connect Gopher spaces together. You could end up registering the servers of different Gopher spaces so that they made larger networks, and that would allow users to navigate from

one system of servers to another. But that wasn't necessarily the aim of Gopher. So if I did a search on a Gopher space for a specific term, like again at you g A, if you g A was its own contained system, its own network of servers throughout the campus, but none of those had connections to other campuses. I'm not gonna find files that are stored at the University of Minnesota because the two systems are distinct. I'll only

find files that are on u g A system. So it was a little different from the World Wide Web. It had these uh again, these kind of islands of information. Well, I've got some more to talk about, including the rise and fall of Gopher itself, but before I get into that section, let's take another quick break to thank our sponsor.

All Right, we're talking about the nineteen nineties. Now, the Internet was still pretty darn young back then, Especially an Internet that was accessible to people beyond the computer science field old, and no one was really sure what it would evolve into. In those early nineties, in the Internet engineering Task Force or i E. T F held a meeting in San Diego and they invited Michael and also Ankle Saria to come out and to speak to the group as a whole about the work they were doing

with Gopher now. The meeting included a whole bunch of different important figures in Internet history, including Tim burners Lee, who is the guy who pioneered the Worldwide Web. He built the first web page at CERN, that's the same organization that runs the Large Hadron Collider. So Burner's Lee was there to talk about his approach to Internet navigation using what he called the web and hypertext, which I'm sure you're familiar with because that's what everybody uses today.

He also was very interested in trying to find a way for the Web and Gopher to work together. Um, the folks over at Gopher they were looking at burners lee approach to navigation and they said, well, this doesn't make any sense using hypertext of different words too to leap to connected but distinct ideas. That's that makes an organization impossible. It's like the opposite of what we're doing. We're trying to create hierarchies of information and the Web

is is a web. It's all this interconnectivity. So they never really got to work things out with burners Lee, something that they said in retrospect perhaps was a mistake, but they didn't know that at the time. No one was sure at the time whose approach was going to work out best. So uh, it wasn't as a weird experience, right And besides, the web programmers learned about other means of accessing and navigating the Internet. There were other ones like a Prospero and waste or w A I s

so be. Clifford Neumann was the pioneer behind Prospero, which was meant to create personalized directories of the Internet in response to user queries so they could organize information and allow users to search grouping resources together so that users didn't have to go down several different individual paths and just hope for the best. Ways stood for Wide Area Information Server. It was a text searching system that could look for specific strings of text on files on the server,

retrieving any hits that it might find. And so it was also very different from the Gopher approach or the Prospero approach. It was a pretty basic strategy to search and retrieval. So at this gathering, Michael discovered that people already knew a lot about Gopher. He thought he was going out there to tell people about a system that he had developed and kind of launched the year before, but everyone there seemed to really be familiar with it. A lot of them were running their own Gopher servers.

They were very curious to hear more about the team behind Gopher. The software had spread rapidly because of its easy implementation and interface, and adoption was incredible. By Gophers, traffic growth rate hit nine hundred nine seven percent. Now that definitely sounds astronomical, but keep in mind percentages are tricksy. For example, if I sold one newspaper in a week, and then the following week I sold ten newspapers, I'd have a growth sales rate of nine. So while growth

is spectacular, we're not talking about enormous numbers. By April, the number of Gopher servers, or at least the ones that the team was aware of, had hit just under seven thousand servers. But Goverer did have a big head start on the web. It took the web a bit longer to catch on because you had to have the development of the clients that people could use to browse the web, and you know, you have to have the development of the actual software people were using to create

web servers. Gover was popular enough for the team to start to hold conferences of their own Gopher cons They even created t shirts and merchandise with the Gopher logo on it. Colleges and companies were adopting it. Even the White House launched a Gopher site back in those days. But hot on the heels of Gopher was the Worldwide Web concept, which had its own compelling methods of navigating

and present presenting information. Even though it seemed nonintuitive to the Gopher group, it turned out that people really like it. Anyone who spent a lot of time on a site like Wikipedia dancing from one topic to another, just diving down those rabbit holes, they know what I'm talking about. Someone, ironically, I would say Tim burners Lee actually was able to spread the word about the Worldwide Web using a Gopher site.

That's how people were able to get the files they needed to create web servers and web clients, as well as find more information about the web itself. And the Gopher team was running into problems with the University of Minnesota as well. The administration was always something of a reluctant partner with this group. At first, the college had been a roadblock. You remember I mentioned they refused to

implement Gopher in those early days. They only did it after it had already been implemented at other college campuses. Members of the Gopher development team, we're looking at the possibility of creating a private entity, like a spinoff company, to create Gopher as a commercial product. But back in those days, the Internet was still largely the domain of universities and government offices. In fact, a lot of people looked at the possibility of private enterprise getting involved with

the Internet as something they did not want. A lot of people kind of compared it to public broadcasting. They said, the Internet should remain like PBS and all these companies. That's like ads supported TV. We don't want that here. So there was a lot of resistance even among the group themselves. Not everybody was in agreement that they should go the privatized route. And remember the dot com era had not yet begun at this point. Then, the University

of Minnesota instituted a licensing policy for Gopher. They said that any organization out there that was operating for profit would need to pay a license fee to the University of Minnesota in order to use Gopher, and the cost of this license fee was sliding. It depended upon the size and type of business in question, and the university

was looking to keep all that money for themselves. Really I Meanwhile, the development team found that the university still wanted them to do their regular desk jobs as programmers for the University of Minnesota, so they were supposed to both develop Gopher and work on their normal jobs, and they weren't really given any more resources to do this. It was still just the six of them, so their

morale began to decline. And then they had the university expecting them to do these two jobs at once, as well as having an entire population of users out there who are angry about this licensing policy that the university has had put in place, and and the team was kind of caught in the middle. And at one point the university even considered outsourcing Gopher to other programmers, essentially taking it away from the team that created it and giving it to someone else. Meanwhile, the web was just

getting started. Remember that I said Gopher grew by back in well. The web also grew that year by three hundred forty one thousand, six hundred thirty four percent. It was also the first year of the commercial web browser, Mosaic. Mosaic proved that you could go commercial on the Internet. So while the Gopher group was reluctant the website, things were going in a very different direction, and the web was incorporating stuff that Gopher couldn't really support, like images

on web pages. Not first, an image on a web page was not a huge asset because it took forever to render a picture on a screen, and it caused some people to say that WWW actually stood for world

Old Wide Weight. But modem speeds were on the rise as well, and that helped reduce some of that loading time, and some of the Gopher team rather sardonic Lee said, we knew the game was up when we realized that people could get naked photos on their computer screens using the Worldwide Web, something that you could not be done with Gopher, and they were being pretty serious about it at the time. By the spring of Web traffic exceeded Gopher traffic, so even though Gopher had a headstart, Web

had caught up and passed Gopher traffic. Companies were discovering that there were some possibilities on the web, though really web commerce was still a couple of years away from really taking off, but it offered opportunities beyond just sharing information, which was really the only thing Gopher was good for. It was really sharing information and distributing files. It wasn't meant to do really more than that. So the web

had versatility on its side as well. And one of the big things that helped drive the knife home and Gopher had nothing to do with how people use the Internet. It had to do with a scandal unrelated to anyone on the Gopher team. Dr John Nigerian, a transplant surgeon at the University of Minnesota, was accused of fraud, tax evasion,

and embezzlement. The charges led the National Institutes of Health, which is a federal government office here in the United States, to withdraw funding to the university, and that was a serious blow to the school, so they went to emergency mode to try and fix the situation. They as part of that, asked the Gopher team to create a new system to track accounts and file paperwork because a large part of this accusation really dealt with the way paperwork

was failing to be filed on time. So the team eventually developed a web based transaction program, which is also kind of ironic when you think about that was a web based approach. It was the world's first web based transaction program. But it also meant that while they were developing this, they could not continue working on Gopher because

they just didn't have the time to do it. So by the time they finished the web based application, Gopher was dead in the water, or I guess dead under the ground, I suppose, if we want to stick with the metaphor anyway, it's it's not really dead dead. It's not entirely gone. There are still Gopher servers out there if you know where to look. But as an evolving entity, Gopher was essentially a thing of the past and at some point, and no one's really sure, when someone took

the original Gophers server known as Mother Gopher offline. The University of Minnesota supported it for several years after Gopher had clearly lost the race to the web, but that as no longer the case. As for Michael, he would go on to join Duke University, where he still works today, and other members of the team have gone on to do other things. Some of them retired, some of them

while I was working for Google. One of them stayed with the University of Minnesota, oh And Dr Nigerian, who was accused of those crimes, was ultimately exonerated of those accusations of fraud and embezzlement. The jury returned with a

verdict of not guilty. But by then the damage was done in more ways than one Gopher it faded away due to lack of support, and the university found itself struggling to regain the trust of the n i H. So that's the tragic story of the Gopher protocol, and that's why we serve the web rather than burrow through the Internet. I hope you guys enjoyed that look back into the history of the Internet. If you have suggestions for topics I should cover in future episodes, let me know.

Send me an email. My address is tech Stuff at how stuff Works dot com, or you can drop me a line on Facebook or Twitter. The show's handle at both of those is tech Stuff hs W. And if you want to watch me record a show live, and that includes all the times I make mistakes, and go back and do it again. You can follow me on twitch dot tv. We're tech stuff. They're surprisingly enough, and we will be streaming on Wednesdays and Fridays unless something

changes between now and then, which could happen. But that's all for now, and I'll talk to you again and really soon. For more on this and thousands of other topics, is a stock works dot com