306 lines
17 KiB
ReStructuredText
306 lines
17 KiB
ReStructuredText
==============
|
||
Open Community
|
||
==============
|
||
|
||
One of our core goals is to maintain a healthy, vibrant developer and user
|
||
community. Most decisions are made using a lazy consensus model. 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 recorded.
|
||
Additional technical communication is through public mailing lists and is
|
||
archived.
|
||
|
||
"Open Community" is the critical piece of the Four Opens puzzle. It embodies
|
||
the key difference with 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<61><6C>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 rule, to to
|
||
make them up as you go along. This is anarchy as a form of governance, and a
|
||
community formed under the absence of rule 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 those 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 carefully crafted, but also prominent, part of 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<74><63> 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 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 (example of collaboration across forces, product
|
||
definition) including 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 Goal 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
|
||
|