diff --git a/docs/opencommunity.rst b/docs/opencommunity.rst
new file mode 100644
index 0000000..bfe8651
--- /dev/null
+++ b/docs/opencommunity.rst
@@ -0,0 +1,305 @@
+==============
+Open Community
+==============
+
+    One of our core goals is to maintain a healthy, vibrant developer and user
+    community. Most decisions are made using a lazy consensus model. All
+    processes are documented, open and transparent.
+
+    The technical governance of the project is provided by the community
+    itself, with contributors electing team leads and members of the Technical
+    Committee.
+
+    All project meetings are held in public IRC channels and recorded.
+    Additional technical communication is through public mailing lists and is
+    archived.
+
+"Open Community" is the critical piece of the Four Opens puzzle. It embodies
+the key difference with single-vendor controlled open source projects. It is
+about ensuring that the community is a cohesive, inclusive, level playing
+ground where all the voices are heard and anyone can rise to leadership
+positions.
+
+To build a truly open community, you need to balance the three forces:
+developers, users and ecosystem. It's easy to think simply in terms of upstream
+and downstream, but communities are complex organisms, and the reality is much
+more dynamic. It's important to establish common goals and build strong
+connections between the forces, because operating in silos will dilute the
+power of the community. Each force affects the others and they have to be
+working in harmony to achieve anything. 
+
+Open Community defines how to best align these forces through:
+
+- Common mission & goals.  - Effective governance & leadership.  - Diversity &
+  Inclusiveness.  - Contributor recognition & motivation.  - Communication.  -
+  Branding & positioning (example of collaboration across forces, product
+  definition).  - Education & On-boarding.  - Marketing & events.  - Ambassadors
+  & meet-ups.  - Cross-community collaboration (NIH).
+
+Common Mission & Goals
+----------------------
+A strong mission statement is one
+of the most critical elements to achieve a healthy open source community. It's
+imperative to outline a long term vision that is focused, but not overly
+constrained. A strong mission statement helps define the community values and
+provides a guide to make decisions and prioritize activities. It also helps new
+contributors and adjacent communities quickly understand the goals of the
+project.
+
+Getting the current stake-holders input and buy-in is key to the success.
+Typically a mission statement is developed in the early days of the project
+when there are fewer contributors, which makes it critical��and as a bonus, a
+bit easier--to have an open discussion and process. Similarly, changing the
+mission statement should not be taken lightly, and can be a challenging process
+as the community grows and there are a broader range of perspectives.  A good
+example of this process came from the Zuul project. Project leaders first
+drafted example mission statements in an etherpad, which was circulated to the
+public mailing list for feedback and new ideas [link to archive]. The list of
+ideas from the etherpad was then put to a Condorcet vote [link to archive] for
+the same group of contributors, and the result was:
+
+Effective Governance & Leadership
+---------------------------------
+Any group needs some form of governance. Governance is the set of rules that
+the group follows in order to address issues and make decisions.  Open source
+projects are just another group, so they need governance in order to avoid
+decision apathy. There needs to be a place where the buck stops, with a clear
+strategy in place to how to solve problems before they arise.
+
+It is tempting, especially amongst tech people, to start with no rule, to to
+make them up as you go along. This is anarchy as a form of governance, and a
+community formed under the absence of rule will naturally resist later
+organization, as something they did not sign up for and resent.
+
+It is also tempting to crown the project's initial creator as the "benevolent
+dictator for life". That can work well, until the dictator becomes less
+interested in the project or sadly disappears, at which point the project
+enters governance limbo (as evidenced by the Gentoo and Python examples) with
+no clear way forward. Or worse, engages in unchecked toxic and abusive behavior
+that drives away contributors who aren't "tough enough" to handle the it.
+
+A base framework for an Open Community governance would balance 4 basic rules:
+
+Contributor-driven bodies It is critical that the people contributing code,
+documentation, usage experience, mentoring time or any other form of
+contribution to the project are aligned with the leadership of the project.
+Without contributor-driven bodies, leadership and contributors gradually drift
+apart, to the point where the contributors no longer feel like their leadership
+represents them, making the disruptive decision to fork the project under a
+new, contributor-aligned governance, generally leaving the old governance body
+with a trademark and an empty shell to govern.
+
+Allowing for replacement Nobody should be appointed for life, as life will
+change people.  Contributors should regularly be consulted, and the governance
+should generally encourage turnover.
+
+Distinct groups call for distinct governance bodies If a community is made of
+disjoint groups with little to no overlap in membership, and those groups all
+need decisions to be made, then they probably need to each have their own
+governance body at that level.
+
+Avoid vanity governance bodies There is no point in having a governance body
+where there is nothing to govern and no decision needed. Not every group of
+people in a community needs a governance body.
+
+There is no one-size-fits-all implementation of those basic rules that would
+work for any project. The size of the project is a critical difference.
+Sometimes a multiple-level structure to properly balance autonomy and
+consistency.
+
+We generally recommend using regular elections using a ranking vote mechanism
+(Condorcet, STV...). Condorcet is known to favor consensual candidates over
+faction candidates. Staggered elections (replacing half the seats at each
+election) ensures some leadership continuity. Limits in the number of seats
+potentially held by employees from a single organization are usually a good way
+to sidestep governance gaming.
+
+Governance bodies should ideally only make consensual decisions, but when that
+proves impossible and a decision needs to be made, a formal vote should be
+held. It's useful that the body has an odd number of members to avoid having to
+give anyone a tie-breaking specific power.
+
+Some of the things that indicate a healthy community are:
+
+Diversity & inclusiveness Nowhere are the three forces (developers, users,
+ecosystem) more important than when dealing with diversity and inclusiveness.
+Providing an inclusive and safe experience for everyone, regardless of gender,
+sexual orientation, disability, physical appearance, body size, race,
+nationality or religion is not only critical to the health of the entire open
+source community, it's something that must be considered at the beginning of a
+project.
+
+Code of Conduct A code of conduct may not seem necessary as your community is
+getting its start.  However, creating a path for conflict identification and
+resolution at the start can head off issues before they balloon out of control
+and alienate valuable contributors and community members.  Make the code of
+conduct carefully crafted, but also prominent, part of larger strategy to be
+inclusive and diverse. The OpenStack Foundation initially adopted the Ubuntu
+Code of Conduct when establishing its own.
+
+    The first lesson learned is the enforcement policy is equally as important
+    as the code of conduct. We did not put enough thought into how it was
+    applied or enforced across our various community events and activities.
+    Delaying the resolution process while your leadership consults legal
+    experts and attempts to come to a solution can be more damaging than the
+    violation itself.  Having a clear path to enforcement and resolution sends
+    a strong message to the community that you have thought through the process
+    and are looking out for their best interest.
+
+Representation?  A few years into the project, we worked with the community,
+including the Diversity Working Group, to publicly document an enforcement
+policy. Again, we looked to another successful open source community, Python
+and PyCon, as a basis for our policy. This policy gives anyone who wants to
+report an issue a clear call to action and sets expectations for how it will be
+handled and gives the Foundation staff a clear process to follow and removes
+the emotion from the process.
+
+    Check the health of your community as you go. Do you have something similar
+    to the following?
+
+    Groups that advocate for minorities: A working group to help ensure
+    projects and teams within the community are following the code of conduct
+    and properly representing diverse voices.
+
+    Visible documentation of policies and enforcement
+
+    Regular surveys and check-ins with your community
+
+The strength of the community can be enhanced through education, culture,
+pro-active recruitment, in addition to the processes mentioned above.
+
+Consider that the needs for diversity and inclusiveness extend beyond the
+normal development community and must be shared with your users and the
+ecosystem at large. Don't assume that you know all of the barriers that your
+community members may face. Take the extra steps to pro-actively ask them to
+identify the challenges they face in trying to contribute and then break down
+barriers to participation — whether those barriers are time zones, culture,
+gender, age, education, etc�� Supporting a diverse set of leaders, both
+geographical and by organization, can help reinforce this participation and
+will ultimately make for a stronger community.
+
+Contributor Recognition & Motivation
+
+Communication
+
+Is there anything more emblematic of the modern work-force than attempting to
+solve the problem of day-to-day communication? Open source communities face
+standard issues of isolation due to remote work, time zone variations, travel,
+and so on. There is typically no home office for teams to meet face-to-face in.
+Conversely, remote tribes of team members can work together on a project, but
+in the same physical office space, creating friction amongst other team
+members.
+
+Highly transparent communication is imperative to help bridge these barriers to
+a healthy community.  Open communication channels (mailing list, IRC or slack,
+web-site) not only help to document decisions, but enable new contributors to
+catch up and get involved with the community. Providing a set of open source,
+and internationally available, tools will aid collaboration and help build
+community. OpenStack initially started collaborating with Google Docs, but
+ultimately realized that we excluded a large portion of the world where Google
+products were inaccessible/unavailable.
+
+Host meetings in way that can be archived and searched so that the
+conversations are accessible to all time-zones and participants who do not speak
+English as their first language. Internationalization (translation, tool
+choices like google docs, time-zones), in general, helps foster a more diverse
+group of contributors.
+
+Board meetings in particular should be open so that anyone can dial in.
+Notes/re-cap should be sent out to the community at large via mailing lists
+within 48 hours of the meeting.  At the OpenStack Foundation, the transparency
+policy for the board developed within the first year.
+
+In person communication is as important as online.  Identify the most
+accessible way to leverage the community and their channels to share your
+messaging.  This can include local user groups, regional meet-ups,
+international/national summits, developer mid-cycles.  All can be used to
+further educate and engage your open source community.
+
+Branding & positioning (example of collaboration across forces, product
+definition) including tools and processes Develop with stake-holders, open to
+community Some degree of collaboration is useful and necessary, but only to an
+extent. This is especially true in regards to visual identity since it can be
+subjective and contentious. Design rationale should be provided to the
+community to build consensus, but there should be key decision makers to
+prevent the ideation process from continuing to infinity.  Lessons learned with
+project mascots In an attempt to provide consistency we discovered removed
+individuality with some projects Slippery slope - Once the projects got them,
+every small group also wanted their own mascot Upside - These are actually
+picked up and used regularly by the press and in group events.  Critical to
+develop brand guidelines, to give community guidelines to extend brand beyond
+internal resources Development of consistent UX to be applied to web-sites,
+documentation, etc....  This can be tough b/c the needs of the design team
+don't always mesh with the needs/methods of developers managing properties like
+documentation.  Design must be available as an easy plug in (HTML or javascript
+snippet) for headers and footers of sites.
+
+Marketing & Strategy Once the initial branding and positioning has been
+finalized, share with all key stake-holders. The challenge is often identifying
+the correct channel to ensure everyone is apprised of updates and changes. This
+may take time, but trying different options and even a combination of a
+few often helps reinforce the messaging and branding for the maximum impact.
+Ahead of the start of the year, identify the largest areas of opportunity to
+increase brand visibility and favorability to create a strategy. After
+identifying programs, events and projects that can support the strategy,
+communicate this back to the community, reaching out to the marketing teams at
+the ecosystem companies directly to participate and provide feedback. This is
+your biggest opportunity for a ripple effect.  Stay apprised of market share
+and user adoption metrics. Share these metrics openly and broadly, particularly
+with the ecosystem companies and elected officials who represent the three
+forces. This can be done in joint leadership meetings, both remote and in
+person, as well as mailing list newsletters. If the information could be
+perceived negatively, come prepared with a solution or action plan to increase
+confidence of key stake-holders. It's important to pro-actively share the
+negative information when possible to prevent reactionary fear, uncertainty and
+doubt.  Identify key dates and milestones that celebrate the successes of the
+community. Whether it's specific to a force, like a software release or new
+case study or specific to the software or community itself, like results in a
+market report or participation in a supported event. This helps create momentum
+and rewards the positive community efforts that are impacting another force or
+even the broader industry.  Leverage collaborative opportunities when possible.
+If the broader market perceptions indicate a confusion around facts that affect
+one of the three forces, collect the people most affected to identify a way to
+pro-actively address the problem. An example would be that OpenStack is seen as
+only a private cloud solution. A Public Cloud Working Group that
+collaborates to create programs and most recently messaging that will help
+alleviate the confusion is a response that helps leverage the affected parties
+to address the overarching issue.
+
+Events Support upstream developers with dedicated space and events to
+collaborate and get work done. This includes collaboration within a project and
+cross-project collaboration.  Create a productive event that combines upstream
+developers with operators so that production challenges and successes can be
+combined with software road-maps and bug tracking.  Create an opportunity for
+ecosystem companies to interact with operators and developers to educate around
+available products, gain insights from the market and participate in road-map
+discussions.  Identify gaps in both the community and the overall market and
+use events as an opportunity to gather content, subject matter experts and
+adjacent communities to share knowledge and solve problems.  OpenStack Days
+Industry events
+
+Education & On-boarding Goal to make the barrier to entry as low as possible.
+Clear, discoverable and digestible documentation Recorded and real time
+on-boarding sessions - webinars, f2f sessions at events Suggest training the
+trainer - creating a toolbox and guidelines to provide to regional community
+members so they can lead their own on-boarding sessions Documented ways to
+communicate with seasoned experts / join meetings to accelerate on-boarding.
+Mentorship programs
+
+Ambassadors & Meet-ups Supporting global communities through user groups,
+ambassador program, Providing resources & content for events and meet-ups, and
+setting precedents for those events (branding, content, etc.), while still
+giving them creative freedom building the relationships first; find leaders
+outside of the Foundation to foster new user groups leaders; collab sessions at
+Summits using tools available to all regions community of 90,000; team of 23
+(XX ambassadors, 100+ user groups) Collaborating with local leaders to better
+understand regional differences in the technology choices, use cases and
+community involvement.  Create a way to co-own user group contacts to ease the
+transfer of ownership if people leave the community or if there are any bad
+actors.
+
+Cross-community collaboration (NIH) From the very beginning invite other
+communities and projects to collaborate and participate. In turn actively reach
+out to engage and participate in other communities to enhance integration
+efforts.  Need examples here
+