Merge branch 'infra-policy' into 'main'

Add infrastructure policy

See merge request !1

CONTRIBUTING.md

@@ -4,6 +4,9 @@ These technical guidelines (mostly) apply to (most) [Open Tech
 Strategies](https://opentechstrategies.com/) software projects.  A
 given project may extend or override these guidelines as needed.
 
+We have related guidelines about [how to deploy](DEPLOYMENT.md) and
+about [choosing deployment infrastructure](INFRASTRUCTURE.md).
+
 Please see also the [Code of Conduct](CODE_OF_CONDUCT), which applies
 everywhere.
 

DEPLOYMENT.md

 *DRAFT: This document is still being finalized.  2023-03-07*
 
 For services that OTS maintains, these are our deployment guidelines.
-See also the related [guidance on testing and quality
-assurance](TESTING_AND_QA.md).
+See also the related guidance about [testing and quality
+assurance](TESTING_AND_QA.md), about [choosing deployment
+infrastructure](INFRASTRUCTURE.md), and about [development in
+general](CONTRIBUTING.md).
 
 * **Perform appropriate testing and QA before deploying to production.**
 

INFRASTRUCTURE.md

+Deploying open source software services online raises complex
+questions about when and how to depend on third-party infrastructure,
+particularly when the infrastructure providers' own services are based
+on proprietary code.  This situation is further complicated by the
+fact that our clients often come to us with hosting arrangements
+already made or partly made.
+
+OTS makes these decisions on a case-by-case basis, adhering to the
+following general principles:
+
+* By default we try to avoid dependencies on proprietary services in
+  the first place.  We use them only when there's a clearly
+  identifiable and non-trivial benefit (such as a noticeable
+  difference in client deliverable deadlines).
+
+* We ask "How expensive would it be to break away from this
+  dependency?"
+
+  If an infrastructure decision is really just a shim to speed up
+  development time in the early stages of a project, and we can leave
+  the dependency later by paying some fixed, predictable cost (in
+  terms of development or reconfiguration time), then that's very
+  different from a situation where the proprietary service is an
+  integral part of our functionality and no open source option
+  currently exists.
+
+* We consider the company behind the service.
+
+  This can involve evaluating many aspects of the company, including
+  but not limited to their participation in open source projects.  It
+  also includes specifically avoiding large, monopolistic service
+  providers with known tendencies to encourage lock-in.
+
+* We may take OTS's own reputational exposure into account.  (And yes,
+  we're okay with you reading that here.)
+
+* Management ultimately decides, in discussion with developers.
+
+See also our [deployment guidelines](DEPLOYMENT.md) and [development
+guidelines](CONTRIBUTING.md).