Throughout my career, I’ve heard the phrase “We can just build our own distro, everyone does it, it’s not difficult,” repeated frequently. Linux has a storied history of people repeating this mantra, a belief that building their own distro is a simple and common task. The reality, however, is that building your own distro is a complex and challenging process. While it is certainly doable, the idea that it’s “not difficult” is far from accurate, and there are several reasons, some not so obvious, why this is the case.
Building the distro isn’t even half the battle
Most open source projects have a vested interest in making their project buildable, ensuring that it can be compiled and built into an executable program or a library by anyone who wants to use it or contribute to its development. To be fair, it’s mostly so that it is buildable by the people working on the project. This has the happy side effect that others who may not be embedded in that project tend to find that getting a project built may not be easy, but it’s at least doable.
Long ago, software didn’t come all nicely wrapped up in RPMs, DEBs, Flatpacks or even just containers as it is today. It came in source form, and it was left to the user to figure out how to compile it and get it running. Typically the pattern for the most basic of builds was ingrained in many people’s fingers and went like this: tar -xzvf .tar.gz && cd && ./configure && make && make install. It would usually work, and you’d end up with something up and running, albeit with the realization that several header files and libraries were missing.
Now, for a distro, you need to do this sort of thing a few thousand times, wrapping them up in nice packages. Once you’ve got the packages sorted, an installer is needed to help you get them onto machines. If the distro doesn’t have a nice system platform to work with – *cough* ARM *cough* – you could just lay all those bits out on a disk image and dd (disk duplicate command) an image straight down onto your bootable media, and off you go.
We’re at the point where all the hard parts are CLEARLY done, right? You’ve compiled the code, you’ve done the packaging (don’t think I’m glossing over this stage, making it seem quick and easy), you’ve got an installer (also not easy), and you can get a system up and running. Ta-da, you have a distro!
Alas, the reality check: All you have here is a one-off system.
Where the real battle lies
The real problem with a Linux distro isn’t the build system, the packaging (although this *IS* a big undertaking), installer or any of the other problems. It’s the unrelenting work of keeping track of updates and always being on the treadmill of your distribution being built on an ever-shifting bed of sand. One thing folks tend to overlook is that writing software is, in reality, the act of writing bugs. By the time you’ve done all the work of building the code and getting it all wrapped up and out, there are bugs present. Consider the additional fact that there are bugs present in the packages of your distribution, resulting in the need for numerous updates. You thought you were done doing all the hard work, right?
Let me tell you, this cycle of updates never stops. And that’s when the million-dollar question arises: Do you update, or do you backport?
Updating or backporting: It all depends
This is a defining aspect of many distributions. Do you just update and upgrade the package constantly, staying out on the latest releases of everything and hoping the leading edge is the simplest solution? OR do you take fixes and such and backport those changes to your existing packaging, not breaking compatibility and usability in the name of stability for your users?
There’s a lot of nuances between those two stances, and each distro makes that call a little differently. Gentoo and Arch, for example, tend to seek the latest and greatest software available. Fedora, on the other hand, takes a minor hedge and stays close to the latest and greatest but not always THE latest and greatest. At the other end of the spectrum, Debian and the Enterprise Linux distros move more slowly and typically prefer to backport fixes while keeping the system secure.
Each approach – using the latest and greatest software, or backporting features and fixes to older versions – requires significant effort. Opting for the newest software increases the likelihood of encountering breaking changes, which could necessitate upgrading other packages to maintain functionality. Backporting, conversely, involves creating a customized version of the package, which requires ongoing maintenance and updates. The decision on which approach to take is complex and can vary based on the specific needs and priorities of the distribution. Regardless of the chosen approach, a considerable amount of work is required to maintain the distro.
Think it’ll be easy, don’t ya
Building the distribution and dealing with the ongoing maintenance isn’t even remotely where the problem lies, and that’s not to belittle either of those tasks. They are in their own right large undertakings. There’s ongoing community interaction, supporting the users using the distro, and also more broadly in making inroads, contacts, and helping patch things that your specific distro finds in upstream projects. This means there’s a continuous upstream interaction across all the packages you maintain, which if you’ve been around the open source world can be a daunting task. There are concerns over cryptography being present in a distribution and how that all works out. There’s even infrastructure you need to worry about to build AND distribute your distro and packages. (For a detailed breakdown that holds true today, refer to Issues in Linux Mirroring: Or, BitTorrent Considered Harmful, beginning on page 177, for distributing content under worst-case scenarios.)
One last word on building your own distros
Challenges with distros are not limited to technical issues; they also extend into the non-technical. A diverse set of skills is required to tackle these issues, which cannot be handled by a single person or even a small team. Building and maintaining a distribution is a team effort that requires a large and diverse team, regardless of how you approach it. So, the next time you hear someone say, “We can just build our own distro, everyone does it, it’s not difficult,” remember to be skeptical about it because it’s more challenging than you might imagine.
Stay tuned to the Open Source Blog and follow us on Twitter for more deep dives into the world of open source contributing.
