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.
_______________________________________________
Freedombox-discuss mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/freedombox-discuss
