four-opens/doc/source/opencommunity.rst

==============
Open Community
==============

    One of our core goals is to maintain a healthy, vibrant developer and user
    community. Most decisions in the community are made using a lazy consensus
    model and all processes are documented, open and transparent.

    The technical governance of the project is provided by the community
    itself, with contributors electing team leads and members of the Technical
    Committee.

    All project meetings are held in public IRC channels and are recorded.
    Additional technical communication is through public mailing lists and are
    archived.

"Open Community" is the critical piece of the Four Opens puzzle. It embodies
the key difference from single-vendor controlled open source projects. It is
about ensuring that the community is a cohesive, inclusive, level playing
ground where all the voices are heard and anyone can rise to leadership
positions.

To build a truly open community, you need to balance the three forces:
developers, users and ecosystem. It's easy to think simply in terms of upstream
and downstream, but communities are complex organisms, and the reality is much
more dynamic. It's important to establish common goals and build strong
connections between the forces, because operating in silos will dilute the
power of the community. Each force affects the others and they have to be
working in harmony to achieve anything.

Open Community defines how to best align these forces through:

- Common mission & goals.
- Effective governance & leadership.
- Diversity & Inclusiveness.
- Contributor recognition & motivation.
- Communication.
- Branding & positioning (example of collaboration across forces, product
  definition).
- Education & On-boarding.
- Marketing & events.
- Ambassadors & meet-ups.
- Cross-community collaboration (NIH).

Common Mission & Goals
----------------------
A strong mission statement is one of the most critical elements to achieve
a healthy open source community. It's imperative to outline a long term vision
that is focused, but not overly constrained. A strong mission statement helps
define the community values and provides a guide to make decisions and
prioritize activities. It also helps new contributors and adjacent communities
quickly understand the goals of the project.

Getting the current stake-holders input and buy-in is key to the success.
Typically a mission statement is developed in the early days of the project
when there are fewer contributors, which makes it critical and as a bonus, a
bit easier--to have an open discussion and process. Similarly, changing the
mission statement should not be taken lightly, and can be a challenging process
as the community grows and there are a broader range of perspectives.  A good
example of this process came from the Zuul project. Project leaders first
drafted example mission statements in an etherpad, which was circulated to the
public mailing list for feedback and new ideas [link to archive]. The list of
ideas from the etherpad was then put to a Condorcet vote [link to archive] for
the same group of contributors, and the result was:

Effective Governance & Leadership
---------------------------------
Any group needs some form of governance. Governance is the set of rules that
the group follows in order to address issues and make decisions.  Open source
projects are just another group, so they need governance in order to avoid
decision apathy. There needs to be a place where the buck stops, with a clear
strategy in place to how to solve problems before they arise.

It is tempting, especially amongst tech people, to start with no rules and to
make them up as you go along. This is anarchy as a form of governance, and a
community formed under the absence of rules will naturally resist later
organization, as something they did not sign up for and resent.

It is also tempting to crown the project's initial creator as the "benevolent
dictator for life". That can work well, until the dictator becomes less
interested in the project or sadly disappears, at which point the project
enters governance limbo (as evidenced by the Gentoo and Python examples) with
no clear way forward. Or worse, engages in unchecked toxic and abusive behavior
that drives away contributors who aren't "tough enough" to handle the it.

A base framework for an Open Community governance would balance 4 basic rules:

Contributor-driven bodies
 It is critical that the people contributing code, documentation,
 usage experience, mentoring time or any other form of contribution to
 the project are aligned with the leadership of the project.

 Without contributor-driven bodies, leadership and contributors
 gradually drift apart, to the point where the contributors no longer
 feel like their leadership represents them, 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, as life will change people.
 Contributors should regularly be consulted, and the governance should
 generally encourage turnover.

Distinct groups call for distinct governance bodies
 If a community is made of disjoint groups with little to no overlap
 in membership, and those groups all need decisions to be made, then
 they probably need to each have their own governance body at that level.

Avoid vanity governance bodies
 There is no point in having a governance body where there is nothing
 to govern and no decision needed. Not every group of people in a
 community needs a governance body.

There is no one-size-fits-all implementation of these basic rules that would
work for any project. The size of the project is a critical difference.
Sometimes a multiple-level structure to properly balance autonomy and
consistency.

We generally recommend using regular elections using 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. 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, a formal vote should be
held. It's useful that the body has an odd number of members to avoid having to
give anyone a tie-breaking specific power.

Some of the things that indicate a healthy community are:

Diversity & inclusiveness
 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
------------------------------------

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.

Branding & positioning
----------------------

Branding and positioning is an example of collaboration across forces
and product definition which includes tools and processes.

Develop with stake-holders, open to community Some degree of
collaboration is useful and necessary, but only to an extent. This is
especially true in regards to visual identity since it can be
subjective and contentious. Design rationale should be provided to the
community to build consensus, but there should be key decision makers
to prevent the ideation process from continuing to infinity. Lessons
learned with project mascots In an attempt to provide consistency we
discovered removed individuality with some projects Slippery slope -
Once the projects got them, every small group also wanted their own
mascot Upside - These are actually picked up and used regularly by the
press and in group events. Critical to develop brand guidelines, to
give community guidelines to extend brand beyond internal resources
Development of consistent UX to be applied to web-sites,
documentation, etc.... This can be tough b/c the needs of the design
team don't always mesh with the needs/methods of developers managing
properties like documentation. Design must be available as an easy
plug in (HTML or javascript snippet) for headers and footers of sites.

Marketing & Strategy
--------------------

Once the initial branding and positioning has been finalized, share
with all key stake-holders. The challenge is often identifying the
correct channel to ensure everyone is apprised of updates and changes.
This may take time, but trying different options and even a
combination of a few often helps reinforce the messaging and branding
for the maximum impact. Ahead of the start of the year, identify the
largest areas of opportunity to increase brand visibility and
favorability to create a strategy. After identifying programs, events
and projects that can support the strategy, communicate this back to
the community, reaching out to the marketing teams at the ecosystem
companies directly to participate and provide feedback. This is your
biggest opportunity for a ripple effect. Stay apprised of market share
and user adoption metrics. Share these metrics openly and broadly,
particularly with the ecosystem companies and elected officials who
represent the three forces. This can be done in joint leadership
meetings, both remote and in person, as well as mailing list
newsletters. If the information could be perceived negatively, come
prepared with a solution or action plan to increase confidence of key
stake-holders. It's important to pro-actively share the negative
information when possible to prevent reactionary fear, uncertainty and
doubt. Identify key dates and milestones that celebrate the successes
of the community. Whether it's specific to a force, like a software
release or new case study or specific to the software or community
itself, like results in a market report or participation in a
supported event. This helps create momentum and rewards the positive
community efforts that are impacting another force or even the broader
industry. Leverage collaborative opportunities when possible. If the
broader market perceptions indicate a confusion around facts that
affect one of the three forces, collect the people most affected to
identify a way to pro-actively address the problem. An example would
be that OpenStack is seen as only a private cloud solution. A Public
Cloud Working Group that collaborates to create programs and most
recently messaging that will help alleviate the confusion is a
response that helps leverage the affected parties to address the
overarching issue.

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 & Meet-ups
----------------------

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 (NIH)
-----------------------------------

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