Open Source Anti-Patterns
I had the opportunity to attend FOSSY this year, which proved to be one of my favorite events so far. Meeting people (friends) who have defined what Open Source and Free software landscape looks like, and hearing to their challenges, challenges in FOSS ecosystem, path forward, and new changes was as much inspiring as a learning experience. This post focuses on the talk anti-patterns in Open Source.. The talk resonated deeply with me, as I've frequently encountered these very anti-patterns while mentoring various companies. Changing the embedded mindset that accompanies these anti-patterns is often a long process. In my experience with over 23 companies, a good number had at least one of these anti-patterns present. I highly recommend checking out the original talk—it's excellent.
What is
- Anti-Pattern: An anti-pattern is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive.
- VCOS: VCOS refers to "Vendor-Controlled Open Source." This term describes a model of Open Source software development where the project is primarily controlled and driven by a single commercial vendor. Often, more than 50% of the contributors are from a single vendor (vendor can be a traditional vendor, company, NGO, IGO)
- CDC: Corporate developer culture refers to the set of values, practices, and norms that prevail in a traditional corporate software development environment. This culture often contrasts sharply with the ethos of open and community-driven Open Source projects.
With that, let's look at the anti-patterns
Un: Cookie Licking
Our first Open Source anti-pattern is called "Cookie Licking." In this context, "cookie licking" refers to a situation where a member of an open-source community or a corporate team claims ownership of a task but fails to complete it effectively. This claim then prevents others from stepping in to finish or improve the task. The problem can arise both intentionally and subconsciously, often stalling progress and growth.
This anti-pattern is particularly noticeable in vendor-controlled open-source projects. Vendors might claim ownership of a task with the assumption that they are the only ones capable of doing it right. Alternatively, community members might assume the vendor will handle it even if the vendor doesn't explicitly say so. This creates a stale environment where tasks remain incomplete or poorly done, and no one feels empowered to contribute. Spot suggests several antidotes to mitigate this issue:
Antidotes
Explicitly Encourage Concurrent Development: Create a community culture where multiple people can propose solutions to a single problem. This fosters healthy discourse and prevents the monopolization of tasks.
Documented Governance: Having clear rules on how, when, and where decisions are made can add structure and support to a community, making it clear how tasks can be claimed or reassigned.
Time Limits on Tasks: Establish a reasonable timeframe for someone to complete a claimed task. If the task is not completed in that window, it should be considered up for grabs again.
Roadmaps with Issues: Having a documented roadmap helps set expectations. However, it should be clear that listing an item on the roadmap does not imply ownership. There should be an additional step to claim the task, and multiple people should be able to do so.
Deux: Nepotism
The second anti-pattern discussed by Top Spot Callaway is "Nepotism," traditionally understood as favoritism based on family relations but extended here to include blind trust in team members or vendor-controlled decision-making. This pattern manifests in several ways:
Blind Team Trust: In corporate culture, nepotism can manifest as undue trust in team members, irrespective of their suitability for a task.
Fast Paths in Vendor-Controlled Projects: Vendors in open-source projects might create a fast-track approval process for their own contributions, sidelining community members and stifling collaboration.
Lack of Governance: In many cases, a lack of structured governance exacerbates the issue, making it hard to build a genuine community around a project.
Erosion of Trust: This anti-pattern can lead to the erosion of trust not only within the current project but in any other project associated with the vendor.
To counteract this issue, Spot suggests some antidotes.
Antidotes
No Fast Paths: Equal treatment should be the norm; a maintainer or vendor should not have any shortcuts.
Documented and Practiced Governance: Rules should be established and followed, determining how decisions are made and who gets to make them.
Code of Conduct: A strong code of conduct is essential to curbing nepotism, as it makes it clear that no one gets a "free pass" to misbehave, regardless of their position or affiliation.
Limited Maintainer Pool: Rather than having a large number of inactive corporate maintainers, it's better to start with a smaller, more engaged pool and expand naturally over time based on trust and proven responsibility.
Trois: Confusing Leadership with Ownership
In corporate environments, there's a misconception that leadership equates to ownership, causing imbalances in community involvement. Leadership is the ability of an individual, group or organization to influence or guide others. In corporate developer culture In a conventional corporate setting, the concept of "ownership" often equates to taking full responsibility for a problem, seeing it through to resolution, and ultimately pleasing the customer. In this context, ownership is not only endorsed but often rewarded. Teams are explicitly assigned to "own" specific challenges, and the fruits of their labor are recognized through various incentives. However, in a vendor-controlled open-source environment, leadership is distinctly different from ownership. Here, leadership emerges from the actions one takes within the project. The more you contribute constructively to the project, the more you solidify your role as a leader. Leadership isn't about legal possession or unilateral control; it's about active, meaningful participation that garners influence within the project.
Antidotes
Tracking Contributions: Make it a goal to track diversity in all contributions, including type, background, and affiliations, to foster an inclusive environment.
Governance: Reiterate the importance of transparent governance to promote shared ownership and decision-making.
Understanding Shared Control: Be explicit about the benefits of a more extensive contributor pool. Frame it as a shift from a linear to an exponential growth model to encourage corporate buy-in.
Reward Leadership: Acknowledge acts of leadership in both public and private settings, depending on the individual and community preferences.
Quatre: Warnock’s Dilemma in Open Source Projects
Lack of response to posts in open-source communities can be misinterpreted in five ways
- The post is 100% correct, so correct that there is nothing to add
- It's 100% incorrect, so incorrect that it doesn't deserve a response
- It's unread,
- It's not understood
- No one cares about it
This becomes an issue especially in vendor-controlled projects, where the absence of community feedback leads to disillusionment with the Open Source model.
In corporate settings, silence is usually considered a sign of busy productivity. However, in a community setting, it could mean the opposite. The vendor may conclude that Open Source isn't effective if nobody shows up to contribute.
Antidotes
Transparent Discussion: Start with a culture of open discussion, to help newcomers gauge the community’s values and know that they are welcome to participate.
Ask for Feedback: Be explicit about wanting responses or comments. This act invites participation and breaks the silence.
Recognition and Appreciation: When feedback does arrive, appreciate it, regardless of whether it's positive or negative. This validates the effort people take to contribute.
Lazy Consensus Model: Consider using this approach to decision-making, where silence is taken as implicit agreement. This empowers the remaining active members to proceed without getting bogged down in endless discussions.
Invest in Marketing: Maybe the room is empty because people don’t know about it. Market your community or project to bring more people into the discussion.
Measure Barriers to Entry: Consider the difficulty for newcomers to get involved. Are the questions too complex? Is the technology intimidating? Reduce these barriers to encourage more participation.
Community Signals: Ensure that your platform is welcoming and functional. Broken forums, convoluted subscription methods, or a hostile environment will deter potential contributors
Cinq: The Launch
This anti pattern Open Source approach involves developing a project in secrecy or isolation for an extended period and then unveiling it, expecting accolades and rewards. This method is deeply ingrained in corporate culture, but it often falls flat in an Open Source context. The problem with "the launch" strategy in Open Source projects is that it excludes external feedback and devalues community input. Key Issues:
- Lack of External Feedback: Working in isolation means missing out on valuable input from the open-source community.
- Demotivation: The community may feel marginalized or undervalued, leading to reduced participation.
- Risky: Focusing solely on a big launch may overlook important community feedback and may even result in competition from parallel projects.
Antidotes
- Educate on Community Value: Stress the importance of involving the community in development.
- Frame it in Agile Terms: Use the Agile framework to convince teams of the value of ongoing, iterative development and feedback.
- Quantify Risks: Explain the competitive risks of not involving the community, such as parallel projects that could provide better solutions.
- Alternate Recognition Systems: Introduce new performance metrics that encourage diversity of contributors and community involvement, aligning them with corporate rewards.
Six: Bike-Shedding
Bike Shedding refers to the tendency to focus on trivial details at the expense of meaningful progress. Often this occurs because individuals or companies are afraid of making mistakes and looking bad publicly. Key Issues:
- Stifling Progress: Bike shedding often leads to stagnation, as participants get stuck arguing over minor details rather than pushing the project forward.
- Vendor-Centric Thinking: Companies are concerned with their own image, leading them to micromanage trivial details and neglect community input.
- Community Alienation: Focusing on minor details can create a divisive atmosphere, separating vendors from the community and creating a caste system.
Antidotes:
- Identify Decision Points: Adopt Amazon's concept of "one-way" and "two-way doors" to decide whether a detail is critical enough to halt progress or whether it can be decided later.
- Call Out Bike Shedding: Politely inform participants when they're getting lost in minutiae to help refocus the discussion.
- Parallel Development: Encourage multiple approaches to be developed in parallel to assess the best solution at the end.
- Inclusive Language and Transparency: Work transparently and consider every participant as part of the community, avoiding language that separates "us" from "them."
If you made it here, I am interested in hearing if you have experienced these, if not, are there any specific ones you can think of? You know where to find me :)