docs: Add FAQ entry about vendoring dependencies

docs/faq.md

@@ -69,6 +69,61 @@ serious automation workloads. Support for non-Linux operating systems isn't a
 high priority of mine, but we're happy to accept patches for missing features
 or resources that you think would make sense on your favourite platform.
 
+### Why aren't you using `glide` or `godep` for dependency management?
+
+Vendoring dependencies means that as the git master branch of each dependency
+marches on, you're left behind using an old version. As a result, bug fixes and
+improvements are not automatically brought into the project. Instead, we run our
+complete test suite against the entire project (with the latest dependencies)
+[every 24 hours](https://docs.travis-ci.com/user/cron-jobs/) to ensure that it
+all still works.
+
+Occasionally a dependency breaks API and causes a failure. In those situations,
+we're notified almost immediately, it's easy to see exactly which commit caused
+the breakage, and we can either quickly notify the author (if it was a mistake)
+or update our code if it was a sensible change. This also puts less burden on
+authors to support old, legacy versions of their software unnecessarily.
+
+Historically, we've had approximately one such breakage per year, which were all
+detected and fixed within a few hours. The cost of these small, rare,
+interruptions is much less expensive than having to periodically move every
+dependency in the project to the latest versions. Some examples of this include:
+
+* We caught the `go-bindata` swap before it was publicly known, and fixed it in:
+[adbe9c7be178898de3645b0ed17ed2ca06646017](https://github.com/purpleidea/mgmt/commit/adbe9c7be178898de3645b0ed17ed2ca06646017).
+
+* We caught the `codegangsta/cli` API change improvement, and fixed it in:
+[ab73261fd4e98cf7ecb08066ad228a8f559ba16a](https://github.com/purpleidea/mgmt/commit/ab73261fd4e98cf7ecb08066ad228a8f559ba16a).
+
+* We caught an un-announced libvirt API change, and promptly fixed it in:
+[95cb94a03958a9d2ebf01df0821a8c13a4f3a28c](https://github.com/purpleidea/mgmt/commit/95cb94a03958a9d2ebf01df0821a8c13a4f3a28c).
+
+If we choose responsible dependencies, then it usually means that those authors
+are also responsible with their changes to API and to git master. If we ever
+find that it's not the case, then we will either switch that dependency to a
+more responsible version, or fork it if necessary.
+
+Occasionally, we want to pin a dependency to a particular version. This can
+happen if the project treats `git master` as an unstable branch, or because a
+dependency needs a newer version of golang than the minimum that we require for
+our project. In those cases it's sensible to assume the technical debt, and
+vendor the dependency. The common tools such as `glide` and `godep` work by
+requiring you install their software, and by either storing a yaml file with the
+version of that dependency in your repository, and/or copying all of that code
+into git and explicitly storing it. This project thinks that all of these
+solutions are wasteful and unnecessary, particularly when an existing elegant
+solution already exists: `[git submodules](https://git-scm.com/book/en/v2/Git-Tools-Submodules)`.
+
+The advantages of using `git submodules` are three-fold:
+1. You already have the required tools installed.
+2. You only store a pointer to the dependency, not additional files or code.
+3. The git submodule tools let you easily switch dependency versions, see diff
+output, and responsibly plan and test your versions bumps with ease.
+
+Don't blindly use the tools that others tell you to. Learn what they do, think
+for yourself, and become a power user today! That process led us to using
+`git submodules`. Hopefully you'll come to the same conclusions that we did.
+
 ### Did you know that there is a band named `MGMT`?
 
 I didn't realize this when naming the project, and it is accidental. After much