• General Overview
  • Cathedral vs. Bazaar — The Central Thesis
    • Cathedral model: centralized, carefully crafted software in the classic GNU style
    • Bazaar model: open, decentralized development with many agendas, exemplified by Linux
    • Core claim: critical complexity does not require centralized a priori design
    • Linux proof: amateur hackers built a quality multitasking OS, overturning professional-only assumptions
  • The Bazaar's Development Insights
    • Release early, release often: rapid turnaround scales with complexity, sometimes daily
    • Linus's Law: enough eyeballs make all bugs shallow; finding the problem is the harder challenge
    • Users as co-developers: open source lets users diagnose, fix, and improve code faster than one developer
    • Personal itch: good software starts by scratching a developer's own itch
    • Smart data structures: dumb code with good tables beats clever code with ad-hoc data
    • EGCS experiment: same source and tools; bazaar-style management beat cathedral GCC decisively
  • The Hacker Culture of Reputation
    • Gift culture: status comes from what you give away, not what you control
    • Reputation economy: peer prestige is the primary reward driving hacker effort
    • Homesteading the noosphere: Lockean property theory maps onto project ownership
    • Anti-forking customs: divergent copies split communities; ownership customs prevent fission
    • Egoless coding: Weinberg's non-territorial review accelerates improvement
  • The Economics of Open Source
    • Use value vs. sale value: software's tool value dominates; factory pricing conflates the two
    • "Information wants to be free" myth: zero copying cost does not imply zero clearing price
    • Indirect sale-value models: market-positioning, service-led, accessorizing, and speculative
    • Strategic weapon: Apache, X, and Mozilla show cost-sharing, preemption, and blocking coalitions
    • Five discriminators: reliability, verifiability, criticality, infrastructure role, common knowledge favor openness
  • The Movement and Its Campaign
    • Netscape's epiphany: January 1998 source release, crediting The Cathedral & the Bazaar
    • "Open source" coined: February 1998 rebrand to sell pragmatically to managers and investors
    • Mozilla's lesson: open source demands runnable code — "not magic pixie dust"
    • Halloween Documents: Microsoft's leaked memos validated open source and drove Wall Street interest
    • Infrastructure dominance: Apache, Perl, Sendmail, and BIND already led key Internet layers
  • Management, Motivation, and the Future
    • Brooks's Law refuted: Linux beat the N² complexity effect through bazaar organization
    • Management's Maginot Line: fascination routes around forced boring work; play is efficient
    • Leadership without coercion: Kropotkin's common understanding beats command
    • Future predictions: open infrastructure, mixed middleware, closed applications
    • Beyond software: music and books need no debugging; win the software fight first
• Deep Dive
  • Foreword
    • Freedom Drives Innovation
      • Business freedom: industry success tracks the freedom of suppliers and customers
      • Telephone example: AT&T's monopoly slowed innovation; competition unleashed it
      • Hardware vs. software: hardware's global freedom produced the fastest innovation ever seen
      • Software stagnation: office suites ruled the 1980s; browsers and servers only challenged them in the 1990s
    • Open Source and Control
      • Open source: brings even greater freedom to software than hardware enjoys
      • Programming languages: let programmers build and communicate ideas that benefit society
      • Proprietary licenses: restrict access to knowledge infrastructure society increasingly relies on
      • Customer control: open source gives users control over technology instead of vendor lock-in
      • New business models: required to supply open-source tools successfully
      • Competitive edge: model-driven suppliers can outcompete vendors who retain customer control
    • Communicating the Revolution
      • Two prerequisites: widespread open-source use plus clear communication of its benefits
      • Raymond's role: explaining the open-source development model accurately and effectively
      • Central contribution: his writing powered Linux adoption and the open-source revolution
      • Lasting impact: enables success for open-source users and the companies serving them
  • Preface: Why You Should Care
    • Why This Book Matters
      • Software economics: software is increasingly critical to the global economy and business strategy.
      • Open source: systematically harnesses open development and decentralized peer review to lower costs and improve quality.
      • Infrastructure stakes: open source is bidding to define the computing infrastructure of the next century.
      • Practical relevance: anyone who relies on computers needs to understand this movement.
    • The Hacker Tribe
      • True hackers: enthusiasts, artists, tinkerers, problem solvers, experts — not criminals.
      • Proven builders: hackers created the Internet, Unix, the World Wide Web, and Linux.
      • Cultural significance: hacker success poses fundamental questions about motivation, work organization, professionalism, and the firm.
      • Future prefiguring: hacker culture hints at profound changes in how humans will relate to economic life.
    • The Essays as Living Documents
      • Original context: essays were published on the Internet between 1992 and 1999, then revised.
      • No dumbing down: technical material is left intact to puzzle and challenge readers.
      • Open peer review: the essays evolved through feedback, mirroring the open-source process they describe.
      • Ongoing inquiry: these are reports from a continuing journey, not fixed or final forms.
  • Chapter 1. A Brief History of Hackerdom – The End of Elder Days
    • Prologue: The Real Programmers
      • Real Programmers: post-1945 enthusiast culture of bright engineers and physicists who built software for fun.
      • Batch-computing roots: dominant from WWII to early 1970s, tied to big iron and batch scientific computing.
      • Folklore artifacts: Murphy's Laws and mock-German "Blinkenlights" poster survive from this era.
      • Seymour Cray: legendary supercomputer designer; toggled an entire OS in octal via front-panel switches without error.
      • Eclipse: interactive computing, universities, and networks eventually displaced Real Programmer culture.
    • The Early Hackers
      • MIT's PDP-1 (1961): Tech Model Railroad Club hackers created programming tools, slang, and culture that survives today.
      • Hacker term: MIT's computer culture first adopted it; club hackers became nucleus of the AI Laboratory.
      • ARPAnet (1969): first transcontinental high-speed network turned isolated hackers into a networked tribe.
      • Jargon File: cross-net collaboration (1973–75) became defining slang dictionary; later published as The Hacker's Dictionary.
      • University nodes: MIT, SAIL, and CMU thrived; XEROX PARC invented mice, windows, icons, laser printers, and LANs.
      • PDP-10 and ITS: MIT rejected DEC software, built "Incompatible Time-sharing System"; LISP enabled creative thinking.
    • The Rise of Unix
      • Ken Thompson: invented Unix in 1969 at Bell Labs after Multics bloated into a white elephant.
      • C language: Dennis Ritchie's pleasant, flexible language made Unix portable across machine types.
      • Portability revolution: first OS written in C; software survived hardware obsolescence and toolkits carried between machines.
      • KISS philosophy: Unix as flexible toolkit of simple combinable programs; C's whole structure held in one head.
      • Spread through universities: by 1980 thousands of hackers used Unix on PDP-11 and VAX; UUCP and Usenet created its own network nation.
      • Culture clash: PDP-10 hackers dismissed Unix as primitive "stone knives and bearskins"; microcomputer BASIC was beneath contempt.
    • The End of Elder Days
      • Decline of ITS: aging PDP-10, commercialization of AI, and DEC's 1983 Jupiter cancellation left ITS no future.
      • Unix on VAX: Berkeley Unix became the hacking system par excellence; portable microcomputers swept the field.
      • Richard M. Stallman: "last true hacker" founded Free Software Foundation and began GNU, a free Unix clone in C.
      • Ideological torch: GNU preserved ITS spirit within Unix culture; Stallman led hacker tribe for over a decade.
      • Workstations: Ethernet and 68000 chips led Sun Microsystems (1982) to make Unix on cheap hardware the industry pattern.
  • The Proprietary-Unix Era – The Mail Must Get Through
    • The Proprietary-Unix Era
      • Network nation: Internet/Usenet Unix hackers cohered; microcomputer enthusiasts stayed disconnected.
      • Berkeley Unix and X: ARPAnet support and freely distributed X window system beat proprietary graphics.
      • Fading rivalries: last ITS machine died in 1990; Berkeley and AT&T Unix versions converged.
      • Micro cultures: without networks or shared source, DOS/Mac hackers never developed a common tradition.
      • FSF gap: HURD kernel stalled; FSF supplied most other parts of a Unix-like OS but no kernel.
      • Proprietary failure: costly no-source Unixes lost to Microsoft as portability vanished in bickering.
    • The Early Free Unixes
      • Linus Torvalds: built a free Unix kernel for 386s with FSF tools; early success drew Internet hackers.
      • 386BSD ports: Jolitzes' port spawned freeBSD/netBSD/OpenBSD, building cathedral-style; initially expected to dominate.
      • Sociological novelty: Linux grew from casual hacking by many Internet volunteers, not cathedral coordination.
      • Darwinian method: weekly releases and hundreds of user reports drove rapid selection of good mutations.
      • Competitive results: by late 1993 Linux rivaled commercial Unixes and hosted far more software.
      • Market fallout: proprietary Unix vendors folded; BSDI thrived by selling full sources with its BSD Unix.
    • The Great Web Explosion
      • Web synergy: public Internet access and Linux growth accelerated each other in the early 1990s.
      • Free Unix focus: Linux and 386BSD descendants became central hubs after Berkeley's group shut down.
      • Mass medium: the Web made the Internet mainstream; hackers became ISPs and gained respectability.
      • Political victories: activism defeated Clipper encryption controls and the Communications Decency Act.
      • Narrative shift: the historian became an actor as the movement entered current events.
    • Chapter 2. The Cathedral and the Bazaar
      • Cathedral vs bazaar: centralized, carefully crafted software versus open bazaar of many agendas.
      • Linux overturned assumptions: critical complexity did not require centralized a priori design.
      • Torvalds's style: release early and often, delegate everything, be open to the point of promiscuity.
      • Fetchmail test: a deliberately bazaar-style open-source project yielded aphorisms and success.
      • Core proposition: enough eyeballs make all bugs shallow; self-correcting systems of selfish agents.
    • The Mail Must Get Through
      • Mail problem: SMTP required full-time connection; author needed a POP3 client for intermittent dialup.
      • Personal itch: every good work of software starts by scratching a developer's own itch.
      • Reuse over write: great programmers know what to rewrite and reuse; constructive laziness wins.
      • Source-sharing tradition: Unix/Linux code reuse made finding almost-good-enough code practical.
      • Switch rationale: Brooks's "plan to throw one away" justified abandoning fetchpop for popclient.
      • Successor handoff: losing interest in a program means passing it to a competent successor.
  • The Importance of Having Users – When Is a Rose Not a Rose?
    • The Importance of Having Users
      • Users as co-developers: with source open, users diagnose, suggest fixes, improve code faster than you alone.
      • Linus's real hack: not the kernel but the Linux development model, leveraging user collaboration.
      • Lazy like a fox: Torvalds gets credit by rewarding others' contributions with ego and visible improvement.
      • Precedents: GNU Emacs Lisp library and Emacs VC mode thrived as bazaar-style, user-driven code pools.
      • Two-level architecture: cathedral-mode core plus bazaar-mode toolbox concentrates innovation in the open part.
    • Release Early, Release Often
      • Break with cathedral habit: frequent releases were once thought to wear out users; Linux proved otherwise.
      • Release early, often, listen: Linus scaled rapid turnaround to match complexity, sometimes releasing daily.
      • Linus's Law: enough eyeballs make all bugs shallow; finding the problem is the bigger challenge.
      • Delphi effect: many varied observers beat one expert; self-selection filters make contributors useful.
      • Parallelizable debugging: debuggers need little coordination, so costs avoid Brooksian quadratic blowup.
      • Stable vs. cutting edge: kernel version numbering lets users choose safety or new features, making both attractive.
    • How Many Eyeballs Tame Complexity
      • Weak bug reports: non-source-aware users report surface symptoms, omitting environment and reproduction recipe.
      • Shared representation: open source lets testers hook reports to code, conserving core developers' time.
      • Core and halo: small core pays coordination overhead; halo handles parallel subtasks with little communication.
      • Multi-symptom bugs: a source-level clue can explain several symptoms at once, even without attributing fixes.
      • Parallel trace paths: many testers sampling random paths find the easiest route quickly, especially for deep bugs.
      • Rapid releases amplify: once one tester nails a bug, a new release lets others abandon harder traces.
    • When Is a Rose Not a Rose?
      • Rewrite for understanding: reorganizing popclient made the code fully his own before adding new features.
      • Smart data structures: dumb code with good tables beats clever code with ad-hoc data, per Brooks.
      • Earn the name: fetchmail got its identity only after forwarding mail to SMTP, a genuinely new step.
      • Theory in practice: release often, grow beta list, announce chatty, listen, and reward testers.
      • Immediate payoff: high-quality bug reports with fixes, criticism, and feature suggestions arrived at once.
      • Most valuable resource: treating beta-testers as such made them so; list shrank as fetchmail stabilized.
  • Popclient becomes Fetchmail – Necessary Preconditions for the Bazaar Style
    • Popclient becomes Fetchmail
      • SMTP forwarding: Harry's user idea made other delivery modes obsolete; next best to good ideas is recognizing user ideas.
      • Design reframe: popclient had the wrong problem as combined MTA/MDA; SMTP forwarding made it a pure MTA.
      • Stuck? Reframe the question: ask whether the right question is being asked, not just whether the answer is right.
      • Acknowledge credit: self-deprecating truthfulness about others' ideas earns reputation, as Linus and Perl's Larry Wall show.
      • Delete superannuated features: Saint-Exupéry: perfection is when nothing remains to take away; code better and simpler signals right design.
      • fetchmail name change: new design was sendmail's dual — pulls then delivers rather than pushes; identity emerged from rethinking.
    • Fetchmail Grows Up
      • Category killer: SMTP forwarding filled the niche so well alternatives faded; such results are pulled, not planned.
      • Pushing ideas further: fetchmail extended Harris and Hochheiser; Linus extended Minix; originality is less common than pushing good ideas.
      • Higher standards: write for others' needs beyond your own while keeping the program simple and robust.
      • Multidrop support: added partly for users, mostly to shake bugs out of address parsing; unexpected use: client-side mailing lists.
      • 8-bit MIME: easy because code stayed 8-bit clean; gateway software should never throw away information.
      • Listen to users: added per-session message limits for cost-conscious Europeans despite reluctance; unpaid customers still matter.
    • A Few More Lessons from Fetchmail
      • Noise keywords: ignored English-like rc syntax improves readability; experiment from noticing an imperative minilanguage.
      • Syntactic sugar: terseness is a legacy of expensive cycles; with cheap hardware, human convenience matters more.
      • English-like risks: parser complexity and bent English confuse users; restricted domains make English-like syntax safe.
      • Pseudo-secrets: encrypted rc passwords add no protection; security is only as strong as its secret, so beware fake secrecy.
    • Necessary Preconditions for the Bazaar Style
      • Runnable promise: bazaar development cannot originate from scratch; start with code that runs and seems plausibly evolvable.
      • Coordinator's eye: Linux drew on Unix and fetchmail on popclient; recognizing good ideas matters more than originating them.
      • Restrain cleverness: habitual originality breeds cute, complicated code; fetchmail succeeded partly by resisting that urge.
      • Base competence: expected skill level is a given; open-source reputation markets filter out incapable project starters.
      • People skills: charm and communication attract co-developers; Linus's niceness and ESR's extroversion are not coincidental.
  • The Social Context of Open-Source Software – On Management and the Maginot Line
    • The Social Context of Open-Source Software
      • Origin: best hacks start as personal solutions; to solve an interesting problem, find one that interests you
      • Brooks's Law falsified: adding developers to a late project makes it later; the bazaar's nonlinearities swamp this effect
        • Complexity grows with the square of developers, work only linearly
        • Linux would be impossible if Brooks's Law were the whole story
      • Egoless programming: Weinberg's Psychology of Computer Programming shows non-territorial review accelerates improvement; the bazaar harnesses it
      • Worldwide talent pool: Linux was first to use the entire world as a talent pool
        • Preconditions: cheap Internet, the Web, ISP takeoff
      • Leadership without coercion: Kropotkin's "principle of common understanding" beats command; Linus builds an efficient egoboo market
        • Egoboo: ego satisfaction and reputation drive volunteer effort
      • Evolutionary victory: open-source can outspend closed source in skilled attention; many heads are better than one
    • On Management and the Maginot Line
      • Continuity: open-source projects sustain coherent vision over decades
        • GNU Emacs: 15 years, many contributors, one continuous author
        • Linux: 8 years of rapid hardware and platform change
      • What management buys: no reliable deadlines, budgets, specs, or adaptation
        • 60–75% of conventional projects fail or are rejected
        • Legal liability is an illusion; licenses disclaim warranties
      • Resource marshalling: volunteers bring their own resources; only skilled attention is scarce
        • Projects die only when contributors lose interest
      • Self-selection beats organization: open-source culture accepts the top 5%
        • 100x productivity variance makes herding the rest a poor bet
      • Motivation's Maginot Line: management forces boring work; fascination routes around it
        • Fascination is a more effective motivator than money
      • Joy as asset: enjoyment predicts efficiency; play is the most economically efficient mode of creative work
  • Epilog: Netscape Embraces the Bazaar – Ownership and Open Source
    • Epilog: Netscape Embraces the Bazaar
      • Netscape's source release: announced January 1998, inspired by The Cathedral & the Bazaar, credited by CTO Eric Hahn.
      • Strategy conference: co-designed source-release strategy and license with Netscape in February 1998.
      • Stakes: open source faces large-scale commercial test; failure could discredit it for a decade, success could spark revolution.
      • Mozilla verdict: qualified success—denied Microsoft a browser monopoly, but failed to draw the hoped-for outside effort.
      • Bazaar rule broken: early Mozilla didn't ship runnable code; required proprietary Motif library, delaying contributors and production browser.
      • Jamie Zawinski's warning: “Open source is not magic pixie dust”; it cannot cure ill-defined goals or spaghetti code.
    • The Introductory Contradiction
      • Core contradiction: hackers' official ideology clashes with their actual behavior and ownership customs.
      • Adaptive culture: open-source culture responds to drives and pressures; unconscious adaptations are partly at odds with stated ideology.
      • Method: examining the contradiction reveals the culture's underlying social dynamics and incentives.
    • The Varieties of Hacker Ideology
      • Shared commitment: members agree open source is good, but zealotry and anti-commercial attitudes vary widely.
      • FSF ideology: Stallman's Free Software Foundation framed free software as confrontation against “software hoarding”; GPL is its weapon.
      • Pragmatist tradition: Unix/Internet engineers value good tools and open standards, treat GPL as a tool, not ideology.
      • BSD and Linux: BSD bazaar communities fragmented; Linux made pragmatism a power base and softened anti-commercial purity.
      • Netscape's effect: corporate interest triggered re-labeling of “free software” as open source, welcomed across the culture.
      • Semi-independent cultures: Perl, Tcl, and Python communities grew their own leaders and non-GPL licenses.
    • Promiscuous Theory, Puritan Practice
      • Official theory: open-source licenses guarantee anyone can modify and redistribute, per the Open Source Definition.
      • Fork danger: divergent copies cannot exchange code and split the developer community.
      • Pseudo-forking: separate distributions sharing common code are healthy, not forks.
      • Rare practice: true forks almost never happen; split projects must rename and publicly justify (Emacs/XEmacs, gcc/egcs).
      • Ownership customs: unspoken rules regulate who can modify, under what circumstances, and who may redistribute.
      • Taboos: no forking without dire necessity; no rogue patches or removal of credits without consent.
    • Ownership and Open Source
      • Ownership defined: exclusive community-recognized right to distribute modified versions of a project.
      • Official vs. rogue: maintainers' patches are trusted; third-party rogue patches are unusual and distrusted.
      • Acquiring ownership: found a project, receive the baton from the previous owner, or adopt an orphan after due diligence.
      • Orphan adoption: must seek the owner, announce publicly, wait, and yield to prior claimants; legitimacy grows with visible improvements.
      • Customs in practice: followed consistently for decades, often unconsciously, and evolve toward public accountability and preserved credits.
      • Useful contrast: comparing hackers with pirate “warez d00dz” illumines the generative patterns of both cultures.
  • Locke and Land Title – Ownership Rights and Reputation Incentives
    • Locke and Land Title
      • Lockean property theory: acquire by homesteading, chain-of-title transfer, or adverse possession.
      • Chain of title: documented deeds prove ownership; hackers maintain version histories like title records.
      • Common-law origins: evolved organically where central authority was weak, from Norse and Germanic tribal law.
      • Noosphere analogue: hacker project ownership maps Lockean theory onto the space of programs.
      • Economic logic: Lockean customs arise when return exceeds defense cost, as with !Kung San waterholes.
    • The Hacker Milieu as Gift Culture
      • Gift culture: status comes from what you give away, not what you control; adaptation to abundance.
      • Command hierarchy: allocation by force, poor scaling, status from coercive power; often parasitic.
      • Exchange economy: decentralized trade, status from control of things; scales well.
      • Hacker abundance: disk, bandwidth, and code are plentiful, so peer repute is the status currency.
      • Cracker contrast: secret-hoarding shows gift cultures can take very different forms.
    • The Joy of Hacking
      • Craftsmanship model: pure joy of building beautiful software is a real motivation, not devalued by reputation analysis.
      • Peer evaluation: without scarcity metrics, even craftsmanship cultures rely on reputation games.
      • Unconscious incentives: reputation rewards operate even when craftsmen believe they act purely from love.
      • Maslow's hierarchy: joy of hacking fulfills self-actualization after peer-esteem and security needs are met.
    • The Many Faces of Reputation
      • Primary reward: peer prestige is wired-in status satisfaction.
      • Cooperation magnet: reputation attracts attention and alliance, making gifts effective social currency.
      • Spillover: hacker prestige can yield jobs, consulting contracts, or book deals outside the culture.
      • Critical judgement: complex artifacts make peer evaluation essential; gift quality is hard to assess.
      • Cultural purity: few alternative status paths make repute unusually dominant among hackers.
    • Ownership Rights and Reputation Incentives
      • Homesteading yield: peer repute is the real return; customs maximize reputation incentives.
      • Forking taboo: forks expose pre-fork contributors to reputation risks in both child projects.
      • Rogue patch taboo: patches under owner's name create unfair blame when bugs appear.
      • Name-stripping theft: removing a developer's name steals the gift and is an ultimate crime.
      • Efficiency arguments: duplication and maintenance concerns reinforce taboos but don't explain their emotional force.
      • Global harm: taboo violations reduce confidence that gift/productive work will be rewarded.
  • The Problem of Ego – Noospheric Property and the Ethology of Territory
    • The Problem of Ego
      • Ego taboo: hackers despise egotism, yet reputation drives their reward system—an unresolved cultural contradiction.
      • Cultural inheritance: Western distrust of “ego” forces motivation into disguised forms like peer repute and professionalism.
      • Myth of selflessness: altruism is deconstructed into unacknowledged self-interest by Nietzsche and Rand.
      • Blind spot: the taboo keeps hackers from consciously understanding their own social dynamics.
    • The Value of Humility
      • Cracker contrast: overt status-seeking plus secrecy slows knowledge growth; hackers’ open code accelerates it.
      • Noise control: suppressing boasting and competence attacks protects the reputation scoreboard’s signal quality.
      • Project-labeled bugs: criticism targets code, not authors; fixed bugs earn status, old ones aren’t held against developers.
      • Maintainer humility: needed to show good judgment, give credit, attract contributions.
      • Unfinished posture: being humble about a program invites patches for missing features.
      • Cult avoidance: leaders like Linus Torvalds and Larry Wall self-deprecate to avoid personality cults.
    • Global Implications of the Reputation-Game Model
      • Homesteading analogy: hackers settle the noosphere’s frontier, filling functional gaps at an optimal distance from rivals.
      • Category killers: dominant projects like GNU Emacs absorb would-be competitors into extension work.
      • Historical shift: open-source effort moved from toys and demos to tools to operating systems, then to applications.
      • Future virgin territory: applications for non-techies, led by GIMP and KDE/GNOME toolkits.
      • Protocol pollution: Microsoft’s embrace-and-extend poisons the noosphere hackers need to cultivate.
      • Hacker identity: a hacker becomes one only when other hackers call them hacker.
    • How Fine a Gift?
      • Reliability rule: software must match expectations; beta signals risk, and open-source 1.0 bets reputation.
      • Noosphere extension: breaking closed protocols counts as original work; Samba earns hero status.
      • Distribution certification: inclusion in major distributions certifies quality and prestige.
      • Utilization prestige: widely used, category-killing work earns the most peer esteem; repeated success earns “demigod” status.
      • Effort norms: sustained hard work such as debugging outranks cherry-picking easy hacks; novel “brand identity” gets noticed.
    • Noospheric Property and the Ethology of Territory
      • Property as territory: property is an evolved abstraction of animal territoriality, reducing conflict by marking bounds.
      • Performative claims: even a README’s maintainer name is a boundary declaration backed by community support.
      • Homepage effect: a project web page concretizes abstract noospheric homesteading in spatial web territory, making it feel more real.
      • Hyperlink strength: links and search visibility make a web page a stronger performative claim on territory.
      • Conflict role: ownership customs also exist to prevent and resolve disputes, not just maximize reputation.
  • Causes of Conflict – Conclusion: From Custom to Customary Law
    • Causes of Conflict
      • Four conflict sources: binding decisions, credit/blame, duplication/rogue versions, technical right thing.
      • Technical disputes vanish: objective tests either settle them or reduce to who decides.
      • Three core problems: design authority, contributor credit, preventing project fission.
      • Ownership customs: settle design authority and anti-forking; fit craftsmanship model of protecting vision.
      • Credit customs need reputation game: pure craftsman lacks motive; Lockean property applies within projects.
    • Project Structures and Ownership
      • Single owner/maintainer: no internal conflict; succession and anti-forking norms demand public handoff.
      • Benevolent dictator: common for groups; solves who decides on scale of Linux or Emacs.
      • Credit obligation: owner credits contributors; contributions earn reputation return, like sharecropping.
      • Co-developer tiers: arise from subsystem ownership or lord high fixer role; authority follows responsibility.
      • Subsystem property: maintainer controls implementation and interfaces; leader consults, rarely overrules.
      • Complex models: voting committees (Apache) or rotating dictatorship (Perl) are stable but hard to map onto Lockean ownership.
    • Conflict and Conflict Resolution
      • Territorial rule: authority follows responsibility resolves most technical disputes.
      • Seniority wins: when no one owns territory, side with most invested in project prevails—like database deadlock victims.
      • Leader fiat: backs up customs; disputes surviving both filters are rare.
      • Serious conflict: occurs when rules point differently and leader authority is weak—succession fights worst.
      • Enforcement: community flaming and shunning uphold custom.
    • Acculturation Mechanisms and the Link to Academia
      • Customs transmitted: largely by example (e.g. README convention) rather than explicit instruction.
      • "Mysteries": hidden clues and tests prove acculturation and cultural fitness.
      • Three levels: password-like secrets (alt.sysadmin.recovery), technical initiation (languages), social-context study of project archives.
      • Academic parallel: peer review and reputation; tenure creates post-scarcity gift culture.
      • Common source not settled: customs likely not merely lifted from academia—high-schoolers acquire them readily.
    • Gift Outcompetes Exchange
      • Gift culture is optimal: reputation-game gift exchange beats scarcity rewards for high-quality creative work.
      • Extrinsic rewards hurt creativity: Amabile: commissioned work less creative; complex activity more hurt by reward.
      • Flat pay fine, bonuses bad: piecework/bonuses demotivate; decouple salary, let programmers choose projects.
      • Autonomy matters: Ryan: limited self-determination reduces creativity; controlling feedback demotivates.
      • Recognition without control: reward for work's value does not demotivate; reward for meeting standards does.
      • Zen paradox: productivity requires giving up control; open source outcompetes industrial model.
    • Conclusion: From Custom to Customary Law
      • From custom to law: like Anglo-American land tenure, hacker culture may need written codes and arbitration.
      • Code requirements: voluntary adoption, flexibility over time, broad consensus for enforcement.
      • Malvern Protocol: author's draft model code for dispute resolution, offered for critique and development.
  • Chapter 4. The Magic Cauldron – The “ Information Wants to be Free ” Myth
    • Indistinguishable From Magic
      • Cauldron metaphor: open source seems to conjure high-quality software for free; the real question is sustainability.
      • Ephemeralization: technology becomes more effective and cheaper as physical inputs are replaced by information.
      • Clarke’s law: sufficiently advanced technology is indistinguishable from magic; open source’s magic has an economic explanation.
    • Beyond Geeks Bearing Gifts
      • Gift culture is insufficient: status competition explains motivation but not how developers stay viable inside scarcity economics.
      • Economic lens: analyze open source as cooperation and exchange under scarcity; answer “How do I make money at this?”
      • Non-ideological case: open source wins on engineering and economic outcomes—quality, reliability, cost, choice—not anti-IP or altruism.
    • The Manufacturing Delusion
      • Two values: software has use value as a tool and sale value as a commodity; factory-model pricing conflates them.
      • Use-value dominance: about 95% of programming jobs serve in-house use, not sale; maintenance is over 75% of paid work.
      • Sale-value myth: price tracks expected future vendor service, not development cost; orphaned software collapses in value.
      • Factory-model incentives: reward shelfware, starve support, push markets toward monopoly and orphaning.
      • Service pricing: contracts, subscriptions, and ongoing exchange fit real life-cycle costs; ERP already works this way.
      • Open-source effect: freeing bits forces service-fee world and grows support demand; programmers gain, closed-source-only bets lose.
    • The “ Information Wants to be Free ” Myth
      • The myth: zero marginal copying cost does not imply zero clearing price.
      • Standards vs pointers: standards gain value with wider access; treasure maps and passwords inherit the cost of rivalrous goods.
      • Not the basis: open-source utility arguments hold even if software keeps the value structure of a manufactured good.
  • The Inverse Commons – Why Sale Value is Problematic
    • The Inverse Commons
      • Tragedy of the Commons: overuse and underprovision doom shared goods unless coercion or enclosure intervenes.
      • Inverse commons: using software adds value; patches make the grass grow taller, so overuse is impossible.
      • Timely need: people need solutions on time, so any sufficient payoff triggers contribution despite free riders.
      • Patch value: small fixes are hard to price or collect for, even with ideal micropayment systems.
      • Optimal selfishness: contributing avoids future re-merging costs and invites reciprocal improvements.
      • Friction costs: submission hoops, not end-user free riding, limit contributors; Linux outcompeted BSD/FSF.
    • Reasons for Closing Source
      • Sale value: the only rational reason for closing most software; 95% written for internal use has none.
      • Competitor denial: weigh development-load gains against free-rider competition, counting development costs as sunk.
      • Business logic: secrecy fears betray bad design; separate sensitive schemas from open-sourced engines.
      • Security: closed source doesn't secure systems; only peer-reviewed algorithms can be trusted.
    • Use-Value Funding Models
      • Use vs. sale value: open source threatens only sale value, so use value alone can fund development.
      • Apache case: cost-sharing webmasters pooled effort, beating proprietary servers and roll-your-own.
      • Apache result: 60% market share with no owner, promotion, or contracted service organization.
      • Cisco case: risk-spreading; open-sourcing print-spooler hedged against developers leaving.
      • Risk mitigation: multi-funded communities provide fail-safe economically valuable enough to attract support.
    • Why Sale Value is Problematic
      • Social contract: open-source licenses impede sale-value capture more by norms than by technical barriers.
      • Symmetry: hackers oppose privileged profit positions; Netscape Public License is a tolerated exception.
      • Unintended consequences: sale restrictions chill cheap CD-ROM redistribution and explode legal uncertainty.
      • Forking option: must preserve last resort against maintainer incompetence or license defection; Sun's Community Source failed.
      • Open Source Definition: written to express consensus, its clauses make direct sale value hard to capture.
  • Indirect Sale-Value Models
    • Market-Position Models
      • Loss-leader/market positioner: open-source software creates or maintains a market for proprietary revenue streams.
      • Netscape's Mozilla: open-sourcing the browser denied Microsoft a browser monopoly and protected server sales.
      • Widget frosting: hardware makers open-source drivers and OS layers because software is overhead, not profit.
      • Future-proofing: source access lets customers patch drivers after hardware support ends, building loyalty.
    • Service-Led Models
      • Give away the recipe, open a restaurant: open-source software to sell services, not closed products.
      • Cygnus Solutions: pioneered by domesticating GNU tools and selling support plus configured binaries.
      • Red Hat model: sells assembled, tested, warranted distributions and support, not bits alone.
      • Digital Creations/Zope: open-sourcing core tool markets the team's expertise and builds customer trust.
      • e-smith: free downloads of turnkey server software considered free marketing for support contracts.
    • Accessorizing and Delayed Openness
      • Accessorizing: sell low-end gear (mugs, T-shirts) or high-end documentation around open software.
      • O'Reilly: hires and supports well-known open-source hackers to build reputation in its market.
      • Free the future, sell the present: closed license guarantees code goes GPL later or if vendor folds.
      • Aladdin/Ghostscript: successful model; older GPLed code gets peer review and eases maintenance burden.
      • Drawback: closure provisions inhibit early peer review, exactly when it is most needed.
    • Speculative Models
      • Sell the brand: open-source the technology, sell a compatibility brand validated by tests.
      • Sun/Star Office: announced open-sourcing plus brand certification for code passing validation suite.
      • Sell the content: open-source client and server, sell subscriptions to reliable content.
      • AOL rationale: open-sourcing its client would expand the market for content subscriptions.
  • When to be Open, When to be Closed – Open Source and Strategic Business Risk
    • When to be Open, When to be Closed
      • Payoff trade-off: closed source collects rent from secret bits; open source gains independent peer review, whose payoff is usually underestimated.
      • Reliability payoff: peer review is the only scalable route to high reliability and quality, proven by Linux and Internet software.
      • Trust, standards, symmetry: users avoid supplier monopoly; visible code, equal rights, and future-proofing favor open infrastructure.
      • Five discriminators: reliability, hard-to-verify correctness, business-criticality, infrastructure role, and common engineering knowledge favor open source.
      • Doom’s crossover: as imitation and network effects eroded secret-bit rent, id Software rationally released source and exploited secondary markets.
      • Let-go timing: missing the crossover invites a first open-source entrant that captures sticky users and developers.
    • Open Source as a Strategic Weapon
      • Cost-sharing weapon: Apache lets each participant field a superior, majority-market-share web server against Microsoft IIS at lower cost.
      • Resetting the competition: DEC funded X Window System to neutralize Sun’s graphics advantage and shift rivalry to hardware.
      • Growing the pond: Red Hat funded RPM to standardize Linux installation, enlarging the market and weakening Microsoft’s admin advantage.
      • Preventing a chokehold: Netscape open-sourced Mozilla to block Microsoft locking up HTML and HTTP; bigger blocking coalitions win.
    • Open Source and Strategic Business Risk
      • Customer’s dilemma: opaque, unmodifiable closed source makes key business processes run out of your control.
      • Supplier monopoly: one vendor controls fixes; it needs you less than you need it, and lock-in deepens.
      • Open-source choice: source code can’t be taken away; multiple service vendors bid, or you build a captive support organization.
      • Fiduciary risk: choosing closed source when an open alternative exists may soon be shareholder-actionable irresponsibility.
  • The Business Ecology of Open Source – Conclusion: Life after the Revolution
    • The Business Ecology of Open Source
      • Tier separation: developers, distributors, and users form a fluid internal market for improvements.
      • No indispensable node: failing developers or distributors don't damage the common code base.
      • Specialization: developers avoid closed-project tar pits—no marketing checklists, no deadlines, no mandated tools.
      • Distributor value: integration, packaging, quality assurance, and service, aided by constant user feedback.
    • Coping with Success
      • Fragmentation risk: unlike proprietary Unix, Linux can't fragment; licenses force sharing of every cloned feature.
      • Competition moves to service, support, and ease-of-use, benefiting consumers.
      • Monopoly risk: Red Hat's bits are not ownable; the community routes around control attempts.
      • Red Hat survives by selling brand/service/support, not by monopolizing source code.
    • Open R&D and the Reinvention of Patronage
      • Corporate labs: Red Hat, O'Reilly, and VA Linux pay star hackers to grow their markets.
      • Economic logic: dominant players capture a lion's share of returns despite free riders.
      • Goodwill motive: firms hire talent as "the right thing," buying goodwill and trust.
      • Service-industry pattern: resembles law firms, universities, and aristocratic patronage of art.
    • Getting There From Here
      • Capital influx: Linuxcare and Red Hat's successful IPO show rising investor interest.
      • Task markets: SourceXchange and CoSource apply reverse-auction models to fund open-source work.
      • Open-source momentum: Linux and Apache gain share; open-source OSes lead on Internet hosts.
    • Conclusion: Life after the Revolution
      • Open Source Doomsday refuted: software demand keeps programmers busy even if code is free.
      • Infrastructure will be almost all open source, maintained by consortia and service firms.
      • Applications stay closed where network effects are weak and reliability costs are low.
      • Middleware will be mixed, with higher failure costs pushing toward openness.
      • Categories decay: applications become middleware, middleware becomes infrastructure; closed software dies or opens.
  • Afterword: Why Closing a Drivers Loses Its Vendor Money
    • The copy myth
      • Old resistance: hardware vendors historically hid specs; Adaptec and Cyclades now open up
      • Old logic: three- to five-year product cycles made secrecy a plausible defense
      • Shorter cycles: copying consumes time that competitors should spend innovating
      • Kalugin’s lesson: stolen designs still left the Soviets perpetually behind
      • Kipling’s dictum: “They couldn’t copy my mind”—stay ahead and let rivals chase you
      • Internet time: acceleration makes plagiarism a trap you want competitors to fall into
    • Secrets don’t stay secret
      • Drivers are easy: small binaries invite disassembly and cloning by novices
      • Hacker speed: simple interfaces let Linux/FreeBSD programmers prototype without docs
      • Legal barriers are porous: an international effort always finds a legal jurisdiction
      • Proof: Linux supported-device lists grow fast even without vendor support
    • Reasons to go open
      • Innovation focus: no internal staff time spent rewriting and distributing kernel binaries
      • Rapid fixes: nobody waits six months; open competitors win on responsiveness
      • Future-proofing: customers value open drivers for extending hardware lifetime
      • Revenue effect: poor or hidden drivers hurt hardware sales; open drivers boost them
      • Market confidence: openness demonstrates you can out-think and out-innovate rivals
    • If secrecy is unavoidable
      • Strategic warning: closed looks attractive short-term but is bad strategy against open rivals
      • Fallback plan: burn code into ROM and publish the interface to it
      • Closed costs: secrets leak, no free development help, and no cloned rivals wasting time
      • Adoption penalty: server managers write off closed vendors and buy from open ones
  • Chapter 5. Revenge of the Hackers – The Accidental Revolutionary
    • Beyond Brooks's Law
      • Linux shock: Amateur hackers had produced a quality multitasking OS, breaking the assumption that only professionals could.
      • Brooks's Law: Work scales as N, but complexity and bugs scale as N²; thousands of contributors should be unmanageable.
      • Beat the N² effect: Linux defeated Brooks's Law; understanding how took years of observation and experiment.
      • From spectacle to theory: The polished Ferrari-like system convinced the author the hacker method deserved deep analysis.
    • Memes and Mythmaking
      • Unstated method: The community had an effective development practice but lacked the theory or language to explain it.
      • Memetic engineering: Chapter 2's vivid metaphors and narrative aimed to reshape hacker culture's generative myths.
      • Early reception: Rapt attention at Linux Kongress, then cheers and a standing ovation at O'Reilly's Perl Conference.
      • Netscape's crisis: Microsoft threatened to bend Web standards into proprietary channels; Netscape debated opening its browser source.
      • Chapter 2 tipped the case: It provided key reasons to believe open source could stop Internet Explorer dominance.
    • The Road to Mountain View
      • "Shot heard 'round the world": Netscape announced browser source release on 22 January 1998, citing the author's work as fundamental inspiration.
      • High stakes: Failure would discredit hackers for another decade; success was essential to escape the ghetto.
      • Hands-on help: Author advised on licensing and strategy, flew to Mountain View, and helped shape the Mozilla Public License.
      • Longer strategy: The community needed follow-through so Netscape's breakthrough would not become a one-off experiment.
    • The Origins of "Open Source"
      • Rebranding as marketing: "Open source" was coined at VA Research on 3 February 1998 to sell pragmatically to managers and investors.
      • Free software stigma: "Free" ambiguity plus FSF stereotypes repelled corporate buyers, regardless of FSF's actual positions.
      • Top-down evangelism: Unix's bottom-up tactics failed; Netscape's breakthrough came from a CEO, so target executives.
      • Linux as flagship: Best name recognition, broadest base, largest community; if Linux cannot consolidate, nothing will.
      • Fortune 500 and prestige media: Target concentrated corporate buying power through the New York Times, WSJ, Economist, Forbes, and Barron's.
      • Certification mark: "Open Source" was tied to the Open Source Definition to prevent corporate corruption; the trademark faded but the term had momentum.
    • The Accidental Revolutionary
      • Personality required: Press tunes out abstractions; the story needs drama and a larger-than-life frontman.
      • Reluctant role: Author accepted evangelism despite losing privacy, hacking time, and facing suspicion from his own tribe.
      • Attractive dissonance: Provocative topics plus wholesome honesty create curiosity that promotes the ideas.
      • Exponential coverage: Ten months of surging Linux media coverage followed; about a third of articles quoted him directly.
      • Succession plan: Charisma should give way to institutional respectability; the Open Source Initiative was built to carry on.
  • Phases of the Campaign – Chapter 6. Afterword: Beyond Software?
    • Phases of the Campaign
      • Open-source label: adopted to offer a less doctrinaire message than the Free Software Foundation.
      • Free Software Summit: leaders ratified the term; mainstream press caught on.
      • Infrastructure dominance: Apache, Perl, Sendmail, BIND already led key Internet layers.
      • Fragile victory: Oracle and Informix ports made Linux safe after Mozilla's slow start.
      • Halloween Documents: Microsoft's leaked memos validated open source and drove Wall Street interest.
      • Windows Refund Day: guerrilla theater helped end the “Microsoft tax” on new PCs.
    • The Facts on the Ground
      • Technical progress: Linux gained SMP, 64-bit cleanup, Titanic rendering, and Beowulf clustering.
      • Market gains: Apache led; Netscape reversed its slide; IDG predicted Linux growth.
      • Mozilla lesson: Jamie Zawinski resigned; open source is “not magic pixie dust.”
      • ISV adoption: Computer Associates backed Linux; surveys named it essential in enterprise strategies.
      • Linux IPOs: Red Hat and VA Linux created a durable for-profit open-source industry.
    • Into the Future
      • Short-term predictions: developer population explodes; Linux leads; C-level awareness grows.
      • Windows 2000: shipped with curtailed features and weak adoption, validating the forecast.
      • Data-center capture: Linux will own ISPs and data centers; proprietary Unix nearly collapses.
      • Microsoft pressure: fixed per-unit OEM fees break near the $350 desktop price point.
      • GUI challenge: hackers design for hackers; Macintosh-style ease must reach ordinary users.
      • Eazel: original Macintosh designers aim to bring “Macintosh magic” to Linux.
    • Chapter 6. Afterword: Beyond Software?
      • One battle at a time: focus on winning software before applying open source elsewhere.
      • Music and books: don't need debugging or maintenance, so open-sourcing offers little.
      • Political implications: open source harmonizes with libertarianism, but avoid over-application.
      • Victory timeline: software battle winnable by 2003–2005; then leverage insights wider.
      • Changing the world: even without ideological noise, hackers are already reshaping institutions.
  • What Is a Hacker? – Points For Style
    • What Is a Hacker?
      • Hacker: member of a shared culture of expert programmers and networking wizards.
      • Built the Net: hackers created the Internet, Unix, Usenet, and the World Wide Web.
      • Cracker: security breaker; real hackers say crackers are lazy, irresponsible, and not bright.
      • Builder vs. breaker: hackers build things, crackers break them.
      • Mindset beyond software: hacker attitude appears at high levels of any science or art.
      • Recognition: you are a hacker when other hackers know you and call you one.
    • The Hacker Attitude
      • Problem thrill: feel a basic delight in solving problems and exercising intelligence.
      • Learning faith: tackle one piece, learn from it, and keep solving the next.
      • No re-invention: creative brains are precious; give solutions away so others solve new problems.
      • Anti-drudgery: boredom and repetitive work are evil; automate the boring bits.
      • Freedom: hackers are anti-authoritarian; fight censorship, secrecy, and coercion.
      • Competence over attitude: respect skill everywhere; practice, dedication, and hard work matter.
    • Basic Hacking Skills
      • Programming: the fundamental skill; learn to think about problems independent of any language.
      • Language set: Python first, then Java, C/C++, Perl, and LISP — each teaches different thinking.
      • Reading and writing code: learn by studying masters, then writing your own, repeatedly.
      • Unix: install Linux or BSD; Unix powers the Internet and open source lets you tinker.
      • Web and HTML: learn to write markup; build a page with useful content, not sludge.
    • Status in the Hacker Culture
      • Gift culture: hackerdom runs on reputation; you gain status by giving things away.
      • Open-source software: write programs hackers find useful, and give the sources away.
      • Beta-testing: good testers who localize problems clearly are worth their weight in rubies.
      • Publishing: collect and filter useful information into FAQs and web documents.
      • Infrastructure: volunteer for mailing lists, newsgroups, archives, and standards.
      • Culture service: become a tribal elder or historian; avoid blatant ego.
    • The Hacker/Nerd Connection
      • Nerd not required: but social outcast status helps concentration on thinking and hacking.
      • Badge of pride: adopt "nerd" or "geek" to declare independence from social expectations.
      • Having a life: possible today; hackers can be good lover and spouse material.
    • Points For Style
      • Write well: learn to write your native language; many top hackers are able writers.
      • Cross-training: science fiction, Zen, martial arts, music, and wordplay build hacker minds.
      • No posing: avoid grandiose handles, flame wars, "cyberpunk" labels, sloppy writing.
      • Real names: declare pride in your work; hiding behind a handle marks you as a loser.
  • Other Resources – Appendix B. Statistical Trends in the Fetchmail Project's Growth
    • Other Resources
      • Hacker FAQ: Peter Seebach's guide helps managers understand how to deal with hackers.
      • ESR's essays: A Brief History of Hackerdom, The Cathedral and the Bazaar, and Homesteading the Noosphere explain open-source culture.
    • Frequently Asked Questions
      • Self-teaching: hacking is an attitude and skill you must acquire yourself; show initiative before asking experts.
      • Getting started: join a local Linux user group; a motivated start at any age works.
      • Language path: learn HTML, then Python; C matters later; avoid Visual Basic and Delphi.
      • Security ethics: no help with cracking or passwords; Windows is insecure and best abandoned.
      • Open-source livelihoods: free software creates jobs and demand; write good code instead of hating Microsoft.
    • Appendix B. Statistical Trends in the Fetchmail Project's Growth
      • Graph: Gnuplot 3.7 scattergram from NEWS-file data and custom shellscripts, starting October 1996 at version 1.9.0.
      • Metrics: tracks total participants, post-split friend/announce lists, and lines of code.
      • Linear growth: project population grew steadily; list turnover was roughly 5% per month.
      • Key event: release 4.3.0 (October 1997) moved code to maintenance mode and split the list.
      • After split: developer population stabilized near 250; later growth came mostly from announce-list users.
      • Code size: sublinear, perhaps logarithmic, unlike population's linear trend.
  • The Cathedral and the Bazaar
    • Scaling and Organization
      • Hasler's Law: duplicated work costs scale sub-quadratically with team size, making bazaar duplication cheap.
      • Three size regimes: small projects need only a lead; midrange uses management; large projects make management's net value zero.
      • Brooks's Law contrast: complexity overhead scales with team size, but duplication is a special case that doesn't.
    • Deadlines and Quality
      • Stable/experimental split: hedges risk and attacks the deadliness of deadlines.
      • "Wake me up when it's done": flexible delivery beats realistic or aggressive scheduling in quality and speed.
      • GNOME 1.0 caution: premature release can neutralize most quality benefits of open source.
      • Three quality drivers: process transparency, anti-deadline scheduling, and developer self-selection.
    • Bazaar Tactics in Practice
      • EGCS experiment: same source base, tools, and developer pool; bazaar-style management won decisively.
      • GCC's transition: FSF dissolved original GCC group and handed control to EGCS steering team.
      • Core-plus-halo vs surgical team: generalists with powerful tools replace Brooks's specialist roles.
    • Innovation and Individuals
      • Halloween Documents critique: bazaar chases taillights claim contradicted by Linux's state-of-the-art firsts.
      • Insight is individual: groups develop and test ideas, but breakthroughs spark in one person's head.
      • Social machinery's role: nourish, reward, and rigorously test insights rather than squash them.
      • Freshmeat test: count original releases; open-source channels show more innovation than closed ones.
    • Communication and Power
      • Conway's Law: system designs copy organizational communication structures; means determine ends.
      • Peer-to-peer organization: open source mirrors the Internet's distributed, redundant, graceful-degradation network.
      • SNAFU Principle: true communication only between equals; inferiors tell pleasant lies to power.
      • Kropotkin's warning: power relationships cost bugs, productivity, and lost opportunities.
  • Homesteading the Noosphere – For Further Reading:
    • Homesteading the Noosphere
      • Noosphere: the "sphere of human thought" concept, coined by LeRoy, popularized by Vernadsky and Teilhard de Chardin.
      • Open process: low entry barriers make participation beat secession; Linux's openness prevented forking while BSD's centralization didn't.
      • Rogue patches: friendly patches seek merge; unfriendly patches compete and push toward forking.
      • Reputation economy: founders harvest prestige like early IPO investors; new territory outweighs later equal contributions.
      • Gift-culture signaling: humility and costly source-code gifts signal fitness, like a peacock's tail or the knightly ideal.
    • The Magic Cauldron
      • Talent curve: skilled contributors find fitting projects early; talent assimilation follows a logistic curve, not linear scaling.
      • Service-cost trap: fixed up-front price is swamped by future service costs; the factory model rewards shelfware and penalizes quality.
      • Accounting fiction: software firms book programmers as expenses and hardware as assets, distorting value and driving acquisitions.
      • Defection forking: closed licensing can trigger a fork, as OpenSSH split from SSH.
      • Underprovision: free-riding worries are muted because qualified people self-select into projects matching their interests.
    • For Further Reading:
      • Parallel requirements: Ross Anderson's How to Cheat at the Lottery applies bazaar-style parallelism to security requirements.
      • Gift vs commodity: Baird's Scientific Instrument Making reaches Homesteading-like conclusions without touching software.
      • Formal modeling: Khalak's Evolutionary Model for Open Source Software simulates market penetration and cost/behavior parameters.
      • Business case: Mantarow's Open Source Software as a New Business Model studies Red Hat as a case of lowering entry barriers.
      • Provocative polemic: Moglen's Anarchism Triumphant is entertaining but flawed—"software flows in the wires."
  • Colophon – SPECIAL OFFER: Upgrade this ebook with O’Reilly
    • Cover Design
      • Cover creation: built in Adobe Photoshop 5.0 and QuarkXPress 4.1 with Interstate and Sabon fonts.
      • Cover art: Liubov Popova's 1913 painting Composition with Figures, from the State Tretyakov Gallery.
    • Interior Typography
      • Body font: Adobe Sabon, designed by Jan Tschichold in 1964.
      • Design roots: roman based on Garamond; italic based on Robert Granjon's typefaces.
      • Trademark: Sabon is a registered trademark of Linotype-Hell AG.
    • Production Workflow
      • Authoring: done with GNU Emacs using DocBook 4.1 markup.
      • Formatting: custom perl and GNU troff tools developed by Steve Talbott, Norm Walsh, and Lenny Muellner.
    • Credits
      • Core contributors: Tim O'Reilly, Edie Freedman, Sarah Jane Shangraw, Claire Cloutier, Lenny Muellner, David Futato, and many others.
      • Online edition: Safari production group used Frame-to-XML conversion tools by Erik Ray, Benn Salter, John Chodacki, and Jeff Liggett.
    • Special Offer
      • Ebook upgrade: $4.99 at oreilly.com adds DRM-free PDF and EPUB formats.
      • Lifetime updates: included free with the upgraded edition.
• Core Conclusion and Practical Takeaways
  • Core Conclusions
    • Bazaar beats cathedral: open, decentralized peer review outcompetes centralized design for complex software.
    • Linus's Law: enough eyeballs make all bugs shallow; finding the problem is the harder step.
    • Release early, release often: rapid releases plus user feedback drive Darwinian selection of good mutations.
    • Gift culture wins: reputation, not money, fuels the most creative high-quality work.
    • Open source is sustainable: use value, service models, and market positioning fund it, not magic.
    • Ownership customs prevent forking: clear maintainer rights and credit norms keep communities coherent.
  • Practical Development Practices
    • Scratch your own itch: every good work of software starts from a developer's personal problem.
    • Start with runnable code: bazaar development needs a promising base, then open it to contributors.
    • Treat users as co-developers: with source open, users diagnose, patch, and improve faster than one team.
    • Listen to your testers: reward good bug reports with fixes; the beta list is your most valuable resource.
    • Delete superannuated features: perfection means nothing left to take away; simpler code signals right design.
    • Hand off when interest fades: passing a project to a competent successor preserves momentum and community trust.
  • Business and Strategy Takeaways
    • Choose open for infrastructure: reliability, verifiability, and common knowledge favor open source.
    • Give away the recipe, open a restaurant: sell support, services, or validated brands around open code.
    • Use open source as a weapon: cost-sharing coalitions can neutralize competitors' proprietary advantages.
    • Avoid the manufacturing delusion: software price tracks service value, not development cost or copies.
    • Watch for the let-go timing: when secret-bit rent erodes, open-sourcing first captures users and developers.
    • Plan for business ecology: developers, distributors, and users form a fluid market with no indispensable node.
  • Mindset Shifts
    • Fascination beats coercion: joy and play are the most economically efficient modes of creative work.
    • Self-selection beats organization: accept the top talent and let people choose what fascinates them.
    • Humility earns influence: self-deprecating leaders attract contributions and avoid personality cults.
    • Build, don't break: hackers construct the Net; crackers are lazy, irresponsible, and not bright.
    • Give credit lavishly: acknowledging others' ideas builds reputation and draws more collaboration.
    • Learn by doing: read masters' code, write your own, and publish useful information to gain status.