In this chapter Linus Torvalds discusses the story of how he and his band of merry programmers released Linux 1.0 to the world and how surprised he is that project interest exploded as quickly as it did. But I’m not sure why he’s surprised, everything Linux has attained is from a developer base that hacked real life as effectively as they hacked together that kernel.

It would have been so fitting for Linus to just declare to the world “Version 1.0 is here. Deal with it.” as he claims, but it was even more fitting for him to sit back and let people much more passionate about the public relations handle things. What a metaphor for open source: when you don’t care, do what you love and let the people with the passion cover for you. Linux was destined to succeed because whether or not you believe that there is a cult of ego in Open Source projects, ego is in check well enough to take advantage of the cool parts of open source: the best people available to do the job will come to do the job, and they’ll be very motivated to do it well. And that attitude extends to interacting with people that exist outside of the existing community. Any project that gets along without developers killing each other is “successful,” but the fact that Linux could make other people care care is what makes it legendary.

Linux didn’t just succeed on the back of smart PR though, there were several properties of the project that made it destined for success. The first was that by their own admission, Linus and Co. never tried to sell Linux. “In that (first) talk, and in every virtually every talk for the next several years, I spoke not so much about the technology but about Open Source.” Linux is a Big Open Source Thing, and once you’ve sold people on Open Source they’re going to at least give Linux a try because its Open Source, but to get there you have to convince people why you care about Open Source software.

When I say that Linux is a Big Open Source Thing, I mean its HUGE. It’s a fully-featured general-purpose operating system. Everyone knows they need an operating system, and even if you don’t notice the major differences, you’ll probably notice something, like what you can and can’t install or what bugs you encounter (but hopefully no bugs). At the same time, the modern OS is just far enough removed from the world of firmware and device drivers that it can actually be delivered in a consistent form to users across multiple generations of hardware (you can even cross architectures with little hassle once you figure out how to write the compiler).

Once you’ve sold people on open source, they might want to liberate their OS, and Linux is the only game in town (almost, I am ignoring the existence of BSD temporarily because it serves my argument).

I think one day another project could succeed in the way Linux has succeeded, but it would have to meet a similar set of prerequisites.

1. It needs to play nicely with others.
2. It needs to associate closely with the open source movement and try and uphold its principles
3. It needs to be big enough in scope that a lot of people are impacted by it.
4. It needs to offer something that no one else does yet.
5. It needs make some people stop talking about Linux

Yeah, you read that last one right. The world only has so much time and energy, which means there can only be so much excitement, and right now Linux has all of it. You can’t be a flagship of Open Source if Linux is already holding the flag. One day maybe there will be enough awesome Open Source things that it becomes a buzzword, something for people to say after “synergy” when they’re making fun of business majors, and and we won’t need to fight so hard for 2 and 5 to be a big deal. But until then Linux has proven that people get excited about you by first getting excited about Open Source.

Today I start reading about the life of Linus Torvalds, the literal creator-god of Linux. The man we’ve all been told we should be like. The firebrand with meme-worthy rants. Which of those sides will we see first? The answer: none of the above. Linus tries to peel away the mystique and tell a real story, and I get to meet two less mythical characters: Kid Linus and Bored Linus.

First off, I like Linus’ reflection on his childhood. While he may have been labeled a nerd, he didn’t fall into the ostracized loner role that most people think comes with the label. While unpopular kids exist in school by definition, I don’t think there are any that fulfill the media stereotype. Everyone has something going for then in primary or secondary school, or at the very least they think they do. But he describes his family history like he’s giving an anecdote on software history (or he wrote it for nerds who read everything like it’s an anecdote about software), highlighting the oddities and big changes. You know you’re a nerd when model trains are too easy of a system for you.

It’s funny that he describes his discovery of computers as a transition away from “regular kid stuff” to spending his time tinkering with his computer and getting angry at anyone who interrupted him. That I can relate to, and I assume anyone who’s ever had a problem that they really loved can relate to it too. There’s that tunnel vision, where nothing matters except completing the problem. The MIT hackers were the same way. Any amount of time was spent. Any tradeoff gets made.
And by the time he starts talking about his investments in computers you know he’s a nerd. He’s learned the architectures, the shortcuts, and exciting features, and he rattles off the good stuff quite efficiently.

Hearing Linus rant about the excitement in recreating games and enhancing his system in high school reminded me of my first years in college. I didn’t make the connection, however, until I heard about the slump his first year of college. Which is about how I end my undergraduate career: unmotivated, hoping for something to come to rekindle the fire, to give purpose for all the skill and training. I really hope that there’s always a mid-career crisis, in between the excitement of the first discoveries and finding the projects of a lifetime (cough cough Linux cough). I’d love to get into something with the same running-start excitement that Linus charged at Unix.

I believe it was Paul Graham who complained that you could never know the metal of a hacker unless you’ve worked with them. I don’t know if that’s true, but I know I have no clue how to evaluate Linus as a hacker. I don’t think that’s the point of this book anyways. What I can tell is that he seems passionate. He genuinely loves computers, he genuinely cares about making them better, and there’s nothing that would stop him from hacking. And that is enough to make him role-model for computing.

Is there more to life than money? Can software developers contribute to these higher values? And is that value lost when the source becomes closed? Eric S. Raymond says yes to all of these questions, and sets out to prove it. But is the difference between Open Source and Closed Source that black and White?

I think ESR is too close to software to see that its simply doing what most crafts do: becoming filled with a wide range of hobbyists. There are those that don’t pay for the job they can do themselves, but plenty of people can’t, or don’t want to do the work of being open source members themselves. And for those people, some things will stay closed.

In his essay, “The Magic Cauldron,” Raymond attempts to explain how the Open Source can produce useful tools and services for no cost, no promise of participation, and an arguably negative economic result. He sets out to prove that Open Source serve different values than the closed source model, and that when you acknowledge those non-monetary values Open Source is truly the way to go. In fact, Raymond wants us to believe that Open Source trumps Closed Source in most situations, due in part to Closed Source is failing to adhere to its own principles.

ESR builds his argument on an interesting framework concerning the value of software. He separates two course classes of value: the sale value is the profit to be made by distributing the software, and the use value is the amount of utility the software serves. He rationalizes Open Source and the Closed Source as serving these values differently. Open Source is obsessed with use value. Developers seek to maximize the amount of utility their product can give them, users who report issues try and make software better suit their needs.

Closed Source, by the nature of its advertisement and sales model, must be all about sale valu, right? Raymond spends a bit too much time digging in to the “contradiction” of this practice, but I don’t think I get it. ESR insists that closed source is this weird mash of hidden software and unmaintainable garbage-for-sale, but I think that he’s undervaluing Closed Source as a smaller inter-corporate open source behind a secure wall.

ESR claims that the “factory model” of closing source makes no sense because for any piece of software that has to be sold, many times more software is written that will never see the outside world. Can that code never be given a use value for developers at the office? Isn’t working on those projects for your peer developers similar to working on open source for the world, just on a smaller scope? While this is obviously less noble than working on something to give to the world for free, doesn’t it make sense to build an ecosystem with use value, that occasionally spits out paying products, which is equivalent to the

ESR also cites an oddity with security by obscurity, but I don’t think that’s the point of closing source, covering up specifications and build systems, or even hiding the amount of user data being processed as feedback. Keeping that information in the dark as a defense mechanism is only good for profits if the customers keep paying. Of course ESR would never stoop so low as to shell out hard cash to be disrespected by a corporate software shill like that.

It isn’t that companies are hiding anything from their users. The users aren’t missing a thing. It’s that the people who pay for the software don’t notice that those features are missing. The price of paid-for software is a tax on laziness. People pay so they don’t have to steal it themselves, or implement it themselves. That’s why programmers don’t buy software. And that’s why there will always be a place for paid software in the world. Not everyone can master computing enough to modify things themselves. There’s never been a craft in the history of mankind that we haven’t hired someone else to do when we’re looking for quality or time-saving.

In “Homesteading and the Noosphere,” Eric S. Raymond discusses his examination of open source culture as a peer game, where participants forgo material desires in favor of reputation. However, this reputation is checked by a caveat: no one who acts egotistically is allowed to acquire reputation, but is this system possible? Is reputation a viable reward when ego is repressed? Or is hackerism a subtle replacement for a different corporate arrangement?

Raymond acknowledges this contradiction early in the essay by saying that “Anyone who watches the busy, tremendously productive world of Internet open-source software for a while is bound to notice an interesting contradiction between what open-source hackers say they believe and the way they actually behave—between the official ideology of the open-source culture and its actual practice.” This isn’t a direct criticism of open source. If someone looks carefully they kind find contradiction in the spoken principles as well. The foundational ideas of hackerism are impossible to try and implement without some contradiction.

I love the idea of hackerism. I’m convinced that I want to be a hacker. But I’m not sure that I understand the rules of the game. Maybe it’s that the rules aren’t as strict as I think, but perhaps there is a way to make the whole system work and I just don’t see it.

If we examine Raymond’s list of taboo behaviors, we start to see elements of the open source that encourage behavior distinct from the open source.

There is strong social pressure against forking projects. It does not happen except under plea of dire necessity, with much public self-justification, and requires a renaming. I find this weird, because Free software was supposed to allow anyone to access/modify at their heart’s content. This makes software much more available to consumers, as limiting the number of forks keeps users from becoming confused, but I feel like open source is restricting itself with a rule like this.

“Distributing changes to a project without the cooperation of the moderators is frowned upon, except in special cases like essentially trivial porting fixes.” This touches on the forking issue again, if others aren’t allowed to start their own  forks, touching other forks willy-nilly is dangerous. I actually like this rule better than the anti-forking policy, because it is essentially a pledge that whatever one does to software that they use, they will not touch something another person depends on without going through channels that should make that person aware of the change with reasonable notice.

“Removing a person’s name from a project history, credits, or maintainer list is absolutely not done without the person’s explicit consent.” This seems fair, everyone should get credit for the work they did, however, it’s hard to dissociate this from trademarking. The contradiction is that open source contributors don’t like to be faceless or replaceable (no one does), but as a result their names attach to things like trademarks.  Keeping your name on a thing you helped make isn’t the same as branding, but its weird for a culture that looks down on ego to be so touchy about giving credit. Perhaps the more proper description of the Hacker stance on ego is no to be ego free, but for everybody to maintain balance with exactly the same amount of ego.

 

Taken together, all of these taboos bear the trappings feel like the open source world has incorporated itself. Is this because some elements associated with corporatization are actually good, or at least inseparable from organized software development?

In “The Cathedral and the Bazaar,” Eric Raymond lays out an examination of the modern open source community. He unpacks its roots, its features, and examines why this apparently disorganized collective of developers works well enough to produce software for free as fast as the billion-dollar industry that has risen around computers and their general use. Raymond makes some insightful observations about what the passion and flexibility of the open source community. It’s clear that the service of dedicated volunteer developers is capable of producing some wonderful things, but I’m concerned that Raymond’s optimism about the modern state of open source overlooks a few corners that will always be held by industry.

There is definitely a power in the willingness of open source developers to commit massive amounts of their time just for the sake of their product. Raymond’s 4th and 5th principles demonstrate this well.
4. If you have the right attitude, interesting problems will find you.
5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
Anybody who wants to work on a project is working on it, and everybody working on a project cares about what they’re doing, because when they don’t want to work on it they leave. Labor is always allocated by zeal, and volunteer hours are as well-used as they can be. This is, in my opinion, the greatest strength and weakness of the open source community. Provided there are enough developer-hours to do the work, it will get done. Of course, if the world’s motley crew of open source developers isn’t at a critical mass, then all the world gets is a generation of arbitrary passion project.

Praise be Linus, today open source seems to be at or around the critical mass. You can get an open source version of almost anything, and most of the exceptions are really low-level hardware-interfacing things

To his credit, I don’t think Raymond wears rose-colored glasses with regards to the capabilities and limitations of open source, his discussion on Mozilla’s slow startup time should make that clear. But I think there are ways that the principles of software development work against the open source community.

Take the first principle, for example: “every good work of software starts by scratching a developer’s personal itch.” Projects receive a massive boost in quality from the dedication of their developers. Products are designed by people who want to use them, who know what features they want, who are serious enough to buy into the idea that they’re trying to make art, whether their project is a web browser or a graphics card driver. Unfortunately, interests can only stretch so far. We have dozens of ambitious hotshots taking a stab at web browsers, shell scripts, and languages/compilers/interpreters, but there is a lot less excitement about building the next great laptop monitor driver. There are millions of little things on that go into the general-purpose operating systems world that slip through the cracks of a persons passions or are so big that they’ve never been effectively started from grassroots.

In this set of essays we read Paul Graham discuss his theory on innovation as a source of wealth, freedom, and perhaps even social good. Does forming a startup really liberate the working hacker? Do startups and their wealth provide social good? Is taking the “reliable way to get rich” consistent with the rest of Graham’s vision as a Hacker?

 

There were two really good points Graham made romanticising startups in “How to make wealth.” The first was the startups are a “reliable way to get rich.” The second was that joining a startup was stating “I want to work faster.” he’s not wrong about startups cutting through red tape, moving faster and producing products at blinding speeds. However, when Graham suggests that hackers naturally tend toward startups, or that startups are the place for all innovation, I’m less convinced that Graham has a consistent vision of a hacker.

 

In earlier essays hackers were people who saw the world differently, and refused to conform with the ideas everyone else seemed to hold. Now this natural nonconformity leads to the world of startups, but is a startup really nonconformist? Or is it a profiteering tool in the business life cycle that Graham discussed a few essays ago? Are hackers really escaping red tape when they join a startup, because for the average developer, the need to cover business ownership in the company actually creates more things to worry about that I would call “un-hacker-like.”

 

Graham’s references to hackers in his previous essays were too broad what he’s always meant to say about hackers is that they’re the perfect startup wiz kids. They’ll produce code at a breakneck pace, implement new features as fast as you ask for them, and look just the right amount of nerdy to convince everyone they’re good at computers. The perfect little venture capital punching bags. Graham’s “hackers” are only artists if producing minimum viable products quickly is an art. And I can’t help but find something sad in that. Graham has so conflated the ideas of “beautiful” and “profitable” that there is no beauty without profit.

 

I hate this implicit belief that nothing in code is beautiful if other people don’t care about it. That’s not how art works. That shouldn’t be all that people who create are measured by and to try and have it both ways: hackers as money machines and creatives, doesn’t work. Yes code that is efficient and readable is beautiful, but that doesn’t mean someone who toils away to piece together an operating system with patchy source code is less of an artist or a hacker.

 

This isn’t the first time Graham and I have disagreed on what makes hackers great. I don’t even think we agree on what makes computers great. But with every cycle it becomes more clear that Graham is married to the cycle of Silicon valley. There is no other game to play, there is no other way to be, and anyone who doesn’t fit in with this profiteering vision doesn’t have a place in Graham’s hackers.

 

Sorry Graham, but I want more. I want a standard of brilliance that isn’t married to the dollar. I want to celebrate hackers for something more than their economic value.

 

“How disgraceful is the lawyer whose dying breath passes while at court, at an advanced age, pleading for unknown litigants and still seeking the approval of ignorant spectators.” (Seneca)

I suppose we couldn’t give Paul Graham his nerd bona-fides if we didn’t hear him voice his opinions on programming languages… three times… if you ran these essays through a plagiarism checker, I’m pretty sure we’d see a strong dependency circle, but at least we know Graham is consistent.

 

Before I actually unpack my feelings on Graham’s feelings about programming languages, I’m still mad about “Why Nerds Are Unpopular,” so I’ll blow off some steam by asking: if nerds (and hackers) are born, then do mindset changes actually matter? Why can’t a non-hacker do the same thing and adopt the hacker mindset?

 

Now that that’s out of my system, let’s talk programming languages. Most people have some idea of what a programming language is, even if that idea is “the spell programmers cast on computers to make them do stuff.” Everyone knows that there is more than one language and if you use the wrong one you’ll be shamed forever. This variety is actually the most cited reason I’ve heard for why people give up learning to code; the weight of figuring out what all of these languages mean and what you want to do in them is harder than actually learning some of these languages. Figuring out how to talk about languages would be great, we could sort this weak pile of labels and get back to using the languages instead of hemming and hawing at them.

 

Graham presents a simple solution to the problem of picking a language: pick the most powerful one and use it. His proof: it is better than all the others because it is the most powerful, anything else would be less effective.

 

Hooray! We did it! We solved the language crisis! Let’s go grab a book for the language with the most power and learn the last language we’ll ever need. Okay, powerful language… power… power, power, power…

 

Power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power, power.

 

Wait, what makes a language powerful? Is it its efficiency in CPU cycles? But if so, what operations are we measuring? Is it some flexibility in its typing system of data paradigm? Is it its ease of learning? Or maybe the brevity of its syntax? Nobody knows the answer to this question. If you go to any forum discussing programming language, you’ll find ample evidence that not everyone is even aware that this is the question they should be answering.

 

To his credit, Graham does offer an opinion on what power is: he belongs to the cult of brevity in source code. “It may not be quite true that the shortest program is the least work to write, but it’s close enough that you’re better off aiming for the solid target of brevity than the fuzzy, nearby one of least work.” It’s not a bad argument, it pairs well with his point on sacrificing CPU cycles to save programmer time. But I have to disagree. Partly because of my own principles, partly because it goes against some of Graham’s own statements.

 

Graham’s best point about languages was the blurb paradox, most programmers are willing to do a less efficient job using a language (tool) that they are familiar with than to take the time learning a new skill. And in that speech Graham says that people should try to rise above this to a acquire a more universally useful tool. Unfortunately, I’m still waiting for that definition of “power” and I don’t think I’ll get it. I contend that there is no single standout language, having a set of tools is necessary to achieve productivity Nirvana. Sorry Graham, you contradict yourself and you’re wrong twice.

 

I think this idea of languages as a perfectible part of programming is an extension of Graham’s vision of hackers as an artist: the medium through which you convey your messages is important, after all. But for me this is a proof of why hacking isn’t an art form the same way, oh, let’s just randomly say painting is. We choose a language for any number of reasons: resource constraints, relationship to past work, fitness with our mentality, but none of them connect to expressing ourselves: it’s always about getting the job done. Programming languages are all tools, they’re for investing effort to generate products, and avoiding other types of effort (if you write esoteric languages, I guess it’s actually about creating more effort, but that’s a different 500-word blog post). If Graham wants beauty brevity, and perfect axioms, I suggest he switch to math, there’d be much less in his way.

I see little sense in the statement “Why don’t people like me? It must be because I’m better than them,” but Paul Graham insists that nerds should come to this conclusion. Graham presents a vision of hackers as people who are inclined, and almost required, to think this thought. Do hackers have to be outcasts? Is intellectualism always part blessing, part curse? If hackers are so different, does that mean not everybody can be a hacker?

 

In his first four essays of “Hackers and Painters,” Paul Graham depicts, in his own, abstract way, a vision Hackers as creators and critical thinkers, who have no fear of what others think and whose creations have a lasting impact in the world. Unfortunately, this view quickly devolves into that of an elitist artisan.

 

Graham opens with his essay “Why Nerds are Unpopular,” in which he asks readers to recall their teenage years in prison… I mean high school… same thing, whatever.

 

Secondary school children frequently divide between popular students, nerds, freaks, athletes, etc. This giant Breakfast Club waiting to happen turns students against each other in an essentially unsupervised competition for social status. Nerds seem to be the outcasts in this arrangement, and there is some speculation as to why. Nerds should be smart enough to play the popularity game, why does the stereotypical high school nerd never win it? Graham Argues that nerds could be popular, but either they threaten the rest of their peers with intellectual superiority, or they’re distracted by other, more academic pursuits.

 

Graham has created a very small box for this group he calls “nerds” and sets up a defeatist ideology trapped by the self-fulfilling prophecy that intellect and friends are mutually exclusive.

 

I’m not a big fan of labels in most cases, but what Graham does here goes too far. He’s created a group he calls nerds that conforms to all his stereotypes: intellectual, socially awkward, with less focus on socialising than the average teenager. These people don’t exist. At the very least, they’re not born, but made in rough approximation when an impressionable youth displays a handful of these traits, even one, and feels pressured to embody them all. If you’re doing a serious social analysis, or at least prescribing a response, then you don’t buy in to harmful labels. Graham is trying to observe the state of young computer scientists growing up, but he’s either misattributing the problem (overseeing the labeling that brings this about) or willfully buying in to the meme that people fit into these boxed stereotypes.

 

What’s worse is this warped understanding that “ in some cases the reason that nerds don’t fit in is that everyone else is crazy.” Graham has come to the unspoken conclusion that all people who don’t display the nerd gene are unfit for interaction with the nerds. Coupled with all the later benefits of intellectualism that Graham cites later (successful individuals claiming to have been nerds and such), nerds have become an exclusive club. Others are mad at this group because they don’t display their special traits (and it’s suggested they never can). “They hate us ‘cause they ain’t us.” nerds purport to say. This unbridgeable gap becomes increasingly problematic as Graham begins to conflate the terms “nerd” and “hacker” in his later essays.

 

In “Hackers and Painters” Graham starts assigning more labels. Makers build things that others can interact with or appreciate. Mathematicians produce abstractions, facts that can be built on but never seen, and are more isolated than others. Hackers are software makers, they produce code that has an inherent, observable “beauty” to it. I’m willing to believe that beautiful code exists. At the very least we’ve all seen code that we’d call “ugly.” But I also think we could all list some ways to avoid code that is ugly, does that mean anyone can write code that is beautiful?

 

While I don’t love the ambiguity surrounding the word beauty, I can accept how this statement touches on Levy’s Hacker Ethos. Hackers take a heightened pride in their work, seeking to produce something that doesn’t “just work.” While this analogs well to Levy’s “instruction bumming” culture at MIT, but not every one of Levy’s HAckers were obsessed with small, pretty code. Sometimes they swung axes, punch cards, and soldering irons at a machine until they got some new feature to emerge. And isn’t the running program the part that others can appreciate? Like any art, the nature of its creation is of interest, but the general public is much more attracted to the finished project, right?

 

I also don’t love Graham’s skepticism on research, either. He describes academia as a system that pressures participants into targeting simple changes that produce good-looking graphs. I’ll admit there exists research that does that (it’s how I survived in undergraduate research), but I feel like there are people who work towards an end with their research. Maybe research can happen industrially, but so does software development. If hackers developing software can rise from the industrial mire, then can’t people become hackers by doing beauty focused research in an original way? Graham will tell you: it’s because almost all true Hackers are working on startups.

 

Graham describes the race of startups with a simple give and take between companies of different sizes. Large monolithic corporations are familiar and entrenched in public minds, they have an easy time sticking around in established markets. However, (Graham thinks) product managers are stupid and make it harder and more time consuming to produce good software, so a small company with focus and less management overhead can beat large competitors to a new market like Davids landing a focused blow on Goliath. And thus the software company life cycle is complete, with large, stationary companies buying ideas being outpaced by startups on the fringes of the industry, the most successful of which become larger, slower companies, either buying faster companies to grow or being bought themselves.

 

Graham’s background makes this kind of obvious, but this essay affirms his belief that start-ups are the only source of new ideas.Everyone else is a sellout, a 9-5-er, a cog in a machine that’s way too big. If a hacker exists at one of these places, then it’s because they hack on their own time. If you don’t have the right job then you can’t do Graham’s “cool” labor and you’ll never be cool enough to be a Hacker.

 

It’s too bad, because I like Graham’s vision of a hacker as “someone who can make a computer do what he wants -whether the computer wants to or not.” I like the idea that hackers have taken computing from a droll occupation or an iterative science and made it into an art. A place for creatives to builds things that speak to non-experts. These tenants were the core of Levy’s philosophy that I found so attractive. How can Graham and I purport to love the same ideas in ways that make us so different?

Video games are art. Fight me on it. The most exciting moment in reading this entire book came when I read about how Roberta and Ken Williams got the Apple II to play adventures games. Beauty itself. The start of a movement. Why’d everything fall downhill from there?

 

The Williamses, and the entire fledgling game industry, started as the hacker ethic personified in software. Here we got pure hobbyists, passionately grinding away hours to do things that no one had ever done with computers, squeezing every last bit of performance out of these machines. These people were real software hackers, not the exclusionists of MIT, sitting behind closed doors and pointing fingers at the “losers.” The game hackers were pushing towards personal goals, teaching each other the secret ways that make these pieces of art. Finally, we had an example of how computer programmers could be the kind of good (not just in skill, but socially impactfully good) that the hardware hackers were doing.

 

Unfortunately we never got a software Woz. Most of the stars of the industry turned sell outs. Ken Williams became particularly divergent, turning his company, Sierra Online, into a profiteering, copy-protecting machine (and a silicon valley casting of The Wolf of Wall Street). Individual game programmers could make a fortune off the royalties of a best-selling game. These single coders became like authors: individually seeking success in the form of money in the most uncooperative-unhacker display possible.

 

Computers are finally entering the homes of all Americans. Not only is there now an affordable mode of computing available in the form of many personal computing machines, but the software was being written so solidly that non-programmers can use them without worrying about corner cases or writing their own updates. Computers were finally becoming something for everyone, just the way the evangelical hackers wanted. Unfortunately, the convenience comes at a cost. Making computers more readily available to non-programmers meant that software has to be made available too, and so we have a demand for proprietary software grow into almost a necessity. Computers made their way to everyone, but they weren’t machines for hackers anymore. Historically open source would reach a low point as computers became more equipped for people who didn’t know anything about them: the sheep for the proprietary shepherds.

 

Every conversation any of us have ever had with someone who didn’t understand computers started because of this. I love computers, I think everyone’s lives could be improved by them and I think everyone deserve to have access to these wonderful machines. But reading about the change to hackerism and the video game age makes me wonders if my vision of a computer that everyone can access and have mastery of is even possible. It seems that more mainstream computers become, the less magical they are, the less potential they exercise.

 

The first game companies really suck the luster out of computing. All of them rose up from individual talent seated in front of their terminals to become browbeating trolls, forcing distributors to negotiate their way. Maybe Online, Sirius, and Broderbund aren’t entirely to blame, they were just a few companies with something to prove doing what any community of hackers do, just with more resources. And besides, Atari was doing worse for to them.

 

For the first time, the problem wasn’t copying code, it was re-implementing a program on a new machine. Software was dodging above hardware, and ideas had somehow transcended software. At this point companies stopped being interested in software and started caring about something else, the money, intellectual property, whatever, and hackerism stopped working. I hated reading these pages because they started to look like a reflection of the modern world, and every change seems to make it harder to be a hacker.

Can computers change people’s lives for the better? Can hackers act “heroic?” Can computer science be something more than a job or means to its own end? Steven Levy seems to think all of these things, as do the 1970s Hardware Hackers of Northern California.

I hope computers, and the people who use them, can present a social value. If they can’t then there really isn’t any point to them, and we’re all just playing with calculators too difficult for the average human to use. I want to believe that computers and computer science can improve lives, that there’s some point to all of those lines of code I curse at in a dark room at 2:00AM. Maybe it’s just wishful thinking, maybe I need the field I chose to be special because I chose it, but I think computers changed my life for the better, and could do that for someone else. These chapters resonated with me because the Hardware Hackers are trying to prove the mantra of computers for everyone that I want to believe in. And they’re good at it.

When Levy presented his Hacker Ethos, Levy states that “Computers can change your life for the better,” and it isn’t until this section that an argument for this has been depicted. The MIT hackers were closed-off from society, they treated their code as a pure art form, and while they developed several improvements to the way software is written and computers can be used, MIT Hackerism never produced anything that a non-hacker would find significant. Levy immediately presents Lee Felsenstein, an electronics wizard who used his tools to advance activist movements. He very expressly sets out to put his electronics craft to use producing and maintaining tools for demonstrators. As incidental as Felsenstein’s technical skills may be to his activism, this is certainly the closest Levy has come to demonstrating the sixth point of his ethos since he introduced it over 100 pages ago.

An even more obvious example of computers impacting lives comes when Felsenstein, and later Efrem Lipkin, become members of Common Memory, a group that existed to build public interest and knowledge on computers. While Common Memory is not a force to be reckoned with when developing computer applications (the strongest technology demonstrated is a flexowriter that can do high school math problems), it represents a different take on the Hacker Ethos, less competitive, more focused on sharing information.

 

The truly strong demonstrations of computers changing lives come to with the Homebrew hackers’ club. This groups of hackers works with electronics to build machines that are, by nature of their origin, much more suited to individual ownership than the massive counting machines that software clubs have been playing with up to this point.

We see the first microcomputers developed, allowing computers to approach the tools of the people that the Hacker Ethos attempts to display.

Again, it’s striking how much more collaborative the California Hardware hackers are, both with each other and with other people. I’m left to wonder if this is a property of this hacking club that distinguishes it from MIT hackers, or a consequence of the need for physical pieces. The network necessary to acquire components (a complete knowledge of all the parts that have to be bought and them disposed of before the hackers can get them).

After enjoying the romanticism of the hardware hackers, reading Bill Gates’ open letter to the Free Software people made me kind of angry. That he could say Free Software is “unsustainable” or claim it isn’t capable of investing the time and effort to complete a large project. “What hobbyist can put 3 years into his product… and then distribute it for free.” I think that attitude that we need proprietary software is kind of lame. Yes, if you build a product, and want to secure it so other people can’t distribute it and change it and then sell it, then go ahead. But if hobbyists need a thing, they make it. Then they share it, so it gets better. In my limited time in computing I have found computer nerds for every level of system hierarchy and free projects for every piece of software on my computer above the firmware (and a long list of reasons that the firmware can’t be written).  To be honest I’m always surprised to hear the horror stories of how Open Source came close to dying. It was hacker ethics that pushed computers into the hands of the general public, and a big enough group of hackers (and the Homebrew hub proves that hacking groups can become big). I’ll admit that paid products will always be able to find a place in the time/space tradeoff, but the Free Software people are willing to do it on their own. They don’t need anyone else to hack and improve world-altering code.