jkim56cse40842

I have a friend who aspires to be an actor. To pursue his dreams, he dropped out halfway into college and started working in small theatre productions around New York City. Today, he spends his days acting a semi-major role in a small play in NYC while auditioning for something bigger.

Whenever we have a chance to talk, we end up spending our time talking about his audition process. To date, he has had hundreds of auditions for roles large and small, but he has yet to be casted for anything significant. And even though he is a very optimistic person, the years of preparing for auditions – and failing to be casted – has started taking a toll. One day, in his frustration, he asked me in tears, “Am I just not talented enough? Or is this just not for me? I just don’t know what I’m doing wrong.”

Seeing his despair has taught me, once again, that success is not always fair. People often say that success is a product of one’s hard work alone. But if hard work was all it took, my friend would have already found success – he works harder than anyone I’ve ever met. And yet, no matter how hard he tries, no matter how much he prepares, no matter how many auditions he has, he always seems to fall short of making it big. So success must be a product of hard work AND a stroke of luck. That’s the only explanation for people like my friend – those who work so hard, and yet never seem to find that success.

So in light of Linus and his success with Linux, I also believe his success was found by a stroke of luck. Because even though Linus worked hard to make Linux what it is today, I’m sure there have been many other people who tried to do something similar that never found similar success. No matter how long they toiled over their similar projects, we will never know about them. We will never hear about them. And we will never be able to recognize their efforts because they didn’t find success and Linus did.

Ultimately, the point that I’m trying to make is that some people are luckier than others. We all work hard for similar things, but only few get that stroke of luck you need to make it all the way. Put another way, life is not fair. But, hey, what’s new?

—

Right now, across the world, there are tons of people who are working on open source projects, vying to be the next Linus. Though we cannot see it, they are investing tons of their time and money into these projects, with the hope that it will eventually be their ticket to success. But the fact is that only a rare few of these open source projects will ever be known to us – the rest will be buried in the overwhelming number of projects released every year. So will there ever be another open source success story as big as Linux? Yes, there will. But let’s not forget that there will be thousands of open source failure stories for every one success story.

I love this book (so far). It’s written so well: it’s the perfect combination of self-deprecating humor and quirky personal anecdotes. Just from reading, I can tell Linus is a down-to-earth guy. I’d love to meet him one day. I just know he’s the kind of guy you’ll start having a conversation with at a bar and actually enjoy talking to.

What I like most about Linus is how relatable he is. To begin, our childhoods look very similar: we both hated physical education (gym), we both loved junk foods (although I’m a Sprite guy, not a Coke guy), we both had narrow interests in math and physics during high school, and our charms for the ladies were rock bottom.

Moreover, he had the same attitude toward computers and technologies as I did: “I don’t even remember where I got really into computers at all. It started slowly, and it grew on me.” Like Linus, I also don’t even remember why or where my interest into computers really started. One day, I just found myself hunched over an Arduino I bought for $5 at a yard sale; a few weeks later, I found myself using the Arduino to power a car made out of Legos. I guess that’s when everything started.

—

Though I found Torvalds’ upbringing relatable, I’m not sure what that that has to do with his creation of Linux. His childhood is the childhood of every geek that has ever lived, but not every geek created something as revolutionary as Linux. To try to correlate a geeky upbringing with the creation of Linux, I think, is insulting to Torvalds’ determination and hard work.

Moreover, there are many important figures in computer science that never even touched a computer until much later in their lives. These people (though I can’t exactly remember who they are) serve as living evidence that you don’t need an upbringing surrounded by computers, as Linus did, to have as much influence as Linus did. In short, upbringing is irrelevant to what you make of yourself.

—

I think there are many similarities with Linus Torvalds and Gates/Jobs. The most obvious similarity is that all three gentlemen tinkered with computer parts and calculators as young kids – while other kids went outside to play, Torvalds/Gates/Jobs stayed inside to learn about computers. Another similarity is that they all had interests in math and physics, though Jobs was well known to be interested in philosophy as well.

But I don’t think we should make much of what these three gentlemen have in common. People often try to find similarities between successful people and imitate their similarities in the hopes of becoming successful too. But while there is some value to that, I think that there is only one true common trait that makes someone successful: determination and drive. There is nothing more important. You can live your entire life modeled after Bill Gates or Steve Jobs, but without their resolve and drive, you won’t ever be able to replicate their success. The greatest common denominator between these men and other visionaries is their drive.

—

What do I wish my story to be?

Hmm. That’s a thinker. I’m not 100% sure yet.

What I am sure of is that I want to have impact. The good kind.

I don’t think I’ll be satisfied with having an ordinary day job that just makes a ton of money.

Instead, I hope my future-self is someone that works to bring good into the world. Someone that makes peoples’ lives easier, better, and happier.

How will I do that?

We’ll see…

At a high level, open source doesn’t make ANY business sense: if an open source developer creates something wonderful and magnificent, businesses have an incentive to steal it, make it slightly better, and sell it at a profit. Therefore, businesses win and open source developers lose; in the long run, open source has no hope.

And yet, open source is still very much alive and well. At this very moment, there are open source developers out there putting time and energy into projects, knowing fully well that they’ll never make a dime from what they’re doing. To be sure, there are some open source projects funded by generous donors and philanthropists, but the vast majority of projects aren’t. This means that open source developers are doing something that doesn’t make ANY business sense – they’re working for free.

—

I think that open source developers and the work they do is really important for two reasons:

First, they are the living evidence that our world is not just inhabited by selfish, money-grubbing individuals, but also filled with good people who care about other people. This is really assuring – can you imagine how depressing it would be if our world was full of purely selfish individuals?

Second, and perhaps more importantly, open source developers continue to drive innovation. Businesses are hardly ever at the forefront of innovation because corporate structure often suffocates independent thinking – a critical ingredient for innovation. On the other hand, open source developers are literally “open” to pursue any idea they have in mind, which gives them an edge in innovation. It is through their insight and innovation that our corporations continue to be successful.

In order to keep the important open source community alive and well, we need to support them. And I use “support” in all sense of the word: monetarily and otherwise.

For starters, we need to bankroll important open source projects. One example of an important open source project (in my opinion) is the Mozilla Firefox browser project – a project that supports a browser which does not have the tracking and data harvesting as other browsers do. If we monetarily support this open source project, we can be assured the browser will stick around for the long term and continue to carry out its important mission. Financial contributions do not have to be in in large quantities either – many small donations equal a large donation.

We also need to support open source communities by making our own contributions. In other words, anybody who can contribute technically should do their part to do so. This doesn’t necessarily have to be in the form of hard coding something entirely new; it can be as simple as checking for bugs or cleaning up the code.

—

I believe in the magic of open source. I believe in the magic cauldron. The source of that magic lies in the good will of people who genuinely wish to help others. And as long as that spirit never dies, I believe the magic cauldron will continue to produce the nourishing food of good software (cheesy).

Eric S. Raymond (a.k.a. ESR) says that people are driven to contribute to open source because they want to look good in front of others; that people contribute to something only for the praise that follows. And this makes sense: the open source community often showers dedicated contributors with compliments and gratitude. So it’s easy to see how the contributors are there for the praise.

But even so, what ESR says cannot be 100% true. If it was, think of how depressing that would be? To think that no one in this world ever contributes to something out of genuine dedication but out of a thirst for compliments – what an awful, sad world to be a part of.

Fortunately, ESR is wrong – partly. While there are those of us who only ever contribute to something to collect compliments, I also believe there are those of us who contribute to something simply because they want to. Think of all those contributors who never reveal their true identities and choose to work through aliases. It is clear that these individuals aren’t peddling for compliments, but rather working to further the cause of the open source project they are contributing to. These individuals would prove ESR wrong.

Contributions don’t always come in the form of lines of code, either. Indeed, monetary contributions are often just as important as coding contributions. And there are many wealthy individuals who patronize open source projects as anonymous donors. It is clear these people aren’t using their wealth to further their name, but rather working (through monetary contributions) to further the cause of the open source project they are literally contributing to. These individuals would also prove ESR wrong.

That doesn’t mean that contributing to open source projects (either monetarily or through lines of code) is for everyone, however. Not everyone who knows how to code *must* partake in an open source project – right? We all have our reasons for not contributing to open source. Here are my reasons why:

To begin, I just feel like I’m not “good” enough to contribute. Have you ever worked on a group project where everyone else knows exactly what he or she is doing, and you’re the only one confused and totally lost? I do. And it’s times like these where I often wonder if my “helping” is actually just holding the group back or serving as a distraction. So when I think of contributing to an open source project, where there are active contributors who are infinitely better at coding than I am, I feel helpless in trying to discern where I can help. Even if I want to contribute, my fear of being inferior holds me back.

Another reason why I don’t contribute to open source projects is because I don’t even know where to start. Because I’ve never been a part of an open source project, just thinking about how to go about communicating with the project leaders, editing the code, etc. is scary. I’d much rather not go through any of that to contribute than to do so. Moreover, I’ll often find interesting open source projects that look finished. In other words, I’ll find these projects where there seems to be nothing else that I can do to contribute. It’s like when you buy a piece of furniture pre-assembled, as opposed to furniture in parts from Ikea – if it’s pre-assembled, there’s nothing for you to do because it’s already done for you.

With that said, I hope I will one day contribute to an open source project. But that won’t happen anytime soon because 1) I don’t feel confident in my coding abilities, and 2) I don’t even know where to start. So in the meantime, I’m just going to keep learning. Maybe that’ll get me somewhere. Or not.

There are two different models of software development: the cathedral model and the bazaar model. Of the two, the cathedral model is the more conservative: software development happens within an exclusive circle of a select few engineers, and the source code is released to the public only after the work is finished. On the other hand, the bazaar model to software development is much more open: it allows the source code of any work-in-progress to be open to the Internet, handing the public a role in the direction of the ultimate project.

There are pros and cons to both models of software development. With the cathedral model, limiting outside exposure to work-in-progress effectively limits distractions and removes the potential for third-party errors. Moreover, the cathedral model of software development often feels more fulfilling because the work that you’ve done is really yours – no one else helped you across the finish line. However, the cathedral model also makes no room for a third opinion. This lack of a third opinion can deprive software developers of novel ideas and prevent them from getting real time feedback on their work.

But the downsides to the cathedral model are the upsides to the bazaar model. Under the bazaar model, the source code is posted online and hundreds of thousands of different people can provide useful real time feedback. This means that not only will the original software developers gain an exposure to ideas that could not have come within the inner circle, but also provide them with a support group of hundreds of thousands of people that can help review/edit their source code. In short, the bazaar model is a real life application of the adage: two heads are better than one.

This isn’t to absolve the bazaar model of its shortcomings. One downside with the bazaar model is that the work you’ve done is no longer really yours. It’s the work of hundreds of thousands, maybe even millions, of people combined! While that sounds like an incredible feat of mankind, the original software developers may lose a sense of accomplishment or fulfillment in their work because it is no longer exclusively their own. Furthermore, with the bazaar model comes the potential for errors that happen when you entrust your work to strangers. For example, Wikipedia is a powerful resource made possible because it is “open source,” but we also know that Wikipedia is not always the most accurate source of information precisely because it is “open source”. Likewise, the bazaar model of software development is arguably only as useful as the people who contribute to the project.

Historically speaking, the cathedral model has been the more popular model for software development among firms. And this makes sense: the exclusive nature of the method would protect the trade secrets and the innovation that lead to profits. But with time, some people began to consider the exclusive nature of the cathedral model as harmful to what should have been a cooperative environment for software development. These people believed that the best software development comes about when good ideas are bounced off each another in an open space – the core foundation on which the bazaar model stands. As a result, various individuals and firms began to implement a bazaar model in their software development, even as other refused to follow. Today, the environment is largely a heterogeneous mix – there are those “open source” environments for software development, but there are still those exclusive clubs for software development. This begs the question – is there a better model of the two, after all?

It is difficult to know for sure. As discussed, both models of software development have their upsides and downsides. But if I had to choose one, I would argue that the bazaar method of software development is better. This is for the simple fact that the bazaar method harnesses the potential of many different people, whereas the cathedral method relies on the potential of a few. I am a firm believer that more diversity is better – it brings new perspective that ultimately leads to a better outcome. While the cathedral method has its upsides, I am afraid that it is far too conservative and narrow in scope to compete with the more diverse and open-minded bazaar method. But the greatest feature of the bazaar method is that millions of people will be helping you to debug your code! No one wants to debug something all alone – and the bazaar method says you don’t have to!

Paul Graham is right to encourage young people to start or join a startup. Entrepreneurs have always led the innovation that drives our society forward. Without these trailblazers, our society would have no future – just an indefinite present.

But while I agree with the message, I am also against Graham’s motive to advance it. When he says, “If you [want] to get rich… your best bet would be to start or join a startup…” he pushes the unhealthy view that entrepreneurship is the fast lane to wealth. That isn’t necessarily true – the chances of success are slim, if not rare – but even if it was, is this the right way to promote starting or joining a startup? Should we be telling young people that if you want to get rich, start or join a startup? Is this what our society has come down to? Is that what we’ve become? Is being filthy rich the ideal we wish to push on our children?

I don’t believe that all entrepreneurs are money-grubbing, materialistic folk. Many of them start or join a startup because they truly believe that their idea will better the world and make it more efficient. But when Graham promotes his view that entrepreneurship is the fast lane to success, he NOT ONLY perverts the honorable intentions of these virtuous entrepreneurs BUT HE ALSO damages the crop of new, aspiring entrepreneurs by perverting their intentions from a noble cause to that of greed.

Moreover, Graham’s view of entrepreneurship is unhealthy in the sense that it promotes the idea that working for somewhere other than a startup – be it a big corporation or the government – is somehow inferior. When he says, “if a fairly good hacker is worth $80,000 a year at a big company, then a smart hacker working very hard without any corporate bullshit to slow him down should be able to do work worth about $3 million a year,” he is basically telling everyone not working for a startup that they’re doing something wrong.

But why is that wrong? If I don’t have a startup idea to change the world, does it make me stupid to not join a startup anyway? If I prefer the structured work environment at a big company over the loose structure of a startup, should I have to disregard my preferences to work at a startup anyway? And if I need the financial security of a big company to feed my large family, as opposed to the unpredictable compensation at a startup, should I risk it all and work at a startup anyway? Perhaps more importantly, who is Paul Graham to tell these individuals that their life choices are somehow “not smart” or “inferior?”

I find it repulsive that these entrepreneur-turned-millionaires think they’ve earned an inkling of credibility in their massive wealth to tell people what to do and not do. There is nothing that makes you different from everyone else other than the number of zeroes in your bank balance. So why should we have to  listen someone who isn’t any different from us?

Paul Graham is right about one thing – we are materialistic creatures. The poor want to be wealthy, but even the wealthy want to become wealthier; hence our society’s worship of uber-wealthy individuals. But what Paul Graham fails to recognize is that, for many of us, wealth and materialism is not the sole purpose in life. For many of us, there are values and virtues we uphold higher than dollar bills and checks. None of us would say “no” to a free yacht, but we wouldn’t take it if it meant sacrificing those values and virtues.

Along the same line of reasoning, I don’t think everyone would rush to start or join a startup even if it meant a (slim) chance at making millions of dollars. We all have our unique circumstances – a sick family member, children to take care of, a rocky marriage, mental health issues, etc. – that may make starting or joining a startup inappropriate. But unlike Paul Graham, I DO NOT think that choosing to work for a non-startup is, in anyway, inferior to working for one. Because if that was the best decision for you, why should anything else matter? Fuck what he (and everyone else) tells you.

In The Hundred-Year Language, Paul Graham describes the world of programming languages as an evolutionary tree: just as some animal species survive while others go extinct, some languages will continue to remain relevant and applicable while others will grow out of fashion. Graham goes on to say that it is in the best interest of modern programmers to think beyond the languages of today and position themselves for the languages of the future: instead of thinking about how we can program something in Python or Java, we should be thinking about how a new language might solve our problem more effectively. Ultimately, Graham’s view is that the goal of every skilled programmer should be to position themselves on the right “branch” of the programming language evolutionary tree – and NOT bet on a language that might go extinct in the near term.

—

Mr. Graham raises some great points, and his discussion about what future programming languages might look like – flattened data structures, irrelevant data types – was an interesting read. But I don’t agree with his overall view that programmers should work with a language just for its longevity and potential for long-term relevancy.

This understanding that you should always strive to learn the “latest” or the most “hip” language promotes an unhealthy “arms race” view of programming – this idea that the better your programming language, the better programmer you’ll be. And I’m not going to say that this view is completely wrong – we all know that working with a fast and convenient language can make our lives so much easier and make us more productive. But this view of programming is dangerous in that it easily undermines the work that you can do in other, more older languages.

To me, it shouldn’t have to matter what language you work in. Anyone can create something beautiful in any programming language, no matter what that language is. Just because you program something in Crystal or another “hip” language doesn’t mean that your program is automatically cool and amazing. On the other hand, just because you programmed something in Perl or another obsolete language, doesn’t mean that that program inherently lame.

I think as programmers, we should always the value the work that is done – regardless of the language. The programmers before our time did not have the fast and efficient tools that we had – such as Crystal or Swift – but they were still able to do so much with what they had to create the world of programming as we know it today. And even if their work became obsolete or other programmers came up with something better, does that mean we should discount the influence of their work? Should we disregard the impact their work had on the trajectory of computer science?

When Paul Graham describes the world of programming as an evolutionary tree, he makes one fatal flaw: he only sees the languages, in and of themselves. Under this view, it’s easy to take lightly the languages that have since become irrelevant or forgotten because other languages survived while they were forgotten. But when we see the evolutionary tree, the better way to understand it is to realize that all of those languages have, in some way or form, contributed to the world of programming that we know today. Not every single language has had the equal level of influence – some, like Java and C, have had considerably more influence and continue to do so today. But that shouldn’t discredit the other languages. The work that was done through those languages have become the brick and cement by which our world has been constructed. We should respect these languages and understand that there is always value in a tool, even if it has been replaced.

Paul Graham and Steven Levy have very different views on what it means to be a hacker. While they do agree on a few select points, these are rare; much of their views are diametrically opposed to one another —

Steven Levy envisioned hackers to be the modern equivalent of the medieval hero, Robin Hood. Just as Robin Hood stole from wealthy aristocrats and shared the loot among commoners, Steven Levy imagined hackers as the tech-savvy deviants who stole information and knowledge from the privileged few and spread it among the many. Levy believed that this was not only the moral duty of the hacker, but also the characteristic of one – someone who would stop at nothing to break down and pick the locks of any barrier that served to block the flow of information.

Steven Levy also believed that in order for a hacker to effectively promote decentralization of information, they must first “learn about the systems by taking things apart, seeing how they work, and using this knowledge to create new and even more interesting things” (Levy, 28) – also known as the Hands-On Imperative. Levy considered this capacity, above all, as the prime standard by which hackers ought to judge one another; instead of judging one another by trivial things like skin color, education, or gender, Levy said that it was best to judge one another by the ability to hack.

But Paul Graham couldn’t feel more differently. To begin, Graham believed that a hacker was someone who created new things by simply “making tweaks to something that already exists, or to combine existing ideas in a slightly in a new way” (Graham, Hackers and Painters). This means that in the eyes of Graham, if a hacker assembled something different from the pieces that were given to him, that alone would suffice as a ‘hack’. But Steven Levy would fiercely object to that view. He argued that a hacker is someone who takes everything apart to first develop a comprehensive understanding of the system, which could later be used to invent new things. So Levy would say that a true hacker is someone who breaks down the given pieces, and create something new from the fragments — only then would it suffice as a ‘hack.’

But there’s more. Paul Graham believed that hackers “need to understand the theory of computation about as much as painters need to understand paint chemistry” (Graham, Hackers and Painters). In other words, Graham considered a thorough investigation of the tools available to hackers as frivolous and impractical. This, again, would have been fiercely opposed by Levy, who argued that hackers require a fundamental understanding of the tools they are handed so that they can best the system and make a better one.

And then there’s still more. Steven Levy believed that the primary goal for hackers should be to promote the decentralization of information as to help ordinary people become hackers themselves. But Paul Graham thinks that role of hackers should be to create easy-to-use software that would simplify the computer for the average user: “Programs should be written for people to read, and only incidentally for machines to execute” (Graham, Hackers and Painters). In other words, Graham is not concerned with trying to teach people the intricacies of his software as much as he is concerned with having them use it. But Levy would strongly object to any dumb-ing down of technology and criticize it as a form of obstacle that centralizes the very knowledge that hackers ought to help disseminate.

But even if they seem at complete odds with one another, Levy and Graham still agree on one thing: you can create art and beauty on a computer. Indeed, Graham goes to great lengths to describe why ‘hacking’ and coding, in general, is no different from drawing on a canvas or painting on an easel. And similarly, Levy believed that even within a few lines of code, you can find beauty – especially if you turn an ugly mess of a code into something short, simple, and clever.

—

I’m not sure what to make of these two opposing views on what it means to be a hacker. For starters, I couldn’t relate at all to Steven Levy’s view of hackers. In his hackers: heroes of the computer revolution, he makes hackers sound like these superheroes who go around making the world a better place by making “information” and “knowledge” accessible. And while that’s a noble cause, I don’t know if I could spend all of my time working for such a purpose. Moreover, I don’t like Levy’s binary view that you’re either a hacker or you aren’t: if you have some interest other than ‘hacking’ – whether that be cycling, reading, or just spending time with family(!) – you’re not devoting all your time to ‘hacking’ and therefore you’re not cut out to be a true hacker. And I just can’t relate to that.

At the same time, I don’t find myself completely aligned with Paul Graham’s view of what it means to be a hacker, either. While I agree with Graham’s view that a hacker shouldn’t have to understand everything there is to know about the theory of computing, I don’t think that the knowledge found in abstract theory is complete garbage. I believe there is some value to such theory, though the degree of which is subjective to the individual.

Furthermore, I disagree with Paul Graham where he writes that “Most makers make things for a human audience” (Graham, Hackers and Painters). Here, Graham seems to imply that the greatest value a hacker can extract from his or her craft is by making things for others – be it software, hardware, or just a simple design. But I disagree with that view. While many of the things that hackers produce tend to be useful for others, that doesn’t mean these things *have* to be made with the purpose of being useful for others. Sometimes, it’s okay to hack and create cool things just for yourself and your own satisfaction.

Ultimately, I find myself more confused than I was when this class first started. What really constitutes a hacker? I really have no clue. Or maybe I do, but then I can’t seem to express it in words. It’s weird. But you know what, I don’t think I really care. That’s because I’m fine with who I am and the hacker that I am. I may never follow in the exact footsteps of the ideal hacker as outlined by Steven Levy. And I probably will never turn out to be the painter-esque hacker that Paul Graham envisioned, either. But who cares? Why should we concern ourselves with trivial labels? Here’s a crazy thought: let’s not.

The third part of Steven Levy’s Hackers: Heroes of the Computer Revolution discusses a new generation of hackers, the so-called “game hackers” or “hotshot programmers,” who seem to have dropped the baton of the Hacker Ethic as it got transferred from the previous generation. Whereas the Hacker Ethic placed importance on the freedom of information and widespread access to computers, the 3^rd generation of hackers were more concerned with developing trade secrets – and guarding them with their life – to develop marketable technology that could, put bluntly, make them filthy rich. Moreover, the once-cherished Hacker Ethic principle that hackers should be judged by the basis of their hacking abilities – not by their race, age, sex, or position in society – was no more: hackers were judged on their ability to make a higher profit margin than they were on their ability to develop remarkable technology.

To be fair, the Hacker Ethic was somewhat already diminished even before the 3^rd generation of “game hackers” entered the fray. We should not forget that when the “Hardware Hackers” began to develop, and ultimately sell, technology for the masses, this came at the cost of some of the core values outlined in the Hacker Ethic: that all information should be free, and that access to technology should be available to everyone in an unlimited fashion. So in the context of the “Hardware Hackers,” it can be argued that the next generation of “hotshot programmers” only took it one step further.

But even though both generations of hackers were indifferent towards the Hacker Ethic, there is still a critical difference to be noticed as we go from one generation of hackers to the next. While the “Hardware Hackers” diminished the relevance of the Hacker Ethic as they turned to marketing and commercializing their technology, they still had the Hacker Ethic in mind. Yes, profit margins were important, but they were still less important than the collaborative, innovative environment that brought hackers together. In short, while the “Hardware Hackers” were concerned with making money, they were also brought together by their love for the technology that they were building.

But we see a startling, disturbing shift with the “hotshot programmers.” In the next era of hackers, we begin to see the once-collaborative hacker environment replaced with cutthroat competition and an obsolete Hacker Ethic. These “hot shot programmers” are no longer concerned with those trivial Hacker Ethic principles of making information available to all in an unlimited fashion. Yes, they made technology cheaper and available to the masses – but none of the people using this technology actually knew how they worked! That is a 180-degree turn away from the founders of the Hacker Ethic who believed that it was important for everyone to pick things apart and learn more about the technology they were using. The original hackers believed it was necessary to be skeptical and curious, but the “hotshot programmers” made all of that unnecessary by giving their customers a piece of technology that required no understanding of the inner workings. Moreover, the public had no means of modifying or improving the technology they were given because they had no understanding of it to begin with.

This brings to the forefront the central question that Steven Levy raises: “Did you really benefit from your computer if you did not program it?”

This question is a difficult question to answer because it depends on your perspective. For some people, the answer is obviously “yes.” Even if they didn’t “program” the technology itself, that doesn’t stop them from being able to use what the technology was capable of: type documents, access information portals, play games, etc. To these people, unconcerned with learning how their technology worked as long as they could use it for their own purposes, Steven Levy’s question is irrelevant.

But there are others who would argue differently. People who understand how technology works, and people who know that by understanding technology we can individually make improvements to further it, would claim that it is a tragedy that technology has been commercialized to people who are limited in their capacity to use it because they don’t know how to. These are the kinds of people who still revere and try to adhere to the original Hacker Ethic: those values that say we should stay forever skeptical and curious to learn as much as we can about the technology that surrounds us.

The real tragedy is that there is no right answer. On one hand, how can we criticize people for being indifferent towards learning how their technology actually works, if they are fully satisfied in using the technology in a limited capacity? If these people are happy with just being able to do the basic things: type documents, access information portals, play games, etc., who are we to judge them as fools or imbeciles? Yet on the other hand, those of us who still believe in the principles of the Hacker Ethic are right as well: as technology became commercialized, the need to understand technology has diminished. This has placed an unintentional dam on the flow of intellectual curiosity and innovation.

Ultimately, I think Steven Levy’s question is a rhetorical one because there is no right answer. Rather, the question serves to demonstrate both the tragedy and the societal benefit of the commercialization of technology.

In the ancient times, literacy – the ability to read and write – was not a basic right or skill but a privilege. If you came from a poorer household or from a lower socioeconomic background, it was not only certain that you’d never learn how to read or write, but also heretical for you to wish otherwise. On the other hand, nobles and aristocrats were not only expected to be literate, but also exceptional literary scholars of their time. It makes sense, then, that most of the manuscripts, essays, and other classics we have left from the ancient times were written by wealthy individuals of their time.

But all of this privilege began to unravel starting around the 4^th century – Catholic priests and monks wandered from town to town, educating ordinary people how to read and copy the Bible, and literacy rates skyrocketed all over Europe. To be sure, their efforts were met with serious disdain from the elites – they argued that the commoners were “damaging” the delicate art of literature with their ignorance. Nevertheless, the priests and monks persisted and ultimately succeeded in transferring the skill of literacy in the hands of the few to the many.

—

The history of world literacy may seem irrelevant in the context of hackers: the heroes of the computer revolution, but there is significant overlap in both stories. To me, the True Hackers reprise the role of the aristocrats of ancient times who sought to preserve their literacy within their inner circle: sitting on their holier-than-thou Hacker Ethic, the True Hackers never cared to extend their rare access to expensive technology to the average Joe – rather, they reveled in their privilege. On the other hand, the Hardware Hackers are much like those priests who sought to break down the barrier of literacy in spite of the criticism: even as they were framed by fellow hackers as materialistic, money-grubbing capitalists, there is no doubt that Hardware Hackers altered the path of history for the better as ordinary people got access to something that, otherwise, would have been delayed indefinitely.

—

What’s most ironic about the True Hackers and the Hacker Ethic they held to their hearts is that they claimed to fight for equality – that access to computers and anything that might teach you something about the way the world works should be unlimited, and that hackers should mistrust authority, promote decentralization. But the fact is, none of these True Hackers ever fought for that level of access or decentralization of information. Perhaps they were clouded by their privilege, but the fact is they failed to recognize that ordinary people just didn’t have the same opportunities that they had. And instead of acting to enact change, these True Hackers sat on their high pedestals and dumped their Hacker Ethic on ordinary people – as if they could understand the credo without the same resources. It’s hard not to see the similarity in their behavior with that of Mary Antoinette’s, when she infamously said “Let them eat cake” to the French peasantry that had no food to eat while she engaged in gluttony.

On the other hand, the Hardware Hackers recognized that while the Hacker Ethic promotes equality and unlimited access to information, there isn’t any incentive for a True Hacker to actually go out and do so – and so the Hardware Hackers took it upon themselves. With trial and error, pioneers of this new venture eventually brought the computer from the hands of the few to the many, just like those priests and monks of ancient times did with literacy. To be fair, these individuals also became filthy rich. But why is that so wrong? If society always criticizes those who become rich by providing innovative solutions to problems that desperately needs solutions, how will our society ever move forward?

Nevertheless, critics of this capitalistic endeavor will say that by pushing the computer into the marketplace, the original Hacker Ethic-esque values were diminished: that instead of using the computer to “create art and beauty,” these computers were being used for quite literally the opposite – facilitating the development of weapons of destruction. But that ignores the fact that, as computers were brought to the marketplace, millions upon millions of people had access to a level of technology to do things that they never were possible.

Ultimately, the debate that is to be had is a repetition of the ancient Aristotelian debate of the greater good – is it better to give everyone the same resources, even if it comes at the cost of possible abuse of the resources? Or is it just better to limit the resources to the few? But as Aristotle often said, there is never a perfect answer to the question of the greater good – it only leans in one direction. So, when we weigh the pros and cons of what the Hardware Hackers have done for us, I hope it leans in the direction of good.