Draft: Things to consider when selecting apps for FreedomBox

Community
1

This is an initial draft. Please provide feedback in the replies.

An application considered for inclusion into FreedomBox should preferably have the following characteristics, though not everything is a must-have. (This list is not sorted in any order).

  1. Well-maintained
  • Must have a bus-factor greater than 1
    We will avoid applications created by a single developer. The FreedomBox team shouldn’t shoulder the burden of maintaining abandoned applications.
  • Activity on the source code repository is not to be taken as a proxy for good maintenance. There could be feature-complete applications that receive only infrequent updates.
  1. Interoperability
  • Must be interoperable with other servers
    If a server implements a protocol, it should be interoperable with other servers implementing the same protocol. Servers with good interoperability will be preferred over those with an incomplete or faulty implementation.
  1. Client support
  • Must support the popular clients, for example
    • an ActivityPub server must support Tusky/Fedilab
    • a Matrix server must support Element/FluffyChat
  • Nice to have support for multiple clients on various platforms.
  1. Available as a Debian package
  • This implies that the application is DFSG-compliant, which gives us a reasonable guarantee of software freedom.
  • Debian adds patches to the application to make it more privacy-respecting.
  1. User experience
  • The application’s minimalism will be appreciated for reasons of self-hosting, but this cannot come at the expense of user-friendliness.
  1. Use cases
  • An app must have clearly documented use cases for FreedomBox users. FreedomBox isn’t a generic platform for every possible Debian server application.
  • The use cases of the application should be easily discoverable to a FreedomBox user (in short description, long description, wiki pages, upstream documentation etc.).

The following are NOT reasons to reject an app’s inclusion into FreedomBox

  1. An existing FreedomBox app provides the same functionality
    We can have multiple servers implementing the same protocol or providing the same features in FreedomBox provided they meet most of the above criteria.

  2. It might not be used by a home user
    We might not want to create a specialized hospital box or a school box which creates a significant deviation from FreedomBox’s purpose, but we want to support community use cases of FreedomBox as well as home-user use cases. Often, features implemented for communities were made generic enough for home users in subsequent releases (Customization, Android app).

  3. Seems to be too heavy for self-hosting
    A user might decide to host their FreedomBox on more powerful hardware or just run this heavy app on a dedicated server. Also, our decisions about what is considered heavy will keep changing as hardware gets more powerful.

4 Likes