Fragmentation is a massive problem in computer software development that has only gotten worse with mobile computers. By fragmentation I’m referring to incompatible platforms that require a developer to maintain separate forks of their code. Twenty years ago if you wanted to write software for an end user, you had to decide whether to support Windows, Macs or Linux. Each of those platforms required you to build, test, and maintain different forks of your software.
Fast forward to today, and at a minimum a developer has to decide whether to develop a “mobile app” or a “desktop app” and depending on that choice, has to decide whether to support Android or iOS (and if they want to be fancy, all of the Android forks and different mobile-only Linux OSes), or Windows, MacOS and Linux, or potentially all of the above!
Each platform means a separate fork, a separate set of libraries and in some cases means you have to develop your application in a completely different language with a completely different framework! Fragmentation means developers must divide their limited time and attention between different codebases and understand the nuances of each platform. Fragmentation wastes valuable developer time. Since so many of these applications are proprietary (especially true for mobile apps), developers also typically can’t rely on the community to step in and port and support their application on a different platform.
There is even further fragmentation of the Android ecosystem not only from vendors creating their own custom forks of Android, but also because vendors stop providing OS updates for a particular piece of hardware after a year or two–that is if hardware gets Android updates at all. If you combine that with new backwards-incompatible OS features, Android app developers have to support wide ranges of OS releases and monitor reports of how many old Android devices are still in the wild, so they know how many existing users they might leave behind with a future update.
Over the years there have been numerous efforts to create “mobile” Linux OSes that attempt to resemble more traditional Linux distributions, but that only run on mobile hardware. These OSes combine a Linux kernel (often from Android) with a custom userspace environment and run the continuum from Android itself (which is a mobile-only OS that runs a Linux kernel with a custom userspace), to Android forks that add security features, to Android forks that remove all proprietary software, to finally what most people think of as “mobile Linux” OSes that feature a wide range of different and incompatible userspace environments.
Unfortunately, most “mobile-only Linux” efforts to date have made the fragmentation problem worse, not better. This is because in the end, if a software developer wants their software to run on any of these OSes that don’t feature the Android userspace, they must port their software to yet another platform. This is true even if the developer already supports Linux on the desktop.
More than anything else, it’s this fragmentation that has led to limited adoption of mobile Linux OSes (or really any alternative to Android and iOS). It’s why almost every conversation about these platforms ends up being around “how many apps do you have?” If you have to port every application to your platform to be a success, you face a steep uphill climb.
Number of apps mattered on Android and iOS originally because apps had to be ported (and essentially rewritten) from an existing platform. If all MacOS apps “just worked” on iOS, “number of apps” would have never been part of the conversation. Just like web developers responded to the surge of mobile browsing with responsive web design in only a matter of years, Mac developers would have done the same so their MacOS apps worked on iOS. This is why the Librem 5 runs PureOS.
In addition to “how many apps do you have?” another frequently asked question we get about the Librem 5 is “why didn’t you use Android/Android fork/other mobile-only Linux OS?” We think of the Librem 5 as a portable, general-purpose computer, not a “smartphone” and it should use a general-purpose OS. We wanted to avoid all of the fragmentation, app porting woes, and mistakes of other platforms by using the same OS we use on our laptops.
Instead of asking developers to support yet another mobile OS, we realized the best path to success in providing an alternative to Android and iOS is using a platform they already know and already support: PureOS. So instead of spending effort porting apps, we invested in making the existing Linux desktop ecosystem portable.
By making the Linux desktop portable, we already had thousands of apps at our disposal. Like web designers making responsive web sites, we just had to make them adaptive to look good on a small screen. So we developed libhandy to make it easy to add adaptive features to existing GTK applications. We also developed phosh, phoc and squeekboard, among other tools, so we had a desktop environment that worked well in a phone form-factor.
Because of our approach, the Librem 5 runs regular desktop Firefox and we didn’t have to ask Mozilla to port Firefox to our platform. We’ve also worked upstream to help make more and more desktop applications like Epiphany (web browser), Geary (email), Lollypop (music player) and a number of foundational Gnome applications adapt to smaller screens.
What does this mean if you are a developer who wants to write an app for the Librem 5? It means you can write your app just like you would for a Librem laptop using the same exact development tools. You can develop applications either on a Librem laptop running PureOS or the Librem 5 itself. There’s no need to maintain a separate Librem 5 fork of your code–just make sure your standard Linux desktop app still works when resized down to the Librem 5 screen size, and widgets are touch-friendly, and you’re done.
By avoiding fragmentation and bringing the existing desktop ecosystem to the phone, we save valuable developer time. Apps developed for the Librem 5 not only work on the Librem 5, they work when the Librem 5 is docked with a larger screen, as well as on Librem laptops and the Librem Mini.
At the moment I would describe the Linux desktop ecosystem like the web development ecosystem before “responsive web design” made web browsing usable on mobile screens. All the applications work, they just don’t all fit. The work to make an existing website responsive is similar to making an existing desktop application adaptive, and both are easier–and better design–than maintaining a mobile-only port.
Avoid fragmentation and bring your apps to PureOS and the Librem 5–the general-purpose computer in your pocket.