diff --git a/README.md b/README.md
index 282d509b3..ba0a3cd4d 100644
--- a/README.md
+++ b/README.md
@@ -59,3 +59,27 @@ For the images, you can specify the configuration much like Compose, with some c
 there are no volumes only `binds`.
 
 The config is liable to be changed, and there are missing features; full documentation will be available shortly.
+
+## Roadmap
+
+This project was extensively reworked from the code we are shipping in Docker Editions, and the result is not yet production quality. The plan is to return to production
+quality during Q2 2017, and rebase the Docker Editions on this open source project.
+
+Security by default is a key aim. In the short term this means using modern kernels, using best practise settings for the kernel, from [KSPP](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project)
+and elsewhere. It also means working to incorporate more security features into the kernel, including those in our [projects](projects/). In userspace, the core system components
+are key to security, and we believe they should be written in type safe languages, such as Rust, Go and OCaml, and run with maximum privilege separation and isolation.
+There is ongoing work to remove C components, and to improve, fuzz test and isolate the base daemons.
+
+This is an open project without fixed judgements, open to the community to set the direction. The guiding principles are:
+- Security informs design
+- Infrastructure as code: immutable, manageable with code
+- Sensible secure and well tested defaults
+- An open, pluggable platform for diverse use cases
+- Easy to use and participate in the project
+- Built with containers, for portability and reproducibility
+- Run with system containers, for isolation and extensibility
+- A base for robust products
+
+## FAQ
+
+See [FAQ](docs/faq.md).
diff --git a/docs/faq.md b/docs/faq.md
new file mode 100644
index 000000000..502c799a4
--- /dev/null
+++ b/docs/faq.md
@@ -0,0 +1,32 @@
+# FAQ
+
+Please open an issue if you want to add a question here.
+
+## How do updates work?
+
+Moby does not require being installed on a disk, it is often run from an ISO, PXE or other
+such means, so it does not require an on disk upgrade method such as the ChromeOS code that
+is often used. It would definitely be possible to use that type of upgrade method if the 
+system is installed, and it would be useful to support this for that use case, and an
+updater container to control this for people who want to use this.
+
+We generally use external tooling such as [Infrakit](https://github.com/docker/infrakit) or
+CloudFormation templates to manage the update process externally from Moby, including
+doing rolling cluster upgrades to make sure distributed applciations stay up and responsive.
+
+Updates may preserve the state disk used by applications if needed, either on the same physical
+node, or by reattaching a virtual cloud volume to a new node.
+
+## What do I need to build Moby?
+
+We have tried to make this as simple as possible, by using containers for the build process, so
+you should be able to build Moby on any OSX or Linux laptop; we should have Windows build support
+soon.
+
+## Why not use `systemd`?
+
+In order to keep the system minimal, `systemd` did not seem appropriate, as it brings in a lot
+of dependencies and functionality that we do not need. At present we are using the `busybox`
+`init` process, and a small set of minimal scripts, but we expect to replace that with a small
+standalone `init` process and a small piece of code to bring up the system containers where the
+real work takes place.