This session began with intros, with each person sharing backgrounds and experiences of balancing ego with process.
Session proposed/led by @Luispo
Contrasting models of OSS decision-making
- Having OSS leadership as a charismatic person who oversees how code is developed. AKA, a BDFL (Benevolent Dictator For Life).
- OSS as a meritocracy, and “the best code wins.” This relies on process to conduct reviews, manage direction, and drive community consensus.
People go to open source to escape bureaucracy. The risk for a project: what if a process is intolerable? People get fed up and leave a community. Process can create tension between:
- the immediacy of an open source project (landing a patch)
- the need to go through review (making contributions qualify/ensure quality).
- Review and code review can be a barrier, but is essential to having a maintainable codebase.
Relevant Characteristics / Differences between open source projects
Can we think about OSS projects in terms of categories, and does that impact these models and their appropriateness?
- Mature versus new/emergent?
- What is the tolerance for bugs or expectation for testing?
- How does scale (of code? community?) impact this?
Projects evolve; grow or shrink. Point made that projects may benefit from a BDFL early-on for vision and direction, but need to evolve as the community grows.
- When does a project get critical mass to rely more-heavily on process? And how does that impact the need (or lack of need) for a BDFL?
- “In a larger project, even a single ego is drowned out by the masses.” Larger community == more voices == less reliance on an individual.
Managing community disagreement
We’ve discussed projects that have a process (code review, etc), but what happens when you submit code but for political reasons it won’t land in a project? How do you change the governance?
Open source is non-neutral; it’s often a strategic agenda and used to influence others for various reasons. This can create conflict.
How is this managed?
- Some projects have vender neutrality rules, such as OpenStack.
- Greater documentation of process to fall back on.
- Suggestion made to keep rules/process as simple as possible. Like the Apache rules, “if it doesn’t happen on the mailing list, it didn’t happen.”
- Challenge: despite having defined rules for community conduct, participation, and process, large companies often pay engineers on those projects. By increasing their corporate participation, they can sometimes indirectly wield influence through pushing specific development.
Case study of community ownership, autonomy, process
Module ownership system at Mozilla as a model for how communities manage development of individual project components.
Need for Coherence and Direction in Absence of BDFL
Concluding discussion of how a project grows in the interest of its success and its users.
- “You need a really good product manager”; someone who will change the order of issues in a bug tracker to prioritize them for users (this is rare).
- Reason: engineers may prioritize tickets for development and technical merit, but may sometimes lack a broader perspective on how software is used.
- Alternative solution in the absence of an individual: creating a strategy council (quarterly meetings are often done), to provide the role of shaping an open source product.