[Freedombox-discuss] Request for Comments: Agenda Items for 2020 Summit

[Fioddor Superconcentrado]

Sorry for the long report. I hope its structure helps a diagonal read.


In my humble and still quite ignorant opinion, the most *important
challenges* for FreedomBox in 2020, Q4 are:

*Video-conferencing feature*:
Covid19 has forced masses of people and small businesses online. Those
newcomers are falling into free-as-in-free-beer SaaSS traps. We missed a
huge opportunity to serve and grow, and we should catch up ASAP and rescue
as many as we can. FreedomBox needs a proper video-conferencing solution
for individuals and small communities. I don't know if I'm biased by my
personal experience, but I tried to get my daughters to use JSXC and it
resulted to be way too buggy.

*Consistency*:
We're inconsistent! We and/as debianites use Jitsi Meet for
videoconferencing, but it is not packaged in Debian and due to web
standards evolving so fast, will likely never be, unless it is granted the
same exceptional status that browsers have.

Project *effectiveness* as *relevance* for end users:

   - This is becoming a general trend: It happened to Docker, VirtualBox,
   PyCharm, etc. Despite the growth in the amount of packages maintained, more
   and more popular free software is installable but missing in Debian => It
   needs a strategic solution at Debian level.
   - As Debian pure blend this limits us over other solutions. I don't know
   how far we could/should bend those limits. I believe we could include such
   software as long as we clearly distinguish what is FreedomBox (Debian) and
   what are external plug-ins. YunoHost would be a good partner here because
   they're Debian based as well. If not allowed, we should *consider*
   prioritising purpose over path/means and become a derivative instead of a
   pure blend. I say *"consider"* because we might as well decide to
   prioritise the path over the purpose and remain a limited effort to provide
   privacy with available hard-certified free software only.
   - This challenge has technical aspects but it is a political issue.
   Foundation might push/help to raise awareness of this within Debian (?).
   - DPL said in DebConf 2020 that Debian was overbudgeted (See
   https://chuangtzu.ftp.acc.umu.se/pub/debian-meetings/2020/DebConf20/9-bits-from-the-dpl.webm
   at minute 3:00 to 9:30). Well, I guess the problem isn't the money
   actually, but rather a very constrained list of policy/culture-compliant
   ways to spend that money. Debian is volunteer-run by definition for
   independence's sake and thus, we should avoid money to become a vital
   infrastructure. Instead, it should better remain an optional accelerator we
   can live without. Foundation might perhaps persuade Debian to spend buying
   upstream (or from Freexian, see
   https://www.freexian.com/en/services/debian-sponsorship.html) solutions
   to problems suffered by Debian (?).


In my humble and still quite ignorant opinion, in order for Freedombox to
become a *mainstream consumer* solution we need:

To *fix* the minimal viable product (*MVP*).
The basic functionality must work out of the box and the admin procedures
must be easy to find and execute.
Find below my suggestions for developer priorities, for more details.

*Marketing*:
Strategy: I see at least 2 compatible, but different approaches:

   - Seek geeks as evangelists for consumers trusting their advice.
   - Consumer first approach with geek goodies as secondary extra value.

Numerically-controlled: Hard facts and metrics are key to manage anything,
if you seek results, and marketing is no exception.

There was some interest 2 years ago in a marketing team but it diluted (See
#1944 <https://salsa.debian.org/freedombox-team/freedombox/-/issues/1944>).
Perhaps it can be re-launched?

To *prioritize* *purpose* over maintainability.
         Current examples of the opposite:

   - The apps are sorted by app name (identification) instead of by user
   functionality (delivered value). See #1859
   <https://salsa.debian.org/freedombox-team/freedombox/-/issues/1859>.
   - Self-constraining to be a pure blend (maintainability) over providing
   a highly demanded, available, free software based, working solution (like
   Jitsi Meet).

         Prioritising purpose isn't gratis. It implies some extra effort.

To *collaborate* with other privacy-focused *communities*:
        * "On your own, you get faster. Accompanied, you get further."*

   - Self-hosting: FreedomBone, YunoHost, SandStorm,
   https://lists.debian.org/debian-devel/2020/11/msg00202.html.
   - Offgrid: See https://wiki.debian.org/FreedomBox/Design#Similar_Projects
   - Alternative networks/services: Tor, I2P, Disapora, GNUSocial,
   Mastodon, Matrix, Protonmail, DuckDuckGo...etc
   - Privacy Tools Debian Maintainers:
   https://wiki.debian.org/Teams/PkgPrivacyMaintainers
   - https://lbry.com, FSF/FSFE/FSF-LA, ...
   - Current upstream.
   - Would-be upstream. See
   https://wiki.debian.org/FreedomBox/LeavingTheCloud

         We should list such communities on our wiki in order to track them.

I've tried to set my proposal for *developer priorities* in line with the
previous view/goal:

1. Fix *basic* usage/UX *caveats*:

   - The easiest path for consumers is *buying a kit*. Our webs still
   highlights download over purchase or as equivalent options. Consumers use
   to think that 'download' is more affordable, and when they discover that it
   is technical and difficult they just give up because they already forgot
   they can cheaply buy-and-plug. Download should be marketed as a secondary
   choice because it is a very interesting solution for a secondary target
   (geeks). It should always be presented as such.
   - A router reset (caused for example by a power outage) renders the *FB
   unreachable*. (Q&A doc can help a lot!!) See #1833
   <https://salsa.debian.org/freedombox-team/freedombox/-/issues/1833>.
   - Some *asynchronous procedures* cause uncertainty, provoking a feeling
   of unfinished product. On screen spinners help. We need some helper
   mechanisms to be able to read progress and report it to the user in
   real-time.

 2. Fix *reachability*:
       Once the consumer has FB running in her LAN and benefits from it, a
usual step is wanting to share it with family and friends.

   - Current *networking documentation* is still difficult for regular
   consumers (magels). Graphical schemes help a lot but the UI still uses too
   much technical jargon and lacks explanations of consequences and
   side-effects. I don't yet see a clear overall solution. I can only think of
   small improvements for specific cases. We need some design discussions here.
   - *Dynamic DNS is important* because if it fails (it does) it usually
   blocks Cockpit. Cockpit needs a full DN.

 3. We should (try/aim to) provide *self-hosted web clients* for
IRC/quassel, mumble, etc.
     Some don't even exist. We should ask for them upstream or in
privacy-centric forums.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/freedombox-discuss/attachments/20201125/3515dfdc/attachment.html>