Question 1: 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.

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.

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?

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?

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?")

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.

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:

"OH MY GOD! THIS IS ON THE TOP VEIWED LIST!!!!! [...] THIS IS THE HAPPYEST DAY OF MY LIFE"

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

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.

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.