A possible solution to the fragmentation problem

Technical post ahead !

Fragmentation can be a pain for mobile users, and might drive them away of a brand, or even totally ruin a brand reputation. For example, Apple maintained a very good reputation, by supporting (although not uniformly) nearly all its devices, whereas Nokia (or Microsoft in this case) nearly abandonned its flagship (Lumia 900) by announcing that it was impossible to upgrade to WP8.

Fragmentation is also the result of an interaction (or lack of interaction) between many players, that are the company that develops the OS, the manufacturer and the retailer. Apple is both the company that develop iOS and makes the iPhone, and it forbids retailer to add customization. Apple is then in total control of its software, and is able to provide seamless system updates.  In the other hand, Android devices runs Android, that is made by Google, but are build from different manufacturers (Samsung, HTC etc.) and are then customized by retailers. There are at least 3 levels where fragmentation can occur:

  1. Google might optimize Android and drop support for old hardware
  2. Manufacturers might not want to spend time upgrading their devices
  3. Retailers might take time (or do not bother) applying their customization

That’s why Android is always known as being very fragmented.


What I feel wrong with the software industry today is that, although if it is or is nearly developed in an agile way, the release is not agile at all.

For a reminder, agile software developement is a set of methods that is used to make software developement progress in an incremental ways, by adding small features (or preparing features addition) and provide bugfixes in each iterations. Many companies, especially IT companies uses agile developement.

Some well known software also have a full agile process: Mozilla Firefox and Google Chrome provides one release every month and a half, releasing each time small features and fixing bugs. But they dub their version X.0.0, that means that each release is major, although they are only releasing an iteration, and should be dubbed 1.X.0 instead, or even 1.X (there is no minor release, only iterations). And the major version should be used if a complete rewrite and change in architecture is done.

Linux kernel or Qt also have a developement that can be considered as agile, but is a bit different. Contributions are provided as commits in a git repositiry, that are approuved. Each of these commits can be considered as a single cycle in the agile developement process.

In fact, most of the software are developed using (more or less) an agile method. What is not agile is the release method. Before releasing, the Kernel team or Qt maintainers tests intensively all added features, while the repository is closed for new commits. And they fix bugs, before releasing everything. This should also be what happen behind the doors of Google for Android, or Apple for iOS. Following the release of the sotftware, there are two developement “branches” that are opened. One is for doing bugfixes in the current released version, and the other is the one used in the developement (“master” or “trunk” etc)

Google Chrome and Firefox are doing it a bit differently, and have a more interesting way of releasing software. Instead of having only one branch of developement, that is freezed before release, they have 3 of them.

  1. Some unstable branch, that always accept commits
  2. Some branch used to do bugfixing, but is not yet stable
  3. A stable branch

Being able to do the three tasks in a parallel way allows Google and Mozilla to release more often, providing new features and fixes often, with an integration processt that also follows an iterative scheme (small cycles “unstable -> bugfix -> stable”).

You might be puzzled on why I’m asking to release more often while the fragmentation issue is because of some actors laggying behind release, and that more releases will affect them even more.


In fact, manufactuers and retailers are not interested in everything on a phone OS. They don’t want to patch the Linux kernel on Android, nor changing the compositor or the graphics-system. Most of them provide a skin over the plain Android experience, by adding a different homescreen or different apps.

So, instead of doing release of Android X.Y.Z version, it might be interesting to provide modules. A set of different softwares that have a common role. That’s what Mer project (base of Jolla OS) is actually providing. They have a set of base software, including a kernel, and base tools, a set of network system, a set of packaging tools, etc. Each of these sets might be updated differently, to provide better performances, or to provide security fixes.

Sadly, in the GNU-Linux world (Mer is a Linux distribution), there are a lot of dependancies on different components. For example, every process depends on the system loader (init), and replacing init is very hard. While Ubuntu, or more recently, Mageia (a community-driven french Linux distribution) migrated to systemd, it causes many bugs, and took a lot of time as well.
This is a problem that should be addressed, by first minimizing dependancies, and by finding smooth upgrade path.

If a system is splitted into several modules, updates to some of these modules can then seamlessly provided by the company that deploy the OS. There is then no need to wait for new features (like new apps) that do not interfere with the manfacturer or retailer UI, or waiting for security fixes.

Even upgrading toolkits can be done easily. The transition from Qt4 to Qt5 can be done by two sets of “graphics tools metapackages”, that do not conflicts one to another. A message from the server to users might however indicate that the old one is not being officially supported, although still usable. Developers should then be warned as well, that the API they are using should no longer be used.

Binary compatibility

Something that can help transitionning in a smooth way is binary compatibility. Many opensource libraries (including Qt) tries to be binary compatible. If an application is compiled with Qt X.Y.Z, it will run without recompilation with Qt X.A.B where
A >= Y and B >= Z. Interpreted programs, that are for example written in python are also compatible, because they are interpreted, and do not link to libraries. Instead, a program reads the code and execute what the code says. Even if this program changes, the expected behaviour should be the same, so there is also a compatibility.

Binary compatibility will help shipping updates (either security or features) without breaking existing applications, including constructors and retailers skins.


The points raised shoud match both Android and Jolla, that might expect fragmentation problem in their product (in fact, Android is already having this problem). Splitting the OS into several components, or set of packages, and updates them in an agile way. Release often small updates, and keep binary compatibility guarantees that the OS is up-to-date, despite manufacturers and carriers customizations.

In exchange, this developement is costly, especially in manpower, since each small release should be tested before being pushed to devices. But small features can be tested more easily and extensively, so more bugs can be hunt before release as well. This way of releasing might also be bad for advertisement, since there are not a lot of feature coming with each release, but small additions.

This also guarantee that old phones will still have decent updates. If they cannot get the next update to apps that needs capacities that they don’t have, they might still get security, kernel, networking etc. updates. It might also possible to deliver to them a light version of the heavy update that is provided to newer devices.

In short, the release of major version evey 6 month might not make sense in a world exposed to security menaces and also where everybody wants changes, quickly. Pushing small updates of different components seems to be a good compromise. There might still be major version break, but only when important, architectural changes, are done.


One thought on “A possible solution to the fragmentation problem

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s