Restructuring body and text
This change restructures the body of the book to add an additional chapter about actions and processes. It also edits the chapters to create a more cohesive flow and voice through the whole. Change-Id: I31690e21ecc801e6c62cce57c5ed4174335bdc61 Signed-off-by: Ildiko Vancsa <ildiko.vancsa@gmail.com>
This commit is contained in:
Ildiko Vancsa
parent
0bf814f232
commit
5db7e933c2
343
doc/source/activities_and_processes.rst
Normal file
343
doc/source/activities_and_processes.rst
Normal file
@ -0,0 +1,343 @@
|
|||||||
|
==================
|
||||||
|
Practical Examples
|
||||||
|
==================
|
||||||
|
|
||||||
|
NOTE: This section still needs editing
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
- Common mission & goals.
|
||||||
|
- Effective governance & leadership.
|
||||||
|
- Diversity & Inclusiveness.
|
||||||
|
- Contributor recognition & motivation.
|
||||||
|
- Open & Transparent 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 [#f1]_, which was circulated
|
||||||
|
to the public mailing list for feedback and new ideas [#f2]_. The list of
|
||||||
|
ideas from the etherpad was then put to a Condorcet vote [#f3]_ for the same
|
||||||
|
group of contributors, and the result 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
|
||||||
|
---------------------------------
|
||||||
|
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
|
||||||
|
------------------------------------
|
||||||
|
|
||||||
|
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 [#f4]_ 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.
|
||||||
|
|
||||||
|
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
|
||||||
|
|
||||||
|
|
||||||
|
.. rubric:: Footnotes
|
||||||
|
|
||||||
|
.. [#f1] https://etherpad.openstack.org/p/zuul-mission
|
||||||
|
.. [#f2] http://lists.zuul-ci.org/pipermail/zuul-discuss/2018-May/000394.html
|
||||||
|
.. [#f3] https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_708e8e18e160cdcf
|
||||||
|
.. [#f4] https://superuser.openstack.org/articles/open-infrastructure-community-contributor-awards-denver-summit-edition/
|
||||||
|
|
||||||
@ -10,6 +10,7 @@ Contents
|
|||||||
|
|
||||||
introduction
|
introduction
|
||||||
opensource
|
opensource
|
||||||
|
opencommunity
|
||||||
opendesign
|
opendesign
|
||||||
opendevelopment
|
opendevelopment
|
||||||
opencommunity
|
activities_and_processes
|
||||||
|
|||||||
@ -2,365 +2,48 @@
|
|||||||
Open Community
|
Open Community
|
||||||
==============
|
==============
|
||||||
|
|
||||||
One of our core goals is to maintain a healthy, vibrant developer and user
|
The success of open source -as a concept, mindset and way of collaborative
|
||||||
community. Most decisions in the community are made using a lazy consensus
|
activities, such as software development-, lies within the community and the
|
||||||
model and all processes are documented, open and transparent.
|
ecosystem around it.
|
||||||
|
|
||||||
The technical governance of the project is provided by the community
|
This pillar of the Four Opens ensures an open and collaborative environment
|
||||||
itself, with contributors electing team leads and members of the Technical
|
that is welcoming and inclusive to everyone who would like to participate.
|
||||||
Committee.
|
Whether you are one of the contributors or a person who supports a community,
|
||||||
|
you need to work on making it a level playing field for everybody regardless
|
||||||
|
of gender, race, company affiliation, and so forth. Everybody's actions count.
|
||||||
|
|
||||||
All project meetings are held in public IRC channels and are recorded.
|
Every community that is bigger than a handful of people will form governance
|
||||||
Additional technical communication is through public mailing lists and are
|
bodies that are responsible for the smooth and efficient operation of the group
|
||||||
archived.
|
of people who work on to achieve their common goals and mission. In order to
|
||||||
|
make your community an open environment everyone needs to have the opportunity
|
||||||
|
to take on a leadership position or become part of any of the governing bodies.
|
||||||
|
Processes, such as meritocracy-based leadership, are good examples to practice.
|
||||||
|
|
||||||
"Open Community" is the critical piece of the Four Opens puzzle. It embodies
|
In order for people to be able to rise to become leaders within the community,
|
||||||
the key difference from single-vendor controlled open source projects. It is
|
they need to have access and be able to participate in the design and
|
||||||
about ensuring that the community is a cohesive, inclusive, level playing
|
development process. We will discuss these principles in later sections of this
|
||||||
ground where all the voices are heard and anyone can rise to leadership
|
document.
|
||||||
positions.
|
|
||||||
|
|
||||||
To build a truly open community, you need to balance the three forces:
|
To make a community open and diverse, the participants need to define common
|
||||||
developers, users and ecosystem. It's easy to think simply in terms of upstream
|
goals and a mission that they will work on together. Goals and mission can
|
||||||
and downstream, but communities are complex organisms, and the reality is much
|
evolve over time to follow the evolution of the project based on technology
|
||||||
more dynamic. It's important to establish common goals and build strong
|
evolution, users' needs and contributors' ideas and innovations. The open
|
||||||
connections between the forces, because operating in silos will dilute the
|
environment, where all actors can equally participate, provides the possibility
|
||||||
power of the community. Each force affects the others and they have to be
|
to create a feedback loop between those who work on the project and those, who
|
||||||
working in harmony to achieve anything.
|
are using it - either directly or by creating a service or offering based on
|
||||||
|
the project.
|
||||||
|
|
||||||
Open Community defines how to best align these forces through:
|
The open and well documented communication channels will help you to establish
|
||||||
|
good interaction between all participants. By creating and maintaining an equal
|
||||||
|
environment for everyone with open and neutral governance you will encourage
|
||||||
|
the community to become diverse as opposed to being controlled by a single
|
||||||
|
company or organization.
|
||||||
|
|
||||||
- Common mission & goals.
|
In an ideal world users of the project also become contributors to your
|
||||||
- Effective governance & leadership.
|
community, as their participation is invaluable to provide feedback and share
|
||||||
- Diversity & Inclusiveness.
|
their needs and channalenges the project is trying to solve.
|
||||||
- Contributor recognition & motivation.
|
|
||||||
- Open & Transparent 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
|
To build and maintain an open community, everyone who participates and supports
|
||||||
----------------------
|
it needs to have an open and inclusive mindset with which they perform all
|
||||||
A strong mission statement is one of the most critical elements to achieve
|
actions and interactions. Furthermore, there are processes and actions to
|
||||||
a healthy open source community. It's imperative to outline a long term vision
|
support this pillar of the Four Opens, which this document will discuss later.
|
||||||
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 [#f1]_, which was circulated
|
|
||||||
to the public mailing list for feedback and new ideas [#f2]_. The list of
|
|
||||||
ideas from the etherpad was then put to a Condorcet vote [#f3]_ for the same
|
|
||||||
group of contributors, and the result 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
|
|
||||||
---------------------------------
|
|
||||||
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
|
|
||||||
------------------------------------
|
|
||||||
|
|
||||||
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 [#f4]_ 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.
|
|
||||||
|
|
||||||
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
|
|
||||||
|
|
||||||
|
|
||||||
.. rubric:: Footnotes
|
|
||||||
|
|
||||||
.. [#f1] https://etherpad.openstack.org/p/zuul-mission
|
|
||||||
.. [#f2] http://lists.zuul-ci.org/pipermail/zuul-discuss/2018-May/000394.html
|
|
||||||
.. [#f3] https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_708e8e18e160cdcf
|
|
||||||
.. [#f4] https://superuser.openstack.org/articles/open-infrastructure-community-contributor-awards-denver-summit-edition/
|
|
||||||
|
|||||||
@ -2,80 +2,117 @@
|
|||||||
Open Design
|
Open Design
|
||||||
===========
|
===========
|
||||||
|
|
||||||
We are committed to an open design process. Every development cycle the
|
In the previous section we established the concept of Open Community, which
|
||||||
OpenStack community holds face-to-face events to gather requirements and
|
requires transparency in every step of creating and maintaining artifacts;
|
||||||
write specifications for the upcoming release. Those events, which are open
|
Open Design is an essential part of this.
|
||||||
to anyone, include users, developers, and upstream projects. We gather
|
|
||||||
requirements, define priorities and flesh out technical design to guide
|
|
||||||
development for the next development cycle.
|
|
||||||
|
|
||||||
The community controls the design process. You can help make this software
|
In order to provide access to everyone to all steps and decision points of the
|
||||||
meet your needs.
|
design process, no one person, group of people or organization can maintain
|
||||||
|
control over the project.
|
||||||
|
|
||||||
The Four Opens are all about the acceptance of letting go of control over an
|
It is a common practice for companies to develop software in-house and then
|
||||||
open source project. A common open source development model for traditional
|
release the code as open source and start to form a community around it. As
|
||||||
software development organizations is to develop internally, then release
|
part of their actions on the way they often fail with letting go of the control
|
||||||
their project under an open source license once it is mostly complete.
|
over the software and processes within the community. This can easily result in
|
||||||
While most of them will also commit to a transparent and inclusive
|
a single-vendor community as the leadership positions and decisions are mainly
|
||||||
development process, they still frequently maintain control of the software
|
controlled by this organization and therefore other contributors cannot take
|
||||||
with most of the design decisions being made by organization leaders and
|
ownership and feel as being equally involved in the community.
|
||||||
implemented by their employees. This keeps control of the direction of the
|
|
||||||
project with the organization, but can result in missing out on unexpected
|
|
||||||
ideas from community members and may actually discourage others from getting
|
|
||||||
involved in what they may perceive as a company product rather than an open and
|
|
||||||
inclusive community project.
|
|
||||||
|
|
||||||
Using the principle of "Open Design" takes this one step beyond and guarantees
|
Single-vendor projects don't have a good reputation as both the design
|
||||||
a transparent and open process for planning and designing the software. It's
|
directions and maintenance are highly dependent on the controlling organization
|
||||||
about letting go of the control of the design of the software and its feature
|
which puts high risk on the project for users and other companies to depend on
|
||||||
roadmap, and accepting that it should be driven by the community.
|
it. At the same time contributors, who are not part of that one company, can't
|
||||||
|
feel to be equal members if they don't have the option to be involved in all
|
||||||
|
steps and decisions, which will discourage them from participating.
|
||||||
|
|
||||||
This is not easy to do. Design is an opinionated process. Design by committee
|
By opening up the design process for everyone to participate in and have their
|
||||||
can be inefficient. It's easier and faster to keep design and feature
|
voices heard, you will get more innovative ideas and more robust solutions.
|
||||||
development in the hands of a happy few, behind closed doors, than to get
|
|
||||||
consensus across a community around desired features and priorities. But that
|
|
||||||
would be choosing to go fast in the short term with a small group rather than
|
|
||||||
going far in the long term with a larger group. Community-agreed design will be
|
|
||||||
slow, but it will lead to a better product that better answers the need of the
|
|
||||||
users.
|
|
||||||
|
|
||||||
In this section we'll cover how to set up your project and your development
|
On the other hand, you need to be aware that opening up the design and decision
|
||||||
cycle in a way that enables and encourages Open Design.
|
making process to a larger group can slow down to come to consensus in some
|
||||||
|
cases. However, by electing leaders from the community and by the community
|
||||||
|
based on merit, you can ensure that the decisions will always reflect and
|
||||||
|
represent the community, whether the contributors made them or their elected
|
||||||
|
leaders. While the decision making process might still be longer than in case
|
||||||
|
of a smaller group, it is a tradeoff that will benefit the whole community on
|
||||||
|
the long run.
|
||||||
|
|
||||||
The "Open Design" Principle in Practice
|
The community also needs to ensure that the processes and timelines they use
|
||||||
---------------------------------------
|
are clearly defined and made available for anyone to access publicly without
|
||||||
|
any restrictions. This will ensure that both newcomers and established
|
||||||
|
contributors know how they can participate, when and where decisions are made
|
||||||
|
and will make it easier for them to participate and help improving and
|
||||||
|
maintaining the project.
|
||||||
|
|
||||||
Open Design begins with the establishment of a structure to guide the "when",
|
To provide you an example, we will discuss the approach the OpenStack community
|
||||||
"how", and "where" of the design process. The "when" refers to the
|
took with their release process.
|
||||||
release-cadence of the software, particularly if it is a feature-based or
|
|
||||||
time-based release. A feature-based release allows the community to reach a
|
|
||||||
consensus on required capabilities a release should have, then only deliver the
|
|
||||||
next version of the software when those features are complete. While there are
|
|
||||||
many processes that can help estimate the time and effort it will take to
|
|
||||||
deliver a set of requirements, feature-based releases often result in delays in
|
|
||||||
delivery. If you're encouraging a large community of diverse developers, it
|
|
||||||
gets pretty difficult to get commitments and coordinate activities, leading to
|
|
||||||
significant delays. Those delays can have differing and significant impacts,
|
|
||||||
particularly on vendors who rely on release schedules for delivering software.
|
|
||||||
Release delays can create tension in the community, and raise the barrier of
|
|
||||||
entry for contributors by creating an unknown cost.
|
|
||||||
|
|
||||||
Rather than adopting feature-based releases and doing a bad job at them, it
|
The Open Design Principle in Practice
|
||||||
is healthier to adopt time-based releases and embrace their benefits. Knowing
|
-------------------------------------
|
||||||
when a release will be cut gives you predictability that is key to a
|
|
||||||
healthy collaboration. With a time-based release, there's no single group that
|
|
||||||
decides what feature can or can't be included in a release. The features that
|
|
||||||
are complete at the release deadline are the features available in that
|
|
||||||
release. A time based release means that everybody who depends on the software
|
|
||||||
has a clear expectation of how to contribute to the software, and what to
|
|
||||||
expect at any given step in the software development process. An additional
|
|
||||||
benefit is the ability to schedule events around aspects of the development
|
|
||||||
cycle.
|
|
||||||
|
|
||||||
A time-based release cycle becomes critical for the success of "Open Design".
|
Open Design involves to define the lifecycle of the software development
|
||||||
Once the schedule is set, contributors know exactly when they can add their
|
process, which boils down to define a release process to be able to evolve and
|
||||||
voice to the design process. Part of the OpenStack design process is to have
|
maintain the project artifacts. A release process defines the "when", "where"
|
||||||
face-to-face events at the beginning of every release cycle to begin the design
|
and "how" the design process happens.
|
||||||
process for the next release. This in-person meeting focuses the attention of
|
|
||||||
the community in a neutral environment. These events are open to anyone,
|
To define the "when", you need to define a release cadence to put out new
|
||||||
including developers, users, and vendors.
|
versions of the software and related items, such as documentation. To make this
|
||||||
|
step more complicated, you need to decide between a feature-based or a
|
||||||
|
time-based release model.
|
||||||
|
|
||||||
|
With the former approach, the community needs to identify a set of features
|
||||||
|
that needs to be complete in order to be able to cut a release. In most cases
|
||||||
|
this results in the inability to provide a good estimate on when the new
|
||||||
|
version of the artifacts will be available. With delays in the estimated
|
||||||
|
delivery time, users will likely look for alternatives after some time as it
|
||||||
|
is harder to plan downstream with this model. A larger community with a more
|
||||||
|
complex structure will likely have a hard time to commit to a set of
|
||||||
|
functionality and coordinate the steps needed to deliver them as estimated.
|
||||||
|
However, projects with a higher number of external dependencies or with a
|
||||||
|
larger refactoring activity this option can still be something to consider even
|
||||||
|
if only on a temporary basis.
|
||||||
|
|
||||||
|
A time-based release model commits to a release cycle and adapts the
|
||||||
|
development process to ensure to produce stable and reliable software and
|
||||||
|
artifacts on time. This model has a lot of advantages compared to the previous
|
||||||
|
one in case of open source communities of any size. Most importantly, it gives
|
||||||
|
predictability which is important for those who depend on the release
|
||||||
|
downstream as well as to those who are participating in the community. In
|
||||||
|
addition, it also makes it easier for newcomers to start participating in your
|
||||||
|
community, as they can identify which phase of the release cycle the community
|
||||||
|
is going through and that makes it easier for them to find a task or activity
|
||||||
|
to start to contribute. This model provides a higher level of transparency with
|
||||||
|
being able to define deadlines for processes throughout the cycle.
|
||||||
|
|
||||||
|
This approach makes it a little harder to commit, when it comes to features and
|
||||||
|
functionality. The community will prioritize work items and will include the
|
||||||
|
items that are ready by the time of the release. In some cases a feature might
|
||||||
|
only get partially complete and users need to wait until the next release to be
|
||||||
|
able to use it. While this can be inconvenient, by looking at the roadmap for
|
||||||
|
the project you can still get a good picture about when you get new
|
||||||
|
functionality that you need. If a feature is important to you, you can also
|
||||||
|
always decide to participate in the making, if you are not doing so yet.
|
||||||
|
|
||||||
|
In addition, time-based release cycles provide you and the community the
|
||||||
|
ability to plan events and activities, like hackathons around the cadence to
|
||||||
|
boost the planning phase, bug fixing or share news and updates with those
|
||||||
|
who are interested or new to the project.
|
||||||
|
|
||||||
|
While choosing time-based release process is not a criteria of the Open Design
|
||||||
|
principle, it is a more natural choice to create good dynamics for a community
|
||||||
|
with processes that are easy to discover and follow.
|
||||||
|
|
||||||
|
The OpenStack community chose this model and has been practicing it
|
||||||
|
successfully since the launch of the project. The community picked a 6-month
|
||||||
|
release cadence as that fits best to the size and complexity of the project.
|
||||||
|
The community gathers at the beginning of every release cycle, either in person
|
||||||
|
or virtually, to provide an environment for more efficient discussions that can
|
||||||
|
help with faster planning and better maintenance. The events are open to
|
||||||
|
everyone to participate, let them be contributors, users, new comers, and so
|
||||||
|
forth.
|
||||||
|
|
||||||
|
In order to remain inclusive to those who cannot participate in an event the
|
||||||
|
community avoids making decisions at these events. Contributors rather making
|
||||||
|
meeting notes available and share thoughts and proposals on the mailing list
|
||||||
|
and other channels to provide an opportunity to engage in the discussion to
|
||||||
|
those who didn't have access to the event.
|
||||||
|
|||||||
@ -2,51 +2,71 @@
|
|||||||
Open Development
|
Open Development
|
||||||
================
|
================
|
||||||
|
|
||||||
We maintain a publicly available source code repository through the entire
|
Open Development is the next pillar as well as the next step after establishing
|
||||||
development process. We do public code reviews. We have public road maps.
|
the Open Design principle. Similarly to the former steps, you also need a
|
||||||
This makes participation simpler, allows users to follow the development
|
transparent and inclusive development process that enables everyone to
|
||||||
process and participate in QA at an early stage.
|
participate as equals on a level playing field.
|
||||||
|
|
||||||
"Open development" refers to the adoption of transparent and inclusive
|
The contributors of your community need to have access to every step of the
|
||||||
development processes that enable everyone to participate as an equal on a
|
process. This means that the process needs to be documented and accessible for
|
||||||
level playing field. Publicly-accessible services means that everyone can see
|
everyone including established contributors and newcomers. You need to use
|
||||||
everything about development activities, without even needing to sign up to a
|
tools and services that are also available to all participants to use in order
|
||||||
service. Open development also means that all patches are welcome for
|
to perform the required steps of the process.
|
||||||
consideration, whether that patch is from a project founder or a first time
|
|
||||||
contributor. A successful open source project will adopt a set of standards
|
|
||||||
that clearly states the metrics and standards that a contribution will be
|
|
||||||
evaluated against. By defining these standards we create an egalitarian process
|
|
||||||
in which contributions are evaluated on a level playing field. The metrics for
|
|
||||||
evaluating a patch can include:
|
|
||||||
|
|
||||||
- Correctness: does the code include tests of its functionality?
|
The community should not differentiate between contributions depending on the
|
||||||
- Quality Assurance: does the code integrate with other projects and
|
affiliation of the person who authored or committed that change. The review
|
||||||
not introduce regressions?
|
process needs to be open with history so requests and decisions can be accessed
|
||||||
- Documentation: does a new feature include documentation on what
|
later. While accepting contributions can look subjective you need to put all
|
||||||
it does and how to properly configure it?
|
the effort into documenting criteria, guidelines - to write code or
|
||||||
- Purpose: does the code implement a feature identified in the open
|
documentation - and processes to ensure the most objective process possible.
|
||||||
design process?
|
In addition, you can also put a lot of emphasis on automation, such as testing
|
||||||
|
- unit, functional, integration tests and more - in case of source code.
|
||||||
|
|
||||||
Automation, like automated unit, integration, and style checking, can go a long
|
Reviewing contributions should be available, and encouraged, to everyone who is
|
||||||
way to establishing a baseline standard for new code. Code review by trusted
|
interested in the project, even if the final decision can be made only by a
|
||||||
community members is the additional critical layer on top of the automated
|
subset of contributors. These contributors -called core reviewers, committers,
|
||||||
tooling?
|
etc-, should be members of the project leadership and elected by the fellow
|
||||||
|
community members based on merit.
|
||||||
|
|
||||||
This raises the question, how does one become a trusted community member?
|
The open development process opens up the avenue for newcomers to become
|
||||||
Regular participation in code review and submitting patches builds reputation
|
seasoned contributors and then take on leadership positions, if that is
|
||||||
and trust within a community. Aspects of the open development process must
|
something that they desire. Besides contributing new ideas and functionality,
|
||||||
include facilities for anyone (not just existing projects contributors and
|
it is very important to demonstrate how much one cares about the project,
|
||||||
leaders) to:
|
including the quality of the software as well as the processes used to create
|
||||||
|
and maintain it. You can become part of the community by reviewing
|
||||||
|
contributions, propose new ideas, fix issues and participate in the community's
|
||||||
|
communication channels, like mailing lists, meetings, and so forth.
|
||||||
|
|
||||||
- Discover current priorities and tasks.
|
|
||||||
- Report bugs and vulnerabilities.
|
|
||||||
- Leave reviews on existing patches.
|
|
||||||
- Submit patches to a project.
|
|
||||||
|
|
||||||
There must also be a clearly defined process that describes how a contributor
|
Open Development Process Examples
|
||||||
can graduate to different levels of leadership within a project. The success of
|
---------------------------------
|
||||||
Open Development relies not just on the availability and accessibility of
|
|
||||||
tooling in a project, but also upon the healthy governance of a community
|
|
||||||
(which we will discuss further in the next chapter on :doc:`Open
|
|
||||||
Community <opencommunity>`).
|
|
||||||
|
|
||||||
|
The OpenStack community is a large group of contributors with multiple project
|
||||||
|
teams who've been actively practicing and evolving their development processes
|
||||||
|
to make it more efficient and inclusive.
|
||||||
|
|
||||||
|
The community is following a set of metrics and guiding principles to evaluate
|
||||||
|
a code or documentation change:
|
||||||
|
|
||||||
|
- Correctness: code changes need to have corresponding tests to ensure it works
|
||||||
|
as specified
|
||||||
|
- Quality Assurance: the code has test cases to ensure smooth integration with
|
||||||
|
other services and does not introduce regression
|
||||||
|
- Documentation: a new feature needs to be properly documented, including
|
||||||
|
API documentation and configuration options
|
||||||
|
- Purpose: the code change should implement a bug fix or new functionality as
|
||||||
|
previously identified and discussed as part of the open design process
|
||||||
|
|
||||||
|
The OpenStack community prioritized automation from the beginning to ensure the
|
||||||
|
quality of the code as well as an open development process. Code changes go
|
||||||
|
through multiple rounds of automated testing where a change cannot be approved
|
||||||
|
without a successful test run. Once a change is approved by the core reviewers
|
||||||
|
it goes through one more round of testing. If that is successful, the change
|
||||||
|
gets merged into the project's code base. It is very important to note, that
|
||||||
|
the last entity who votes on the change is the tool that executes all the
|
||||||
|
applicable test cases.
|
||||||
|
|
||||||
|
The community is actively working on their contributor focused documentation
|
||||||
|
that captures the development processes and tools that are used throughout all
|
||||||
|
the phases. This ensures that everyone can gain the knowledge to be able to
|
||||||
|
contribute and follow the same guidelines to ensure a level playing field.
|
||||||
|
|||||||
@ -2,83 +2,92 @@
|
|||||||
Open Source
|
Open Source
|
||||||
===========
|
===========
|
||||||
|
|
||||||
We do not produce "open core" software. We are committed to creating truly
|
The most fundamental principle, historically reaching back to the Four Freedoms
|
||||||
open source software that is usable and scalable. Truly open source
|
of the Free Software Foundation, is Open Source. Any software developed under
|
||||||
software is not feature or performance limited and is not crippled. There
|
the guidance of the Four Opens must be released under an open source license.
|
||||||
will be no "Enterprise Edition".
|
It means that anyone should be able to study a program, modify it, and
|
||||||
|
redistribute either the original or the modified version so that others may
|
||||||
|
benefit from their work. But the Four Opens is much more than just access to
|
||||||
|
the source code, as you will see in the following chapters.
|
||||||
|
|
||||||
We use the Apache License, 2.0. It is:
|
As discussed earlier, free and open access to the source code is just just one
|
||||||
|
factor, but it doesn't ensure anything about the quality, usability and
|
||||||
|
scalability of that code. Open Source also entails the possibility to openly
|
||||||
|
collaborate on any enhancement or new development direction to the software,
|
||||||
|
and it should not be limited in features or performance to enable a company's
|
||||||
|
business model. Open Core is a collaboration model where some of the
|
||||||
|
functionality is open source, while there are features that are withheld by a
|
||||||
|
company controlling the open source project, allowing to sell a proprietary
|
||||||
|
"Enterprise Edition".
|
||||||
|
|
||||||
- OSI approved [#OSI]_.
|
While the Open Core model is compatible with open source and might seem like a
|
||||||
- GPLv3 compatible [#GPLv3]_.
|
good model at first, it has a lot of shortcomings that prevents you from
|
||||||
- DFSG compatible [#DFSG]_.
|
building a healthy and balanced community around it. It cannot engage
|
||||||
|
participants from other vendor companies long term as not all functionality is
|
||||||
|
available to add to the community version of the software. This can lead to
|
||||||
|
copy the existing code base and develop it further under a different name and
|
||||||
|
maybe license, this is what is called forking. This behavior creates
|
||||||
|
fragmentation in the community that can result in tension and unhealthy
|
||||||
|
environments.
|
||||||
|
|
||||||
The most fundamental principle, historically reaching back to the "Four
|
Users of the open source edition of an Open Core software may fall into similar
|
||||||
Freedoms" of the Free Software Foundation, is "Open Source". Any software
|
traps, as they can be forced to purchase the Enterprise Edition to access extra
|
||||||
developed under the Four Opens must be released under an open source license.
|
functionality that is only available there. This can result in lock-in, despite
|
||||||
It means being able to study a program, modify it, and redistribute either the
|
of them originally choosing an open source solution, which then didn't give
|
||||||
original or the modified version so that others may benefit from your work.
|
them the freedom it was supposed to. This can lead them to the choice of
|
||||||
|
looking for a different community or solution overall.
|
||||||
|
|
||||||
That is a minimum standard for what we mean by "Open Source" in the Four Opens.
|
The Open Core model always fails when a contributor eventually tries to add a
|
||||||
Beyond that, we want the software to be truly usable and scalable. This adds
|
feature that is not supposed to be made available in the open source version
|
||||||
the additional condition that it should not be limited in features or crippled
|
according to the company in control, who owns the productized version. This
|
||||||
in performance to artificially enable any business model.
|
circumstance leads to confusion, frustration and tension which undermines the
|
||||||
|
concept of open collaboration on a level playing field, which the Four Opens
|
||||||
|
are meant to ensure.
|
||||||
|
|
||||||
In particular, the "Open Source" principle is strongly opposed the "open core"
|
In addition, these enterprise features often fall in the groups of security or
|
||||||
model, where source code and features in a proprietary "Enterprise Edition" are
|
scalability, which are desirable by all users.
|
||||||
deliberately withheld from the open source software. This model invariably
|
|
||||||
fails both vendors who promote it and users of the software. On the vendors
|
|
||||||
side, the ethos of committed open source developers will lead to the withheld
|
|
||||||
features and shortcomings being addressed as part of the open source version of
|
|
||||||
the product. In the best case the enhancements are made to the original
|
|
||||||
version. In the worst case, the software is forked, fragmenting the community.
|
|
||||||
Either way, the commercial upshot for "open core" is limited and risky. On the
|
|
||||||
users side, they are unnecessarily given a limited experience, with the
|
|
||||||
choices of giving up the freedoms that open source software provides by
|
|
||||||
purchasing the "enterprise" edition, wasting time and resources re-implementing
|
|
||||||
features or capabilities that already exist, or turning to other projects to
|
|
||||||
fill their needs.
|
|
||||||
|
|
||||||
This model always fails once a community member tries to add a feature that the
|
The Open Source Principle in Practice
|
||||||
open core company product management would prefer to keep in the proprietary
|
-------------------------------------
|
||||||
version. That ultimately results in reduced adoption, prevents a community of
|
|
||||||
equals to be formed, and increases the risk of a fork or emergence of a truly
|
|
||||||
open competition. It is an especially bad choice for infrastructure software,
|
|
||||||
where enterprise features (like security or scalability) are desirable for
|
|
||||||
every user.
|
|
||||||
|
|
||||||
The "Open Source" Principle in Practice
|
Open Source begins with the choice of license a community applies to its
|
||||||
---------------------------------------
|
project. In most cases, the communities supported by the Open Infrastructure
|
||||||
|
Foundation use v2.0 of the Apache License [#apachev2]_. It is:
|
||||||
|
|
||||||
"Open Source" begins with the choice of license a community applies to its
|
- OSI approved [#OSI]_
|
||||||
project. In most cases at the OpenStack Foundation, we use v2.0 of the Apache
|
- GPLv3 compatible [#GPLv3]_
|
||||||
License [#apachev2]_. The license meets the requirements of being able
|
- DFSG compatible [#DFSG]_
|
||||||
to modify and
|
|
||||||
redistribute a work. It includes a number of provisions that also protect
|
|
||||||
end-users by granting copyright and patent licenses to all end users, while
|
|
||||||
limiting liability to the original copyright holder. This patent protection is
|
|
||||||
one of the distinguishing features in comparison to other open source licenses,
|
|
||||||
like the MIT License.
|
|
||||||
|
|
||||||
In practice, individual and corporate contributors need to understand the
|
This license meets the requirements of being able to modify and redistribute
|
||||||
consequences of contributing code to an Apache Licensed project, particularly
|
the work. It includes a number of provisions that also protect end-users by
|
||||||
the granting of copyright and patent licenses to all users of the software. To
|
granting copyright and patent licenses to all, while limiting liability to the
|
||||||
acknowledge this, many projects require that all contributors sign a
|
original copyright holder. This patent protection is one of the distinguishing
|
||||||
"Contributor License Agreement" (CLA) [#OSCLA]_ or "Developer Certificate of
|
features in comparison to other open source licenses, like the MIT License.
|
||||||
Origin" (DCO). Typically, a CLA is a stronger statement, attesting that a
|
|
||||||
contributor has a right to submit work to the project and that they are
|
In practice, regardless if you are an individual or corporate contributor, you
|
||||||
granting copyright and patent licenses in accordance with the Apache License
|
need to understand the consequences of contributing code to an Apache Licensed
|
||||||
along with their submissions. A DCO, on the other hand, is a bit lighter weight
|
project, particularly the granting of copyright and patent licenses to all
|
||||||
and is more of a statement (rather than a license) that the developer is indeed
|
users of the software. To acknowledge this, many projects require that all
|
||||||
authorized to submit changes to the project and understands that their
|
contributors sign a "Contributor License Agreement" (CLA) [#OSCLA]_ or
|
||||||
contributions will be used in accordance with the license. A CLA, being a
|
"Developer Certificate of Origin" (DCO).
|
||||||
stronger document, is also considered a barrier to entry. A DCO, in contrast,
|
|
||||||
lowers the barrier to entry by removing the requirement to consent to a legal
|
Typically, a CLA is a stronger statement, attesting that you, as a contributor,
|
||||||
document [#CLAvDCO]_.
|
have a right to submit work to the project and that they are granting copyright
|
||||||
|
and patent licenses in accordance with the Apache License along with your
|
||||||
|
submissions.
|
||||||
|
|
||||||
|
A DCO, on the other hand, is a bit lighter weight and is more of a statement
|
||||||
|
(rather than a license) that you, as developer, are indeed authorized to submit
|
||||||
|
changes to the project and understand that your contributions will be used in
|
||||||
|
accordance with the license.
|
||||||
|
|
||||||
|
A CLA, being a stronger document, is also often considered to be a barrier to
|
||||||
|
entry. A DCO, in contrast, lowers the barrier to entry by removing the
|
||||||
|
requirement to consent to a legal document [#CLAvDCO]_.
|
||||||
|
|
||||||
Apache 2.0 is very liberal in allowing companies to modify and use the code in
|
Apache 2.0 is very liberal in allowing companies to modify and use the code in
|
||||||
any way they want, and doesn't place requirements to release changes (although
|
any way they want, and doesn't place requirements to release changes (although
|
||||||
it doesn't prohibit them from doing do). This, along with the patent
|
it doesn't prohibit them from doing so). This, along with the patent
|
||||||
protections of the license, is one of the reasons why it is so popular. It has
|
protections of the license, is one of the reasons why it is so popular. It has
|
||||||
also been used in practice since 2004, and is fairly well understood amongst
|
also been used in practice since 2004, and is fairly well understood amongst
|
||||||
the corporate and open source legal communities.
|
the corporate and open source legal communities.
|
||||||
@ -88,21 +97,22 @@ very easy for companies to withhold enhancements that would be beneficial to
|
|||||||
the wider community, or to make changes to their version of the software that
|
the wider community, or to make changes to their version of the software that
|
||||||
breaks interoperability. While the license doesn't address these directly,
|
breaks interoperability. While the license doesn't address these directly,
|
||||||
there are guard-rails that a project can put in place to mitigate these risks.
|
there are guard-rails that a project can put in place to mitigate these risks.
|
||||||
Trademark programs based on interoperability or conformance testing are one
|
|
||||||
such tool. The OpenStack Foundation uses such a program. In order to qualify
|
|
||||||
for the trademark, a product can not modify API code (thus adding a stronger
|
|
||||||
modification restriction than provided by the Apache License), and it must
|
|
||||||
successfully demonstrate compatibility by passing a suite of interoperability
|
|
||||||
tests, run against the public API of the product. In this way, the scope of
|
|
||||||
modifications is limited.
|
|
||||||
|
|
||||||
Furthermore, in the case of fast-evolving infrastructure software, it's worth
|
Trademark programs based on interoperability or conformance testing are one
|
||||||
|
such tool. The Open Infrastructure Foundation uses such a program. In order to
|
||||||
|
qualify for the trademark, a product can not modify API code (thus adding a
|
||||||
|
stronger modification restriction than provided by the Apache License), and it
|
||||||
|
must successfully demonstrate compatibility by passing a suite of
|
||||||
|
interoperability tests, run against the public API of the product. In this way,
|
||||||
|
the scope of modifications is limited.
|
||||||
|
|
||||||
|
Furthermore, in case of fast-evolving infrastructure software, it's worth
|
||||||
noting that keeping local changes private is not a great long-term strategy.
|
noting that keeping local changes private is not a great long-term strategy.
|
||||||
Maintaining a delta between code running in production and fast-evolving
|
Maintaining a delta between code running in production and fast-evolving
|
||||||
upstream open source code is very costly, and gets more difficult as time
|
upstream open source code is very costly, and gets more difficult as time
|
||||||
passes. Technical debt adds up quickly to a point where paying it back is
|
passes. Technical debt adds up quickly to a point where paying it back is
|
||||||
impossible. Engaging upstream to propose your local improvements and finally
|
impossible. Engaging upstream to propose your local improvements and finally
|
||||||
getting most of them in the open source project itself is the only sane
|
getting most of them in the open source project itself is the only sustainable
|
||||||
way forward over the long run.
|
way forward over the long run.
|
||||||
|
|
||||||
References
|
References
|
||||||
|
|||||||
Loading…
x
Reference in New Issue
Block a user