openinfra/four-opens
Code Issues Proposed changes

Restructuring body and text

Browse Source 
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 2021-02-21 16:36:37 +01:00
parent 0bf814f232
commit 5db7e933c2
6 changed files with 633 additions and 539 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

343
doc/source/activities_and_processes.rst Normal file
View 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/

3
doc/source/index.rst
View File

@ -10,6 +10,7 @@ Contents
introduction
opensource
opencommunity
opendesign
opendevelopment
opencommunity
activities_and_processes

393
doc/source/opencommunity.rst
View File

@ -2,365 +2,48 @@
Open Community
==============
One of our core goals is to maintain a healthy, vibrant developer and user
community. Most decisions in the community are made using a lazy consensus
model and all processes are documented, open and transparent.
The success of open source -as a concept, mindset and way of collaborative
activities, such as software development-, lies within the community and the
ecosystem around it.
The technical governance of the project is provided by the community
itself, with contributors electing team leads and members of the Technical
Committee.
This pillar of the Four Opens ensures an open and collaborative environment
that is welcoming and inclusive to everyone who would like to participate.
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.
Additional technical communication is through public mailing lists and are
archived.
Every community that is bigger than a handful of people will form governance
bodies that are responsible for the smooth and efficient operation of the group
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
the key difference from single-vendor controlled open source projects. It is
about ensuring that the community is a cohesive, inclusive, level playing
ground where all the voices are heard and anyone can rise to leadership
positions.
In order for people to be able to rise to become leaders within the community,
they need to have access and be able to participate in the design and
development process. We will discuss these principles in later sections of this
document.
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.
To make a community open and diverse, the participants need to define common
goals and a mission that they will work on together. Goals and mission can
evolve over time to follow the evolution of the project based on technology
evolution, users' needs and contributors' ideas and innovations. The open
environment, where all actors can equally participate, provides the possibility
to create a feedback loop between those who work on the project and those, who
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.
- 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).
In an ideal world users of the project also become contributors to your
community, as their participation is invaluable to provide feedback and share
their needs and channalenges the project is trying to solve.
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/
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
actions and interactions. Furthermore, there are processes and actions to
support this pillar of the Four Opens, which this document will discuss later.

173
doc/source/opendesign.rst
View File

@ -2,80 +2,117 @@
Open Design
===========
We are committed to an open design process. Every development cycle the
OpenStack community holds face-to-face events to gather requirements and
write specifications for the upcoming release. Those events, which are open
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.
In the previous section we established the concept of Open Community, which
requires transparency in every step of creating and maintaining artifacts;
Open Design is an essential part of this.
The community controls the design process. You can help make this software
meet your needs.
In order to provide access to everyone to all steps and decision points of the
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
open source project. A common open source development model for traditional
software development organizations is to develop internally, then release
their project under an open source license once it is mostly complete.
While most of them will also commit to a transparent and inclusive
development process, they still frequently maintain control of the software
with most of the design decisions being made by organization leaders and
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.
It is a common practice for companies to develop software in-house and then
release the code as open source and start to form a community around it. As
part of their actions on the way they often fail with letting go of the control
over the software and processes within the community. This can easily result in
a single-vendor community as the leadership positions and decisions are mainly
controlled by this organization and therefore other contributors cannot take
ownership and feel as being equally involved in the community.
Using the principle of "Open Design" takes this one step beyond and guarantees
a transparent and open process for planning and designing the software. It's
about letting go of the control of the design of the software and its feature
roadmap, and accepting that it should be driven by the community.
Single-vendor projects don't have a good reputation as both the design
directions and maintenance are highly dependent on the controlling organization
which puts high risk on the project for users and other companies to depend on
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
can be inefficient. It's easier and faster to keep design and feature
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.
By opening up the design process for everyone to participate in and have their
voices heard, you will get more innovative ideas and more robust solutions.
In this section we'll cover how to set up your project and your development
cycle in a way that enables and encourages Open Design.
On the other hand, you need to be aware that opening up the design and decision
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",
"how", and "where" of the design process. The "when" refers to the
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.
To provide you an example, we will discuss the approach the OpenStack community
took with their release process.
Rather than adopting feature-based releases and doing a bad job at them, it
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.
The Open Design Principle in Practice
-------------------------------------
A time-based release cycle becomes critical for the success of "Open Design".
Once the schedule is set, contributors know exactly when they can add their
voice to the design process. Part of the OpenStack design process is to have
face-to-face events at the beginning of every release cycle to begin the design
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,
including developers, users, and vendors.
Open Design involves to define the lifecycle of the software development
process, which boils down to define a release process to be able to evolve and
maintain the project artifacts. A release process defines the "when", "where"
and "how" the design process happens.
To define the "when", you need to define a release cadence to put out new
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.

102
doc/source/opendevelopment.rst
View File

@ -2,51 +2,71 @@
Open Development
================
We maintain a publicly available source code repository through the entire
development process. We do public code reviews. We have public road maps.
This makes participation simpler, allows users to follow the development
process and participate in QA at an early stage.
Open Development is the next pillar as well as the next step after establishing
the Open Design principle. Similarly to the former steps, you also need a
transparent and inclusive development process that enables everyone to
participate as equals on a level playing field.
"Open development" refers to the adoption of transparent and inclusive
development processes that enable everyone to participate as an equal on a
level playing field. Publicly-accessible services means that everyone can see
everything about development activities, without even needing to sign up to a
service. Open development also means that all patches are welcome for
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:
The contributors of your community need to have access to every step of the
process. This means that the process needs to be documented and accessible for
everyone including established contributors and newcomers. You need to use
tools and services that are also available to all participants to use in order
to perform the required steps of the process.
- Correctness: does the code include tests of its functionality?
- Quality Assurance: does the code integrate with other projects and
not introduce regressions?
- Documentation: does a new feature include documentation on what
it does and how to properly configure it?
- Purpose: does the code implement a feature identified in the open
design process?
The community should not differentiate between contributions depending on the
affiliation of the person who authored or committed that change. The review
process needs to be open with history so requests and decisions can be accessed
later. While accepting contributions can look subjective you need to put all
the effort into documenting criteria, guidelines - to write code or
documentation - and processes to ensure the most objective process possible.
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
way to establishing a baseline standard for new code. Code review by trusted
community members is the additional critical layer on top of the automated
tooling?
Reviewing contributions should be available, and encouraged, to everyone who is
interested in the project, even if the final decision can be made only by a
subset of contributors. These contributors -called core reviewers, committers,
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?
Regular participation in code review and submitting patches builds reputation
and trust within a community. Aspects of the open development process must
include facilities for anyone (not just existing projects contributors and
leaders) to:
The open development process opens up the avenue for newcomers to become
seasoned contributors and then take on leadership positions, if that is
something that they desire. Besides contributing new ideas and functionality,
it is very important to demonstrate how much one cares about the project,
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
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>`).
Open Development Process Examples
---------------------------------
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.

158
doc/source/opensource.rst
View File

@ -2,83 +2,92 @@
Open Source
===========
We do not produce "open core" software. We are committed to creating truly
open source software that is usable and scalable. Truly open source
software is not feature or performance limited and is not crippled. There
will be no "Enterprise Edition".
The most fundamental principle, historically reaching back to the Four Freedoms
of the Free Software Foundation, is Open Source. Any software developed under
the guidance of the Four Opens must be released under an open source license.
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]_.
- GPLv3 compatible [#GPLv3]_.
- DFSG compatible [#DFSG]_.
While the Open Core model is compatible with open source and might seem like a
good model at first, it has a lot of shortcomings that prevents you from
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
Freedoms" of the Free Software Foundation, is "Open Source". Any software
developed under the Four Opens must be released under an open source license.
It means being able to study a program, modify it, and redistribute either the
original or the modified version so that others may benefit from your work.
Users of the open source edition of an Open Core software may fall into similar
traps, as they can be forced to purchase the Enterprise Edition to access extra
functionality that is only available there. This can result in lock-in, despite
of them originally choosing an open source solution, which then didn't give
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.
Beyond that, we want the software to be truly usable and scalable. This adds
the additional condition that it should not be limited in features or crippled
in performance to artificially enable any business model.
The Open Core model always fails when a contributor eventually tries to add a
feature that is not supposed to be made available in the open source version
according to the company in control, who owns the productized version. This
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"
model, where source code and features in a proprietary "Enterprise Edition" are
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.
In addition, these enterprise features often fall in the groups of security or
scalability, which are desirable by all users.
This model always fails once a community member tries to add a feature that the
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
-------------------------------------
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
project. In most cases at the OpenStack Foundation, we use v2.0 of the Apache
License [#apachev2]_. The license meets the requirements of being able
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.
- OSI approved [#OSI]_
- GPLv3 compatible [#GPLv3]_
- DFSG compatible [#DFSG]_
In practice, individual and corporate contributors need to understand the
consequences of contributing code to an Apache Licensed project, particularly
the granting of copyright and patent licenses to all users of the software. To
acknowledge this, many projects require that all contributors sign a
"Contributor License Agreement" (CLA) [#OSCLA]_ or "Developer Certificate of
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
granting copyright and patent licenses in accordance with the Apache License
along with their submissions. A DCO, on the other hand, is a bit lighter weight
and is more of a statement (rather than a license) that the developer is indeed
authorized to submit changes to the project and understands that their
contributions will be used in accordance with the license. A CLA, being a
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
document [#CLAvDCO]_.
This license meets the requirements of being able to modify and redistribute
the work. It includes a number of provisions that also protect end-users by
granting copyright and patent licenses to all, 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, regardless if you are an individual or corporate contributor, you
need to understand the consequences of contributing code to an Apache Licensed
project, particularly the granting of copyright and patent licenses to all
users of the software. To acknowledge this, many projects require that all
contributors sign a "Contributor License Agreement" (CLA) [#OSCLA]_ or
"Developer Certificate of Origin" (DCO).
Typically, a CLA is a stronger statement, attesting that you, as a contributor,
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
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
also been used in practice since 2004, and is fairly well understood amongst
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
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.
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.
Maintaining a delta between code running in production and fast-evolving
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
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.
References