Key Moments
How Open Source Projects Survive Poisonous People (And You Can Too)
Google TalksWant to know something specific about what's covered?
We've already dissected every moment. Ask and we will deliver (with timestamps).
Key Moments
Open source projects can be derailed by 'poisonous people' who disrupt focus and cause emotional drain, but clear mission statements, defined scope, and community policing can prevent this.
Key Insights
The most valuable resource in an open source project is the attention and focus of its community, which 'poisonous people' can disrupt by causing distractions and emotional drain.
A project's mission and scope should be clearly defined from the outset to provide direction and limit 'limitless feature creep' or unintended additions.
Parkinson's Law (or the 'bike shedding' phenomenon) states that the amount of discussion on a feature is inversely proportional to its complexity, leading to excessive debate over trivial matters.
Documentation, including design decisions, bug fixes, and even mistakes, is crucial for long-term project health and knowledge transfer, preventing repeated discussions.
Code collaboration practices such as commit emails and using branches for large features help maintain transparency and allow for incremental code reviews, preventing large, unmanageable changes.
The 'bus factor' refers to the number of developers whose absence would cripple a project; spreading expertise and avoiding individual ownership of code (e.g., by not putting names at the top of files) helps mitigate this risk.
Understanding the core threat to open source communities
The fundamental resource in any open source project is not hardware or code, but the attention and focus of its community. 'Poisonous people' are those who disrupt this vital resource. They can detract developers from productive work, cause emotional drain through infighting and squabbling, and ultimately slow down or reroute the project's progress. This disruption can be intentional or unintentional, with perfectionism and an overzealous desire to 'get the process just perfect' being common culprits. A key takeaway from the Subversion project is the mantra: 'Don't let the perfect be the enemy of the good.' When faced with such disruptive perfectionism, gaining support from a large percentage of developers can help move the project forward, ignoring the 'noisy minority' who aim for unattainable ideals.
The 'bike shedding' phenomenon: disproportionate discussion on trivialities
A common pitfall in community development is the 'painting the bike shed' effect, which illustrates how the amount of discussion on a feature is inversely proportional to its complexity. This phenomenon, attributed to Parkinson's Law (or the Fourth Law of Parkinson), highlights how committees often spend excessive time debating minor details (like the color of a bike shed) rather than crucial aspects (like building a nuclear power plant). In open source projects, this translates to endless arguments over minor design choices or stylistic preferences, consuming valuable time and energy that could be dedicated to actual development. Open source projects often adopt phrases and practices to combat this, such as calling out 'bike shedding' early and often, and reminding themselves and others to focus on substantive issues rather than trivial debates.
Fortifying your project with prescriptive community practices
To build a resilient open source community, several best practices are essential. A clear mission statement and a well-defined scope are paramount to provide direction and prevent 'limitless feature creep' or unintended additions. For instance, the Subversion project's mission statement was crucial for guiding its development towards its core goal: a version control system superior to CVS. Similarly, the Google Web Toolkit established a clear direction of 'no compromise Ajax development environment in Java' limited to the Java and browser context. Communication, primarily through mailing lists, needs structure: point newcomers to archives, avoid re-opening old discussions unnecessarily, and actively manage 'filibustering' – where one individual dominates a thread, creating the illusion of more dissent than actually exists. Robust documentation, covering design decisions, bug fixes, mistakes, and code changes, is also vital for knowledge sharing and onboarding new contributors.
Encouraging code collaboration and managing dependencies
Effective code collaboration is key to a healthy open source project. Commit emails serve as a primary mechanism for developers to stay informed about each other's work, acting as a decentralized form of code review and fostering transparency. It is critical to avoid large, isolated feature development; instead, developers should work on features incrementally, perhaps on branches, allowing continuous oversight and feedback. This practice directly addresses the 'bus factor' – the number of developers whose absence would cripple the project. By encouraging shared knowledge and preventing individuals from becoming sole owners of critical code sections (e.g., by not placing names at the top of files), projects can reduce their dependence on any single contributor. This approach ensures that code is understood and maintainable by multiple team members, safeguarding the project's long-term viability.
Identifying and addressing 'poisonous' individuals
Recognizing 'poisonous people' is crucial for community health. While not always obvious, indicators include poorly chosen communication handles, excessive use of capital letters, and an inability to gauge the community's mood or urgency. Open hostility, a sense of entitlement, blackmail (threatening to withhold contributions unless demands are met), and trolling are clear red flags. Some individuals are merely 'talkers, not doers,' complaining without offering solutions; for them, the standard response is 'patches welcome.' Others exhibit a lack of humility, believing their experience outweighs others' opinions and often reopening long-settled discussions. Sometimes, 'poisonous' behavior stems from genuine but misplaced enthusiasm, where a newcomer inadvertently drains community attention with constant questions. The key is to maintain a balance: be tolerant of newcomers and potential miscommunications, but be firm in upholding community standards and long-term goals.
Disinfecting the community: strategies for dealing with disruption
When disruptive individuals are identified, assessing the damage is the first step. Questions to consider include how they are affecting the project's attention and focus, and if their behavior is actively hindering forward momentum. A critical 'do not' is to 'feed the energy creature' by engaging in emotional arguments or giving disruptive individuals a 'gripping surface' for their behavior. Instead, ignore trolls, stick to facts, and avoid emotional responses. A 'good cop' approach involves giving newcomers the benefit of the doubt, looking past abrasive communication to find potential valid points (like a bug report), and responding calmly and rationally. In extreme cases, like when a single enthusiastic newcomer consumes a disproportionate amount of committers' time, or when a founder becomes disruptive, forcibly removing them from the community, revoking commit access, or even politely but firmly asking them to leave may be necessary. The health of the community and its long-term goals should always take precedence over individual ego or short-term appeasement.
The universality of community management principles
The principles discussed for open source communities are not exclusive to them. They apply broadly to any team or social group, including workplaces, volunteer organizations, and even social circles. The challenges of managing attention, focus, and disruptive personalities are universal. This realization often leads to collective 'group therapy' sessions where individuals from different projects or organizations share similar experiences with difficult people. Applying these strategies requires consistent documentation, clear communication channels, and a willingness to enforce community norms, regardless of the context.
Establishing consensus and decision-making processes
Consensus-based development, a hallmark of many successful open source projects, emphasizes collective decision-making. While voting mechanisms exist, they should be used sparingly. Frequent voting indicates underlying issues within the community, as it creates winners and losers and can stifle compromise. Ideally, communities should reach resolutions through healthy discussion and compromise. Some projects, like Subversion, have gone years with very few formal votes, often on minor but passionately debated topics like code formatting. The consensus model, even when paid employees are involved, ensures that community members have a say in the project's direction, reinforcing a culture where collective agreement supersedes individual authority or corporate backing.
Mentioned in This Episode
●Software & Apps
●Companies
●Organizations
●Concepts
●People Referenced
Open Source Community Survival Guide
Practical takeaways from this episode
Do This
Avoid This
Common Questions
The most crucial resource for an open source project is the attention and focus of its community. This resource needs to be protected from 'poisonous people' who can distract developers, cause emotional drain, and slow down or halt project progress.
Mentioned in this video
A version control system discussed extensively as an example for applying open source community management principles, including its mission statement and development process.
An example project whose clear mission and scope (Ajax development environment in Java, browser-based) helped guide its community and development.
Noted as one of the first major projects to adopt a consensus-based voting system for decision-making in its communities.
One of the speakers and engineers behind Google's project hosting feature and Subversion, who shares insights on managing open source communities.
One of the speakers and engineers behind Google's project hosting feature and Subversion, who shares insights on managing open source communities.
Author of a recommended book on running open source projects and a friend of the speakers, known for his diplomatic approach to community management.
A key developer for Subversion's Berkeley DB file system code, whose sole responsibility initially led to a low 'bus factor'.
The company hosting the speaker series and employing the speakers, which has a bottom-up company culture that functions similarly to open source communities.
A company that employed developers working on Subversion, emphasizing that even paid employees operated under community consensus rather than having special privileges.
More from GoogleTalksArchive
View all 79 summaries
58 minEverything is Miscellaneous
54 minStatistical Aspects of Data Mining (Stats 202) Day 7
45 minKey Phrase Indexing With Controlled Vocabularies
63 minMysteries of the Human Genome
Ask anything from this episode.
Save it, chat with it, and connect it to Claude or ChatGPT. Get cited answers from the actual content — and build your own knowledge base of every podcast and video you care about.
Get Started Free