Hackers In The Bazaar Blog

The reading “King of the Ball” shows a side of Linus that is interesting to read about. Kind of Uncomfortable. Here’s someone who just wanted to solve a technical problem, and suddenly he is being asked unnecessary questions in public and at press conferences. The growing pains Linus faced weren’t really about the technology. The real challenge was dealing with people treating him like some kind of king/prophet when all he wanted was to write good code and get feedback. The “I am your God” incident at the Red Hat conference is the perfect example. It was clearly a joke to deflect the embarrassment of a standing ovation, but people dissected those four words and blew it out of proportion. The pressure to always say the right thing can be exhausting.

What struck me the most was how Linus handled success by basically refusing to play the game. He wouldn’t return phone calls, he would let his voicemail fill up. And he made receptionists deal with the journalists that were reaching out to him. That sounds horrible to deal with at first. It makes sense as to why he did this. He wasn’t trying to be rude, he was just protecting the thing that matters the most to him, his time and his work. It’s not about the fame or recognition for Linus. It is about the responsibility to the people using his software. That’s a completely different definition of success than what companies/people think in Silicon Valley. 

Honestly, reading about Linus’s work-life balance issues hit me differently. This capstone project has completely taken over my life. I’ll go for hours where the only people I see are my teammates, and I barely have time to talk to friends at the gym or at dinner. It’s like the project demands every spare moment I have, and before you know it, you’ve become that person who cancels plans because “I really need to finish this motor control code.” This becomes even worse when exam season comes along. When I lock in for a big test, I basically disappear. I’ll hole up in the library or fitpatrick hall for multiple hours, barely eating, just grinding through lectures and practice problems/review material. My friends joke that I go into hibernation mode, but it’s honestly kind of unhealthy. I skip meals, my sleep schedule gets destroyed, and I become a zombie focused on one single thing. It’s effective for the exam, but the cost is pretty high. Reading about Linus rolling out of bed to check email and never leaving his apartment makes me realize this pattern isn’t unique, it’s something engineers fall into when they’re obsessed with solving a problem.

Linux’s success seems like a mix of both the bizarre model and the fortunate circumstances. Yes, the open development model was powerful, where thousands of hackers contributed to creating something better than any closed team could have built. But Linus was also in the right place at the right time. The internet was taking off, people needed a free OS, and there were a lot of restrictions with other OS. If he had started five years earlier or later, would it have worked? As for another success story as big as Linux, the conditions that made Linus possible, the timing, the community, Linus’s specific approach. Overall they are hard to replicate. We might see more successful open source projects but it will be rare and is very unlikely. 

Comparing my own path to Linus’s path reveals that while we share an aspect of high academic drive and a strong focus on logic, the motivations for these feats are different.

Linus’s academic pursuit was internal, as he focused solely on things he found interesting. He stated that “math and physics were interesting, and therefore easy.” If a subject required memorization, then Linus would not care as much. Conversely, my high drive was external, focused on achieving exceptional grades to meet the expectation of attending a school like Notre Dame. While Linus embraced the world of a “nerd” and admitted to having “no social graces whatsoever,” I am far more social, actively disliking loneliness and maintaining a wide network of friends. Despite these social and motivational differences, we share a similar drive for math/logical subjects.

Where did Linus’s spark come from? It came from tinkering with his grandfather’s Commodore VIC-20. This early access quickly progressed to “low-level problem solving,” where he worked directly with machine code and assembly language to feel like he was pushing the limits of this amazing machine and gaining control over every aspect of the machine. He found satisfaction in finding the solution. The long solitary Finnish winters would also keep him concentrated in this effort, making programming something he would do indoors. My own technical foundation, in contrast, was built on the hardware construction aspect. Building my own gaming PC is what ignited my interest in engineering. While I used my computer for entertainment (gaming, music production), Linus used his for purely intellectual exploration, driven by the challenge of creating his own world.

Linus’s decision to create Linux was the ultimate example of scratching a personal itch, really embodying the core of the “Just for Fun” idea. The project began as a small personal effort to write a simple terminal emulator because he hated using the existing one in the Minix operating system. His entire goal was purely private: to learn the hardware of his new PC. The commitment grew organically, as he added features like disk and file system drivers to support his emulator. He kept the first public release at a low version to signal it was just a limited project/hobby and wouldn’t be a big thing. But his endeavor only became more serious when he accidentally destroyed his existing Minix partition, forcing him to make Linux “self-hosting.” This casual approach highlights the core point: open source is powered by engineers choosing to do interesting things, and the success is just an aftermath. Just like Linus’s story, partially his tendency to tackle minor frustrations with technical solutions, like his decision to write his own editor because it was faster than the actual version, is comparable to my own engineering interests. My small project to solve a mundane annoyance, a clap-activated light switch for my room’s lights using a Raspberry Pi and a 5V relay, was born from the same impulse: just for fun. This project directly relates to Linus’s early tinkering and desire for control. Similarly, my current CAPSTONE project building an automatic guitar tuner also utilized a Raspberry Pi, combining my technical skills with a hands-on hardware solution. I would not have been familiar with the Raspberry Pi if it were not for my own curiosity. The biggest innovations come from solving problems with curiosity, and ultimately, just for fun.

Linus Torvalds, unlike billionaire Titans such as Bill Gates, Steve Jobs, or Mark Zuckerberg, represents the pure engineer. He was the “accidental revolutionary” because he prioritized the technical solution that gave users freedom and control, proving the pursuit of a beautiful technical solution is the most powerful force for innovation.

This week’s reading from ESR was very interesting. I think they definitely fall in the same vein in terms of the way he wrote in his previous writings, as well as offering a mix of interesting and insightful analysis. He was giving off the “I’m the coolest hacker in the room” type vibe. But regardless of his style, he posed some interesting notions surrounding why open source is a sustainable model and why people should feel more compelled to contribute to it, which is the core question of this discussion. The debate boils down to two different things: Ego and economics.

One major point ESR made that really stood out was the idea that open source runs on a “gift economy.” We know that there isn’t a massive financial benefit to expect when indulging in open source, so it is often for prestige and glory that people feel inspired to chip into the projects. ESR’s thought here was that this isn’t a bad thing. If people are motivated by glory, that means they are going to be producing better quality products to receive the recognition they desire. I find that the whole ego satisfaction idea is where the fuel comes from, and it’s not bad. As a student, contribution is a huge way to build a resume, establish credibility, and show off your skills. It’s about being seen as a competent person by the community. I view participation in open source as way more than just ego; it’s like a professional apprenticeship and a great way to build a community where you can find a home with others who are as passionate about the same thing as you.

Peer review is important. The whole system, fueled by ego and reputation, is what makes the open source model so enticing. ESR’s core trade-off in The Magic Cauldron is between collecting “rent” from secret bits (the closed source) and gaining “independent peer review” (the open source). When could peer review be classified as better? I think always, when it comes to the quality of the project.

I can relate to the value of independent peer review. Last semester, I was working on a salamander robotics project for an experimental robotics course. The motor control code for the leg was not as efficient as it could be, and I was spending a couple of hours staring at the code, thinking about how I could make it more efficient. I showed this motor control code to my partner, and he took it upon himself to figure out a better algorithm to operate the motors for the spine as well as the legs. That moment was a perfect demonstration of the speed and reliability that open source taps into: “Linus’ Law,” which says, “given enough eyeballs, all bugs are shallow.” If my proprietary project had been a closed system, that robot would not have been able to move at a higher, more efficient speed. And I could have been limiting myself as well as my project’s capabilities. The ability to have those fresh eyes is, in my opinion, a greater form of value than any “rent” a company could collect by keeping that code secret.

Outside of this project, there are rules in the real world. There is strong social pressure against forking projects and removing a person’s name from the credits. These norms seem rigid, but they are actually what protect the magic cauldron. Since reputation is the currency, removing a name is basically stealing money. These norms don’t violate the spirit of freedom; they just put a high social cost on actions that would destroy the collective good of a project.

This is why open source makes business sense, as it leverages these non-monetary incentives to produce a superior product. As ESR argues, the value shifts to the “services instead of software” business model. When software is free, you pay for the support, customization, and reliability around it. This model shows that the open source business model isn’t broken, but has simply evolved to a higher value, focusing on quality and transparency. The cauldron still has power, just mixing/brewing a different kind of valuable product.

Eric S. Raymond’s essay, The Cathedral and the Bazaar, compares two different models of creation. The Cathedral Model is the traditional, corporate style, described as planned, closed-source, and built by “wizards” working in isolation. On the other hand, the Bazaar Model is chaotic, collaborative, and open-source, relying on many people instead of just one master/wizard. I strongly believe the Bazaar model is clearly superior.

The Cathedral model is ultimately focused on the bottom line or requirement. The primary goal isn’t making the absolute best piece of software; it’s just to fulfill a contract and make money. Developers are definitely talented people, but their work is heavily restricted by corporate rules. Having to protect their intellectual property and being pressured to deliver a product that is “good enough” just to meet a schedule means the resulting code will not necessarily be the best version. This pressure and secrecy corrupt pure creative passion. The Cathedral’s process prioritizes the company’s financial interests, rather than the quality of the code that they are generating.

As for the other model, the Bazaar model, it is driven by intrinsic motivation—people just wanting to make cool stuff. Raymond highlights this with his first key rule: “Every good work of software starts by scratching a developer’s personal itch.” People contribute because they generally need a problem solved or want to improve a tool that they use. This drive is similar to what I have experienced in my own class projects. My most successful collaborative project was creating an app for a course on Human-Computer Interaction. It wasn’t a solo genius effort. It was a small-scale, open-source environment with my four other partners. By constantly sharing code and getting outside perspectives from partners and classmates, we were able to develop this application much faster than I could have done alone. That collaborative perspective proved to be essential in this app development.

Raymond explains the reliability and speed of this collaboration directly in his most important principle, the Linus Law: “Given enough eyeballs, all bugs are shallow.” In the Bazaar, developers follow the rule to “release early, release often.” This means that even buggy, incomplete code gets exposed to thousands of people who are motivated and immediately act on debugging as a team. In the closed-source Cathedral, a bug might be hidden for months until it is found. In the open-source Bazaar, that same bug would be found and fixed within days or even hours of release. Going back to crossword puzzles in system programming, I could not find the issue with my code for the life of me, and I spent hours on it. As soon as I shared it with friends and asked for their input, I was able to correct my simple mistakes and complete the assignment on time. If it weren’t for the act of sharing my code, I would not have been able to complete my assignment before the due date. This collective power is why Raymond argues that the closed-source world cannot win an arms race. The Bazaar model is just simpler, faster, and more reliable because it taps into a huge global pool of talent and uses human passion and emotion of satisfaction to its advantage. For the future of serious software innovation, the open, decentralized Bazaar model sounds like the only logical choice.

Preparing for interviews and a full time career after I graduate, there is a direct path that has been laid out before me: continue to get good grades, secure an internship, and land a stable corporate job with a good salary so I can pay off my student loans. It is 100% the safe route, the one that promises a steady climb up a predefined ladder. After reading Paul Graham, and his essays for week 06 reading, and I realize that the path seems incredibly slow. His idea of a startup as a way to “compress your whole working life into a few years” is inspiring but also terrifying. The thought of trading forty years of low-intensity work for four years of maximum effort is a high-stake gamble. But the potential payoff is not just in wealth, but in experience of leadership and ownership. Is it enough to convince people?

The main point of this gamble, as Graham points out, isn’t just about having a great idea, but also about having the stomach to see it through. It is about persistence. Reading his essay on persistence brought me back to my first few months of C programming in Fund. Comp. I remember having a horrible time with Crossword at 2 AM, feeling completely defeated. My morale was shot. But I had to finish the project. So, I met up with a friend of mine and we went over the code, eventually finding the bug in my code. It wasn’t obstinacy; I had to change my approach and my mindset multiple times. Resilience, as Graham defines it, isn’t about blindly pushing forward; it’s about your morale surviving the setbacks so you have the energy to find a new path. That late night struggle with the project is a scene of the startup journey. You will face demoralizing setbacks, and success depends entirely on your ability to bounce back, learn from your failure, and try again. 

Do I find the idea of creating a company frightening? Absolutely. The risk of failure is immense. But the thought of spending my entire career executing someone else’s vision is, in its own way, just as frightening. The “safe” corporate job provides a salary, which Graham defines as payment for your time. A startup on the other hand offers equity or ownership/value. This is the fundamental difference between them. It’s the shift from renting out your time to building an asset that can provide wealth for you in the future. This is how you are meant to generate real wealth. The idea of pouring everything I have into a project for a few years, with potential to build something lasting and retire early is far more appealing than the guarantee of a 40-year career that might not truly be by my own. But what happens if it fails?

If I were to take that risk, where would I place my bet? We tend to think in terms of hardware categories: VR, wearables (Meta Glasses). The “next big thing” isn’t a device; I think it’s going to be intelligence. The future is AI, not the product itself. The greatest opportunities won’t be in building a better smart-fridge, but in creating the AI service that optimizes the entire global food supply chain, a service that just happens to use that smart-fridge as one of millions of data points. The real challenge, and the greatest opportunity for a startup, is to build intelligence that runs on top of it all.

For this week’s reading, Paul Graham’s essays kept highlighting the idea that programming languages are essentially a medium for which programmers think. Throughout high school, I was part of the robotics build and programming team. We worked in Python to program our robot to complete tasks in the games each year. In Python, you can have an idea for a command/script, and you can just write it. If you wanted to store some key-value pairs, you would just create a dictionary, easy as that. I didn’t take any Python classes in high school, but I did take Java and HTML. The language felt very straightforward, trying to help us as programmers get from the tasks that we envisioned our robot doing into reality.

Then I got to university and took Fund. Comp. Suddenly, I was writing in C. And let me tell you, C is not trying to help you. In fact, it feels like it’s actively setting up traps for you to fall into. Forgetting to free your memory? That leads to a memory leak. Crossword was hell. Accessing one element past the end of the array? That will lead to a Segmentation fault. For the first few weeks, I was miserable. Why would anyone choose to use this language, which makes you manually manage every single byte of memory and constantly worry about pointers? Don’t even get me started with pointers. It felt like a massive step backwards in “Power/efficiency”.

But after a while, something clicked. I realized C wasn’t forcing me to think about memory management and pointers just to be difficult; it was forcing me to think about how a computer actually works. That was the point of Fund. Comp. My thoughts shifted from “I need a list of items” to “I need a contiguous block of memory of a certain size, and I need a pointer to its starting address.” This is exactly what Graham meant. I was tackling the same types of problems as in Python, but the language I was using completely changed the mental framework I used to solve them. I was no longer thinking at the level of abstraction, but at the level of the machine.

This is where Graham’s points about Lisp being a “secret weapon” make so much sense. For building Viaweb, thinking in terms of memory addresses would have been a massive disadvantage. They needed a language that allowed for rapid prototyping and high-level abstractions, letting them build features faster than their competition. Their Lisp code was probably more expressive, allowing them to think about the problem of e-commerce, not the problem of memory allocation. The power of a language isn’t just about execution speed; it’s about the speed of thought and development it enables. C is incredibly powerful when you need to write an operating system or a driver, but it would be a terrible choice for a website startup.

I don’t believe that it will be one specific language. C won’t disappear, and neither will Python. Instead, I think it’s the ideas Graham hints at in “The Hundred-Year Language.” The features that will persist are those that give programmers leverage–(AI). The ability to build powerful abstractions, to create mini-languages within the language (like in the Lisp macros), and to choose the right level of thought for the right problem. The future isn’t about finding the one best programming language, but it is about understanding which language lets you think in the most effective and efficient way to handle the task at hand. AI is on the rise and will be the future in coding.

So what really is a Hacker? Their image has been disguised in the ideology of a digital rebel who follows Steven Levy’s “Hacker Ethic.” This is a person who believes that information must be free to everyone who seeks it in the first place. After reading Paul Graham’s essays, we get a new perspective on what these Hackers really look like. Graham’s hacker isn’t really driven by a political agenda, but rather by an obsessive, creative urge for success. This perspective is very similar to Levy’s depiction of a “Hacker” and what a modern creative mind might entail. 

Graham’s most interesting argument specifically from “Hackers & Painters,” where is compares Hackers to painters since they are fundamentally the same to him. Graham writes, “they’re both makers.” This idea is very similar to how I understand what and who “Hackers” really are. Programming anything can/be complicated, and we have been taught that there are steps to writing a program. It is a purely logical exercise, but it can turn into a messy and deeply creative process. You don’t have to follow all the steps to come to a working solution. Although it may take longer, it is about the journey of creating this program the way you envisioned it.  

Both Graham and Levy see creation as a journey that can change along the way. It isn’t a static plan. When working on a coding project, it rarely follows a clean plan that was well thought out. Problems interfere, and the method of attack changes since one angle may be easier to build upon. For example, for the Notre Dame Pokémon game, at first, Melcin and I believed that we would just be able to copy and paste our sprites into the Assembly language files, but we ended up needing a whole new software that would organize the assembly files and display live sprite modification. Very similar to this art aspect of our project, coding in Graham’s eyes should feel more like sketching, laying down a rough idea, and smudging it around, to slowly refine it until it materializes. This focus isn’t on following specific instructions, but rather it is based on creativity to bring something new into the world. 

Creativity is beautiful, but it can also lead to problems. In the passage “the word hacker”, Graham says that the ideal hacker is “unruly”. But this unruliness isn’t just born; it’s created from intense focus on their ideas. Rules and conventional methods are just obstacles that get in the way of solving interesting problems. This connects to his description of nerds in “Why Nerds are Unpopular”. Nerds aren’t unpopular because they fail at the game of social acceptance; They are just unpopular because they are too busy playing a different game. The game of trying to be smart and building things. 

There is a main difference between Graham’s vision and Levy’s vision of a “Hacker.” Levy’s Hacker ethic is a specific idea for a specific community. Graham pushes for a much broader form of intellectual rebellion. Not only focusing on the specific Hacker community, but general society. He urges us to question the “moral fashions” of our time and to actively “train [ourselves] to think unthinkable thoughts.” People are too interested in their iPhones/AI creating content when our human brains were the first to do it in the first place. A true Graham-style hacker doesn’t just question technology; they would question everything (morality, religion, etc).

Graham’s vision of a “Hacker” is something I feel closer to than Levy’s “Hacker.” I don’t eat, breathe, and dream in code, and I don’t feel a burning need to liberate all information. But I do enjoy the creative spark that Graham explains is within a true “Hacker”. The depiction that hackers are just painters is more relatable and more desirable. It highlights that the “Hacker” identity is just about adopting a mindset and being a nerd; it’s about curiosity and creativity. When it comes to class projects or just self-projects, planning/creating the initial designs is my favorite part, because it is the part that I can claim as really my own. (Building it with my own two hands is a close second.)

A reflection on Levy’s Hackers: Heroes of the Computer Revolution. Now focusing on the generation of “game hackers,” relative to the two previous generations: True Hackers and Hardware Hackers. This third generation grew up with personal computers and readily accessible machines in their own bedrooms, which eliminated the need to “Beg, borrow, or steal computer parts.” The game hackers focused on creating games/software to sell in exchange for money. Unlike the previous generations who focused on using the computer as a tool to make tools, the “game hackers” focused on creating “products” for people who owned computers—thanks to the Hardware hackers who wanted to put technology into the hands of the people. 

I believe that this new ideal of selling your hacks as a product for consumers to purchase is a good thing, as hackers who are passionate about creating something benefit from their hard work. People should be rewarded for putting time and effort into a project, as well as gaining credibility for it. After getting my first gaming computer, I was fascinated by games like Minecraft, Hunger Games, and Roblox. What these games have in common is the ability to be creative, as they are sandbox games. Users would create their own Hunger Games maps and mini-games for Roblox. I would spend hours building these Hunger Games maps in Minecraft and even tried to build my own Roblox games (too hard). I dedicated hours to completing these maps because I truly enjoyed the creative process and the idea of making something that other people could play and enjoy. I never got paid, but I was excited to see that I had three downloads.

Ken Williams, on the other hand, entered the world of computers not out of love for the craft, but with the intention of getting rich. His mindset was that success in the marketplace required optimizing for distribution, promotion, and guessing what the public wanted. This ideal was the complete opposite of the first hackers, and it’s where I believe development took a wrong turn. Ken didn’t care for the creative aspect and preferred to hire programmers who would simply complete assigned tasks rather than those who would use their own creativity to create something they envisioned and loved. Unfortunately, in a capitalist world, people will accept these types of jobs, even if they don’t love what they are doing, because of the high pay.

Ken’s methods have certainly affected the industry today. Many mainstream games lack creativity; they are just reboots of last year’s games with new features, often including battle passes that express an interest solely in money. This is why we must continue to respect and give retro games the light of day.

In my opinion, Ken Williams and the ideals of the “game hackers” have harmed the consumer industry when it comes to creativity and the passion for one’s job. However, games that involve creativity and are sandbox-style, like Fortnite and Roblox, have recently been making a comeback. So, despite the industry’s shift toward a more capitalist/game hacker view, people have still made space for those who love to build and create, and the spirit is not completely dead. Hopefully, we will continue to transition back to creating things for the love of telling a story rather than for fame and money.

A reflection on Levy’s Hackers: Heroes of the Computer Revolution. Reading about the adaptation of the “Hardware Hackers” in Northern California, I was able to identify a dramatic shift in philosophy relative to the Original “True Hackers” we spoke about at MIT. These true hackers were protected by an academic environment that solely focused on the purity of the software and systems that they were working on. For comparison, the California Hackers were more politically motivated. They saw the original hackers as “technological Jesuits” who didn’t appreciate the importance of spreading technology to everybody (page 180). The “Hardware hackers” wanted to share this new technology and to allow the possibility of creation into the hands of the common people. This ideology I do support, but there comes a problem when monetization or intellectual property becomes a topic of discussion. 

The launch of the Altair 8800 was a very important movement that supported the Hardware Hacker mentality and Projects like the Community Memory. As a kid who was fascinated with computers and saved up money for almost 3 years in a shoe box to build his own gaming computer, I can tell you that the Altair 8800 got everyone—not just adult geeks/hackers— excited. This computer kit made it possible for anyone to own and build their own computer. With this new access to technology, groups like the Homebrew club formed, and they were able to exhaust their creativity. When I first built my computer, I played games like Fortnite, Minecraft, Wizard 101, Club Penguin, etc. I was also interested in creating music beats like any 12-year-old should. I would hope that Hacker Steve Dompier would be proud of me, as he also got his computer (the Altair) to play music. Although his methods were much more complex, this is a perfect example of using computers as tools of art and expression, not just for computations and number crunching.

As this new hacker ethic spread of creativity and self-empowerment, a strong tension emerged. Wrapping back to intellectual property, the core belief of free flow of information created a huge conflict. This dispute was highlighted in the famous letter of Bill Gates’ “Open Letter to Hobbyists,” in which he argued that the free sharing of his program was not “communal collaboration”, but “ theft” (page 233). Bill Gates’ idea of intellectual property I would stand by because if he does not want to share his original ideas with others without making them pay for it, then that is his prerogative. There is nothing I can say that would change this, but at the same time, I believe that there should be a line to cross before software/intellectual property calls a need for payment. For example, when using Windows to start up a company that requires multiple units, it seems justified to ask for payment. For small cases where individuals are installing software on their own devices/computers, then it should be ok. (idk) 

Overall, the “Hardware Hackers” succeeded in making personal computers available to everyone, but in doing so, they left behind the purity of their (information is) collective dream, forever complicating the Hacker Ethic with a complex debate between what is theft.

A reflection on Levy’s Hackers: Heroes of the Computer Revolution. The idea of what a “true hacker” is a far cry from what most people, myself included, would have thought given the term before reading this piece. Before reading this, I would have thought that a hacker is a mysterious figure in a hoodie (similar to the TV show Mr. Robot) who breaks into corporate networks—an image deeply rooted in this modern, criminal era. However, Levy’s portrayal in Part One of the book redefines what the word “hacker” really means. It’s not necessarily about the crime but actually the mindset of the person, as well as their code of ethics.

According to Levy, a “true hacker” is someone driven by insatiable curiosity and a deep love for the craft of computing, as well as a passion for learning new things. They are titled as pioneers who can see computers not just as tools, but also as a way to express themselves (creatively in games such as Spacewar). It can also be used for intellectual expression. The most important principle highlighted is the Hands-On Imperative, or the belief that access to computers should be unlimited and total. The early hackers at MIT’s Tech Model Railroad Club (TMRC) perfectly express this way of life. They would stay up all night, taking over machines like the TX-0, not because they were told to, but because they needed to explore every possibility that this computer had. This drive is what led to things like program bumping, trying to get a program down to the absolute minimum number of instructions, just for the challenge that it would be for these “hackers.” This is truly the difference between just using a computer and genuinely mastering a computer.

Another quality of a “true hacker” would be their collaborative spirit and belief that all information should be free. The hackers would create programs like the TX-0 music compiler, not to sell them, but to freely distribute them to anyone who wanted to use them. They also saw their creations as part of a collective body of knowledge. This is a huge contrast to today’s world because everything is monetized when it comes to proprietary software and intellectual property. The book highlights the communal nature of their work, like the time a group of hackers worked for a straight weekend on a new assembler, fueled by Chinese food and code. Their acceptance of twelve-year-old Peter Deutsch into their association shows their meritocratic view—if you were knowledgeable and had something to contribute to the cause, there would be nothing opposing you from joining their group. The unexpected discovery of a circle in a display hack, a happy accident with profound implications, is another great example of this open, exploratory mindset that a “true hacker” should have.

My personal reaction to this concept of a “true hacker” is one of inspiration. It’s a mindset I personally would love to emulate. But it is intimidating. The level of determination one should be willing to undergo is a lot. However, this doesn’t mean there is no room for success. As long as you view it in your own fun way, you can overcome this by looking at it in a positive light. This is a powerful reminder that technology should be about creation and exploration, not just consumption. Levy’s description of Bill Gosper’s Ping-Pong style—full of complex, counterintuitive forces and spins—perfectly parallels his hacking style. It shows that a “true hacker” sees the world as a series of intricate systems waiting to be understood and manipulated in their own ways. They find joy in pushing boundaries and solving these problems with their own creativity. Ultimately, being a “true hacker” means living by a set of principles that value curiosity, freedom of information, and the hands-on imperative. I do aspire to be a “true hacker” in this sense. In a world of locked doors, this philosophy feels more relevant than ever. It’s not about becoming a cybercriminal, but about reclaiming what should be for everyone. It’s about reclaiming the word “hacker” to its original meaning—someone who uses their intellect and passion to explore, create, and contribute to projects that will help the human race advance to the unimaginable, just for the love of it.