FreedomBox and the Importance of Momentum

FreedomBox is another “easy” self-hosting solution that has been around since 2010. The surface-level goals of FreedomBox are similar to that of HexOS, which we investigated in our last post; they seek to provide a path to autonomy for users so they can separate themselves from the corruption of surveillance capitalism. However, FreedomBox went about it in a different way.

First off, FreedomBox was developed by the FreedomBox Foundation, a not-for-profit organization dedicated to providing users a way out of the modern internet by helping them own part of the internet infrastructure. Additionally, FreedomBox is fully open-source and built on top of Debian, a Linux distribution. This means that unlike HexOS, FreedomBox is and always will be free to download and use. Since 2019, they have also had an agreement with Olimex to sell a preconfigured server (made from a single-board computer), enabling users to get a mostly-working FreedomBox out of the box. I say “mostly working” because FreedomBox, like HexOS, has made strides but has not fully addressed the networking issues that users face when hosting their own services.

Why Build on Debian?

Debian is a Linux distribution built on the Linux kernel. What does this mean? It means that it is a proper operating system running on one of the most successful operating systems ever. A distribution means there are additional capabilities built on top of the kernel that give users specific advantages over a base system. Debian, in particular, is all about stability and is considered a reliable choice for solutions requiring long-term dependability, like a server for your data and services.

Debian offers a packaging system that makes it much easier to install software. In earlier computing days, obtaining software meant downloading or receiving source code on disk and then compiling it—converting the human-readable code into binary code that a computer processor can understand. This is no simple task and requires considerable expertise. To solve this problem, Debian pre-packages software applications configured to run on their distribution. Instead of compiling source code, users can download a package containing binary code and configuration files, enabling them to use the software immediately with relative confidence that it will work regardless of underlying hardware.

FreedomBox takes the next step in bringing software to the common user by automating some of the configuration and managing complex tasks like backups, some networking, and updates, among other things. Because it is built as a Debian Pure Blend, FreedomBox is assured to work on any system running Debian. This is a significant advantage because FreedomBox doesn’t need to account for hardware compatibility; the larger Debian community ensures that Debian functions on various hardware, and FreedomBox benefits from this work automatically.

Why Not to Build on Debian?

Several constraints are imposed on users by the decision to build on Debian. The most prominent is that only software developed to work on Debian will be supported by FreedomBox. In 2010, this was a solid bet, as Debian was among the most popular distributions¹. While it remains popular today, it’s no longer guaranteed that specific software will be developed for Debian.

In June 2015, OCI containers like Docker emerged as an alternative to Debian packaging. Within Debian’s packaging system a given application depends on some number of libraries at specific versions. As users install applications the packaging system adds these libraries to the system. If two applications need libraries of different versions the package manager may fail and require the user to make hard technical decisions to resolve the situation. Docker solves this problem by including all dependencies for all applications in a single package.

Docker’s approach requires more disk space and more working memory, in general, compared to package systems like Debian’s. In exchange, application maintainers create one single package and rely on Docker’s abstraction layer to make that application package work on various operating systems. This is a huge advantage for developers and users alike, as it means (with some limitations) you can engineer software once and have it run anywhere Docker runs. This dramatically reduces the incentive to create software specifically for Debian (or any specific Linux distribution), diminishing FreedomBox’s relevance.

Some of the most popular applications, such as Plex, Home Assistant, and Immich, are not compatible with FreedomBox and likely won’t be in the future. This leaves value on the table for users who could benefit from these applications. Additionally, FreedomBox still requires too much technical expertise from users, which deters adoption of open-source solutions.

My personal experience involved a four-hour attempt to install FreedomBox on both a single-board computer and an old laptop. This ultimately led to a polished UI with apps that wouldn’t install. Despite following recommended setup instructions, I faced issues likely related to networking, though this wasn’t explicitly stated in the documentation. Even with tools like Google, Stack Overflow, and ChatGPT, I couldn’t resolve the issue quickly. While I’m not a tech genius, I’m also not a novice, and I found the process discouraging. For many users, this steep learning curve is a significant barrier, illustrating the delicate balance between building on a solid foundation and meeting users where they are.

The Tricky Balance and the Costs

Innovation and maintenance come at a cost, and software is no exception. When these costs are spread across a large user base, they are manageable; the marginal cost of software distribution is effectively zero. However, when the user base is small, the cost per user becomes prohibitively high. This creates a vicious cycle: fewer users mean less revenue or community support, which in turn reduces the resources available for innovation and maintenance. Without continuous improvement, the software becomes stagnant and struggles to attract new users, further exacerbating the problem.

FreedomBox illustrates this challenge well. It chose to build on Debian, which is a fine choice for a Linux distribution. Its UI integrates with Debian’s package manager system and surely works for some users on some systems. New releases are still being produced. However, within the self-hosted developer community OCI containers, and technologies like Docker Compose, are the de facto standard distribution mechanism. FreedomBox doesn’t have a large enough user base to attract developers to maintain Debian packages for even the most popular applications. The lack of momentum means fewer users are contributing feedback, documentation, or updates, making it harder for the project to stay relevant.

Momentum is critical for any software project. It provides the energy needed to push through initial adoption barriers, attract developers and contributors, and maintain a cycle of innovation. Momentum can be generated through several strategies:

1. Community Engagement: Encouraging users to contribute through forums, tutorials, and community events fosters a sense of ownership and commitment.
2. Lowering Barriers to Entry: Simplifying installation and setup processes, as well as providing better documentation, can make software more accessible to non-technical users.
3. Building Partnerships: Collaborating with hardware manufacturers or software platforms can expand reach and provide additional resources for development.
4. Focusing on Key Features: Identifying the core needs of users and delivering on those effectively can create a loyal user base. For example, prioritizing seamless networking setup could significantly reduce frustrations for FreedomBox users.
5. Leveraging Modern Technologies: Adopting containerization or similar advancements can make the platform more versatile and attractive to developers and users.

Innovation is not a one-time event; it’s an ongoing process. Projects like FreedomBox must continuously evolve to meet the changing needs of users and adapt to new technological landscapes. This requires not just technical expertise but also an understanding of user behavior and market trends.

Was FreedomBox’s choice to use Debian’s packaging system a bad choice that limited the project? It was a reasonable choice in 2010 when the project started, the same year that dotCloud was incorporated, 3 years before dotCloud renamed itself to Docker, and 5 years before OCI containers were introduced. Should FreedomBox have shifted to OCI containers at some point in the past 10 years? Perhaps, but I’m not convinced that this specific technical choice is the root cause of FreedomBox’s low adoption. Rather, it’s a symptom of a long-term lack of momentum.

The Criticality of Momentum

So far I’ve been talking about Docker the technology. It’s extremely popular, open source, the de facto standard for deploying self-hosted applications. It was built by Docker the company. Their history is instrumental in understanding momentum.

Docker the technology is extremely popular today. It was preceded technically by LXC, Solaris Zones, and BSD Jails, all of which do the same things in roughly the same way as Docker does. They just work on Linux, Solaris and the BSDs, respectively. Any sufficiently expert sysadmin could create containers on these operating systems without Docker in 2010. Very few did.

Docker the company saw the value in containerization and the extremely high bar to using containers and invested heavily in making the experience easier. At the time they deprioritized security, operational consistency, and large-scale deployments. Instead they focused on lowering the barrier-to-entry, having excellent documentation, tutorials, simple examples, and making Docker the technology work identically across many operating systems (including Windows and MacOS, which did not have a native container runtime)².

Docker’s focus on ease-of-use drove adoption. Increasing adoption created momentum. This led Docker to be able to easily secure funding, hire engineers, and then address some (though not all) of their security shortcomings, missing ops features, and create even simpler solutions (Docker Compose, Swarm mode).

Docker was able to leverage partnerships with cloud vendors (Amazon, IBM, Oracle) and support from Windows to become the cross-platform standard for deploying applications. This led to some commercial success for Docker - they were valued at a billion dollars in 2015 - but that success didn’t last for* Docker the company.* Docker eventually sold off parts of their business, spun out their core technology into the Moby project and focused on profitability through enterprise licensing. To do so they took on funding with a series B of $23 million in 2021 and a $105 million series C in 2022. All of Docker’s revenue comes from licensing the closed-source Docker Desktop tool. Meanwhile, the majority of the software created by Docker the company to create their incredible technical success is open source and maintained by the community rather than the company.

Because Docker the technology gained massive momentum it led to the creation of an entire ecosystem of tools that work with it. There are alternative container runtimes, pluggable network drivers, alternative container daemons and frontends, container orchestration systems, container image build systems, and much more. Containers as a dominant deployment strategy may not last forever, but I wouldn’t bet against it lasting for a decade or more. That’s because Docker made something that was possible but hard into something that was easy and free to build on.

Ultimately, the lesson is clear: building a sustainable software solution is about more than good intentions or even solid engineering. It’s about creating and maintaining the momentum needed to keep pace with user expectations and technological advances. FreedomBox’s struggles underscore the importance of balancing a strong foundation with adaptability, innovation, and user-centered design.

Tealok and Momentum

Generating momentum from scratch is an uncertain path, often requiring a degree of luck. However, luck favors the prepared, and we plan to follow some key principles to build and sustain momentum:

• Customer Pull: One of the most reliable ways to create momentum is by genuinely listening to and responding to customers. This principle is rooted in Lean methodology, which we closely follow at Gleipnir LLC.
• Balance Innovation Against Speed: Innovation is inherently expensive because it involves pure creation. It’s also exciting for the same reason. However, an overemphasis on innovation can stall progress if too many resources are diverted to it. A better approach is to focus on user needs, balancing innovation with ready-made tools that address those needs effectively. By taking a long-term view, there’s plenty of time for innovation—but only if you maintain momentum.
• Be Cautious About Sacrificing Customer Preferences to Ideology: Eli and I are building Tealok because we believe strongly in certain values: users should have autonomy and ownership of their data, parents should have control over their children’s digital experiences, and so on. However, many projects in this space have failed because they prioritized ideology over practicality. For instance, while we disdain advertisements and surveillance capitalism, we may still use Google and Facebook ads to reach our audience. Similarly, while we believe the best path to true autonomy is for everyone to have their own server, we won’t exclude customers who prefer a hosted solution.
• Build Relationships of Trust: One unfortunate consequence of today’s tech industry is the erosion of trust. After more than a decade of exposure to platform decay and harmful business practices, users are understandably wary of tech companies. To sustain momentum, it’s essential to rebuild trust by setting clear expectations and consistently delivering on them.
• Plan for the Long Term: Investing in technology is costly—not just in time and money but also in opportunity cost. Customers shouldn’t have to spend weeks learning a new product only to see it discontinued a year later. To ensure we don’t let our customers down, we plan for the long term. We develop in the open, publish all source code under permissive licenses, and rely on open protocols wherever possible to increase Tealok’s longevity.

We are building Tealok to empower people, and we hope this vision generates the momentum we need. We’re committed to these principles and invite you to join us on this journey. Let us know what you’d like to see from Tealok.

Notes