Skip to content
Featured Article

Artwork: Susan Haejin Lee

What we can learn from “_why”, the long lost open source developer

What happens when your impact outlives your code.

Klint Finley // October 14, 2021

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

Let’s face it: programming books aren’t usually much fun. Informative? Yes. Engaging? Sure. Some authors liven up their books with funny examples or witty asides, but the fun part is usually applying the knowledge found within a book, not its content. 

why's (poignant) Guide to Ruby is different. It's chock-full of comic strips, strange digressions, and seemingly off-topic sidebars. Cartoon foxes offer peanut-gallery style commentary to the text. A strip about an elf and his pet ham provide increasingly strange problems for code examples. As the guide unfolds, the book's prose plays off the strips, and vice versa, until the author writes himself in, disguised as a rabbit, and bounds off the page. Needless to say, it's an unusual way to write a book about computer programming. But it's anything but boring.

The (poignant) Guide was written by the pseudonymous programmer, artist, and musician known as “_why the lucky stiff,” a prolific member of the Ruby community during the programming languages explosive growth in the 00s. _why brought his eccentric humor and sense of adventure to everything he did, mixing his art into programming and his programming into his art. For example, his keynote at RailsConf 2006 featured musical interludes with his band The Thirsty Cups and a guest interview about pudding.

“_why is our Picasso, or perhaps Dali,” says Software Architect Eleanor McHugh. “He would write beautiful code, code written just because it could be done, rather than to solve a particular problem. He wrote code because it was fun, and the code was justified by its own existence.”

For a few years, it seemed like _why was everywhere: blogs, mailing lists, Twitter, GitHub, and the conference circuit. Then on August 19, 2009 he was gone.

For a few years, it seemed like _why was everywhere: blogs, mailing lists, Twitter, GitHub, and the conference circuit. Then on August 19, 2009 he was gone.

He deleted his website, his social media profiles, and his GitHub account along with all the projects he had created. Apart from a brief return in 2013 to publish a series of characteristically strange documents, he has stayed gone and made it clear he doesn't want to be contacted.

He never explained exactly why he committed what some call “infocide,” but his 2013 writings (collected under the name Closure) provide some hints. _why wrote about reading the complete works of Franz Kafka. “I was done. I was decimated. To program any more was pointless. My programs would never live as long as The Trial. A computer will never live as long as The Trial.” But, tellingly, _why also noted that most of Kafka's works were published posthumously and that he'd asked his friend Max Brod to burn his manuscripts.

“Seems weird he didn't burn them himself,” _why wrote. “Tuberculosis doesn't stop you from burning paper, right? A thousand pages. Two thousand pages. Maybe three thousand pages. That's a lot, but I think he could have done it, even alone, even with tuberculosis.”

_why concluded: “Of course he didn't want them burned.”

Kafka did successfully burn most of his manuscripts, but if _why's goal was, paradoxically, to preserve his work by burning it, he was successful. After he disappeared, new maintainers stepped in to steward almost all of _why's projects, giving them each new homes. Had _why’s work been proprietary, it could have disappeared almost entirely. But because it was open source, _why’s own personal Max Brods were able to not only restore his work, but build and continue it.

Many of these projects—including Try Ruby, Hackety Hack, and Shoes—were maintained by the community long after _why's disappearance. Though it's not clear how much of _why's original code remains. “It's definitely a Ship of Theseus question,” says Matt Zmuda, a Software Engineer at GitHub. “Is it still his work if all of the original code has been replaced?” Had _why simply handed off his projects to new maintainers instead of taking a torch to his code, his actual code and all its lovely quirks might have been forgotten. Instead, it lives on even as others have rebuilt his work.

But _why's impact extended far beyond the code he wrote. He helped popularize the Ruby language in the early 00s, pioneered new ways of building web applications, and inspired countless people to learn to code.

“Ruby was still such a small niche thing in the early 00s,” Geoffrey Grosenbach, Director of Product Education Engineering at HashiCorp. “When I first heard about Ruby in 99 or 2000, it seemed like an academic thing, not something you'd use in the real world. Rails was important in popularizing Ruby, but _why was important as well because he made the language seem approachable and fun and gave a character to Ruby that was different from other programming languages at the time.”

“_why had a profound effect on people like me who were still early in our careers when he was active,” Zmuda. “Ruby was the first language I fell in love with and it meant a lot to me that _why was a Rubyist.”



Though the Ruby on Rails framework was nearly synonymous with the Ruby programming language in the mid-to-late 00s, _why wasn't a big user of Rails. Instead, he built a quirky framework of his own called Camping.

_why first released Camping in January 2006. It's a microframework that takes the notion of “micro” to the extreme: it consists of a single 3.9KB file. Like so much of what _why did, Camping appeared to be part joke, part proof-of-concept, and part serious engineering effort. Compressing a workable framework into such a small amount of code required clever and strange tricks. “When you started a Camping project, you’d give it a name. The framework would then run a search and replace to implement that name across the codebase,” Grosenbach says. “It’s the sort of approach no one else would think of, at least not at scale. But it worked.”

“Camping looks like the sort of thing that only someone programming for the art of it would create,” McHugh says. “_why’s code was full of interesting flourishes that I think are essentially jokes. He would write things in odd ways that you might not expect to work. That the code does work is part of the joke. It's hard to explain, it's just a feeling, but it makes me happy to see. There's not typically a lot of humor in codebases.”


And yet McHugh found Camping surprisingly practical. Camping forced her to keep her applications small, which had the benefit of making them easy to understand. “That's important in a commercial project, because other people can't maintain your code if they can't understand it,” she says.

Ultimately, Camping wasn't widely used. But it did provide the inspiration for another framework: Sinatra, which is now the second most widely used Ruby framework after Rails according to the JetBrains Developer Ecosystem 2021 survey.

Blake Mizerany began Sinatra while working for the music player company Songbird in 2006. “We were working on an API, and it didn't quite fit into the Rails paradigm,” he says. So he and his team decided to create a new framework to support their work that was more flexible and lightweight. “I wanted to take Camping a little further, but not so far that it became as big as Rails,” he explains.

McHugh, a Sinatra user herself, describes it as “a really polite and sensible metaprogrammed answer to the chaos inside Camping. A version of Camping for real-world applications.”

The rise of microservices in recent years helped bring microframeworks into the mainstream. Fittingly, Flask—the most popular Python framework by a narrow margin, according to the JetBrains survey—began as an April Fool's prank parodying both Camping and the late Aaron Swartz's Python framework before becoming a serious project.

Like so much of what _why did, Camping appeared to be part joke, part proof-of-concept, and part serious engineering effort.

why_inline 3

Code literacy

_why's technical contributions were influential, but they aren’t his biggest impact.  His advocacy for teaching people of all ages to learn to program is perhaps his greatest legacy. 

In a widely read blog post from 2003, _why lamented the state of programming education. He pointed to the days when PCs shipped from the factory with BASIC interpreters that enabled users to get started writing useful, or at least fun, code right out of the box. 

“In the 1980s, you could look up from your Commodore 64, hours after purchasing it, with a glossy feeling of empowerment, achieved by the pattern of notes spewing from the speaker grille in an endless loop,” he wrote. “You were part of the movement to help machines sing! You were a programmer!” 

But the PCs and gaming consoles of the early 00s required considerably more effort to learn to program, he wrote. Before you could get started you needed to set up your development environment. If you wanted to program for the web, you needed to learn not just JavaScript but HTML and CSS as well—and worry about the different ways web browsers render pages.

To help remedy the situation, _why created an interactive Ruby tutorial called Try Ruby that enabled you to write and run Ruby from within a browser. Today it's not uncommon to see similar sites—Codecademy for example provides students with interactive, in-browser shells for several different languages. But in the era before cloud-based IDEs, _why’s tutorial was a revelation. “This was before Homebrew, when getting a programming environment setup was more painful,” Grosenbach says. “_why had to hack the Ruby interpreter pretty extensively to get it to work.” 

And then there was why's (poignant) Guide to Ruby, which demonstrated that programming education didn't have to be dry. “People who want to learn Ruby should read the pickaxe book,” McHugh says. “But they should also read why's Guide. It provides you with a different way of looking at code, looking at problems.”

_why showed veteran coders and n00bs alike a curious, adventurous, and creative side of programming.

For _why, code literacy wasn't about training the next wave of professional developers. “It was about sharing something he was passionate about,” Zmuda says. “It was about this journey of exploration, not about making money.”

Perhaps most importantly, he taught countless people the joy of programming. _why showed veteran coders and n00bs alike a curious, adventurous, and creative side of programming. He demonstrated that code could be more than just a form of technical problem solving: it could be a form of self-expression and of art.

“His attitude was 'just look at this wonderful world of programming,'” Mizerany says. “You don't need to be a computer science or math major going through years and years of schooling. This is just a fun activity, you can do a little bit of it or a lot of it. It's interesting and worth checking out.”


Comics by _why the lucky stiff from _why's (poignant) Guide to Ruby are licensed by CC BY-SA 2.5

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.