18 KiB

Raw Blame History

Practical Examples

The Four Opens is a set of principles to guide you when you build, support or participate in an open source community to ensure a healthy and balanced environment.

While there is no magic screenplay that would apply to all communities, there are practices you can follow and steps you can take regardless of you being one of the contributors, or if you work for a foundation or company that supports the project.

This chapter will give you examples and recommendations to build on based on the experiences of the OpenInfra communities and the ecosystem around them. We will cover the following areas:

Common mission & goals
Effective governance & leadership
Diversity & Inclusiveness
Contributor recognition & motivation
Open & Transparent Communication
Events
Education & On-boarding
Ambassadors & user groups
Cross-community collaboration

Common Mission & Goals

The idea behind open source software development is to share and work together on tools and projects that provide solution to common problems. While having a challenge to share is a good start for collaboration, it cannot guarantee a stable direction for the community in itself. This is why it is crucial to define the common goals for the community and summarize them in a strong mission statement.

A clear mission statement and goals are essential to create and maintain balance between contributors, users and the ecosystem around a community. They should be easy to discover to give a clear view of the community values and direction to everyone -established and new contributors, adjacent communities, users, and so forth.

It is important to spend time on making the mission statement and goals as clear and simple as possible. In addition, the community can also define a long term vision which describes the target they would like to reach. The vision can serve as big picture to provide guidance for actions and decisions. However, as both technology and the challenges are changing rapidly, it is worthwhile to revisit the mission, goals and vision periodically to ensure that they are still accurate and update them if necessary.

This step should be completed while the community is in the forming phase, as the getting input and buy-in from everyone, who is motivated to participate, is key to succeed long term. The advantage of developing the mission statement in the early days is having fewer contributors who need to reach consensus through an open discussion and process. As the community grows and evolves the process of updating the mission statement and goals should also follow the same open procedures, even if it seems harder at first.

A good example to explore is how the Zuul community worked and agreed on their goals and mission. Project leaders first drafted example mission statements in an etherpad¹, which was circulated to the public mailing list for feedback and new ideas². The list of ideas from the etherpad was then put to a Condorcet vote³ for the same group of contributors to choose the variant that resonated with most, which was: "To provide software and processes to automate continuous integration, delivery, and deployment of interrelated software projects in a secure manner using project gating."

Effective Governance & Leadership

When you are working together with a group of people you will soon need processes and governance to ensure smooth collaboration and operation.

Governance is the set of rules that the group follows in order to address issues and make decisions that affect the whole community or some of the sub-groups and to avoid decision apathy. Governance can also help to resolve any conflicts and help reaching consensus where needed.

While you cannot anticipate all challenges that the community will need to overcome and every governance body that they will need over time, you should still encourage your community -that you are a part of or supporting- to put a basic structure in place. This can help to avoid anarchy where you can hit big road blocks and obstacles if you try to create an organizational structure later as the community is starting to grow.

There are multiple models to choose from and you can find examples to these within existing communitites. While it is not a common practice, it is an option to have one person who takes on the responsibility to drive the project. You can look into the Linux kernel, as an example, where the project's initial creator became the "benevolent dictator for life". Even though the Linux kernel became very successful, this model has many risks that you need to take into account. If the project leader looses interest or has another reason to leave the community, it can enter governance limbo with no clear way forward and challenges to make decisisons the community agrees with (you can see the Gentoo or Python projects as examples). The leader can also engage in toxic and in some cases abusive behaviors that is hard to control and will affect existing contributors and make it hard to on-board newcomers.

A more common way forward is to create governance bodies, which are diverse groups within the community, that are responsible to help and guide the community to work towards its mission to achieve its goals.

To build such framework, you should consider the following four rules:

Contributor-driven bodies

People who are active participants of the community are the best skilled and positioned to become leaders. By building the governance bodies form the project contributors, you can ensure that they are representing the community that remains aligned with the leadership of the project.

Without contributor-driven bodies and leadership contributors will most likely gradually drift apart, to the point where they no longer feel like their leadership represents them This can lead to making the disruptive decision to fork the project under a new, contributor-aligned governance, generally leaving the old governance body with a trademark and an empty shell to govern.

Allowing for replacement

Nobody should be appointed for life. Processes should allow to revisit the governance bodies and elect new leaders and group members from the community by the community. This ensures that new views and ideas are brought into the project leadership.

It can also avoid the burnout of established leaders as well as encourage new contributors to join and maintain the project if they have the opportunity to become one of the leaders over time.

Distinct groups call for distinct governance bodies

As a community grows it often ends up having disjoint groups with little or no overlap between them. For example, these groups can be project teams, who work on different services that make the end product of the community. These project teams usually need a project leader and a stable group of people who ensure quality work and efficient processes around that team and service.

Ever group that is mainly standalone within a community needs to have its own governance body at that level.

Avoid vanity governance bodies

In order to keep balance, the opposite of the former rule also applies. You should avoid to overload a community with governance bodies which then only make the community slower and least efficient. Once a community has an initial framework it needs to be carefully revisited if all the governing bodies are useful and necessairy or if there is a need for a new group for an area that is yet uncovered and therefore not operating efficiently.

There is no one-size-fits-all implementation of these basic rules that would work for every project. The size of the project is a critical factor to take into consideration, where larger communities may call for a multiple-level structure to properly balance autonomy and consistency.

Choosing the project leaders could also be a challenging task, but there are popular ways to build the governing bodies. When a community is forming and people don't necessarily know each other yet, it can be hard to make a decision that involves the whole community. A common practice is to appoint the first group or groups of leaders from the people who launched the project.

After a first term -that often spans from 6-month to a year- when the community is operational they are most often switch to an election-based process to find new members to the governance bodies. Popular choices to make:

Use a ranking vote mechanism (Condorcet, STV...)
Condorcet is known to favor consensual candidates over faction candidates
Staggered elections (replacing half the seats at each election) ensures some leadership continuity with the opportunity of new members to introduce
Limits in the number of seats potentially held by employees from a single organization are usually a good way to sidestep governance gaming

Governance bodies should ideally only make consensual decisions, but when that proves impossible and a decision needs to be made, this can be resolved to hold a formal vote. You can also consider to have odd numbers of members to the governance bodies to avoid having to give anyone a tie-breaking specific power.

Diversity & Inclusiveness

Diversity in all verticals

Gender, sexual orientation, race, nationality, religion ... Technical and non-technical contributors, users, ...

Actions

Code of Conduct Focus group

Nowhere are the three forces (developers, users, ecosystem) more important than when dealing with diversity and inclusiveness.

Providing an inclusive and safe experience for everyone, regardless of gender, sexual orientation, disability, physical appearance, body size, race, nationality or religion is not only critical to the health of the entire open source community, it's something that must be considered at the beginning of a project.

Code of Conduct

A code of conduct may not seem necessary as your community is getting its start. However, creating a path for conflict identification and resolution at the start can head off issues before they balloon out of control and alienate valuable contributors and community members. Make the code of conduct a carefully crafted, but also prominent, part of the larger strategy to be inclusive and diverse. The OpenStack Foundation initially adopted the Ubuntu Code of Conduct when establishing its own.

The first lesson learned is the enforcement policy is equally as important as the code of conduct. We did not put enough thought into how it was applied or enforced across our various community events and activities. Delaying the resolution process while your leadership consults legal experts and attempts to come to a solution can be more damaging than the violation itself. Having a clear path to enforcement and resolution sends a strong message to the community that you have thought through the process and are looking out for their best interest.

Representation? A few years into the project, we worked with the community, including the Diversity Working Group, to publicly document an enforcement policy. Again, we looked to another successful open source community, Python and PyCon, as a basis for our policy. This policy gives anyone who wants to report an issue a clear call to action and sets expectations for how it will be handled and gives the Foundation staff a clear process to follow and removes the emotion from the process.

Check the health of your community as you go. Do you have something similar to the following?

Groups that advocate for minorities: A working group to help ensure projects and teams within the community are following the code of conduct and properly representing diverse voices.

Visible documentation of policies and enforcement

Regular surveys and check-ins with your community

The strength of the community can be enhanced through education, culture, pro-active recruitment, in addition to the processes mentioned above.

Consider that the needs for diversity and inclusiveness extend beyond the normal development community and must be shared with your users and the ecosystem at large. Don't assume that you know all of the barriers that your community members may face. Take the extra steps to pro-actively ask them to identify the challenges they face in trying to contribute and then break down barriers to participation whether those barriers are time zones, culture, gender, age, education, etc. Supporting a diverse set of leaders, both geographical and by organization, can help reinforce this participation and will ultimately make for a stronger community.

Contributor Recognition & Motivation

Contributor motivation is key: Available leadership positions Making sure contributors' voices are heard
Contributor recognition: Contributors recognizing each other and share stories Awards

An open source project cannot survive without contributors, so it is important for project leaders to motivate developers and find chances to encourage them. It could be a mention in the project newsletters or an email sent to public mailing lists or blog posts. Another good example could be the Open Infrastructure Community Contributor Awards⁴ which offer recognition to behind-the-scenes heroes and are nominated at every Summit by other community members.

Open & Transparent Communication

Is there anything more emblematic of the modern work-force than attempting to solve the problem of day-to-day communication? Open source communities face standard issues of isolation due to remote work, time zone variations, travel, and so on. There is typically no home office for teams to meet face-to-face in. Conversely, remote tribes of team members can work together on a project, but in the same physical office space, creating friction amongst other team members.

Highly transparent communication is imperative to help bridge these barriers to a healthy community. Open communication channels (mailing list, IRC or slack, web-site) not only help to document decisions, but enable new contributors to catch up and get involved with the community. Providing a set of open source, and internationally available, tools will aid collaboration and help build community. OpenStack initially started collaborating with Google Docs, but ultimately realized that we excluded a large portion of the world where Google products were inaccessible/unavailable.

Host meetings in a way that can be archived and searched, so that the conversations are accessible to all time-zones and participants who do not speak English as their first language. Internationalization (translation, tool choices like google docs, time-zones), in general, helps foster a more diverse group of contributors.

Board meetings in particular should be open so that anyone can dial in. Notes/re-cap should be sent out to the community at large via mailing lists within 48 hours of the meeting. At the OpenStack Foundation, the transparency policy for the board developed within the first year.

In person communication is as important as online. Identify the most accessible way to leverage the community and their channels to share your messaging. This can include local user groups, regional meet-ups, international/national summits, developer mid-cycles. All can be used to further educate and engage your open source community.

Events

Support upstream developers with dedicated space and events to collaborate and get work done. This includes collaboration within a project and cross-project collaboration. Create a productive event that combines upstream developers with operators so that production challenges and successes can be combined with software road-maps and bug tracking. Create an opportunity for ecosystem companies to interact with operators and developers to educate around available products, gain insights from the market and participate in road-map discussions. Identify gaps in both the community and the overall market and use events as an opportunity to gather content, subject matter experts and adjacent communities to share knowledge and solve problems. OpenStack Days Industry events

Education & On-boarding

The goal is to make the barrier to entry as low as possible. Clear, discoverable and digestible documentation Recorded and real time on-boarding sessions - webinars, f2f sessions at events Suggest training the trainer - creating a toolbox and guidelines to provide to regional community members so they can lead their own on-boarding sessions Documented ways to communicate with seasoned experts / join meetings to accelerate on-boarding. Mentorship programs

Ambassadors & User Groups

Supporting global communities through user groups, ambassador program, Providing resources & content for events and meet-ups, and setting precedents for those events (branding, content, etc.), while still giving them creative freedom building the relationships first; find leaders outside of the Foundation to foster new user groups leaders; collab sessions at Summits using tools available to all regions community of 90,000; team of 23 (XX ambassadors, 100+ user groups) Collaborating with local leaders to better understand regional differences in the technology choices, use cases and community involvement. Create a way to co-own user group contacts to ease the transfer of ownership if people leave the community or if there are any bad actors.

Cross-community collaboration

From the very beginning invite other communities and projects to collaborate and participate. In turn actively reach out to engage and participate in other communities to enhance integration efforts. Need examples here

Footnotes

18 KiB Raw Blame History