Modularity: History and Background

Very few people install a Linux distribution for its own sake. Ultimately, the goal is to “scratch a particular itch” that the user is experiencing. The solutions may take many forms, but ultimately this user wants to deploy some software that solves a problem for them.

This leads us to a classic problem that Linux distributions have faced: the “Too Fast/Too Slow” problem. Linux distributions are traditionally quite monolithic. The package collections they ship are generally self-consistent, providing generally whatever the latest stable major release of the software at the time of the distribution release. As the release ages, it will receive bugfixes and enhancements, but usually will remain on the same major version.

This is excellent for the maintainers of the distribution, because it allows them to test that everything works together as a cohesive whole. It means that there’s one authoritative version to align to.

Users, on the other hand, are most concerned about solving their problem. It matters less to them that the distribution is cohesive and more that the tools they need are available to them.

The “Too Fast/Too Slow” problem is basically this: users want a solid, stable, reliable, unchanging system. They want it to stay that way for the life of their application. However, they also want their application to run using the set of dependencies it was designed for. If that doesn’t happen to be the same version (newer or older) as the one selected for the monolithic distribution, the user will now have to resort to alternative means to get up and running. This may be as simple as bundling a dependency or as drastic as selecting an entirely different distribution that better fits their specific need.

One of the precursors to Fedora Modularity was Software Collections (SCLs). This was a first try at solving the Too Fast/Too Slow” problem in the Fedora/Red Hat ecosystem. provides two basic advantages: Parallel Availability and Parallel Installability.

Parallel Availability means that more than one major release of a popular software project is available for installation. For example, the “Developer Toolset” SCLs provide access to newer versions of GCC and its related toolchain for building software. There are Python and Ruby SCLs that provide assorted runtimes for those languages and so on.

Parallel Installability means that more than one major release of a software project can be installed on the same userspace.

A few years back, the Product Management team inside Red Hat performed a large-scale survey of customers and potential customers about the user experience of Red Hat Enterprise Linux. In particular, they asked about their level of satisfaction with the software available from the enterprise distribution and their opinion on these Software Collections.

Perhaps unsurprisingly, the overwhelming majority of respondents were thrilled to have supported versions of software beyond what had shipped with the base operating system. What the survey team did come away with that was an epiphany was that the respondents generally did not care about the parallel installability of the SCLs. For the most part, they maintained individual userspaces (using bare metal, traditional virtualization or containers) for each of the applications they cared about.

The most common problem reported for Software Collections was that using them required changes to the applications they wanted to run. SCLs install to a separate filesystem location from more traditional RPMs and applications that rely on them need to know where to look for them. (In SCL parlance, this is called “activating” the collection.)

The consequence of this relocation on disk is that users were unable to take existing applications (either FOSS or proprietary) and simply use them. Instead, they had to modify the projects to first activate the collections. This was a consistent pain point.

Given this feedback, Red Hat came to the conclusion that parallel installability, while nice to have, was not a critical user requirement. Instead, the focus would be on the parallel availability. By dropping this requirement, it became possible to create a solution that allowed the different versions to be swapped in and take over the standard locations on the disk.

Of course, it’s not just Red Hat — people in Fedora are also concerned with solving this Too Fast / Too Slow problem for our users. Efforts around this kicked off in seriousness with the Fedora.next initiative and Fedora Project Leader Matthew Miller’s “Rings” talk at the first Flock conference in 2013.

This led to the proposal and approval by the Fedora Council of the Modularity Prototype Fedora Objective and its follow-up Modularity Release Fedora Objective.

For more information on requirements and use cases, read on to the Modularity requirements and use cases page.