Use apps instead of applications

src/_posts/2021-02-16-coop-cloud.md

@@ -13,15 +13,15 @@ Running [free software] apps and infrastructure for ourselves and our clients is
 
 We started out using [Cloudron], which provides a very simple-to-use web interface for deploying free software apps like Nextcloud, Mediawiki, and Rocket.chat with only a few clicks.
 
-Cloudron allowed us to radically reduce our initial and ongoing server costs. We didn't need to maintain a separate server for each service and clients applications could share computing resources whilst containerisation was still allowing us meeting their data privacy needs. Consequently, we've been able to take on many more "solidarity clients", people doing important work, but on a shoestring budget.
+Cloudron allowed us to radically reduce our initial and ongoing server costs. We didn't need to maintain a separate server for each service and clients apps could share computing resources whilst containerisation was still allowing us meeting their data privacy needs. Consequently, we've been able to take on many more "solidarity clients", people doing important work, but on a shoestring budget.
 
 As time has gone on, though, we've had a few moments when we questioned our reliance on Cloudron, and whether it was a sustainable choice for us and for our clients. We came to realise:
 
 - Core parts of the system officially [became proprietary] software. This rang alarm bells for us about its long-term future.
 
-- The work to package the available applications is done [entirely by the Cloudron team itself] and doesn't re-use the existing rich ecosystem of free software packaging work that's already being done. This seems like a big risk. If Cloudron UG, the company goes under, someone or some entity would need to take on that laborious, technically specific and non-transferable packaging work or we'd quickly be leaving ourselves and our clients running outdated and unmaintained software.
+- The work to package the available apps is done [entirely by the Cloudron team itself] and doesn't re-use the existing rich ecosystem of free software packaging work that's already being done. This seems like a big risk. If Cloudron UG, the company goes under, someone or some entity would need to take on that laborious, technically specific and non-transferable packaging work or we'd quickly be leaving ourselves and our clients running outdated and unmaintained software.
 
-- Some aspects of Cloudron's architecture were causing problems. Requiring each app to be a single Docker image makes common application deployment configurations impossible (as far as we know, nobody has yet managed to get Mediawiki's visual editor working in Cloudron, for example). 
+- Some aspects of Cloudron's architecture were causing problems. Requiring each app to be a single Docker image makes common application deployment configurations impossible (as far as we know, nobody has yet managed to get Mediawiki's visual editor working in Cloudron, for example).
 
 - Not being able to delegate user management to specific groups has made it hard for us to use Cloudron's Single Sign On system with groups who manage their own users.
 
@@ -53,21 +53,23 @@ In our spare time (partly funded by income from working for our wonderful client
 
 ## Co-op Cloud public alpha
 
-Co-op Cloud is a simple packaging format using existing [open standards] to build a catalogue of applications, and a command-line client to read the catalogue and deploy those applications.
+Co-op Cloud is a simple packaging format using existing [open standards] to build a catalogue of apps, and a command-line client to read the catalogue and deploy those apps.
 
-If you'd like to learn more about Co-op Cloud, please read [our documentation], where we explain the decisions we've made so far in more depth. What technologies we're using, how we fit into the existing ecosystem, ways to contribute, what applications are available and so on.
+If you'd like to learn more about Co-op Cloud, please read [our documentation], where we explain the decisions we've made so far in more depth. What technologies we're using, how we fit into the existing ecosystem, ways to contribute, what apps are available and so on.
 
 We've already been deploying Co-op Cloud as part of "dual power" strategy. We use Co-op Cloud to run some of our own and our clients' infrastructure while continuing with Cloudron and other strategies for the time being. We're seeing promising stability and it's been a joy to work with.
 
 ## Enter the configuration commons
+
 You can also dive straight in by installing [`abra`, co-opCloud's command-line tool].
 
-You can use Co-op Cloud right now to deploy any of our [30+ applications] to your own physical server or virtual server. These include [Nextcloud](https://nextcloud.com/) (for file, calendar, contacts etc) [Rocket.chat](https://rocket.chat/) for instant messaging, [Keycloak](https://www.keycloak.org/) for Single Sign-On, [Statping](https://statping.com/) for service monitoring, and websites using [Wordpress](https://wordpress.org/), [Pelican](https://blog.getpelican.com/), [Jekyll](https://jekyllrb.com/), or static HTML.
+You can use Co-op Cloud right now to deploy any of our [30+ apps] to your own physical server or virtual server. These include [Nextcloud](https://nextcloud.com/) (for file, calendar, contacts etc) [Rocket.chat](https://rocket.chat/) for instant messaging, [Keycloak](https://www.keycloak.org/) for Single Sign-On, [Statping](https://statping.com/) for service monitoring, and websites using [Wordpress](https://wordpress.org/), [Pelican](https://blog.getpelican.com/), [Jekyll](https://jekyllrb.com/), or static HTML.
 
 Apps deployed via Co-op Cloud have automatic SSL certificates, and many come with pre-configured e-mail, backups, or Single Sign-On options.
 
 ## Packaging for Co-op Cloud
-Packaging new applications for Co-op Cloud is straightforward in most cases: you can re-use an application's own Docker image (or even `docker-compose.yml` file) with minimal changes. We managed to [make a Co-op Cloud version of the Matomo web analytics platform in about 20 minutes]. This standardised architecture also means that nobody using Co-op Cloud is dependent on Autonomic for updates. When a new Wordpress update comes out, you can easily install it yourself or automatically without waiting for us to update some arcane custom Docker image.
+
+Packaging new apps for Co-op Cloud is straightforward in most cases: you can re-use an application's own Docker image (or even `docker-compose.yml` file) with minimal changes. We managed to [make a Co-op Cloud version of the Matomo web analytics platform in about 20 minutes]. This standardised architecture also means that nobody using Co-op Cloud is dependent on Autonomic for updates. When a new Wordpress update comes out, you can easily install it yourself or automatically without waiting for us to update some arcane custom Docker image.
 
 At this point, we'd like to invite other worker co-operatives or democratic collectives to take a look at what we're working on and have a chat with us. We think a common platform for hosting free software infrastructure could make a big difference in terms of what we're able to offer as a movement.
 
@@ -80,7 +82,7 @@ If you're interested in getting involved with Co-op Cloud development, or if you
 [entirely by the cloudron team itself]: https://git.cloudron.io/cloudron
 [our documentation]: https://docs.cloud.autonomic.zone
 [`abra`, coopcloud's command-line tool]: https://git.autonomic.zone/coop-cloud/abra/
-[30+ applications]: https://git.autonomic.zone/coop-cloud/
+[30+ apps]: https://git.autonomic.zone/coop-cloud/
 [get in touch]: mailto:helo@autonomic.zone
 [copyleft licenses]: https://www.gnu.org/licenses/copyleft.en.html
 [open standards]: https://compose-spec.io/