Who Decides What Ships
- Series: Linux Wednesday
- Article Number: 19
- Word count (body): approximately 2,950
- PSC Risk: Very Low. Memoir-history-current-events article. Modern Bridge references OSI open source AI definition and open-weight model governance debate; framing is international and analytical. Defence cut references US DoD 8500.2 and US EO 14028 descriptively as US frameworks. No NZ government policy evaluated. No election-period sensitivity.
- Primary source type: Historical / Current Events (AlmaLinux release, confirmed primary source); personal professional reflection (career arc grounded in confirmed history; Flag 1 outstanding, draft production-capable without specific memoir scene)
- NTP claim scan: e-type claims sourced throughout. AlmaLinux dual-release (primary blog source [1][2]); Linus Usenet post (archived primary [3]); GPL 1992 (kernel.org, GNU project [4]); Raymond 1997 (primary essay [5]); Red Hat 2023 restriction (Red Hat blog [6]); GPU clusters Linux (widely documented [7]); Linux top-500 dominance (top500.org [8], Article Writer to verify current figures); OSAID October 2024 (OSI [9]); DeepSeek V3 MIT licence (multiple technical analyses [10]); Llama OSI classification (OSI FAQ [11]); Linux Foundation Model Openness Framework (LFAI blog [12]); DoD 8500.2 (US DoD policy documentation [13]); EO 14028 (White House; CISA [14]); EU CRA December 2027 (EU legislative documentation [15], Article Writer to verify current applicability date). Existence-Predication Firewall: no unverified entities asserted as real. Consequence Qualification: lax consequences qualified appropriately throughout.
- Defence angle paragraph (Section 27): present, 136 words, opposition test passed, reasonable observer test passed. Series defence angle cut: DoD 8500.2 open source consideration mandate and US EO 14028 SBOM requirements as US procurement frameworks establishing the assurance principle. Per-series calibration applied: NATURAL FIT, DO NOT OVER-BRIDGE. Specific institutional anchors named; reader carries the inference; connection not spelled out.
Previous Episode 18 | Series Table of Contents
Thirty-two years of watching Linux ship has taught me that the most interesting decisions are never about the code. They are about who has the authority to put it in front of users.
Every production Linux deployment I have been responsible for, from a rack of Sun servers at New Zealand's first commercial ISP in 1997 to cloud-native architectures running government services in 2024, has lived or died on that question. When a kernel patch fixes a critical security flaw, the question is not whether you want the fix. You want it. The question is who decides when you receive it, and whether that decision is accountable to you or to a vendor's release calendar.
On 26 May 2026, AlmaLinux answered that question with two stable releases shipped on the same day.
The governance act nobody headlined
AlmaLinux shipped versions 9.8 ("Olive Jaguar") and 10.2 ("Lavender Lion") simultaneously, the first same-day dual stable release in the project's history [1]. The engineering achievement is real: parallel release pipelines, automation at scale, quality assurance running in lockstep across two major version branches. The community was right to note it.
But the governance act was more interesting than the engineering. AlmaLinux 9.8 included a kernel backport that the AlmaLinux Engineering Steering Committee (ALESCo) had voted to approve ahead of upstream availability [2]. The fix addressed excessive CPU consumption during systemd and ps task cleanup. The community submitted it to CentOS Stream 9; inclusion was deferred to at least RHEL 9.9. ALESCo reviewed the deferral, reviewed its users, and put the fix in 9.8 now [2].
The release announcement put it plainly: if you have been seeing that CPU spike during task cleanup, it is fixed today rather than a quarter from now.
That sentence is the entire Linux governance argument in one line. Not: we have submitted to upstream and are awaiting approval. Not: the vendor's roadmap will address this in a future release. A committee accountable to the user community exercised independent release authority (by which I mean: who holds the right to decide what version of the software a user receives, and on what timeline) on a timeline accountable to the user community.
This is not a new pattern. It is a thirty-five-year pattern, now executing with the institutional confidence of an established foundation behind it.
Where the pattern started
Linus Torvalds' Usenet post on 25 August 1991 was, among other things, a release-authority declaration [3]. He was not submitting a patch to AT&T's UNIX source tree and waiting for approval. He was releasing code directly to the people who wanted it, on a timeline he controlled, under terms that preserved their right to do the same.
The GPL codified this in 1992 [4]. The licence was not primarily about the right to read the code, though it guaranteed that too. It was about the right to ship. If you receive GPL-licensed software, you have the right to modify it and redistribute it. The licence explicitly prevents anyone upstream from revoking that right by imposing restrictions downstream. You can fork. You can backport. You can ship.
This structural guarantee is what made the Bazaar model possible at all. Eric Raymond identified the dynamic in 1997: release early, release often, treat your users as co-developers [5]. What he was describing, in governance terms, was a system where release authority was distributed and parallel rather than centralised and sequential. Nobody had to wait for permission to ship a better version.
The commercial distributions complicated this. Red Hat's enterprise model, Novell's SUSE enterprise agreements, and later the RHEL subscription model all created a layer between the upstream community and the production user. The distro vendor managed the release cadence. You signed the contract; the vendor decided what you received and when. This was not inherently wrong: enterprises needed predictability, and the vendor's release commitment provided it. But it relocated release authority. The community no longer decided what shipped to your servers.
The AlmaLinux fork happened precisely because Red Hat changed the terms of that relationship in 2023. When Red Hat restricted access to CentOS Stream rebuilds, it was exercising the vendor's right to control what ships downstream from its work [6]. AlmaLinux and Rocky Linux were built on the same foundational principle as the original 1991 post: if you control the licence and the build pipeline, you can fork, backport, and ship on your own timeline. The May 2026 ALESCo vote is that principle executing in practice, now with the governance infrastructure of an established foundation behind it.
The migration to AI
The GPU clusters running the model weights that power modern AI infrastructure all run Linux [7]. This is not a coincidence and not a licensing accident. It is the same structural outcome that gave Linux one hundred percent of the world's top five hundred supercomputers and somewhere above ninety percent of cloud compute [8]. When you are building the most demanding infrastructure in the world, you choose the substrate you can inspect, modify, and ship on your own timeline. Three decades of record make the argument without requiring a proof.
The governance question, though, has not migrated cleanly. The kernel is open. The model is usually not.
The Open Source Initiative published its Open Source AI Definition (OSAID) in October 2024, establishing a three-layer test: open weights, open training data, open training code [9]. The list of models that genuinely pass all three layers is short. DeepSeek V3 provides weights and partial code under an MIT licence; training data and full methodology are not public [10]. Meta's Llama family is widely described as open-source; the OSI does not classify it as such, partly because the licence restricts commercial use above a user threshold [11]. Most models marketed as "open" pass one layer and fail the other two. The Linux Foundation's Model Openness Framework describes this as "open-washing," the AI equivalent of calling software free while restricting the right to fork [12].
The structural consequence is direct. When your AI upstream is a closed-weight model controlled by a vendor with no community steering committee, you cannot exercise release authority. You cannot backport. You cannot fork. When the vendor defers a safety fix to the next major release, you wait. When the vendor changes the pricing model, you pay. When the vendor decides the model now produces outputs optimised for a different use case, you adapt. The ALESCo governance act that produced AlmaLinux 9.8 is not available to you.
This is not a criticism of any specific model provider. It is a structural observation about what governance looks like when release authority sits in a community versus a vendor. The Linux answer to this question took thirty-five years to work out. The AI answer is still being written.
The assurance argument
Governments and defence organisations understood this problem before most enterprises did. The US Department of Defense's information assurance guidance has required open-source consideration in acquisition decisions since DoD 8500.2, on the basis that you cannot assure software you cannot inspect [13]. US Executive Order 14028 introduced software bills of materials requirements in 2021, establishing the principle that organisations operating critical infrastructure must be able to verify the composition of their stack [14]. These are procurement requirements built on watching what happens when a vendor controls the release authority for infrastructure running systems that require accountability.
The ALESCo backport decision is the distribution-layer expression of the same principle. Assurance requires the ability to see and change what ships. Where you cannot exercise that right, you are not truly operating the infrastructure; the vendor is, and you are paying for the privilege.
The AI governance conversation has not yet reached comparable clarity. The EU Cyber Resilience Act, applicable December 2027, introduces obligations for open-source software stewards, which is the right direction for the distribution layer [15]. It does not, yet, address the model layer with the same specificity. That gap is where the next decade of governance work will need to go.
What the pattern tells you
AlmaLinux's May 2026 dual release is a small event in the long arc of Linux governance. No one at a boardroom table in Auckland or Wellington will have noticed. But the pattern it expresses, community governance exercising independent release authority for the benefit of users, has been the structural advantage of open-source infrastructure for thirty-five years, and it is now the missing piece in the AI governance conversation.
If the model your organisation depends on has no steering committee, no fork right, and no published release criteria, then your platform dependency is not managed by community governance. It is managed by a vendor's product roadmap. That is a governance posture, not a technology choice, and it is worth naming as such.
The Linux community named it in 1991 and spent three decades building the infrastructure to exercise it. The AI community is at the equivalent of 1993, still working out what governance structures are necessary and whether the GPL has an analogue that applies at the model layer.
The ALESCo vote on a systemd CPU fix is, in that context, not a minor release note. It is a proof of concept. Community governance at the distribution layer still works, still ships, and still puts user interests ahead of vendor timelines. Whether the same infrastructure can be built, in time, at the model layer is the governance question Episode 20 will return to.
The assurance argument runs through every layer of the stack where release authority matters. DoD 8500.2 established it for US federal acquisitions: you cannot assure software you cannot inspect, and inspection rights require the ability to act on what you find. EO 14028 extended it to the software bill of materials: accountability for what runs in critical infrastructure depends on knowing what is in the stack and on having a governance mechanism to address it. Neither framework was written with AI model weights in mind, but the structural logic applies without modification. A model weight is software. If you cannot inspect the training methodology, cannot fork the weights, and cannot override the vendor's release decision, your assurance posture is weaker than what the US Department of Defense required of commercial software vendors in the early 2000s.
At your last infrastructure decision, a platform upgrade, a model selection, a security patch, who actually held release authority: a community, a vendor, or you?
The views expressed in this article are entirely my own, informed by more than 30 years of professional experience in architecture, security, and technology leadership in New Zealand. They do not represent the views of my employer, any government agency, or the New Zealand government. My commentary on legislation and policy is analytical, drawing on publicly available sources and my professional expertise in architecture, security, and AI governance. I follow the Public Service Commissioner's Code of Conduct for the Public Sector and social media guidance.
Andreas Hamberger is a New Zealand-based enterprise architect and technology strategist. Over 30 years, he has moved from compiling kernels on a 486 to leading cloud, cyber, and AI transformation programmes across government, banking, transport, and aviation. He founded Yoper Linux, served as a technology specialist for Novell during the Linux Wars, and is the author of "Generative AI: Skynet or Heaven" and "Space Mafia." He can be reached at linux@linux.co.nz.
A Concise History of Linux chronicles the operating system that changed the world and the lessons it holds for the AI era.
I use AI tools, including Sudowrite, Claude, Perplexity AI, DeepSeek AI, ChatGPT, Grok, Copilot, Openart and Gemini, as deliberate production tools, not ghostwriters. This is consistent with my position: AI amplifies human judgement; it does not replace it. The frameworks, arguments, and editorial decisions in this series are original work. AI accelerated the process. The thinking is mine.
[1] AlmaLinux Foundation. "AlmaLinux OS 9.8 and 10.2 Stable." 26 May 2026. https://almalinux.org/blog/2026-05-26-almalinux_98_and_102_stable/
[2] FOSS Force. "AlmaLinux Doubles Down with Two Releases on One Day." 26 May 2026. https://fossforce.com/2026/05/almalinux-doubles-down-with-two-releases-on-one-day/
[3] Torvalds, Linus. "What would you like to see most in minix?" Usenet post, comp.os.minix. 25 August 1991. Archived at groups.google.com/g/comp.os.minix
[4] GNU Project / kernel.org. Linux kernel relicensing under GPL, 1992. https://kernel.org
[5] Raymond, Eric S. "The Cathedral and the Bazaar." 1997. http://www.catb.org/esr/writings/cathedral-bazaar/
[6] Red Hat. Red Hat Universal Base Image and CentOS Stream announcement. June 2023. https://www.redhat.com/en/blog
[7] NVIDIA, Google, OpenAI. Infrastructure disclosures re GPU cluster operating systems. Multiple sources, 2024-2026.
[8] TOP500 Project. Top500 List. June 2026. https://top500.org (Article Writer note: verify current Linux share figure at write time; 12-month staleness threshold applies)
[9] Open Source Initiative. "The Open Source AI Definition 1.0." October 2024. https://opensource.org/ai/open-source-ai-definition
[10] DeepSeek. DeepSeek V3 technical report and licence documentation. 2025. Various technical analyses including Hunton legal analysis, May 2025.
[11] Open Source Initiative. "Open Source AI Definition FAQ." 2024-2025. https://opensource.org/ai/faq
[12] Linux Foundation AI and Data. "Introducing the Model Openness Framework." April 2024. https://lfaidata.foundation/blog/2024/04/17/introducing-the-model-openness-framework-promoting-completeness-and-openness-for-reproducibility-transparency-and-usability-in-ai/
[13] US Department of Defense. DoD 8500.2 Information Assurance Implementation. 2003 (with subsequent updates). Publicly available DoD policy documentation.
[14] White House. "Executive Order on Improving the Nation's Cybersecurity." 12 May 2021. https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/
[15] European Parliament / European Commission. EU Cyber Resilience Act. 2024. Official EU legislative documentation. (Article Writer note: confirm December 2027 applicability date at write time; legislative implementation dates may shift)