King of the Ball

Before Linus was “King of the Ball”, he experienced many challenges, changes and pains. Given how plugged in Linus was leading up to the Linux Version 1.0 launch, the coordinating efforts and user research were tackled through constant attention and work. Before the Version 1.0 release, Linus had to add components and fix bugs as they were discovered by users, which was essentially a full time job. Following the launch of Linux Version 1.0, Linus was excited because that meant he could stop fixing bugs for awhile and focus on development and other aspects of life. Another major growing pain Linus experienced in the early days of Linux was porting it to other machines and ensuring compatibility considering some of the earliest attempts encountered problems. To solve this problem, the first real port of Linux utilized an abstraction layer so that the same code got compiled in two different ways to work on two different architectures. Besides technical growing pains, Linus encountered some legal growing pains taking the form of a trademark dispute in 1995. To solve this problem, Linus embraced the “benevolent dictator” status and simply gave his blessing to others to take care of the problem as they saw fit. Yet another new frontier was that of public speaking. As Linux grew in popularity, Linus was invited to give talks and promote Linux, yet he was not a big fan of public speaking. Rather than stress out about how to explain what was so great about Linux, he solved the problem by mainly talking about open source and its benefits.

Linus seems to paint the people of Silicon Valley as constantly working and obsessing about money (while trying to push their ‘world-changing’ agendas). Linus was counter-cultural as he thoroughly valued sleep, claiming any lost time to sleeping was more than accounted from the increased productivity gained by being well-rested. In addition, he did not subscribe to the idea that he needed to continue working when he went home. While Linus claimed Steve Jobs was interested in his own goals and the marketing side of the tech industry, Linus was much more interested in the technical side though he not really care about Mac and preferred to focus on Linux. On a more philosophical level, Linus differed from Bill Joy who believed that every technical advance resulted in people losing some of their humanity, while Linus believed that stagnating, rather than evolving, was the worst thing for humanity.

In terms of how Linus dealt with success, it seems he almost believed Linux was destined to succeed though he said that others with a more realistic understanding would likely have disagreed. Success in Linus’ mind certainly depended on the success of Linux in some capacity, but the success of open source was ultimately more important. I think that Linux’s success provided at least one main product to help open source gain recognition and momentum. For Linus, his success seemed to recognize his success all at once rather than gradually coming to the understanding. For him he mainly continued living his life, generally in the same frugal manner, until he truly became a celebrity. He realized that open source was gaining popularity as Informix and Oracle ported their databases to Linux and Netscape opening up their source code for its browser as Mozilla. Eventually, with the success of Linux and Linus’ stock options, he came into big money and could suddenly afford whatever he wanted. While he certainly enjoyed having this newly found money, he was never really about the money (considering he once turned down an offer of ~10 million dollars from a London startup because he preferred to work on what he wanted to do). In general, Linus dealt with success in the way he dealt with most of his life: he just accepted it and focused on what interested him. For example, in 1999, he and his wife were invited to the Finnish President’s Ball, the biggest event in Finnish high society, where him and his wife were declared the king and queen of the ball. Despite the honor of this, Linus basically could not have cared less.

Looking at Linux’s success, I think it is proof of the power of hackers in the bazaar rather than a matter of fortunate circumstances. The success of Linux likely would not have happened without the passion and grit of Linus and the other open source developers collectively contribution to the complete of it. In general, I think that people are drawn to passionate people. By having projects as open source, I think that it provides a means of enabling other interested parties to connect and work together to pursue a solution. As Linus mentioned earlier, the emails and support of people before the Linux Version 1.0 launch were a huge motivating factor to finish Linux, rather than just give up. With this in mind, I think the synergy resulting from open source and group work has the power to produce useful and impressive results, to which Linux is a testament.

Birth of a Nerd / OS

Reading about Linus Torvalds’s childhood and upbringing, his childhood seems similar to many kids, despite having its differences. Linus recalls his bad taste in clothes, but notes that this was typical of the majority of kids growing up. Comparing my upbringing to Linus’s upbringing, it seems more different than similar. I’m sure if I looked back at pictures of me growing up, I would see how bad my taste in clothes was (besides when my mom chose something for me to wear on holidays). Another similarity would be my interest in math and computers, but Linus certainly would classify me as one of the kids that played and lost his mind in games rather than trying to learn how the computer actually worked. Despite my interest in math and computers, I was interested in many other subjects (sometimes even subjects that involved rote memorization, which Linus despised). Another point of difference was that outside of school, I played multiple sports and loved meeting with friends, while Linus seemed to little interest in sports and others. Growing up, Linus said that his mother claimed he was generally a low maintenance child as long as he had his computer and some food. For me, there were certainly times while growing up that my parents would tell me to read or go play outside rather than just let play on the computer / watch tv for a long time. It seems that Linus’s early exposure to his grandfather’s old electronic calculator was one of his first influences towards hackerdom. This interest in technology continued when his grandfather got a computer when Linus was 11. Linus’s shy nature and lack of social graces seemed to lead to him having few close friends, giving him more alone time to mess around with the computer and learn how it worked. Reflecting on Linus’s experiences, I think that hackerdom is product of nature and nurture. It seems that he had a nature inclination for math and notes that technology was often adopted early in Finland. Moreover, Linus’s mother and “Morfar” appear to have been enablers, allowing him to foster his interest in computers. Had Linus been raised in another part of the world with less readily available access to computers and other technology, I am not sure he would have become the hacker many people know him as today.

The “Birth of an Operating System” suggests that Linus was driven to create his own operating system out of a cross between some of ESR’s principles and some personal “need.” The developed started with Linus scratching a personal itch as he was writing some programming tools for himself and continued when found certain software, such as the operating system of his Sinclair QL and some drivers, did not work quite how he wanted it to. He also seemed to philosophically disagree with certain characteristics of the QL such as it having a read-only memory. Another significant factor driving Linus to create his own operating system was the ‘life changing’ book “Operating Systems: Design and implementation” by Andrew Tanenbaum. Moreover, Linus’s experience with the Unix and its fundamental ideals and simplicity further inspired him. Given his one email that simply asked people for features they would like to see in an OS since he was working on one, but that claimed it would never be portable or a big thing, I do not think Linus saw the project as more than just a project. Once people told him he could raise money from donations for Linux (to help pay off his 3rd computer) and constantly emailed him with encouragement and suggestions, I think he started to see the potential of the project. The final factor pushing him to complete the development of Linux when when he accidentally destroyed his Minix partition and had to either pursue the project entirely or reinstall Minix. At this point, it seems Linus began considering Linux as a serious endeavor, with the people emailing him and growing popularity of Linux serving as motivation to continue the project with the possibility of the Version 1.0 in the foreseeable future.

Having worked with automation last summer, I think it is fascinating to see what can be achieved with automated processes and to what degree of success the automated task can achieve. When considering a problem/project to tackle, I think it would be interesting to tackle something that lets me apply automation principles in a field that I do not have much experience so as to provide the opportunity to learn something else simultaneously. With my imminent college graduation and financial independence in mind, I think it would be fun to create some sort of stock ticker / investment assistant thing in an effort to learn more about finances and plan accordingly.

The Noosphere

Exploring ESR’s analysis of the open source culture and customs, it seems there are a couple different underlying motives that drive people to participate in open source. For some participants the zealot mentality inspires them to the develop useful tools that are alternative options to commercial software. Besides these zealots, ESR identifies the pragmatists who did not necessarily adhere to a strict ideology, but rather values having good tools and toys. When partaking in open source development, at least at first, it seems uncommon for people to have a personal relationship with the other individuals working on the project. However, by making valuable contributions, one can become ingrained within the community. I think this seems somewhat similar to working at a company as good performance can help people increase their reputation. The idea of the reputation incentive is one ESR firmly believes in. He states that one’s reputation can be critical in providing a social context within the hacking community, possibly even becoming one’s primary motive. More specifically, ESR claims that peer repute is a motivator for a few different reasons. To start, peer reputation can be a primary reward. In addition, it can be a way to attract attention and cooperation form others. Finally, despite the open source community being a gift community, high reputation can have benefits outside the open source community and lead to higher status in an exchange economy or a command hierarchy. While maximizing reputation is a pursuit of the open source community, there is also a commitment to ensuring that peer credit, both good and bad, goes where it is due and does not go where it is not due.

Based on my experience, I would say this portrayal seems accurate. For instance, GitHub tracks how active you have been in the last year and what projects you have contributed to. Similarly, particular projects track how much and what each individual contributor has done, maintaining the entire log of commits. Moreover, you can check the particular commits of users to see exactly what they contributed. This can enable to users to be evaluated by their peers for the quality of their work. Looking at the reasons for pursuing such peer repute, ESR’s three reasons also seem accurate. For instance, when applying for a job, it is common for the application to include a spot for an applicant’s GitHub profile and sometimes even mention in the job description that a “nice to have” is open source experience.

Considering open source history, I think ESR’s list of taboos is true. When I first started computer science and was dabbling, no one had ever mentioned these taboos to me, but they seem almost natural. To me, these taboos seem in line with the spirit of open source. I think the strong social pressure against forking projects is the only taboo that is potentially questionable. The second and third points both seem to revolve around protecting the reputation of the open source contributors. If the spirit of open source has peer repute as an essential motivator, it seems only right that individuals receive credit for the work they do and do not receive credit for the work they do not do. Trying to distribute changes to a project without the cooperation of the moderators being frowned upon seems reasonable because if the change does not align with the moderator’s view and could affect the moderator’s reputation, then this principle seems to be about protecting the reputation of the moderator. The strong social pressure against forking seems more relevant in the event that the project would overtake the original and possibly splinter the user base. If an individual is just playing around with the code and wants to perform some minor changes for themselves, then I do not think this is a serious taboo. If the changes could truly benefit the project for many users, perhaps the user should be trying to get their changes incorporated into the original project.

In a way, I think that the mechanisms and motivations of the gift economy are appealing. I view this as similar to working at a company in a more formal setting. Status and repute can be motivators for some people, but for others they are primarily interested in the work they are doing. I have heard of people that have turned down promotions to continue working on the same team or in the same capacity on work they enjoy rather than the increased status (and probably money) that would come with the new role. I am sure for some people that participation in open source can serve as a means of “ego satisfaction”, but I think a main reason for partaking in open source is that it can be the opportunity to work on something cool that might not be possible at their 9-5. For me, I think I would be more enticed to participate based on the open source project itself rather than the possibility of peer repute. However, within the environment of a corporate playground, I think the potential for peer repute and other benefits would play a larger role than just the project/team I am working on though is not to sure I would not care about the work I am doing.

The Bazaar

ESR’s account of hackerdom seems to be more of the same when compared to previous accounts from Levy and Graham. The “hackers” of Christmas past typically came from other engineering or physics backgrounds and were drawn to computers by fun. Building and playing with software was something they found entertaining. Early individuals loved achieving the absolute efficiency with programs and resource utilization. ESR recognizes the “real programmer” culture associated with batch computing and acknowledges that this mostly gave way to the rise of interactive computing and the evolution of today’s open-source hacker culture. Levy’s hackers were big fans of lock picking and obtaining resources in whatever way to further their learning and cause. Similarly, ESR mentions that DARPA seemed to turn a blind eye to all the “unauthorized” activity, viewing it as a small price to pay in order to attract many bright young people into the emerging computing field.

In terms of software development, ESR describes two main models: the cathedral and the bazaar. The cathedral model revolves around small numbers of programmers working in isolation (generally following some waterfall methodology), adhering to some user specs that are likely misguided or flawed in some way. These people work for 1-2 years and then release the project, generally with patches for months that follow. While this seems be the reality of the cathedral model, I have not had the opportunity to experience this. Looking to the bazaar model, this is characterized as a babbling bazaar of differing agendas and approaches out of which a coherent and stable system could emerge. Within this bazaar view, there is the assumption that bugs (and other emerging development issues) are generally easily remedied when exposed to a thousand eager co-developers. The idea is that the collective knowledge body provided by the numerous contributors is enough to accomplish the task as each person can tackle what they know. At this point, I have not really partaken in a large scale bazaar model project. Perhaps on a smaller scale it can be argued that I have experienced this model, but even this I have generally been in communication with people and are familiar with the individuals involved.

I do not think the bazaar model or cathedral model is unilaterally better than the other. Personally, I think I would prefer some cross over between the bazaar and cathedral models. From the bazaar model, I like the idea of having people contribute what they know. From the cathedral model, I like that there is some sort of plan and that you often know the fellow contributors to the project, which might facilitate communication.

Based on my experience with technology and within software development, two of ESR’s principles that stuck out to me were: “smart data structures and dumb code works a lot better than the other way around” and “perfection is achieved not when there is nothing more to add, but rather when there is nothing more to take away.” When learning data structures, I had assignments the emphasized using smart data structures in order to pass speed and memory tests. These data structures where used in code that likely qualified as “dumb code” with the understanding that it was throw away code for a particular assignment. Such assignments and test cases enforced the idea of smart data structures, but I do not think I truly appreciated having smart data structures until working in industry at a summer internship. When building enterprise software and working with a significantly larger amount of data, choosing/designing a data structure that is well suited for the given application can make a huge difference in efficiency. I think smart data structures can lead to smart code as well. Similarly, I have found that the ideas of smart data structures (and smart code) tie to the idea of achieving perfection through simplicity. Smart data structures and code are generally simplified and their function/purpose is easily discerned. Outside of my software development experience, the idea of perfection through simplicity is especially pervasive. After having taken a human computer interaction course, I have come to appreciate that the simplest designs can be the most effective. Users often appreciate the simple approaches because there is a smaller learning curve and easier to pick up. A couple examples I see demonstrating this idea are iPhone and Google.com. When the iPhone was first released, it had minimized the number of buttons and ways for people to interact with the phone, but gained a huge following. Similarly, Google’s homepage is incredibly simple (even compared to a few years ago) and also has immense popularity.

I do not think open source or bazaar model has definitively won, but I think it is an essential part of the software world. Seeing proprietary software companies utilize some pieces of open source software is a sign that such open source / bazaar-produced software has earned its place. I do not think that an open source or bazaar only strategy will emerge at least in the next few years. At least for some software projects, I think the money and other resources available to large companies are important, maybe even necessary, catalysts for exploration and growth.

Startups

The way Paul Graham pitches startups saying, “If you wanted to get rich, how would you do it? I think your best bet would be to start or join a startup. That’s been a reliable way to get rich for hundreds of years” it seems like you would have to be crazy not try it (unless you prefer to be a wage laborer or something). I think this particular quote lacks some  important context such as the failure rate of startups and logistic obstacles. In addition, success can defend on strategies and the people involved. Moreover, some startups can be based on a great idea that there just might not be a market for and therefore is unlikely to make you rich. Sure, if the startup you start or join makes it big, that is a great way to get rich. However, when starting or joining a startup, you cannot be sure it will succeed. I question the validity of startups being a reliable way to get rich for hundreds of years.

Despite the difficulties behind launching a startup or joining a startup early on, I think it something I could see myself pursuing in the future. For me, the idea of working at a startup is enticing and frightening among other emotions, but I think if you do not get excited, worried, etc, then maybe you should not be trying to partake in such a venture. I think my interest in partaking in a startup is that, in general, the people there are passionate about their work and working with such people is inspiring when trying to build a company from the ground up.

In Paul Graham’s discussion about income inequality, I think he makes an important point in that absolute poverty is worse than relative poverty. Despite the idea that the rich might get richer through increased technological innovation, I think that the standard of living has gone up significantly during these “centuries of startup success and money acquisition.” I think it probably would have been fun to be rich centuries ago, but if you did not even have some basic things like indoor plumbing or soap, were you really that much better off? I agree with Graham that the average person debatably lives a more comfortable life than the rich people did back centuries ago, even with their servants, horses and carriages. At least for now, I think it is fine to pursue technological progress and possible improvement in living conditions at risk of a widening income gap. With the growth of automation, I think it is possible that a widening income gap could continue but if automation is also do more in the home and effectively less expensive, then maybe it is not a societal problem.

I support the “unshackling” of the “wealth creators” though I think it could be useful if there were some means of having the wealth creators give back to society. I do not like the idea of “stealing” from these people and forcing them to pay a large tax just because they made so much but if they was some formula for at least having some of the massive amount of money earned fed back into society.

When thinking about what the next big technological platform, I would not be surprised if it does not even exists yet. Despite the hype for the different possible gold mines to discover, I think if I were going to make an application, I might try to do something with VR. Currently, I do not think that VR or augmented reality technology is the next big thing so making a VR app would more just be out of interest and an opportunity to try something new rather than try to make it big. Maybe the skills learned from building a VR app would transfer later on to pursuing a startup or provide insights on discerning what the next big thing will be.

Programming Languages

In my experience, when people discuss the topic of programming languages, many people will vehemently defend their language of choice. Based on the link between programming languages and way of thinking, writing off a certain programming language or speaking about it negatively could be basically insulting a person and their thought process. I think Paul Graham addresses this with his idea that “programming languages are not just technology, but what programmers think in.” In a way, this mentality can be seen when Graham discusses the “pointy-haired manager” that wants code written in Java instead of say some startup looking to “disrupt” industry X and taking chance of something others might view as unconventional. Moreover, this seems to tie directly to how people sometimes become very attached to the code they write. I have seen people get very angry when code they wrote is accused of having a bug, being inefficient or even revised. Expanding on the idea that a programming language is part of what programmers think in, I have seen people start tackling a problem presented in them by talking about the possible technical details of the problem in language they plan to use writing some initial thoughts/ code snippets before really thinking through a solution. For me this mentality carries over to tasks that are not necessarily related to computer science. For instance, if I have recently been coding in a certain programming language and I am talking notes for a class, I might might comments in my notes using the syntax of the recently used programming language.

With alleged connections between programming languages and the way that people think, perhaps there is some merit in Graham’s claim, “programming languages vary in power.” If programming languages vary in power and they are tied to how people think, it makes sense since people certainly vary in their thinking. Even an individual can vary in “power” of thinking such as how Daniel Kahneman mentions in his book “Thinking Fast and Slow.” However, considering what makes one language “better” or “more powerful” than another language, I think this can have slight variation depending on the situation. In a general sense though, I think the languages with straightforward and cleaner implementations of certain data structures, algorithms and syntax are superior. People might argue that languages with more libraries are more powerful because they can do more, but I think this can sometimes lead to “feature bloat” for a language and degrade its utility.

My experience with “alternative” programming languages is limited to Scheme. Similar to the idea that diversity in the workplace improves productivity, I think experience with other programming languages (especially considering the idea that programming languages are tied to a way of thinking) promotes diversity of thought within an individual. I am by no means a Scheme expert, yet I think my experience using it has helped my thought process when tackling problems in different languages with topics such as recursive thinking. I think these other languages are useful to continue using or dabbling with because of promotion of different thinking. In the future, I would like to explore more languages and tackle new challenges.

Thinking about what programming languages will look like in 100 years, I do not really picture them looking vastly different from what they are today. I think most of the core components of programming languages probably already exist in some form. Thinking back to the first airplane, which was a little over a hundred years ago, sure airplanes today are much more complex but the same core components of airplane design hold. With the increase in automation, I think it is hard to think what big problems programming languages cannot address. People might argue that hospital care and emotion based things are hard to account for when coding, but within a 100 years I do not think it would be too surprising for such solutions to exist. Considering the complexity within many programming languages already, it is argue that a certain feature is missing because others might argue that current features are already wasteful as mentioned by Paul Graham. Rather than wondering what programming languages might look like in 100 years, I wonder if some new invention will be developed that would actually replace programming languages and their function.

Nerds as Hackers

The hacker envisioned by Paul Graham seems to expand on the portrait Steven Levy paints. Both writers emphasize that hackers, in the broadest sense, are “makers”. They want to understand the present to prepare and build for the future. Locks/safes/obstacles? Break/crack/overcome. Information should be freely available. Ideas should be challenged. How can the most efficient solution be determined if access is limited and ideas are suppressed? Sure, people (often those in authority positions) will be annoyed at this general attitude of disobedience, but this right sort of unruliness just might be what has caused the tech explosion seen in America and disseminating elsewhere. One difference between Graham’s vision of a hacker and Levy’s hacker is that Graham seems to embrace a wider understanding of “hacking.” For instance, Graham claims that both ugly and imaginative solutions should be considered “hacks” because they often break the rules to accomplish a goal to a useful problem. Maybe your code is not the most elegantly crafted solution, bummed to the minimum size, but it works so why not embrace it and give others access to it. Often time is the test of the quality or elegance of solution and whether it will continue to thrive or get discarded. Another important difference from Levy’s hackers is that Graham’s hackers often draw inspiration and ideas from other fields inhabited by makers rather than limiting themselves to the “computer” fields.

I think Paul Graham had some interesting point in his “What You Can’t Say” essay. For instance, the reasoning behind wanting to challenge heresy/taboo/groupthink resonated with me. I think a key idea with hackers is the desire of challenging the status quo and color outside the lines to solve a problem or to gain understanding. If nothing else, I think reasons such as curiosity, disliking being mistaken, and being good for the brain, are sufficient for wanting to challenge societal norms. Intellectual curiosity seems like an important factor in rising above the monotony of life. While making mistakes is part of being human, it is important to learn from mistakes to make progress. I get not wanting to swallow one’s pride, but surely it is better to cast off mistaken views (i.e, vaccinations are not giving children autism). In business, groupthink can have horrible repercussions when no one points out mistaken views. Finally, the idea of challenging the norm as being good for the brain seems firmly rooted in the hacker and maker mentality. By creating new solutions and refining old solutions, makers of all types are challenging themselves to think in new ways. The fact that there is no solution to a problem suggests that people will have to consider new ideas that perhaps push the boundaries and move them in directions they might not have otherwise considered.

When considering the people that believe everything they are supposed to now, Graham claims that these might very well be the same people believing everything in the pre-Civil War South or in Nazi Germany. I think this is misguided in the sense that such situations have many other factors to consider. In terms of hackers and corporate America today, hackers might disagree with the direction of a project or the project itself but have to deal with their day job to follow their passions. I think this comes down to choosing one’s battles. Perhaps in hindsight, an individual will realize their mistaken thinking and have wished they had acted differently.

Paul Graham’s idea of a hacker somewhat describes me and some of the mentality I have, but I differ in some ways. For instance, I consider my coding and schoolwork my day job. Even at my current day job and college life, however, I find that my work comes in cycles just like the hackers Graham describes. Maybe once I am working at my post graduation “day job”, I will have more ideas for side projects, but in the meantime I will continue pursuing other passions.

Game Hackers

The 3rd generation of hackers saw the rise of the “Game Hackers.” These game hackers differed from the previous generations of hackers as computers and software had gained widespread availability thanks to the efforts of the “Hardware Hackers.” With this widespread availability, people who no longer just wanted to hack on computers bought computers. Instead, computers became a means of entertainment. While the “Hardware Hackers” had commercialized the computer hardware market, the “Game Hackers” returned to hacking on software, like the 1st gen “True Hackers.” The main difference between the hacking was that “Game Hackers” focused on software games, instead of software for an assembler. The “Game Hackers” started the movement with text based games and progressed to games with more complex graphics such as John Harris’ “Jawbreaker” game. While the “Hardware Hackers” had some people become interested in the possibility of profit, the “Game Hackers” seemed to be where the allure of money enticed people. The “Game Hackers” were not necessarily without the true passion and motivation, but some people such as Ken Williams seemed more interested in the money.

For instance, Ken Williams was at university studying physics and took a FORTRAN class, which soon inspired him to drop out of university and enroll in Control Data Institute to learn programming. Ken was not “superprogrammer” and would try to fake competence to get his foot in the door at a company. After working for a couple years, Ken say the profit to be made if he started his own computer company. Another example of someone drawn to the money was Jerry Jewell. Jerry left the insurance business to enroll in an assembly-language class taught by Andy Herzfeld, one of Apple’s top programmers. Doug Carlston is an example of someone who worked for a big law firm in Chicago and bought a TRS-80 to start developing a large strategy game on. With the enlistment of his brother, Gary, he set up Broderbund Software.

I think the main point with the transformation and development of a marketplace in relation to hackerism is that naturally the allure of money will draw people that are not necessarily passionate to the field and might have other interests and priorities. I think the mindset behind wanting to stifle the hackers was more just wanting to keep hackers focused on developing the product in a timely manner to enable sustainable and even profitable business. For instance, the reading notes that it could be counterproductive to have hackers who wanted to add one more feature or would not let go of a project until it was demonstrably better than anything else around. I think the business aspects drove the channeling of the hackers’ efforts, which seems natural considering most people will not pay you to keep tinkering with things and complete project when you feel like it. While hackerism was changed following the emergence of a marketplace, I think do not think this is necessarily a bad thing and it helps sustain a broad interest and continue to produce growth in the field. I think sometimes you need a market force to help direct people to push the limits and set new boundaries that might be broken in the future.

Programming a computer is not requirement for benefiting from it. I think part of the beauty of computers is the different functions they can provide for different people. I think the “benefits” one derives from their computer is based on the individual rather than some sort of universal benefit gained from programming. Similarly, I think the public benefitted from one company ‘owning a piece of software and preventing others from making it useful in the sense that it is serves another group of people. While potentially frustrating for certain individuals, it seems unlikely that the people wanting to tinker with such technology would buy it or solely buy it without having another alternative. I think it is possible to retain some elements of the idealism that existed at first, but I do not think that the “pure hackerism” could have been preserved once it reached the masses and became commercialized. However, maybe it is better that the pure “Hacker Ethic” of the “True Hackers” is not the sole mentality anymore.

Hardware Hackers

The 70s saw the emergence of the “hardware hackers” based on the foundation laid by the “true hackers” of the 50s and 60s. One commonality between the “true hackers” and the “hardware hackers” was the desire to create, generally for societal improvement. Both groups of people followed most of the ideas from the hacker ethic but in particular they seemed to share belief in the open access to computers or anything else that might teach you something about how the world works, free access to all information, mistrust of authority, and the potential of computers to change one’s life for the better. An example of this continued mentality was free distribution of tapes to others within the Homebrew club with the only stipulation being that those receiving a copy of the tape must make more copies and distribute those copies to other people and other computer clubs. The main difference between the hardware hackers and the true hackers was that the hardware hackers were more obsessed with the hardware and prospect of widespread personal computers availability for everyone. Ideas for such a future included computer centers were people could just walk in and have fun with computers. Furthermore, these hardware hackers envisioned the construction of a computer in one’s own home even if just to play with and explore. Overall, the hardware hackers did not seem to believe in the exclusivity of hacking for only those who were the most skilled. The hardware hacker movement was started by people like Lee Felsenstein who believed that technological tools could be tools of social change when controlled by the people. In fact, the Hardware Hackers section said Felsenstein was offended by what he considered the excessive purity of the MIT “true hackers”, particularly because of their indifference to spreading technology among the “losers.”

To combat the “aura of elitism, and even mysticism, that surrounds the world of technology”, hardware hackers such as Ed Roberts undertook a project in which people could send in money to receive the parts of computer and then build it themselves. Roberts first computer cost $397, had only 256 bytes of memory and the machine came with no input or output devices. Despite the simplicity of the machine, the first day the magazine description of the product saw nonstop interest from people. Checks and money orders for hundreds of dollars’ worth of MITS equipment, including for add-on boards that would make the computers more useful but that had not even been designed yet. Another example of the movement away from the elitist attitude of the “true hackers” was the Homebrew Computer Club which grew rapidly. The Homebrew Computer Club was open to anyone with an interest regardless of skill level. In fact, Gordon French started giving what amounted to tutorials explaining the way the machine uses the code you give it and teaching good coding habits with the goal of saving members from future headaches. Local computer clubs and hobby groups served to fill technical knowledge gaps for many people as each person contributed the bits and pieces they knew.

As the Hacker Ethics spread beyond “the limited, monastic communities around the machine, to a world where the machines were everywhere” via commercialization a few changes occurred. One example was the budding idea that maybe not everything should be free. For instance, Bill Gates seemed to believe that all software being free might detract from progress, while others within the hacker communities firmly stuck to the idea of everything being freely available. Another major change brought about by the commercialization was that broadly attended computer clubs diverged into smaller groups. The motivation behind this post commercialization movement was that these smaller groups pursued interests and diving deep in a particular topic, rather than the big computer clubs where people explored broad range of topics. Apple and its people were a prime example of those departing from Homebrew to thoroughly understand their area of interest.

Personally, I side with Lee Felsenstein that technology can be a force for good, but that does not mean it is unilaterally good. I do not believe that you need to thoroughly analyze tech you use and create from ethical, moral and social viewpoints and potential impacts. Such thorough analysis sounds dangerously oppressive before even doing anything. Moreover, I think there will be debate on what is ethically, morally or socially best as seen even back in the age of the “hardware hackers” who debated practices and whatnot. Maybe a quick, high-level consideration is sufficient so as not to stifle creativity. If people truly think some product or practice is wrong, there will likely be some sort of legal stance in time.

“True Hackers”

Levy suggests that a “true hacker” was more than just a computer obsessed person. Instead, it seems to refer to a lifestyle built upon the philosophy of sharing, openness, decentralization and getting your hands on machines at any cost to improve the machines and to improve the world. In addition to this philosophy, Levy states that many of these kids at MIT that formed this early group were some of smartest and weirdest kids in high school. Oftentimes, they were not athletic and dreamed of making the science fair finals rather than doing the sport. These individuals had an intellectual curiosity that could not be satisfied. They always wanted to know how things worked and were delighted and thrilled when they discovered how elegant some solutions could be. For instance, these “true hackers” were the people that would spend hundreds of man hours analyzing countless solutions until an objectively best solution was discovered. This was also apparent in their practice of “program bumming”, trying to accomplish the same goal in fewer instructions.

In addition to these characteristics and practices, Levy claims that true hackers generally shared the following beliefs:

• Access to computers and anything which might teach you something about how the world works should be unlimited and total
• All information should be free
• Mistrust authority, promote decentralization
• Judge hackers by their hacking ability, not criteria such as degrees, age, race or position
• You can create art and beauty on a computer
• Computers can change your life for the better

This group of “true hackers” were not ones to just talk about these ideals, there were multiple examples of living such a lifestyle to be found when considering this group of hackers from the 50s and 60s. One of the earliest examples of this is exemplified by Samson and his initiation to the TMRC at MIT. New members had to spend around 40 hrs getting familiar with the equipment and other stuff to gain full access and Samson logged all these hours and more within his first weekend. He was so fascinated in understanding the system and trying to improve it for himself and everyone else in the club that he spent the entire weekend lost in his work.

Another prime example of this “true hacker” mentality involved a group of these true hackers and Margaret Hamilton. Hamilton was not a stranger to the technology at MIT and could hold her own with her coding skills. Hamilton wanted to test her Vortex Model, which was a weather simulation program, she used the system’s default assembler instead of the assembler written by the hackers. This choice shocked the hackers as they believed their joint creation was clearly superior to a default and could not understand why anyone would ever want to use the default assembler. Moreover, not only was their assembler thought to be better, they ensured it was freely available (they also conveniently tried to force it on people). The idea is that these people worked feverishly until their assembler was complete and wanted everyone to benefit from their work and even have it available for others to improve if they could.

Comparing this “true hacker” with my previous understanding of a “hacker”, one key difference comes to mind. The “true hacker” might seem to refer to hacker in the singularity, but I think it has more of a communal reference that is actually many people working in unison for mutual betterment. Previously, I thought of hackers working more individually, but still envisioning a goal of improving something. In both cases, I think hackers and the “true hacker” people share a sense that their works/skills are more important than a title/degree. I think a key characteristic of both groups is an unwavering desire to work at something until understanding it and having some mastery, while others might not be willing to expend the time and effort to accomplish such a feat.

Reflecting on the idea of a “true hacker”, sure the concept is inspirational and even intimidating, however, I do not think such a lifestyle is the move for me. I do think some of the stories of these historical people are inspiring in that their environment seems to be one with likeminded individuals that provided the support and encouragement to foster mutual growth and pursuance of such software achievements (though with some detractors). The idea of the “true hacker” does make me want to build some cool things, but at the same time I enjoy a life outside of hacking. I guess many of my fellow ‘losers’ from back in the day likely also enjoyed a life outside of hacking and were not quite on the same level of these “true hackers”, making such an environment seem intimidating for the losers. However, if you do not aspire to be this archetypal “true hacker”, I think such a mindset does not inhibit you from making some interesting “hacks” of your own.