From 5db7e933c2c72cd1e480bd9bc4c4776a97e89b7c Mon Sep 17 00:00:00 2001 From: Ildiko Vancsa Date: Sun, 21 Feb 2021 16:36:37 +0100 Subject: [PATCH] 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 --- doc/source/activities_and_processes.rst | 343 +++++++++++++++++++++ doc/source/index.rst | 3 +- doc/source/opencommunity.rst | 393 +++--------------------- doc/source/opendesign.rst | 173 +++++++---- doc/source/opendevelopment.rst | 102 +++--- doc/source/opensource.rst | 158 +++++----- 6 files changed, 633 insertions(+), 539 deletions(-) create mode 100644 doc/source/activities_and_processes.rst diff --git a/doc/source/activities_and_processes.rst b/doc/source/activities_and_processes.rst new file mode 100644 index 0000000..50a0efa --- /dev/null +++ b/doc/source/activities_and_processes.rst @@ -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/ + diff --git a/doc/source/index.rst b/doc/source/index.rst index f3bd658..dc9bb86 100644 --- a/doc/source/index.rst +++ b/doc/source/index.rst @@ -10,6 +10,7 @@ Contents introduction opensource + opencommunity opendesign opendevelopment - opencommunity + activities_and_processes diff --git a/doc/source/opencommunity.rst b/doc/source/opencommunity.rst index ff13f6a..37969db 100644 --- a/doc/source/opencommunity.rst +++ b/doc/source/opencommunity.rst @@ -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. diff --git a/doc/source/opendesign.rst b/doc/source/opendesign.rst index 0e10391..4e4b795 100644 --- a/doc/source/opendesign.rst +++ b/doc/source/opendesign.rst @@ -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. diff --git a/doc/source/opendevelopment.rst b/doc/source/opendevelopment.rst index d0779f0..32a50e2 100644 --- a/doc/source/opendevelopment.rst +++ b/doc/source/opendevelopment.rst @@ -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 `). +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. diff --git a/doc/source/opensource.rst b/doc/source/opensource.rst index d677f5c..7afd6ed 100644 --- a/doc/source/opensource.rst +++ b/doc/source/opensource.rst @@ -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