Why Open Source Works

Brit Butler
2011-08-08

(use arrow keys or PgUp/PgDown to move slides)

First things first...

• We need an operational defintion of "works".
• Also, of Open Source.

Open Source is a process for making things, the most oft associated artifact being software.

We're going to use software as our vantage point since...

• A) The most data is available for looking at Open Source via software and...
• B) We make software.

Just remember, Open Source is *NOT* about software!

Use the source, Luke!

That said, if software is our artifact, we need to discuss what software is composed of...

CODE

To deliver you from the preliminary terrors...

Source Code

Software is just text...really unusual, exquisitely structured, occasionally expensive text...

Some Key Points about Programming

• Thus, programs must be written for people to read, and only incidentally for machines to execute.
  - Abelson and Sussman

Some Key Points about Software

• Simply a set of behaviors that automate human labor.
• Software is intellectual property.
• Software (when stored digitally) can be copied essentially for free.

This

Great. So what's Open Source Software (OSS)?

Software whose source code is publicly available under an appropriate legal license.

• Two predominant families of such licenses, GPL-style and BSD-style.
• Sometimes known as "Free Software" and "Open Source".
• A historical marketing war, still cared about by some.
• One emphasizes the rights of the software, the other the rights of the user.

In the beginning... (or, History? What history?)

Software used to be free.

• No commodity hardware, not to mention Operating Systems or Programming Languages/Compilers.
• So no notions of reuse or portability.
• ...until the advent of C in the early 70s.
  - (Unix in C happened in 1972)
• Most systems were big organization owned Time-Sharing systems. Mainframes. DEC PDPs and stuff.
• Hence, no notion of software as a commodity.

Early Proprietary Software

Arrived with the "hobbyist" then microcomputer markets in the late 70s and through the 80s.

Bill Gates wrote a particularly famous letter in 1976.

Meanwhile, in 1980...RMS got upset about a Network Laser Printer at the MIT AI Lab...

Then fought against LMI and Symbolics until 1983 when he founded the GNU project.

GNU? Gnu's Not Unix

Intended to write a ton of "Free Software" culminating in an Open Source Operating System.

Unix was a predominant hacker OS at the time...

Finished everything but the OS kernel. Then a Finnish kid (seriously, he was in school) showed up in 1991 named Linus Torvalds...

Fine. Hippies making software. What's hard about that?

Anybody in here old enough to have owned an Atari?

Now you know why Medley's taking so long...

What did they do?

1000s of volunteers, creating a complex public good, beating the pants off established market competitors and giving it away!

Does this correspond with your *intuitions* about economics?

Examples: Apache, Linux running NYSE, 900,000+ Google servers, CMGdigital!

Managed to solve a collective action problem by reframing the notions of ownership and property.

Who did it?

Anybody. Open Source is characterized by distributed, voluntary participation on voluntary tasks.

Lower the barrier to entry as much as possible. But a bunch of people "scratching an itch" is not enough...

Demographics are international, mixed paid and unpaid work these days. 80-20 rule still applies. Top-heavy.

Classical Economics

Property is an exclusionary notion. My ownership means I can deny you access.

Open Source makes the notion of ownership the right to distribute, reframing what property fundamentally is.

Political Economist Steven Weber suggests this underlying change supports all the rest.

The Goods

• Non-excludable due to licensing.
• Non-rival due to digital distribution.

Open Source is a public good!

The Process - You Shall Be Faithful To It!

So what is this open source process? Are there tenets?

Is it like standard software engineering practice?

Glad you asked...

1. The Cool Factor

"Enjoyment predicts excellence." - Eric Raymond (aka an insufferable blowhard)

Work on stuff that interests you and seems cool.

Remember, Voluntary task selection! Self-elected projects.

2. Scratch an Itch

In some way improve or solve a personal problem for the author.

It should be relevant to you as well as just fun or cool.

3. Reuse, reuse, reuse

Maximally utilize and repurpose existing code. Don't reinvent the wheel.

Helps build something genuinely new, useful and/or innovative faster.

4. Parallel Efforts

More than one person wants to solve the same problem at the same time? Fine!

Technical battle royale! (See: LKML)

5. Leverage the Law of Large Numbers

"Given enough eyeballs, all bugs are shallow." - Linus Torvalds

The user is a contributor == the user is a tester. No barriers to entry!

6. Eternal Beta

Release early, release often! Interested users can just run from version control!

The software is never done...because software exists in a social context.

7. Docs, Docs, Docs

Code is *not* enough. Need beginner's guides, IRC channels, Wikis, Unit Tests...

Don't want to be stuck instructing each new contributor.

8. Talk a *lot*.

Argue about licensing. Argue about braindead parts of current architecture.

Argue about brilliant hypothetical overhauls. Argue about history. Wind up maintaining.

Dependencies...

All these behaviors are enabled by a trifecta of three things:

• 1. Network connectivity for dissemination of materials and plummeting transaction costs.
• 2. Legal licenses for protection of code and developers' rights.
• 3. Elders and/or BDFLs for social norms and leadership.

BDFLs?

Benevolent Dictator For Life

"organizations...are constrained to produce designs which are copies of the communication structures of the organization" - Conway's Law

No single dominant organizational structure.

• Linux - Onion-like. Linus, surrounded by maintainers, surrounded by sub-maintainers, surrounded by...
• Apache - Democratic Repulic. Minimal quorum consensus rule.
• Perl - Round-robin. "Pumpkin-holder pattern", still an inner circle.

Not without Dangers...

• Forks
• Licensing disputes
• Occasional crazy maintainers or BDFLs...Ulrich Drepper, anyone? (Glibc)

Oh, and some projects just die... IGNORED!

More Economics...

Microeconomic Issues

• Why volunteer towards a public good? What's the individual motivation?
• Where is the scarcity in this economic system?

Macroeconomic Issues

• How to coordinate, manage complexity and beat Brooks' Law?
• How to avoid forks and sustain functioning communities?

Motivations...

• It's Cool. Elegant code is a thing of beauty. Mongrel was an "art project".
• Job as vocation. Take code seriously, due to scarce resource, having to solve the same problem more than once is stupid, not just inefficient. (See: subcommander)
• Comfort. Sometimes referred to as "Joint enemy". More about community against perceived discomfort of closed source. The shared enemy of software that doesn't do what you want.

Motivations... (pt. 2)

• Ego-boosting but not egotism. About self-satisfaction and self-recognition. Don't brag, let your work brag for you. About self-improvement, efficacy.
• Reputation as a way of signaling expertise. Market signals! Feedback is needed to improve and distance helps with objectivity and flaws. What better way than status in a community of experts?
• Communities should empower individuals to help themselves.

But what about competition for status?

Several reasons it doesn't overwhelm...

• Pretty hard if you can't write code that works. "Let the code decide."
• Largely mitigated by shared beliefs and membership in a community with shared values.
• The only way to get better is to build more stuff!

Scarcity or Abundance?

Abundance

• Framed by some people as a Gift Economy, where status comes from giving away property.
• - Plausible enough. A gift economy can make sense...at the very top of Maslow's Hierarchy...
• "Rings and jewels are not gifts, but apologies for gifts. The only gift is a portion of thyself." - Ralph Waldo Emerson

Scarcity!

• The abundance exists but in bandwidth and CPU cycles. Human cycles are what matter for software.
• The scarce resource in this system is the time and energy of skilled, creative, focused individuals.

The Free Rider Problem

Public Goods generally require government provision because of the free rider problem.

Why not just take? Non-rival *and* non-excludable?

Worse still, why create in the first place?

Hypothesis

Software is not just a non-rival good, it's actually Anti-Rival!

Meaning that it's a network good and receives positive externalities from free riders.

Even free riders actually enhance the utility of the software!

How could this be...

Network dowhatnow?

Network Effect: The impact on the value of a product that one user has on the product for other users.

Positive Externality: The more people that use it, the more useful it is!

Why software? Bugfixing, testing, translation. Users turn to devs and back again!

-- Even a small percentage is HUGE. Still needs *some* balance against userbase.

Large groups thus thrive better. Flip on traditional collective action problems.

The Challenge Shifts: Coordinating Contributions

Forking - Occasional forks are needed, even endorsed!

-- Ex.: Lucid/XEmacs, Samba NG, etc

Licenses *explicitly* designed to empower forking...

• But the cost to fork can be high (projects, not repos)
• Must establish legitimacy.
• Struggle to integrate new contributions to original project.
• Division of contributor pool, less overall useful patches!
• And maintenance efforts? /me dies

Forking Success Stories

Resemble John Locke's Homestead Principle/Labor Theory of Ownership from his Second Treatise on Government.

Three Paths

• Work the land to own it.
• Claim land that is unused/abandoned.
• Have it passed on to you.

What about authority?

"Talk is cheap, show me the code." - Linus Torvalds

• Seniority credentials, even "ownership" ultimately subservient to techincal concerns.
• Demonstrated work is the only law. "Let the code decide."

Fine. What isn't Open Source good at?

Being a panacea or silver bullet.

Creating new markets (usually)

Design or UX-heavy software, games, etc

-- Are these IPs less well-suited to the OS process than code? If so, why?

Non-Code OS Examples?

Structured data definitely!

• Wikipedia
• OpenStreetMap

Structured Products? ...not so much

• Open Hardware...
• Pharmaceuticals

Maybe. Still waiting...

Questions?