Topic 2: Open Source Collaboration

Code of conduct

A Code of Conduct is a set of guidelines that outlines clear expectations for behaviour and values within a project’s community, promoting respectful interactions, inclusivity, and preventing harassment or discrimination. It typically includes rules for communication, conflict resolution, where the code applies (e.g., repositories, events), who it covers (contributors, maintainers, sponsors), how to report violations, and the consequences for breaking the rules.

The Contributor Covenant is a widely adopted code of conduct example, providing a standardised framework for creating safe, inclusive environments in open source projects, with clear guidelines for enforcement and reporting. It is used in multiple projects like Linux and Swift .

Governance models

Governance defines the rules and processes for decision-making within a project, including who has authority, how responsibilities are managed, and when tasks should be completed. It covers everything from setting project roadmaps and designing APIs to managing budgets, addressing code of conduct violations, and encouraging community participation.

A project governance model offers several advantages for open source projects. It reduces the risk of project abandonment or non-maintenance and provides a safe space for innovation. Developers trust that their contributions will be accepted based on merit and the project’s best interests, attracting people with different experiences and backgrounds and strengthening the project.

The following are 2 examples of governance models that I found interesting:

Benevolent Dictator For Life (BDFL): The individual who started the project is the final decision-maker. They establish the project’s vision and control permissions to merge the code. This model comes with multiple limitations. As the decision-making revolves around a single leader, it often blends personal preferences with project direction, which can limit innovation and diversity of ideas. If the founder steps down or loses interest, the project can become directionless or even collapse. Lastly, conflicts between the founder and other contributors can lead to forks or project abandonment if disagreements become too severe, threatening the long-term stability of the project. In my opinion, this model is convenient for small projects with only a few contributors, as it allows for quick decision-making and a clear project vision. However, as projects grow, it becomes impractical for a single person to oversee numerous tasks and maintain effective leadership.

Self-appointing council or board: This model relies on several leadership groups, such as steering committees, committee councils, or technical operating committees, to oversee various aspects of a project. The groups typically create their decision-making processes and succession plans. I believe this model is effective for large open-source projects, as it distributes responsibility across multiple leaders, ensuring diverse perspectives are considered and reducing dependency on a single person’s availability. However, it can also create self-reinforcing leadership cultures, potentially discouraging broader community involvement. For example, more outspoken contributors may dominate decision-making, making it harder for quieter voices to be heard.

The bus factor

The bus factor is a really interesting topic we discussed in class that made me rethink the reliability of the different governance models.

The “bus factor” is a term used to describe the number of people who could be “run over by a bus” before the project would be in danger of failure. Personnel must be key and irreplaceable to contribute to the bus factor; losing a replaceable or non-key person would not result in a bus-factor effect. The expression “hit by a bus” describes a person either dying or disappearing suddenly from the project. Some examples include illness, departure from the company, and abandonment of the project. The smallest bus factor is 1, often seen in projects with a BDFL model, meaning the entire project’s continuity depends on a single individual. In contrast, projects governed by councils or boards typically have a higher bus factor, as leadership is distributed across multiple experts, making the project more resilient.

In mid-2019, programmer Denis Pushkarev, the sole maintainer of the widely used Core-JS library, announced on GitHub that he was likely facing jail time. Core-JS, a fundamental code library that enables developers to reuse already-built components, was being downloaded more than 20 million times weekly, yet Pushkarev alone had the permissions to update it. Pushkarev was found to have been involved in a fatal car accident that left one dead and another injured. He was sentenced to 18 months in prison. During his absence, the project fell into a nearly year-long period of inactivity, with no new maintainers appointed, until Pushkarev returned with a brief “I’m back” message. While his situation is an extreme example, abandoning open source projects is a common challenge, as maintaining a widely adopted library often becomes increasingly demanding over time.

Governance model in p5.js

p5.js follows a community-driven governance model that emphasises inclusivity, collaboration, and shared decision-making. The project relies on a diverse group of maintainers, contributors, and volunteers who collectively shape its direction.

The governance model of p5.js consists of three components:

1. Core Committee: This group of predefined members is responsible for organising proposals, making initial approval or decline decisions, prioritising, and assessing project size and phases.
2. Advisory Committee: The advisory committee makes the final approval or decline decisions on proposals, providing guidance and expertise.
3. Community Input: The broader p5.js community is encouraged to offer feedback on accepted proposals, ensuring that implementation reflects the needs and interests of a diverse user base.

This approach allows contributors to gain influence based on their impact and involvement, reflecting elements of a meritocracy while maintaining a strong focus on community support and accessibility.