Skip to content
GitHub Copilot is now available for free. Learn more

Artwork:

What we can learn from vintage computing

Thanks to open source, nothing is ever obsolete.

Klint Finley // December 13, 2022

The ReadME Project amplifies the voices of the open source community: the maintainers, developers, and teams whose contributions move the world forward every day.

The Apple Newton was already old when Morgan Aldridge bought one in 2005. But the pre-iPhone handheld computer that Apple first sold in 1993—and discontinued in 1998—was the best tool for his needs.

“I’d used Palm Pilots, which were still the go-to digital organizers at the time, and I knew they had syncing issues,” he explains. Plus, most other handhelds then on the market used inexpensive RAM memory that would lose data if you lost power, requiring you to restore from desktop backups.

Aldridge’s research led him to the Newton, which used solid-state storage that allowed it to retain data indefinitely, much like modern smartphones. Users reported leaving Newton devices in drawers and closets for years and finding they still had all their data when they finally powered them on. Plus, he found that the Newton community was still actively developing drivers and software for the platform. So he bought a Newton Message Pad that he continued using well into the smartphone era. These days, Aldridge uses an iPad as his primary digital organizer, but he still participates in the community as the maintainer of the NewtonScript resource website and the United Network of Newton Archives.

Thanks to open source, no technology ever has to become obsolete, so long as a community remains to support it. You can sync Newtons and Palm Pilots with modern desktops, download web browsers for long-discontinued operating systems, or connect vintage computers like the Apple IIe to the modern internet via WiFi. Every year, new cartridges are released for old-school video game consoles like the Nintendo Entertainment System and Game Boy.

People keep old software and online platforms alive as well. The Dreamwidth team forked an old version of the early social network LiveJournal's source code and built a community around it. The dial-up bulletin board system software WWIV is still maintained and there are plenty of BBSes still around. Teams are working to restore aspects of early online services like AOL and Prodigy. And you can still use Gopher, the hypertext protocol that was — for a brief period in the early 1990s — bigger than the web.

Developers spend countless hours on these sorts of projects, often with little, if any, hope of financial reward. So why dedicate so much effort keeping these technologies alive, or reviving them, long after they were discontinued by the companies that created them? Nostalgia and the urge to escape today’s often exhausting digital environments are obvious reasons. But there’s more to it than that. Working with vintage technologies is fun, helps developers learn more about computer science, and preserves computing history. And in many cases there are lessons to be learned from the “old ways.”

Interactive history

Historic preservation is one of the most evident benefits of vintage computing. On one hand, software and digital content are among the easiest cultural artifacts to preserve because they can be copied and backed up easily. But the ability to actually run that software can be a challenge as platforms are discontinued.

Emulators have long provided a way to run old software—written for discontinued hardware and operating systems that might be difficult or impossible to find today—on newer platforms. You can play retro games with MAME or RetroArch, manage your contacts with the cult-favorite Lotus Agenda personal information manager in DOSBox, or run old Palm applications in your browser. The open source communities behind these projects endeavor to mimic the necessary hardware and software layers as accurately as possible. Networked software is inherently more difficult to preserve, however, because it relies on not only local software but server-side software as well. In the case of LiveJournal, the back-end code was open source until 2014, so it was easy enough to not only preserve that code but create forks like Dreamwidth. Rather than a centralized service, Gopher is a protocol, much like HTTP, which makes it straightforward to create modern Gopher clients and servers. But some of the biggest and most historically important networked services relied on lost proprietary software running on servers that have been long since scrapped.

Early online services like AOL/Quantumlink, Compuserve, and Prodigy had millions of users at their peak and played host to software, games, artwork, and, of course, countless online discussions. Before the era of the smartphone and ubiquitous internet, these dial-up services provided access to many digital experiences we take for granted today, including online news, weather forecasts, sports scores, stock market quotes, multiplayer games, email, chat—even online encyclopedias.

While screenshots can help document what these services were like, there’s nothing quite like actually navigating through a service’s menu structure and interacting with its various features to understand these services and their place in computing history. 

“When any sizable online service disappears, a piece of our civilization’s cultural fabric goes with it,” journalist and computer historian Benj Edwards wrote in a 2014 article in The Atlantic about efforts to restore lost Prodigy content.

Prodigy is of particular historical interest. At a time when other online services were typically text-based and difficult to use, Prodigy offered a graphical interface and helped pioneer digital advertising, e-commerce, and online travel booking. Long before Amazon, Prodigy enabled you to buy clothes, housewares, electronics, and even groceries online. Prodigy enthusiast Jim Carpenter realized all of this was poorly documented, Edwards explained in his article. Even screenshots of Prodigy were hard to come by. Fortunately, Carpenter discovered that Prodigy stored quite a bit of content in local cache files and he has been able to restore many images from old computers. More recently, a Prodigy demo disk was uploaded to the Internet Archive. This demo doesn’t connect to a server, but you can explore some of the features from your browser.

In 2019, programmer Phillip Heller came across Edwards’s article and decided to get involved with the Prodigy Preservation Project. He wanted to go a bit further than an offline demo and make it possible to actually use Prodigy today. “Benj and Jim felt that re-creating the Prodigy server was a distant and difficult goal,” says Heller. “I thought it sounded like a fun challenge.”

The result is a Prodigy-compatible backend called Prodigy Reloaded. In a demo for The ReadME Project, Heller connected to a Prodigy Reloaded server using an old copy of the Prodigy client running in DOSBox and walked through features such as the news and weather services. Heller populated those features with news headlines and forecasts culled from screenshots, but he hopes to be able to add live news, weather, and stock updates in the future.

Display of vintage computing items, including a Gameboy, tapes, and Commodore CBM

The joys of vintage computing

Heller says that historical preservation is just one reason he built Prodigy Reloaded. “It’s also just a lot of fun,” he says. “It’s like putting together a really tough puzzle, where I have some of the edge pieces but not the middle pieces. I have to use the shapes I have to fill in the rest of the picture.”

Fun and learning are commonly cited reasons for working on these sorts of projects. “I think the biggest reason a lot of us are into retro-computing is that it harkens to an age when you could understand everything the computer was doing,” says Cameron Kaiser, a vintage computing enthusiast who maintains Floodgap, a server and website that hosts one of the most well-known modern Gopher servers, as well as the PowerPC web browser TenFourFox and many other projects.

“Today’s machines are so complex that you could spend the rest of your life understanding them,” says Matthias Melcher, a contributor to the Newton emulator Einstein. “The Newton or the Game Boy are some of the last systems where you can understand the whole thing, from the CPU to the machine code.”

“If you really want to understand computers, first start off with one of the old classic machines,” game developer Rebecca Heineman said on a recent episode of the podcast Corecursive. “When you truly understand the instruction sets, how the stack works, how memory management works, how the hardware works, how it all interacts, then you have a true understanding of the limitations of computers.”

Indeed, many computer science courses use Game Boy documentation to teach microprocessor architecture because its architecture is small and simple enough for students to learn thoroughly. “The Game Boy is a great way to learn assembly and low-level programming with real hardware and real output,” says Antonio Vivace, who leads the open source Game Boy development initiative gbdev. “You learn computer science concepts that are hard to grasp while doing something cool. It makes what otherwise might not be very interesting into something fun.”

The growing complexity of today’s technology extends beyond computing architectures to software and the web. Modern browsers support cryptographic protocols, JavaScript rendering, a variety of multimedia formats, and much more. “It can be hard to understand everything that’s going on in the browser,” says technologist and entrepreneur Jan Kammerath. That’s part of what drew him to the modern Gopher scene.

Gopher first appeared in 1991 and provided an experience similar to a text-based version of the web. Files on a Gopher server could be linked together, or linked to files on other servers. There were even Gopher search engines. It’s difficult to convey how novel all of this was at the time. It was exciting to connect to someone else’s computer, whether that was a dial-up server like a BBS or an FTP server over the internet. It was even more exciting to hop from server to server, following links from one set of files to another, winding up in places you never anticipated. Gopher gave the world the first glimpse of many things we now associate with the web. Anyone, at least in theory, could host their own Gopher server to host whatever content they wanted and other people might find their way to it.

The platform burned brightly for a moment before fading away as HTTP and web browsers became more powerful and popular. But Gopher has managed something of a comeback in recent years. The number of active servers indexed by Kaiser’s Gopher search engine Veronica-2 nearly doubled between 2017 and 2018, from 133 to 260. As of November 15, 2022, the engine indexes 343 gopher servers, slightly down from a peak of 395 in 2020 but still going strong.

Kaiser points to all the challenges of digital life—from cluttered interfaces to the overwhelming crush of information—as reasons that some people are turning to Gopher and other older internet platforms. “A lot of people are looking for alternatives to the modern web, but I don’t think there is any single reason that the number of Gopher servers surged,” Kaiser says. “I think it’s more of a network effect.” In other words, the more Gopher servers there are, the more people use Gopher, and the more people use Gopher, the more people create their own Gopher servers.

Kaiser’s Floodgap Gopher server provides daily news feeds, weather updates, links to other Gopher sites, and the Veronica-2 search engine. Using Floodgap gives a little taste of what the early internet was like. Kammerath was intrigued, but he says he found the experience of browsing “Gopherspace” a little cumbersome by modern standards. “So I thought it would be fun to write my own Gopher client as a little exercise,” he says. The result is Gophie, a simple, cross-platform Gopher client.

“Building a Gopher client, or just studying the protocol, is good for people to learn the basics of how networking works,” Kammerath says. “It’s a lot simpler than HTTP/3, the current version of HTTP, so it’s easier to understand how the different layers interact.”

Working with Gopher, which lacks support for many modern web features like cookies and headers, can also help developers understand why many of those features were added in the first place. “If you spend some time developing with older tools for older platforms, you’ll fall in love with your modern tools all over again,” Kammerath says.

Lessons from the past

Many users find more than just educational benefits in vintage computing. Alridge didn’t buy that Apple Newton in 2005 out of nostalgia or an urge to preserve a part of tech history. He bought it because it better suited his needs than other digital organizers available on the market at the time. Sometimes old tech provides value that contemporary counterparts don’t.

“I don’t run Gopher servers to learn about history, I like Gopher for its own sake,” Kaiser says. “I use it on a daily basis. There are things I can’t do on Gopher, like logging into my bank account. But for a lot of use cases it’s more efficient, like checking the weather and reading the news. And because it’s so simple, I can run a Gopher client on pretty much any device, even old and low-powered computers.”

Vintage tech enthusiasts often discuss how working within the constraints of these older devices forces them to think more about resource efficiency. “The Prodigy developers did so much with so little,” Heller says. “They implemented not one but two virtual machines that could run in less than 640 kilobytes of memory. The mail program is only about five kilobytes. It’s really eye-opening in terms of how much more efficient we could be.”

Today’s hardware is so powerful in comparison that much less attention is paid to optimizing software performance. “There’s a saying: ‘hardware is cheap and programmers are expensive,’” Kaiser says. “I can sympathize with that view. Most of us don’t hand-code assembly today, even though it might be the best way to squeeze more power out of our hardware. It’s a valid trade-off.” But he points out that increasingly powerful computers don’t just lead to the inefficient use of processing power and RAM.

“There’s a tendency to add more and more features and that makes software interfaces busier and harder to use,” he says. “I think users are cognitively overloaded.” That’s a big part of the appeal of Gopher: its text-based interfaces are much simpler than many of today’s web applications.

Hardware performance wasn’t the only thing that kept older applications relatively simple. Older devices were also limited in the sorts of interfaces they could display. “Newton and Palm applications only had small, black and white or grayscale screens to work with,” Melcher says. “Designers had to be thoughtful about what to include.”

Chris Maltby, the creator of the point-and-click Game Boy game maker GB-Studio, points out that games for the original black and white Game Boy games likewise had to work on small screens with simple graphics and sounds, while still being fun. Maltby found lessons there. “Part of my job when building software is about taking these things that are very complex and creating simple ways to interact with them,” he says. “Game Boy programming has made me a better developer.”

About The
ReadME Project

Coding is usually seen as a solitary activity, but it’s actually the world’s largest community effort led by open source maintainers, contributors, and teams. These unsung heroes put in long hours to build software, fix issues, field questions, and manage communities.

The ReadME Project is part of GitHub’s ongoing effort to amplify the voices of the developer community. It’s an evolving space to engage with the community and explore the stories, challenges, technology, and culture that surround the world of open source.

Follow us:

Nominate a developer

Nominate inspiring developers and projects you think we should feature in The ReadME Project.

Support the community

Recognize developers working behind the scenes and help open source projects get the resources they need.

# For Newsletter

Every month we’ll share new articles from The ReadME Project, episodes of The ReadME Podcast, and other great developer content from around the community.

Thank you! for subscribing