The FreedomBox Foundation is pleased to announce that we will hold our second consecutive FreedomBox Summit on Friday, November 15th, 2019 in New York City. Invited members of the FreedomBox Core Team will join the FreedomBox Foundation’s staff for a full day of discussions about our progress since last year’s Summit and our plans for the year ahead. Read more about the 2019 Summit here.
Though we have an idea of what we want to discuss during Session I, we want community members to have their voices heard. Just like last year, we want to assemble an agenda with your suggestions.
Prompt: In short, our agenda should reflect the most important issues facing the FreedomBox project as we continue to improve our UI, attract new users, and expand our hardware sales. What do you think are the most important challenges facing the FreedomBox project? What should our development priorities be for the upcoming year? We want FreedomBox to become a mainstream consumer privacy solution. What do you think we need to do before we get to that point?
We could package specially designed versions of FreedomBox with specific software ready for a given use case, e.g. “College Edition,” “Village Edition,” “Small Business edition,” etc.
FreedomBox in Debian installer. Current status of the discussion in Debian. What can we do?
FreedomBox blog/news. FreedomBox updates should become part of Debian planet to reach more Debian developers.
Next generation hardware. How to help existing partner and bring new partners. FreedomBox can play multiple roles at home and become much more enticing for buyers. This is, however, secondary compared to the primary goal of protecting privacy and digital rights.
Contribution/donation links for each app. Encourage user connection and contribution to upstream projects.
Show app maintainers. Acknowledge the work for app maintainers. Invite contributors to pick more responsibility.
SPDX license header. Simplify license headers using SPDX license identifiers in source code.
Drop outdated apps. Apps disabled for 1 year and with no prospects of re-addition should be dropped. This eases some framework level changes.
Nextcloud. Is Debian fasttrack as suitable answer for Nextcloud? If not can we use Snaps? What should be expected from an app that is added to FreedomBox implemented using Snaps or similar approach? (Security updates, data storage location, backup/restore, duplication of services such as database, webserver and letsencrypt)
Fediverse. What should be our priorities?
Documentation Wiki. Problems with current wiki approach for creating manual. How to do this in future?
Technical discussion
Future components. Are components working out alright. Plan for introducing new components (info, user groups) and component level actions (diagnostics, setup). Further clean up of code using components (app.init, module loader) and using manifests to automatically create components in a app.
Functional tests. Has using English like description served us better than would be otherwise possible? Should we allow alternatives. Split tests and their utilities into individual apps. Speed up functional tests by avoiding wait times for negative queries and unnecessary re-navigation to app pages.
Toolbar UX. Consolidation of ideas around of UX improvements using a toolbar.
Running actions from DBus. Instead of using the command line, we could consider D-Bus protocol for performing superuser operations. Command line interactions are retained and will be exposed as in a simple, uniform way in the level of framework. This will eliminate a lot of boilerplate code and will eliminate issues such as problems when passing secrets. Further it will provide better performance as loading python interpreter for each command results in very large number of system calls.
Regarding “What should our development priorities be for the upcoming year?”
Two things:
In my opinion simplifying reachability to the Freedombox should be a priority going forward. From what I have seen setting up access to the Freedombox seems to be the biggest obstacle for new users. Setup wizard issue is discussed here: “RFC: Reachability: UX for first setup wizard and apps”
I think Freedombox could be more easily adopted by everyday users if it were sold as a router + Freedombox. Everyone already has a router at home, and I believe it is conceptually easier to buy the Freedombox as a replacement for the router which has the benefit of also working as a home server. To that end, the Freedombox hardware should be designed to function as a router (ethernet ports, etc.).
Staying relevant for the post-millennial generation
FreedomBox as an idea is 10 years old and the product is at least 9. Though the product and its user interface has been continuously evolving, I am not sure if it is keeping up with the needs and expectations of the next generation.
This question has been on my mind for a long time. How does FreedomBox stay relevant and interesting to people born in the 2000s? People who are still teenagers, people who grew up with smartphones in the age of surveillance capitalism, people with scarce attention and used to the bright, flashy distracting things that the advertising industry has unleashed on them.
This leads me to ask some hard questions.
Does our user interface look like it’s made for the previous decade?
Does a teenager look at FreedomBox like some kind of ancient product?
Are we expecting a mostly mobile generation to use a desktop web application?
Does our user interface with too much text repel the tl;dr generation that doesn’t have the attention span to read for 5 minutes straight?
Maybe some of these questions might be based on wrong assumptions. And there are better questions to ask.
I am too old to answer questions like the above. Maybe we should ask some high-school and early college students about their first impressions and perceptions about FreedomBox.
I wrote “Make FreedomBox cool and not boring so that we attract millennials” on the mailing list a year ago. This is a follow-up to that. I think the product in its current state is reasonably good for people who have lived with Web 1.0.
Also, 90s kids like me are already working on solving the problems of the centralized web. We should start thinking about the 2000s kids now.