Principles for Community Software

I’ve been seeing the need to institute a handful of tools for Nyland or its subgroups to use. This wiki and the Forum are examples, but I think there are many more things that might be useful.

The goals and principles that follow are current thoughts, not principles set in stone. Comments are welcome, nothing is really canonical yet.

Some Goals for Community Software

• Community software should be cheap to try and cheap to run. That is, easy to get working, easy for techCAG to maintain, and easy enough for people to use that minimal support is necessary.

• Any particular piece of community software should be expected to keep working for a long time – let’s say, at least 20 years, with sensible but minimal maintenance.

• Our approach to community software should make new things easy to try out quickly, easy to deploy, and easy to abandon if we decide something’s not working.

• Our critical information – anything we hope to save for a years or more – should be reasonably under our control. Tech companies come and go, and we should not lose our work or our history when they do.

• Community software should respect its users. It should treat their time and attention as a precious resource to spend wisely and sparely, rather than something to attempting to "maximize engagement." It should minimize interruptions. It should remain focused. Users should never see ads, including offers to upgrade the service. In short, community software should serve the community and its members, rather than seeking to extract more from them.

Principles for Community Software

• Plan for easy maintenance.

• Make common software easy to use. Special installation or training should be unnecessary for most users.

• Make adding, editing, and organizing information open-by-default. Restrict permissions only where it’s clearly necessary.

• Only build what might satisfy felt shared needs. Only keep what actually does.

  • In more detail: community software should actually serve functions that we want or need. If some system has been around for a while and it doesn’t seem like it’s actually meeting a real want or need – for the community, its groups, or its members – then we should get rid of it, and rethink why we wanted it.

• Respect people’s privacy! In particular, don’t use anything that will launch cross-site trackers, and don’t keep or require personal information that we don’t actually need.

• At least 3 people at Nyland – and preferably 5 or more – should each be able to administer any systems we think critical to how our community operates.

• Expect common software to be simply opt-in wherever possible. Two reasons:

  1. People often resent what they’re forced to deal with, which is bad for that tech's usage, and bad for community spirit overall. This is especially noxious with technology, where people have often gotten accustomed to work culture (or social culture!) requiring that they use often really bad software -- and often harbor a quiet, low-level resentment towards tech in general.

  2. Our job should be to produce and keep systems that the community actually values, and the easiest way to find out about that is to see if people actually use it. Any attempt to make a system mandatory suppresses that signal – and quiets other conversation about it too, because people won’t want to talk about their experience with it.

• Avoid lock-in, and plan for easy exit from private services. Individual tech companies occasionally become noxious or obnoxious; let’s avoid relying on any one of them.

  • A central way of doing this is to only rely on “commodity” services; where you can buy interoperable services from at least 5 other sources.

  • For some technical examples – CDNs, VPSs, SMTP relays, and object storage via S3, are all commodity services. (S3 might be surprising -- it's an AWS product, right? But the S3 protocol is really simple, and lots of other systems now independently provide it; it's become a de-facto standard protocol.) If we build from commodity tools, and then later decide that we don’t like the company we're using, we can just move to a different company to do the same thing. However, if we build some complicated system on AWS Lambda, or build a website using a website builder like Wix or Squarespace, then we have to rebuild our whole thing in order to change companies.