<div dir="ltr"><div>Sorry for the long report. I hope its structure helps a diagonal read.<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">In my humble and still quite ignorant opinion, the most <u>important challenges</u> for FreedomBox in 2020, Q4 are:<br></div><div><b><br></b></div><div style="margin-left:40px"><b>Video-conferencing feature</b>:</div><div style="margin-left:40px">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.<br><br><b>Consistency</b>:</div><div style="margin-left:40px"> 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.<br></div><div style="margin-left:40px"><br></div><div style="margin-left:40px">Project <b>effectiveness</b> as <b>relevance</b> for end users:</div><ul style="margin-left:40px"><li>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.</li><li>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 <i>consider</i> prioritising purpose over path/means and become a derivative instead of a pure blend. I say <i>"consider"</i> 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.</li><li>This challenge has technical aspects but it is a political issue. Foundation might push/help to raise awareness of this within Debian (?).</li><li>DPL said in DebConf 2020 that Debian was overbudgeted (See <a href="https://chuangtzu.ftp.acc.umu.se/pub/debian-meetings/2020/DebConf20/9-bits-from-the-dpl.webm" target="_blank">https://chuangtzu.ftp.acc.umu.se/pub/debian-meetings/2020/DebConf20/9-bits-from-the-dpl.webm</a> 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 <a href="https://www.freexian.com/en/services/debian-sponsorship.html" target="_blank">https://www.freexian.com/en/services/debian-sponsorship.html</a>) solutions to problems suffered by Debian (?).<br></li></ul><div dir="ltr"><br>In my humble and still quite ignorant opinion, in order for Freedombox to become a <u>mainstream consumer</u> solution we need:</div><div dir="ltr"><br></div><div style="margin-left:40px">To <b>fix</b> the minimal viable product (<b>MVP</b>).<br></div><div style="margin-left:40px"><div style="margin-left:40px">The basic functionality must work out of the box and the admin procedures must be easy to find and execute.<br>Find  below my suggestions for developer priorities, for more details.</div><div style="margin-left:40px"><b><br></b></div><b>Marketing</b>:</div><div style="margin-left:80px">Strategy: I see at least 2 compatible, but different approaches:<br></div><div style="margin-left:80px"><ul><li>Seek geeks as evangelists for consumers trusting their advice.</li><li>Consumer first approach with geek goodies as secondary extra value.</li></ul></div><div style="margin-left:80px">Numerically-controlled: Hard facts and metrics are key to manage anything, if you seek results, and marketing is no exception.</div><div style="margin-left:80px"><br></div><div style="margin-left:80px">There was some interest 2 years ago in a marketing team but it diluted (See <a href="https://salsa.debian.org/freedombox-team/freedombox/-/issues/1944">#1944</a>). Perhaps it can be re-launched?</div><div style="margin-left:40px"><br></div><div style="margin-left:40px">To <b>prioritize</b> <b>purpose</b> over maintainability.</div><div style="margin-left:40px">         Current examples of the opposite:</div><div style="margin-left:40px"><ul style="margin-left:40px"><li>The apps are sorted by app name (identification) instead of by user functionality (delivered value). See <a href="https://salsa.debian.org/freedombox-team/freedombox/-/issues/1859">#1859</a>.</li><li>Self-constraining to be a pure blend (maintainability) over providing a highly demanded, available, free software based, working solution (like Jitsi Meet).</li></ul>         Prioritising purpose isn't gratis. It implies some extra effort.<br></div><div><div><div dir="ltr"><br><div style="margin-left:40px">To <b>collaborate</b> with other privacy-focused <b>communities</b>:<br>        <i> "On your own, you get faster. Accompanied, you get further."</i><br></div><div style="margin-left:80px"><ul><li>Self-hosting: FreedomBone, YunoHost, SandStorm, <a href="https://lists.debian.org/debian-devel/2020/11/msg00202.html">https://lists.debian.org/debian-devel/2020/11/msg00202.html</a>.</li><li>Offgrid: See <a href="https://wiki.debian.org/FreedomBox/Design#Similar_Projects">https://wiki.debian.org/FreedomBox/Design#Similar_Projects</a></li><li>Alternative networks/services: Tor, I2P, Disapora, GNUSocial, Mastodon, Matrix, Protonmail, DuckDuckGo...etc</li><li>Privacy Tools Debian Maintainers: <a href="https://wiki.debian.org/Teams/PkgPrivacyMaintainers">https://wiki.debian.org/Teams/PkgPrivacyMaintainers</a></li><li><a href="https://lbry.com">https://lbry.com</a>, FSF/FSFE/FSF-LA, ...</li><li>Current upstream.</li><li>Would-be upstream. See <a href="https://wiki.debian.org/FreedomBox/LeavingTheCloud">https://wiki.debian.org/FreedomBox/LeavingTheCloud</a></li></ul></div><div style="margin-left:40px">         We should list such communities on our wiki in order to track them.</div></div><div dir="ltr"><br>I've tried to set my proposal for <u>developer priorities</u> in line with the previous view/goal:</div><div dir="ltr"><br><div style="margin-left:40px">1. Fix <b>basic</b> usage/UX <b>caveats</b>:<br></div><div style="margin-left:40px"><ul><li>The easiest path for consumers is <u>buying a kit</u>. 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.</li><li>A router reset (caused for example by a power outage) renders the <u>FB unreachable</u>. (Q&A doc can help a lot!!) See <a href="https://salsa.debian.org/freedombox-team/freedombox/-/issues/1833">#1833</a>.</li><li>Some <u>asynchronous procedures</u> 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.</li></ul></div><div style="margin-left:40px"> 2. Fix <b>reachability</b>:<br>       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.<br></div><div style="margin-left:40px"><ul><li>Current <u>networking documentation</u> 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.</li><li><u>Dynamic DNS is important</u> because if it fails (it does) it usually blocks Cockpit. Cockpit needs a full DN.</li></ul></div><div style="margin-left:40px"> 3. We should (try/aim to) provide <b>self-hosted web clients</b> for IRC/quassel, mumble, etc.<br>     Some don't even exist. We should ask for them upstream or in privacy-centric forums.<br></div></div><br></div></div></div>