diff --git a/docs/opendevelopment.rst b/docs/opendevelopment.rst
new file mode 100644
index 0000000..01bcc74
--- /dev/null
+++ b/docs/opendevelopment.rst
@@ -0,0 +1,46 @@
+================
+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" refers to the adoption of transparent and inclusive
+development processes that enable everyone to participate as an equal on a
+level playing field. Open development 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:
+
+- 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?
+
+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?
+
+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:
+
+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 "Open Community").
+