**Author:** [[3. Resources/Authors/Jono Bacon|Jono Bacon]] ![[The Art of Community Visual.excalidraw]] # Book Overview ## About the Author Jono Bacon spent over a decade as Ubuntu's community manager at Canonical, where he built one of the largest and most active open-source communities in the world. Before Ubuntu, he worked in open-source development and advocacy, co-founded the community consultancy firm Jono Bacon Consulting, and later served as Director of Community at GitHub and XPRIZE. He's also a columnist, speaker, and author of multiple editions of this book. His background isn't theoretical -- it comes from years of hands-on work recruiting volunteers, mediating conflicts, running governance boards, and organizing events across global open-source projects. ## Central Thesis Communities don't happen by accident. They require deliberate planning, clear governance, consistent communication, and measurable goals -- but they also require genuine respect for the people who show up. Bacon's core argument is that community management is a craft with repeatable principles, not a vague feel-good exercise. You can design community structures, communication channels, and feedback loops the same way you'd design software architecture, and you should, because thriving communities produce better software, stronger brands, and more resilient organizations. The book treats community as infrastructure. It's not a marketing function or a nice-to-have -- it's the engine that drives participation, contribution, and loyalty in open-source projects and beyond. ## Why This Book Matters Most books about community either stay at the inspirational level ("communities are wonderful!") or focus narrowly on online community moderation. Bacon wrote a comprehensive operations manual. He covers the full lifecycle: strategic planning, contributor onboarding, governance design, event management, conflict resolution, and metrics. For anyone working in developer relations, open-source project management, or technical community building, this is one of the few books that treats the discipline as engineering rather than evangelism. It's been released under Creative Commons, which is fitting for a book about open participation. **Readwise highlights:** [[3. Resources/Readwise/Books/The Art of Community]] --- # Chapter Summaries ## Part I: The Foundations -- Planning Your Community ### The Art of the Community Bacon opens by defining what community actually means in practical terms: a group of people who share common beliefs and collaborate toward shared goals. He distinguishes between communities of interest (people who care about a topic) and communities of practice (people who actively do the work). The Ubuntu community serves as his primary example throughout, but he frames the principles as transferable. The chapter establishes that community building is intentional work that requires strategy, not just enthusiasm. ### Planning Your Community This is the book's strategic planning chapter. Bacon introduces the concept of a community strategic plan, which defines mission, objectives, and measurable goals. He walks through creating a mission statement, identifying your community's core values, and mapping out what success looks like. The key framework here is breaking objectives into SMART goals and connecting them to specific community activities. He's explicit that without a plan, community efforts devolve into reactive firefighting. ### Communicating Clearly Communication isn't just about broadcasting -- it's about building shared context. Bacon covers the choice of communication channels (mailing lists, IRC, forums, wikis), the importance of transparency in decision-making, and how to write for diverse audiences that include non-native English speakers. He discusses the difference between synchronous and asynchronous communication and when each is appropriate. The practical advice on running effective mailing lists and avoiding flame wars reflects hard-won experience. ## Part II: The Engine -- Building Participation ### Processes and Workflow Bacon argues that contributor onboarding is where most communities fail. If someone shows up wanting to help and can't figure out how to contribute within their first session, you've likely lost them. He covers designing contribution workflows, writing documentation for new contributors, mentorship programs, and reducing barriers to entry. The Ubuntu packaging workflow and GNOME's bug triage process appear as case studies. His emphasis on making the first contribution easy and rewarding is the chapter's central point. ### Building Buzz and Attracting Contributors Marketing your community matters, even if the word "marketing" makes open-source developers uncomfortable. Bacon discusses creating compelling narratives about your project, leveraging social media and blogs, writing calls to action that actually work, and building relationships with journalists and bloggers. He's pragmatic about the reality that great software with no community outreach dies quietly. The chapter also covers how to handle press and public relations when things go wrong. ### Supporting Workflow with Tools and Data Technical infrastructure determines what your community can do. Bacon covers version control systems, bug trackers, wikis, forums, and the importance of choosing tools that lower the barrier to contribution rather than raising it. He discusses the trade-offs between different platforms and the danger of tool sprawl. The key insight is that every tool choice is a community design decision -- it shapes who can participate and how. ## Part III: The Organism -- Governance and Growth ### Governance Every community needs governance, but the form it takes matters enormously. Bacon covers several governance models: benevolent dictator (Linux kernel), meritocratic council (Apache), elected governance (Ubuntu Community Council), and hybrid models. He discusses how to design governance that's transparent, accountable, and responsive without being bureaucratic. The chapter is honest about the tension between efficiency (a single leader can decide fast) and legitimacy (elected bodies carry more community trust). He also covers codes of conduct, which were still relatively novel when the first edition was published. ### Measuring Community You can't manage what you can't measure, but measuring the wrong things is worse than not measuring at all. Bacon distinguishes between vanity metrics (mailing list subscriber counts) and meaningful metrics (contributor retention rates, time to first contribution, bug resolution velocity). He covers both quantitative methods (tracking contributions, response times, growth rates) and qualitative methods (surveys, interviews, sentiment analysis). The chapter warns against using metrics to create competitive pressure that undermines collaboration. ### Handling Conflict and Burnout Conflict is inevitable in any community, and pretending otherwise guarantees it'll get worse. Bacon covers the lifecycle of community conflicts: identification, assessment, intervention, and resolution. He discusses the difference between productive disagreement (which drives better decisions) and destructive conflict (which drives people away). The section on contributor burnout is particularly valuable -- he identifies warning signs, discusses structural causes (overcommitted maintainers, unclear expectations), and offers strategies for sustainable participation. This chapter reflects the emotional labor that community management actually requires. ## Part IV: Events and the Wider World ### Creating and Running Events Events are where online communities become real. Bacon covers the full event lifecycle: budgeting, venue selection, speaker management, scheduling, logistics, and post-event follow-up. He discusses the different purposes events serve (recruitment, education, celebration, planning) and how to design events that actually accomplish those goals. The Ubuntu Developer Summits serve as his primary case study. He's practical about the unglamorous work of event planning -- negotiating hotel blocks, managing dietary restrictions, dealing with no-shows. ### Building a Broader Community Ecosystem The final chapters address how communities relate to the organizations that sponsor them. Bacon discusses the tension between corporate sponsors and volunteer communities, how to maintain community autonomy while accepting corporate resources, and how to build a healthy ecosystem of related projects and organizations. He covers the relationship between Canonical (the company) and the Ubuntu community (the volunteers) as a case study in navigating this tension. --- # Key Themes and Highlights ## Community as Intentional Design Bacon's most important contribution is treating community building as a design discipline. Communities don't emerge spontaneously from good software -- they're built through deliberate choices about governance, communication, tooling, and contributor experience. Every structural decision shapes who participates and how. > community as a group of individuals who share a mutual concern for one another's welfare. This definition from the Readwise highlights captures the relational foundation beneath the structural advice. Bacon doesn't reduce community to a set of processes -- the processes serve the relationships. ## The Contributor Funnel One of the book's most practical frameworks is the contributor funnel: awareness, interest, first contribution, sustained contribution, leadership. Each stage has different needs and different failure modes. Most communities focus on the top of the funnel (getting attention) while neglecting the middle (making first contributions easy) and the bottom (developing leaders). Bacon's insistence on optimizing each stage separately is engineering thinking applied to human systems. ## Transparency as Operating Principle Bacon returns to transparency repeatedly as the foundation of community trust. Transparent decision-making, transparent governance, transparent communication. When decisions are made behind closed doors, community members fill the information vacuum with suspicion. This principle applies beyond open-source -- it's relevant to any organization that depends on voluntary participation and goodwill. ## The Governance Spectrum Rather than prescribing a single governance model, Bacon maps a spectrum from benevolent dictator to full democracy and discusses when each is appropriate. Young projects often need strong leadership to establish direction. Mature projects benefit from distributed governance that prevents single points of failure. The transition between these stages is one of the hardest problems in community management, and Bacon doesn't pretend it's easy. ## Burnout as Structural Problem Bacon frames burnout not as individual weakness but as a structural failure. When community structures depend on a few overcommitted people, burnout is predictable. The solution isn't telling people to take breaks -- it's designing systems that distribute responsibility, set clear expectations, and create sustainable participation patterns. This reframing from individual pathology to structural design is one of the book's most important moves. ## Metrics That Matter The distinction between vanity metrics and meaningful metrics appears throughout the book. Mailing list subscriber counts tell you nothing about community health. Contributor retention rates, time to first contribution, and the ratio of new contributors to returning contributors tell you something real. Bacon's insistence on measuring outcomes rather than activity reflects a mature understanding of what community success actually looks like. --- # Analytical Reading ## Main Arguments 1. Community building is a repeatable discipline with identifiable principles, not a personality-driven art form. 2. Communities require deliberate strategic planning with measurable goals. 3. The contributor experience -- especially the first contribution -- determines whether a community grows or stagnates. 4. Governance must be transparent, accountable, and appropriate to the community's maturity stage. 5. Communication infrastructure shapes participation patterns as much as the project itself. 6. Conflict is inevitable and must be managed structurally, not suppressed. 7. Burnout is a structural problem, not an individual failing. 8. Metrics should measure community health outcomes, not activity volume. 9. Corporate sponsors and volunteer communities exist in productive tension that must be actively managed. ## Methodology Bacon writes from practice, not theory. The book is structured as a practitioner's manual, drawing primarily on his experience managing the Ubuntu community and consulting for other open-source projects. He supplements personal experience with case studies from Linux, GNOME, Apache, Fedora, and other major open-source projects. The writing is prescriptive -- "here's what works and here's how to do it" -- rather than descriptive or academic. He doesn't cite social science research extensively, preferring to derive principles from observed outcomes. The methodology is essentially pattern extraction from a career of community work. ## Strengths The book's greatest strength is its comprehensiveness. It covers the entire lifecycle of community management in enough detail to be actionable. Bacon doesn't skip the unglamorous parts -- budgeting for events, writing governance documents, mediating interpersonal conflicts. The practitioner perspective means the advice has been tested against reality and revised through failure. His willingness to discuss what went wrong in the Ubuntu community (governance disputes, contributor burnout, the tension with Canonical's commercial interests) adds credibility that a purely prescriptive book would lack. The book also holds up as a reference. Each chapter stands relatively independently, which makes it useful as something you return to when you face a specific challenge (running an event, designing governance, measuring progress) rather than something you read once and shelve. ## Limitations The book is deeply rooted in the open-source community of the late 2000s. The communication tools it discusses (IRC, mailing lists, Launchpad) have been largely supplanted by Slack, Discord, GitHub Discussions, and other platforms. The principles transfer, but the specific tooling advice is dated. Bacon's perspective is shaped almost entirely by the Ubuntu and broader Linux ecosystem. These are large, well-resourced communities with corporate backing. The book has less to say about smaller communities, communities without corporate sponsors, or communities in non-technical domains. The advice assumes a certain scale that many communities never reach. The book is also more descriptive about what to do than about what to do when things go wrong at scale. The conflict resolution chapter is good but brief relative to the complexity of the problem. Governance transitions -- moving from a founder-led project to a community-governed one -- get less attention than they deserve given how many projects struggle with exactly this. Finally, there's an inherent tension in the book between Bacon's role as an employee of Canonical (Ubuntu's commercial sponsor) and his role as the community's advocate. He acknowledges this tension but doesn't fully resolve it. The question of how community managers serve two masters -- the company that pays them and the community that trusts them -- deserves a more thorough treatment than it gets here. --- # Personal Reflection ## Key Takeaways The contributor funnel framework is the single most useful concept in the book. Thinking about community growth as a pipeline with measurable conversion rates at each stage turns a fuzzy problem into something you can actually diagnose and improve. Most communities I've seen fail at the "first contribution" stage -- someone shows up, can't figure out what to do, and leaves. Bacon's insistence on optimizing that stage is worth the price of the book alone. The reframing of burnout as structural rather than personal resonates strongly. In developer relations and community work, burnout is endemic, and the usual advice ("set boundaries," "practice self-care") puts the burden on the individual. Bacon's framework points at the system: if your community depends on three people doing unsustainable amounts of work, the problem isn't those three people -- it's your community design. The governance spectrum is also useful. Not every community needs the same governance model, and the model should evolve as the community matures. Starting with a benevolent dictator and transitioning to elected governance as the community grows is a pattern I've seen work, and Bacon articulates why it works. ## Questions Raised - How do Bacon's principles apply to communities built around commercial developer platforms rather than open-source projects? The incentive structures are different when the community exists to support a company's product. - What does healthy corporate-community tension look like in practice? Bacon identifies the tension but doesn't provide a clear framework for managing it over time. - How do you measure community health in communities that are primarily consumers (users) rather than producers (contributors)? - The book predates the rise of Discord and social media-native communities. How do Bacon's communication principles adapt to platforms designed for casual conversation rather than structured collaboration? - What's the relationship between community governance and the governance of the software project itself? Bacon treats them as linked but doesn't fully explore the cases where they diverge. ## Connections to Other Works - [[Working in Public]] by Nadia Eghbal -- Eghbal's taxonomy of open-source communities (federations, clubs, stadiums, toys) provides a useful lens for categorizing the communities Bacon describes. Her work on maintainer burnout extends and deepens Bacon's treatment. - [[The Cathedral and the Bazaar]] by Eric S. Raymond -- Raymond's essay on open-source development models is the intellectual backdrop for Bacon's governance discussion. Bacon is more practical and less ideological. - [[Peopleware]] by Tom DeMarco and Timothy Lister -- The insight that software projects succeed or fail based on human factors, not technical ones, runs through both books. Bacon applies it to volunteer communities rather than corporate teams. - [[Drive]] by Daniel Pink -- The autonomy, mastery, and purpose framework that motivates open-source contributors maps directly onto Pink's research on intrinsic motivation. - [[An Everyone Culture]] by Robert Kegan and Lisa Lahey -- The concept of deliberately developmental organizations overlaps with Bacon's vision of communities that grow their members, not just their output. - [[Producing Open Source Software]] by Karl Fogel -- Fogel's book is the closest comparison in scope and approach. Where Fogel focuses on the software development side, Bacon focuses on the community management side. They're complementary. --- # Reading Notes - The book's release under Creative Commons practices what it preaches about open participation and lowering barriers. - Bacon's distinction between communities of interest and communities of practice is more useful than it appears at first glance -- it determines what kind of infrastructure and governance you need. - The Ubuntu Developer Summit format (structured planning events where community and company collaborate on roadmaps) is a model worth studying for anyone running developer relations programs. - The tension between Canonical and the Ubuntu community is the book's most honest and most interesting thread, even though Bacon can't fully explore it given his position. - The contributor funnel concept has direct parallels to developer relations metrics: awareness, activation, engagement, retention, advocacy. - The governance chapter would benefit from more examples of governance transitions that went badly -- the failure modes are as instructive as the success cases.