diff --git a/introduction/principles.md b/introduction/principles.md
new file mode 100644
index 00000000..a7a45448
--- /dev/null
+++ b/introduction/principles.md
@@ -0,0 +1,67 @@
+This file holds the text to accompany the [InnerSource Principles](https://www.safaribooksonline.com/videos/introduction-to-innersource/9781492041504/9781492041504-video321610) video.
+This accompanying text will appear as a part of the learning path (like [this example](https://www.safaribooksonline.com/learning-paths/learning-path-lean/9781491999738/9781491946527-/part01ch01.html)).
+
+# Inner Source Principles
+
+Every company, team, project, and individual is different.
+Because of that fact, the exact way that the concept of inner source works will vary from one situation to another.
+At its core, however, are four principles that form the bedrock of any successful instance of inner source.
+These principles have inspiration in successful open source projects and must be respected and present in order for inner source to achieve the benefits described earlier.
+
+The principles are:
+* **Openness**
+* **Transparency**
+* **Prioritized Mentorship**
+* **Voluntary Code Contribution**
+
+Let's take a look at each of these principles in more detail.
+
+## Openness
+
+In being open, a project is set up in such a way that contributing is as frictionless as possible.
+Projects should be discoverable and well documented.
+Anyone within an organization should be able to find them and ramp up without an inordinate amount of direct guidance from host team members.
+Host team contact information should be prevalent with as many channels as makes sense for the project.
+Host team intentions to inner source their project should be broadcast through relevant organization channels.
+
+By no means is the above an exhaustive list. Project openness will typically be directly related to how successful a project is
+in terms of inner sourcing: The more open it is, the less barriers are put in place for prospective contributors. The less open
+it is, the more difficult it becomes for anyone to contribute.
+
+## Transparency
+
+In order for guest teams to be able to contribute meaningfully to a project, the host team must be _transparent_.
+This means that guest teams should be able to have an understanding of:
+
+* The product and its direction
+* Outstanding feature requirements
+* Progress on feature requirements
+* Decision making of the host team
+
+When possible, the above should be communicated in such a way that does lend itself to tribal knowledge.
+
+## Prioritized Mentorship
+
+_Mentorship_ from host team to guest team via trusted committers is a key aspect of inner source.
+Contributors on guest teams are upleveled so that they understand enough about the host team system to change it successfully.
+In the process of doing so, they come to better understand the host team system as a general consumer.
+They can use it more effectively and help other consumers to do so as well.
+
+It's critical that this mentorship for contributors is _Prioritized_ by the host team.
+The host team should strive to make time to mentor guest team contributors _at the time that the contributor needs it_ as opposed to when it's convenient to the host team.
+At times at may be a culture change for engineers on the host team to spend time helping others to code rather than just coding themselves.
+This mentorship is valuable to both the individual contributor and the host, and it is worth doing well.
+It proves to be mutually beneficial in the long run, by improving the code, the contributor model and forging or
+improving relationships within an organization that may not have existed otherwise.
+Open source readily recognizes this point and considers it as an honor to achieve trusted committership on a project.
+
+## Voluntary Code Contribution
+
+The first word _Voluntary_ means that engagement in inner source from both the guest and host teams occurs of their own free will.
+The guest team voluntarily donates code to the host team and the host team voluntarily accepts it.
+This opt-in nature means that each team needs to be certain that their involvement adds value to the others' objectives.
+Never is a host team required to accept a contribution that isn't in ultimate alignment with their overall mission.
+Never is a guest team required to submit a contribution that doesn't ultimately further their own mission and priorities.
+
+The word _Code_ emphasizes that the collaboration between guest and host goes all the way to the code.
+Guest involvement in opening issues, updating requirements, fixing docs, etc. is good, but collaboration needs to reach as far as submitting code to achieve all of the benefits that we've discussed.