What is a Hack?


Slide 1: Title (Hackers Bomb)

I borrowed this picture from a friend who is a hacker anthropologist.

This is what some people think of when they think of hackers. If not death, then certainly destruction. People breaking into computers. Stealing data. Taking down websites. Attacking.

And I'm only suggesting that as a means of clarifying terminology. Because "Weekly World News" hackers are not what I'm going to be talking today.

Aside: After class I'll teach you all how to turn a computer into a bomb.


Slide 2: Hacking Definition

Here's a definition of hacking that comes straight from the "Jargon File."

JF is a dictionary created by and for hackers. The first entry is, unsuprisingly perhaps, an entry about hacking:

“Hacking might be characterized as ‘an appropriate application of ingenuity.’ Whether the result is a quick-and-dirty patchwork job or a carefully crafted work of art, you have to admire the cleverness that went into it.” - Jargon File (Eric S. Raymond)

So if we break this down, hacking implies:

Hacking, in this sense, is innovation.

But the reason I'm talking to you about it today is that innovation, of this type, is an archetypical example of user innovation of the type that will be taught in the class.

But the reasons hackers are so interesting is that hackers are some of the Internet's first "power users". To this day, they are the most powerful. As a result, they provide examples of how the Internet is changing innovation process by shifting power away from manufacturers, and away from firms more generally, and toward users. They are a source of case studies of exactly what Professor von Hippel is talking about.

The definition from the Jargon file proceeds to tell a bunch of stories. It is a definition of zen where one explains something through stories or koans. Just as Professor gave you the example of the heart and lunch machine, I think it's important to build a strong substantive understanding. So let's start there.


Slide 3: Example of a Hack: CHDK

This story starts with a firm: Canon. Users know their needs and in, in this case, the need was created by a firm trying to do something to users that they teach in business school.

Canon's G7 replaced the G1-G6 and removed the ability to record RAW photos. Of course, this was an attempt at market segmentation. RAW was a high end feature and they wanted to push high-end users to higher-end cameras.

But there's a problem. Because RAW isn't realy a feature. RAW is just raw sensor data. It is more difficult to compress a JPEG than it is to not compress a JPEG.

This annoyed people. And that annoyance is a need.

A hacker, Andrey Gratchevz, understood this decided he was going to do something about this. He set out to write a piece of software to "patch" or modify the software running on his camera.

The first problem he had was getting the code. As I've implied, Canon didn't want people to do this and made it "impossible" to get things off the cameras.

He and others have used some cool tricks to get the code off:

Gratchevz then he patched the software to shoot RAW.

Then he shared his patch by uploading it to a web forum.

What happened next is both astounding and completely typical of communities. Other hackers picked up his work and started adding to it.

What resulted was a framework for building the camera to do all sorts of things that were not possible before.

But what also happened was the creation of a community of users helping each other and hacking together. There are dozens of version including the ALLBEST version.

And finally. Eventually. Firms show up.

Finally, Canon has quietly been looking at this and adding some features.

I a minor consulting arrangement with the camera store downstairs to install CHDK on their cameras because it can help them increase their sales.


Slide 4: Lifecycle

Let's take this moment to step back from the "wow!, that's cool" to unpack what I've shown you.

CHDK's lifecycle is actually pretty typical of a wide variety of hacks in that it involved each of these distinct points/pieces:


Slide 5: More Examples

Walk through examples

Why do hackers hack?


Leave 30 minutes until the end.


Slide 6: Why do hackers hack? title slide

I've talked about what hackers do. The second question now becomes "Why?"

I've shown in my previous slides that there are a whole set of things that hackers are doing. As a result. We can assume that there are motivations at each of those steps. But we shouldn't necessary assume that its the same as each steps.


Slide 7: Why do hackers hack? Two Questions

We'll talk about these more in this class but I think it's clear that are at least two distinct questions. I'll talk about two of them today:

  1. Why do volunteer work on these projects -- that is to say, why do they create these innovations -- with no expectation of getting paid back.
    • For example: They could be working longer hours, putting their time to other things, etc.
  2. Why do hackers (either individual volunteers, paid laborers, or firms themselves), choose to voluntarily reveal their work freely?

Question 1: Why do hackers innovate?


Slide 8: Q1: Why do hackers innovate?

ASK Who here works on a project like one of these as a volunteer? Why do you do so?

ASK Non-volunteers, what do you think?

We don't need to take very much time on this because this is something that has already been covered and is really at the heart of what Professor von Hippel will teach in this class.

Users innovate because they are solving their own problems.


Slide 9: A1: Why do hackers innovate?

This slide can be summarized:

  • Because they need or want to.
  • Because they can.
  • Because they love to.

(1) Eric S. Raymond explained that users were "scratching their own itch." There are real needs that users want to solve. Of course, some times they are more dire than others.

This is very compatible with the user innovation definition: After all, "user innovation is when the developer expects to benefit by using it."

e.g., Andrey Gratchev had a problem with his camera and he solved it
because he wanted to shoot in RAW.

(2) Prof. von Hippel will show in the course how users are ideally suited to notice their own problems (that was step 1 in the lifecycle) as well as being better suited to solving them.

Ironically, this is often the case even when firms are working hard to keep users from being able to do so.

Canon didn't assume that anyone would want to keep a calendar on their camera. They didn't imagine that automatic bracketing would be of interest. Or maybe they considered it but the market was just too small.

(3) Hackers just enjoy doing this type of work. Surveys have shown that the top reasons for contributor are just that solving problems and the act of building stuff is just fun for people.


Slide 10: A1: Intrinsic versus extrinsic.

There is one distinction worth noting that has been at the center:

For example, there's an important distinction between instrinsic and extrinsic motivations.

  • Intrinsic of course means coming from inside (of the person)
  • Extrinsic means coming from outside (money is the big one but praise, etc. are also forms of extrinsic motivation)

Barring philosophical questions of whether we can really have intrinsic motivation (and they certainly exist), this is a useful framing and a good way to see the differences between motivation in user communities.

Go back to the slide with three areas.

We can imagine intrinsic and extrinsic components here.

What's clear though is that, throughout, there is a real shift here away from extensic toward intrinsic motivations.

The implications here are profound:

  • We cannot "incentivize" intrinsic motivation. Indeed, crowding theory from psychology and economics tells that the two are actually in conflict.

  • We can however, build systems that support and encourage intrinsic motivations and that attempt to harness that power. Many of these questions are open and the individuals or organizations that figure this out stand to make enormous gains against competitors that are still largely focused on the old modes of production and promoting the old extrinsic motivations.

    This is your Wikitravel versus Lonely Planet story.

    Or your Wikipedia versus Britannica.

Question 2: Why do hackers choose to reveal their works?


Slide 11: Q2: Why do hacker share their work?

This has been a major source of concern, especially among economists who have written in depth trying to puzzle through the issue:

If people are creating things of such immense value (Linux and associated free software is valued at billions of dollars), why do people just give it away?

On, the problem is solved, you're done. So why do you sharing?

So I've been a hacker since I was 12 years old and the answer to this question is not obvious to me.

ASK Why do hackers voluntarily reveal their work freely?


Slide 11.5: Q2: Why do hacker share their work?

I'm going to highlight 4 answers that come from the academic literature on hacking:

  • Ideological commitment to sharing
  • Building reputation
  • Benefits of collaborative work
  • Sharing is cheap! ("Why not?")


Slide 12: A2.1: Ideology

Ideological commitment to openness and sharing “Software should be free.”

Now "should" can be either strong or weak.

In Stallman's case, the committment is very strong one. Stallman has create a foundation (on which I'm on the board) to promote free software as an ethical issue. He argues that is unethical to distribute non-free software. He calls proprietary software "fettered" and compares it to slavery (not in degree, but in type).

But ideological commitments can be also weaker. Glynn Moody -- author of Rebel code -- where he talked about sharing as a simple thing we're taught in school. There's interesting work in development social psychology about feelings of ownership but certain types of sharing, at least, seem to be nearly built in.

Hackers work on both these levels:

I've done research on the Debian project (the largest FLOSS project) with Gabriella Coleman on how hackers create systems to train and test people in ideology before they are given recognition in a project.

In the case of something like Wikipedia. The "weak" commitment also plays a role.


Slide 13: A2.2: Reputation

Reputation is another good example and, once again it works on two levels.

This time, the distinction is between inside and outside the problem.

On the outside, the hiring process can give one insight into this:

  • A common thing is a code sample
  • Work in FLOSS can show competence, familiarity, and passion
  • If a firm is using software you've contributed to, you have an edge over other participants

From the firm level, there are other options:

  • Options for consulting, services, and support (this is very frequently a business model firms use alongside free revealing of innovation without strong IP protection)
    • Red Hat business model (now a large company, which releases almost 100% of their code freely and all of their code to their code operating system)

There is also the inside the project.

Remember, these are communities. Some research I've done on the Scratch online community has produced this quote:


"Dude, Alan Cox just accepted my patch! He said it's great!"


Slide 14: A2.3: Benefits of collaboration

In the Cathedral and the Bazaar, ESR puts this most fundementally in "Linus' law": "With enough eyeballs, all bugs become shallow."

But there's more to do in than that. For example, sharing improvements means others can help improve and maintain them.

Let's look at a concrete example from CHDK which is particularly true for hardware issues:

  • Let's say I fix something. I could just sit on it. But there's going to be a new version of CHDK coming out. And I'm going to have to then make my change again. If I share it, I benefit from having it be fixed in my product.

The final point is from survey data by Rishob Ghosh. Even the people who contribute the most to wikis and to free software projects feel that they are hugely in debt. They want to give back (perhaps out of a feeling of fairness or just because they feel that the community has given them a lot).

There are few implications of this:

  • It leads to actually better stuff being produced through a process which can outcompete proprietary/secret development.
  • There are more people outside than inside any company and the people outside are willing to share and collaborate.


Slide 15: A2.4: Sharing in cheap and easy

So this is the simple economic explanation that boils down to "why not".

So, by definition, if the benefits to the sharer outweigh the costs, the user will share. In the same way if I hold a free movie here for MIT students I'll get more people than if I hold it in Seattle or Worcester.

There's an argument that Yochai Benkler has made that builds on fundemental work in organizational economics that argues that focuses on transaction costs.

Transaction costs were created as a way of describing why firms exist. "If the market is so great, why create firms?" The answer is that sometimes the costs in "overhead" of a market transaction outweigh the benefits. Firms insulate work from market pressures as a way of reducing those costs.

Benkler's argument is that the costs of sharing have gone down radically. There's reason to suspect that.

Before the Internet, you used to have to contribute and share software by mailing it around. The OED had people mail in small changes. It still happened, but much less.

Think of the costs of fixing a comma on a broken wikipedia article.



Slide 16: A2: Survey Data

Let's look at one survey on FLOSS projects.

This study (like most to date) sort of collapses issues that pertain to both of those two questions.

What we see here is that the answer is sort of all of the above.

You can also notice that these answers add up well above 100%. Within a single individual, there are differen things going on.

On the one hand, that means that motivation is a tricky and complicated thing we need to balance.

On the other, and particularly exciting for a crowd like this, it means we have a number of levers to pull on.