**Author:** [[3. Resources/Authors/Siobhan McKeown|Siobhan McKeown]] # Book Overview ![[Milestones The Story of WordPress Visual.excalidraw]] ## About the Author Siobhan McKeown is a writer and community member who conducted extensive interviews with WordPress contributors, founders, and participants for this project. The book draws on dozens of original interviews (archived at archive.wordpress.org), mailing list archives, trac tickets, blog posts, and community discussions spanning from 2001 to roughly 2014. It was published as a free, open-source book on WordPress.org -- fitting for a project about free software. McKeown brings a journalist's distance to the material, but she's clearly embedded in the community she's documenting, which gives the book access to people and perspectives that an outside historian wouldn't get. ## Central Thesis WordPress didn't succeed because it was technically superior. It succeeded because it prioritized users and freedom -- and because its community, however messy and contentious, kept pulling the project forward through arguments about licensing, governance, design, and commercialization. The book traces WordPress from its origins as a fork of b2/cafelog in 2003 through to WordPress 3.8 in 2013, and the recurring theme is tension: between Matt Mullenweg's BDFL (benevolent dictator for life) role and community ownership, between the GPL's freedoms and developers' desire to protect their commercial work, between design-by-committee and top-down decision-making, and between hobbyist origins and enterprise scale. WordPress's story isn't one of smooth ascent. It's a story of productive conflict -- where the bazaar model produces software people love, but also produces arguments that nobody wins cleanly. ## Why This Book Matters Most accounts of open-source projects are either hagiographic (the founder is a genius, the community is harmonious) or technical (here's how the code evolved). This book is neither. It documents the political, social, and economic realities of running a free software project at scale -- the trademark disputes, the GPL enforcement battles, the design failures, the mailing list flame wars, and the commercial ecosystem that grew up around free code. For anyone interested in how open-source projects actually work (as opposed to how they're supposed to work), this is a useful primary source. It's also a record of a period in web history -- roughly 2003 to 2013 -- when personal publishing tools shaped the internet's architecture in ways we're still living with. --- # Chapter Summaries ## Part One ### Chapter 1: Hello World The book opens with the backstory of b2/cafelog, the blogging software that WordPress forked from. Michel Valdrighi created b2 on the French island of Corsica in 2001. It was a PHP/MySQL blogging tool that attracted a small developer community. When Michel went silent in 2002, the project stalled, and Matt Mullenweg -- a college freshman in Houston -- wrote a blog post suggesting someone should fork it. Mike Little responded in the comments. WordPress was born from that exchange in January 2003. ### Chapter 2: The Only Blogger in Corsica This chapter fills in Michel Valdrighi's story -- a self-taught developer in Corsica who built b2 because he wanted a blogging tool that used PHP and MySQL. He attracted contributors, but personal issues pulled him away from the project. His absence created the opening for Matt and Mike's fork. The chapter establishes the accidental-founder pattern that recurs throughout WordPress history: people building things because they need them, not because they have a business plan. ### Chapter 3: The Blogging Software Dilemma Matt evaluates the available blogging options in late 2002 -- Movable Type, Textpattern, b2 -- and decides to fork b2 rather than switch platforms. The chapter covers the early development decisions, including the name "WordPress" (suggested by Christine Tremoulet), and the first release in May 2003. It also introduces the project's earliest infrastructure: SourceForge for code hosting, a wiki, IRC for communication. ### Chapter 4: Guiding Principles WordPress's core philosophy takes shape: decisions not options, the 80/20 rule (build for 80% of users), clean permalinks, and a focus on the user experience. The chapter traces how Matt Mullenweg adapted ideas from GNOME contributor Havoc Pennington's writing about user interface design in free software. These principles would become both WordPress's greatest strength and a source of recurring conflict, as "decisions not options" repeatedly clashed with community members who wanted more control. ### Chapter 5: The GPL The GPL chapter covers the licensing choice that would define WordPress's commercial ecosystem for the next decade. WordPress inherited the GPL from b2/cafelog. The chapter explains copyleft, the four freedoms, and the distinction between "free as in beer" and "free as in freedom." This licensing decision -- which Matt and the early developers didn't agonize over much at the time -- would produce the project's biggest and most sustained conflicts as commercial themes and plugins emerged. ### Chapter 6: WordPress' First Developers The early developer community coalesces around a handful of contributors: Ryan Boren, who became WordPress's first lead developer and workhorse coder; Alex King, who contributed early UI improvements; Dougal Campbell; and others from the b2 community. The chapter traces how commit access worked in the early days -- essentially, Matt and Ryan decided what went in. Development was fast, informal, and personality-driven. ### Chapter 7: Inside the Bazaar A direct engagement with Eric Raymond's "The Cathedral and the Bazaar." The chapter examines how WordPress's development model fits Raymond's open-source framework. WordPress isn't a pure bazaar -- Matt functions as a BDFL, and major decisions often happen in private Skype channels or small meetings rather than on the mailing list. But the project's low barrier to entry and its willingness to accept contributions from anyone who shows up and does the work makes it more bazaar than cathedral. ### Chapter 8: Support and Documentation The early support forums and documentation (the WordPress Codex) take shape. Mark Riley emerges as a key figure in support. The chapter documents a recurring WordPress problem: documentation is hard to keep current, and the people who are best positioned to write it (core developers) are also the busiest. The Codex becomes a sprawling, partially outdated resource -- useful but messy. ### Chapter 9: Freedom Zero WordPress's relationship with Movable Type gets its defining moment. In May 2004, Six Apart changed Movable Type's licensing terms, restricting free use. Matt wrote the "WordPress, that's what" post, and WordPress saw a massive influx of users migrating from Movable Type. The chapter makes the argument that WordPress's GPL license was a strategic advantage, not just an ethical choice -- users trust software they know won't have its terms changed on them. ### Chapter 10: WordPress 1.2 "Mingus" The first named release (after jazz musician Charles Mingus, establishing the naming convention). This version introduced the plugin API -- one of the most consequential architectural decisions in WordPress history. By letting third-party developers extend WordPress without modifying core code, the plugin system created the ecosystem that would eventually drive WordPress's dominance. The chapter covers Ryan Boren's work on the plugin architecture and the decision to use hooks and filters. ### Chapter 11: The Birth of wp-hackers The wp-hackers mailing list launches as the primary venue for development discussion. It starts productively but gradually becomes a venue for bike-shed arguments -- extended debates about trivial topics while major decisions happen elsewhere. The chapter tracks this decline and its consequences for the project's openness. ### Chapter 12: Themes Michael Heilemann's Kubrick theme becomes WordPress's default in version 1.5, giving WordPress a distinctive visual identity. The theme system -- allowing users to change their site's appearance without touching code -- is a major user-facing feature. But the chapter also documents the friction between Heilemann and the project, and the challenges of designing for a community. ### Chapter 13: Development in a Funnel The development process struggles with scale. The gap between WordPress 2.0 and 2.1 stretches to an agonizing year, because feature-driven releases keep expanding scope. This chapter documents the shift toward fixed release cycles -- the "120-day" schedule inspired by Ubuntu and other projects. The principle of "deadlines are not arbitrary" emerges, though as later chapters show, the project would violate this principle repeatedly. ## Part Two ### Chapter 14: A New Logo WordPress gets a new logo designed by Jason Santa Maria. The chapter is short but documents a characteristic WordPress decision: the logo was chosen by Matt from proposals by a professional designer, not through community vote, which caused some grumbling. ### Chapter 15: WordPress Incorporated Matt Mullenweg and the early business decisions around WordPress. This covers the formation of Automattic (the company behind WordPress.com) and the complex relationship between the company, the open-source project, and the WordPress.org website. The chapter sets up the tension that runs through the rest of the book: Automattic benefits from WordPress, hires from the community, and contributes to the project, but it isn't the project. ### Chapter 16: WordPress.com The launch of WordPress.com as a hosted blogging service built on WordPress MU (multi-user). The chapter covers how WordPress.com served as a testing ground for features that would later land in the self-hosted WordPress software, and the early commercial dynamics of offering a free software product as a hosted service. ### Chapter 17: Akismet Akismet launches as a commercial anti-spam service -- one of Automattic's first revenue products. The chapter covers the spam problem in blogging and how Akismet became the default anti-spam solution. It's also an early example of the commercial model that would define the WordPress ecosystem: give the software away, sell the service. ### Chapter 18: Shuttle The Shuttle project was WordPress's first serious attempt to redesign its admin interface, led by a team of community volunteers. It failed. The chapter documents why: the team worked behind closed doors, produced beautiful mockups that didn't get implemented, and the community felt excluded from the process. Shuttle established a pattern -- design work in WordPress is hard because the community expects to be involved, but design by committee produces poor results. ### Chapter 19: Automattic The chapter covers Automattic's founding, early hires (mostly from the WordPress community), and initial funding. It documents the company's distributed-work culture and its unique position: a for-profit company built on a free software project, where the founder (Matt) is both the company CEO and the project's BDFL. This dual role creates both advantages (resources for the project) and conflicts (whose interests does Matt serve?). ### Chapter 20: Growing Pains As WordPress grows in popularity, the project's informal structures start to crack. Communication is scattered across IRC, Skype, mailing lists, trac, and various blogs. Decision-making is opaque. New contributors can't figure out how to get involved. The chapter documents the growing gap between WordPress's user-friendly reputation and its contributor-unfriendly reality. ## Part Three ### Chapter 21: WordCamp 2006 The first WordCamp -- a community conference in San Francisco. The chapter covers the origins of the WordCamp format: informal, volunteer-organized, and cheap. It also documents some early governance tensions around events and the beginning of what would become a global WordCamp program. ### Chapter 22: Speeding Up the Release Cycle After the painful year-long gap between 2.0 and 2.1, the project adopts the 120-day release cycle. This chapter details how the new cadence worked in practice: WordPress 2.2 and 2.3 shipped roughly on schedule, though features sometimes had to be pulled to meet deadlines. The taxonomy system (tags) caused particular problems -- over-engineered through committee compromise, it created a shared-terms architecture that plagued developers for years. ### Chapter 23: Trademarks Automattic registers the WordPress trademarks, creating tension with community members who feel the trademarks should belong to the community. The chapter covers the complex dynamics of trademark ownership in open-source projects and the decisions that eventually led to transferring the trademarks to the WordPress Foundation. ### Chapter 24: Habari A group of WordPress contributors fork the project to create Habari, frustrated with WordPress's decision-making process and code quality. The fork doesn't succeed commercially or in terms of adoption, but it documents a genuine frustration: some developers felt WordPress's codebase was becoming unmaintainable and that the BDFL model was blocking necessary change. The chapter is honest about the friction that caused the split. ### Chapter 25: Creating a Folksonomy The taxonomy system's troubled implementation. WordPress adds tags, but the architectural decision about how to store them produces a classic bazaar-model compromise: nobody's happy with the database schema, but it ships because the alternatives were worse. The shared-terms problem that results from this compromise takes years to fix across multiple major releases. The chapter is a sharp illustration of how community-driven development can produce technically mediocre solutions. ## Part Four ### Chapter 26: Sponsored Themes Theme designers start selling links in their free themes to SEO marketers. The practice spreads rapidly, polluting the theme ecosystem with spam links to gambling sites, flower delivery services, and credit card companies. Matt and the project leadership ban sponsored themes from WordPress.org, producing a backlash from theme designers who saw link sales as a legitimate way to fund their work. The chapter documents the first large-scale clash between commercial interests and project values. ### Chapter 27: Update Notifications WordPress 2.3 introduces update notifications -- a system that phones home to api.wordpress.org with information about the user's WordPress version, plugins, and site URL. Privacy-minded community members object, arguing that the data collection contradicts free software values. The developers stick with their "decisions not options" philosophy and don't add an opt-out. The debate recurs in 2009 with even more intensity. The chapter highlights a persistent tension: WordPress's user-first philosophy sometimes means making decisions users don't like. ### Chapter 28: Happy Cog Redesign After Shuttle's failure, Matt hires Jeffrey Zeldman's design studio Happy Cog to redesign the WordPress admin. The team produces a professional redesign for WordPress 2.5, but the community is unhappy -- not necessarily because the design is bad, but because they weren't involved. Zeldman later acknowledged the mistake: "we completely bypassed the community." The redesign is a case study in why traditional client-agency relationships don't map cleanly onto open-source projects. ### Chapter 29: Premium Themes The premium theme market emerges. Designers like Brian Gardner, Adii Pienaar, and Chris Pearson start selling WordPress themes, inventing the category as they go. The chapter covers the licensing confusion (should themes carry the GPL?), the emergence of theme businesses, and Matt's early skepticism about the premium theme market. It documents how accidental businesspeople -- hobbyist designers who started getting payment requests -- built what became a multimillion-dollar industry. ### Chapter 30: Riding the Crazyhorse WordPress 2.7's redesign gets it right. Jen Mylo (then Jane Wells) brings professional usability testing to the project, using eye-tracking technology to identify real interface problems rather than relying on community opinion. The Crazyhorse redesign is the project's first data-driven design process, and it produces an admin interface that users actually like. The chapter contrasts this success with the Happy Cog failure and identifies the key difference: Crazyhorse combined professional methodology with community communication. ### Chapter 31: Themes Are GPL Too The Software Freedom Law Center provides an opinion: WordPress themes' PHP code is derivative of WordPress and inherits the GPL. This forces the premium theme market to reckon with licensing. Brian Gardner's Revolution goes fully GPL first. Others follow -- WooThemes, iThemes, Spectacu.la. But Envato's ThemeForest opts for a split license (GPL PHP, proprietary CSS/JS), which is technically compliant but contrary to the spirit of the license. ### Chapter 32: Improving Infrastructure Jen Mylo works to improve project communication and contributor onboarding. The chapter documents the fragmented state of WordPress infrastructure circa 2009: discussion scattered across IRC, wp-hackers, trac, and multiple blogs. The wp-hackers mailing list has devolved into bike-shed arguments. A smilies change produces community outrage. The long-term security branch is deprecated. The chapter is a frank assessment of the project's growing pains. ### Chapter 33: Meeting in Person The core team -- Matt, Mark Jaquith, Ryan Boren, Peter Westwood, Andrew Ozz, and Jen Mylo -- meets in person for the first time in Orlando in December 2009. They discuss everything from canonical plugins to WordPress.org's redesign. The chapter covers the value and limitations of in-person meetups for distributed projects, and the canonical plugins initiative, which generated excitement but ultimately fizzled due to infrastructure limitations and contributor burnout. ### Chapter 34: Update Notifications Redux The data collection debate reopens in 2009, driven by community member Lynne Pope. The discussion produces 291 responses on WP Tavern -- the most popular post in that forum's history. Mark Jaquith, who originally opposed the data collection, explains why he changed his mind. The developers hold firm: no opt-out button. The chapter illustrates the "decisions not options" philosophy under real pressure. ### Chapter 35: The WordPress Foundation Automattic transfers the WordPress trademarks to the newly formed WordPress Foundation, a 501(c)(3) nonprofit. The chapter covers the slow process of setting up the Foundation (the IRS denied applications for several years) and the rationale for separating the trademarks from the company. The move reassures community members who worried about Automattic's influence, and creates a structural check on corporate power over the project. ### Chapter 36: WordPress 3.0 A massive release that merges WordPress MU into core (creating Multisite), introduces custom post types and taxonomies, adds navigation menus (adapted from WooThemes' custom navigation), and launches the Twenty Ten default theme. The chapter also covers the `capital_P_dangit` controversy -- a function that auto-capitalizes the "P" in WordPress, which broke URLs for some users and was committed without going through the normal review process. WordPress 3.0 marks the platform's transition from blogging tool to CMS. ### Chapter 37: The WordCamp Guidelines As WordCamps proliferate globally, Jen Mylo publishes formal guidelines requiring GPL compliance from sponsors and speakers, keeping ticket prices low, and ensuring at least 80% of content is about WordPress. Some organizers feel the guidelines were imposed without consultation. The chapter documents the tension between scaling a volunteer-organized event format and maintaining quality and consistency. ### Chapter 38: Dealing With a Growing Project The project infrastructure matures: make.wordpress.org launches as a hub for contributor teams, using the P2 theme for front-end posting and discussion. The theme review team forms to manage the growing theme directory. The chapter covers the challenges of scaling a volunteer-driven review process and the shift from scattered communication to more structured team blogs. ### Chapter 39: Thesis The biggest GPL enforcement battle in WordPress history. Chris Pearson's Thesis theme refuses to adopt the GPL despite pressure from Matt, Automattic, and the community. A public confrontation on Mixergy devolves into a rambling debate about economics and intellectual property. Developers discover that Thesis contains code copied directly from WordPress core. Under pressure, Pearson releases Thesis under a split license. The chapter documents the full arc of the dispute and its consequences: Thesis's marginalization, Brian Clark's departure from DIYThemes, and a temporary calm in the licensing wars. ## Part Five ### Chapter 40: The Transition to Release Leads WordPress experiments with delegating release leadership beyond Matt and Ryan. The release lead model allows different developers to run individual release cycles, distributing both workload and decision-making authority. The chapter covers how this transition worked in practice and the challenges of decentralizing authority in a project with a strong BDFL tradition. ### Chapter 41: The Community Summit The first WordPress Community Summit brings contributors together for structured discussions about the project's direction. The chapter documents the summit format and how it differs from WordCamps: smaller, invitation-based, focused on contributor decision-making rather than general education. ### Chapter 42: The Spirit of the GPL The licensing debate evolves beyond legal compliance to questions about the GPL's spirit versus its letter. Split licenses (GPL PHP, proprietary everything else) are technically legal but strip users of the freedoms the GPL is supposed to guarantee. The chapter covers the ongoing tension between Envato/ThemeForest and WordPress.org over split licensing, and the broader question of what "freedom" means in a commercial ecosystem built on free software. ### Chapter 43: The Problem with Post Formats Post formats -- a feature for differentiating content types (aside, gallery, link, quote, etc.) -- become a design and development quagmire. The feature ships in a limited form, but attempts to build a more ambitious UI for it repeatedly fail. The chapter documents the "features as plugins" approach that emerges from this failure: instead of building features directly into core, develop them as plugins first and merge them only when they're proven. ### Chapter 44: MP6 The final chapter covers the MP6 project, which redesigns the WordPress admin's visual design for WordPress 3.8. Unlike the Shuttle and Happy Cog processes, MP6 develops as a plugin that anyone can install and test. This "features as plugins" approach -- building the redesign outside of core and merging it when ready -- represents a maturation of the project's development process. The chapter closes with WordPress's admin getting a modern, flat design that would persist for years. --- # Key Themes and Highlights ## The BDFL Problem Matt Mullenweg functions as WordPress's benevolent dictator for life, and the book doesn't shy away from the tensions this creates. Major decisions -- the taxonomy schema, the Happy Cog hire, sponsored theme bans, `capital_P_dangit` -- are made or heavily influenced by Matt, sometimes without community input. The project works because Matt generally makes good calls. But the book documents enough instances of community frustration (Habari's fork, WordCamp guideline backlash, Thesis confrontation) to raise the question of what happens when the BDFL's judgment fails or the BDFL moves on. ## Design Is the Hardest Problem Three major design initiatives -- Shuttle, Happy Cog, and Crazyhorse -- take up significant space in the book, and only the last one succeeds. The pattern is clear: design work in open-source projects fails when it happens behind closed doors (Shuttle, Happy Cog), and succeeds when it combines professional methodology with community transparency (Crazyhorse). This isn't just a WordPress problem -- it's a structural challenge for any project where the people doing the work need buy-in from a community they can't fully control. ## The GPL as Both Shield and Weapon The GPL runs through this book like a thread. It protects WordPress from being locked down (Freedom Zero, the Movable Type migration). It creates a commercial ecosystem by ensuring that derivative works remain free (theme and plugin markets). But it also becomes a weapon in political disputes -- used to exclude non-compliant developers from WordCamps, yank themes from the directory, and publicly shame holdouts like Chris Pearson. The book is honest about this dual nature: the GPL is both a principled commitment to user freedom and a tool for project leadership to enforce conformity. ## Community Communication Is Always Broken In nearly every chapter, communication is a problem. The wp-hackers mailing list devolves into noise. Decision-making happens in private Skype channels. New contributors can't figure out how to participate. Major changes get committed without discussion. Guidelines appear without consultation. The project repeatedly creates new communication channels (P2 blogs, make.wordpress.org, community summits) to fix these problems, and each fix works for a while before new problems emerge. This is probably the book's most honest recurring observation: open-source governance is a perpetual communication crisis. ## Accidental Businesses, Accidental Businesspeople The commercial WordPress ecosystem wasn't planned. Theme designers who wanted to fund their hobby started selling links, then themes. Plugin developers who scratched their own itch found themselves running companies. Automattic itself started as a way for Matt to work on WordPress full-time. The book captures this accidental quality well -- the premium theme market emerges from bloggers tinkering with CSS, not from market analysis. --- # Analytical Reading ## Main Arguments 1. WordPress succeeded because it prioritized user experience and freedom, not because of technical superiority. 2. The BDFL model (Matt as project leader) enables decisive action but creates recurring governance tensions. 3. Design in open-source projects requires balancing professional methodology with community participation. 4. The GPL creates a commercial ecosystem by ensuring freedom, but it also functions as a political tool for project leadership. 5. WordPress's development process matured iteratively -- from ad hoc commits to fixed release cycles to release leads to features-as-plugins -- and each step was forced by real failures. 6. Community communication is a perpetual unsolved problem in large open-source projects. 7. The commercial ecosystem grew accidentally, driven by hobbyists who became businesspeople rather than by deliberate market creation. 8. Trademark ownership, event governance, and contributor infrastructure are as important to a project's health as the code itself. ## Methodology This is narrative history based on primary sources. McKeown conducted dozens of interviews with WordPress participants (many archived at archive.wordpress.org), and draws heavily on mailing list archives, trac tickets, blog posts, conference talks, and community discussions. The book links directly to these sources, making it possible to verify claims. There's no statistical analysis, no theoretical framework, and no attempt at academic rigor. The method is straightforward: interview the people who were there, read the public record, and reconstruct the story. ## Strengths The sourcing is the book's primary strength. McKeown links to original mailing list threads, trac tickets, blog posts, and interviews throughout, creating a richly documented record that can be independently verified. The book doesn't take sides in most disputes -- it presents multiple perspectives on the GPL debates, the design failures, and the governance tensions. The chronological structure works well for showing how decisions compound: the taxonomy compromise in 2007, for example, creates technical debt that's still being paid off in the 4.x series. The book is also honest about failures, which gives it credibility when it describes successes. ## Limitations The book ends around WordPress 3.8 (2013), which means it misses Gutenberg, the REST API, the block editor debates, and the more recent governance controversies that would test many of the patterns it describes. The narrative is almost entirely told from the perspective of contributors and leaders -- there's very little user perspective, which is ironic for a project that claims to be user-first. Some chapters feel padded with long block quotes from interviews that could have been summarized. The book doesn't attempt to compare WordPress's development model with other large open-source projects (Linux, Apache, Mozilla), which would have given more analytical depth. And while McKeown is fair, the book's position as an official WordPress.org publication means it's unlikely to include the most damaging criticisms of project leadership. --- # Personal Reflection ## Key Takeaways The most useful thing in this book isn't any single event -- it's the pattern recognition across 44 chapters. Free software projects have recurring failure modes: design behind closed doors fails. Communication fragments as projects grow. Commercial ecosystems create licensing conflicts. BDFL decisions feel arbitrary to the community. Feature-driven releases miss deadlines. The projects that survive are the ones that recognize these patterns and evolve their processes in response, even if the evolution is slow and messy. WordPress's story is a case study in iterative governance -- not because the project got it right from the start, but because it kept adjusting. The Crazyhorse chapter is the book's strongest single section, because it shows what happens when an open-source project combines professional methodology (eye-tracking usability tests) with community transparency (publishing results, soliciting feedback). Most design work in open-source projects fails because it's either too insular (Shuttle, Happy Cog) or too democratic (design by committee). Crazyhorse found the middle ground. ## Questions Raised - How do the governance patterns documented here (BDFL, release leads, contributor teams) compare to other large open-source projects? The book doesn't engage with this question, but it would add significant analytical value. - The book was published in 2015. How have the patterns it identifies played out over the subsequent decade? Did the "features as plugins" approach hold? Did the release lead model stick? - The commercial ecosystem described here was built by hobbyists who became businesspeople. What happens as that ecosystem matures and attracts people who start as businesspeople? - How would WordPress's governance model handle a fundamental disagreement between the BDFL and the majority of the contributor community? - The book documents several instances where community frustration led to forks (Habari) or departures. At what point does a project's governance model become a net contributor loss? ## Connections to Other Works - [[The Cathedral and the Bazaar]] by Eric Raymond -- WordPress explicitly engages with Raymond's framework, and the book documents where the bazaar model works (low barriers to entry, rapid iteration) and where it fails (taxonomy compromises, design by committee). - [[Producing Open Source Software]] by Karl Fogel -- Fogel's analysis of mailing list dynamics, bike-shed discussions, and contributor management maps directly onto the patterns McKeown documents. - [[Coders at Work]] by Peter Seibel -- Seibel's interviews with working programmers share the oral history approach McKeown uses, and both books reveal the gap between how software development is supposed to work and how it actually does. - [[The Design of Everyday Things]] by Don Norman -- Norman's user-centered design principles underpin the Crazyhorse project's success. The contrast between Happy Cog's designer-centered approach and Crazyhorse's user-testing approach maps directly onto Norman's framework. - [[Execution]] by Larry Bossidy -- Bossidy's insistence that execution is the leader's job (not a thing you delegate) resonates with the WordPress chapters on design failures, where the leader (Matt) delegated design to external teams without maintaining community process. --- # Reading Notes - Michel Valdrighi building b2 on the island of Corsica is the most romantic origin story in open-source history. A French developer in the Mediterranean building a blogging tool because the existing ones didn't work the way he wanted. - The Movable Type licensing change in 2004 is WordPress's "Freedom Zero" moment, and it's a powerful argument for the GPL. Users fled to WordPress because they knew the license wouldn't change on them. The irony is that this competitive advantage was essentially gifted to WordPress by a competitor's bad decision. - The taxonomy/shared-terms debacle is a textbook example of design-by-committee failure. Nobody was happy with the three-table compromise, but it shipped because the alternatives were worse. The technical debt from that decision persisted for years across the 4.x release series. - "Credenza-ware" from Execution has a WordPress equivalent: the wp-hackers mailing list. Thousands of subscribers, endless discussion, minimal impact on actual development decisions. - The Shuttle-to-Happy-Cog-to-Crazyhorse progression is the book's strongest narrative arc. Three attempts at the same problem, two failures, and one success -- with the success driven by methodology (user testing) rather than talent (Happy Cog was better credentialed than the Crazyhorse team). - Zeldman's retrospective honesty about the Happy Cog failure is notable. He acknowledges that bypassing the community was a mistake, even though it produced a cleaner design process for the agency. - The sponsored themes chapter reveals how quickly a well-intentioned practice (credit links for theme designers) can be corrupted by SEO marketers. The trajectory from designer credit to hidden gambling links happened in months, not years. - Chris Pearson on Mixergy claiming Thesis "stands alone outside of WordPress completely" is the book's most memorable delusion. Drew Blas's script finding WordPress code copied directly into Thesis settles the argument more effectively than any legal opinion. - The `capital_P_dangit` function is a trivial change that reveals a structural problem: some contributors can commit code without going through review, while everyone else follows a different process. The function itself barely matters. The precedent does. - WordPress's "decisions not options" philosophy is in constant tension with its community-driven development model. The philosophy says: don't add an option when you can make a decision. The community says: who gets to make the decision? The book documents this tension without resolving it. - The canonical plugins initiative failed because of infrastructure, not ambition. The plugin repository was built for single authors, and nobody had the energy after WordPress 2.9 to build the collaboration tools needed to make shared plugin development work. - Matt sponsoring Otto's barbecue team in Memphis, which led to Otto becoming Audrey Capital's first employee, is the most WordPress-possible hiring story.