Език: English
Open Source is widely regarded as a foundation of digital sovereignty, but an open license and access to the code don’t make your infrastructure sovereign. If critical components are only maintained and understood by a small team of developers, then all you’ve achieved is to replace dependency on a company with a dependency on a few developers.
The infrastructure of Linux distributions illustrates this effect particularly well. It has evolved over decades and is highly specialized for its task: building a Linux distribution. Some of the complexity is essential: building and maintaining an operating system is difficult. But parts of the complexity is accidental and has accumulated by decade-long usage of project-specific packaging conventions, workflows and tools that are rarely encountered outside distribution development. The outcome is a high barrier to entry: what is muscle memory for a seasoned maintainer, becomes a steep wall for a newcomer.
But is this really an onboarding and documentation problem? Based on our own experience in openSUSE and Fedora, we will illustrate the path from an interested user to an active contributor and show where they encounter hurdles and barriers on their journey. Specifically, we distinguish complexity that contributors need to understand, barriers that better onboarding could reduce, from accidental complexity that has accumulated over the past decades.
This leads to an uncomfortable question: should we keep improving old systems, or do we have to start over in some areas to make room for new workflows and ideas?
We will look at approaches that other open-source projects take and what Linux distributions can learn from them, especially where incremental improvements may no longer be enough. We do not want to attract new contributors, only to lose them shortly thereafter, but to ensure a sustainable future for the foundation of our distributions. Because having access to the source code doesn’t help if there’s no one left who can or wants to improve it.