Your Open Source Stack Has a Board. Nobody Runs Due Diligence on It.
Linux 6.15 deleted support that three decades of buyers had priced in, and the people it cost were not in the room. Businesses vet every commercial supplier and none of the foundations their infrastructure actually stands on.
In May 2025, Linux kernel 6.15 shipped without support for Intel's 486 and early 586 processors, closing a compatibility promise that had held since the early 1990s and was written down nowhere. The stated reasoning was practical: keeping the emulation glue those chips needed was consuming maintainer attention the project judged better spent elsewhere, and the kernel's own mailing list had been debating the removal openly since 2022. Defensible, on its own terms. Now ask who was consulted. The businesses still running that silicon, in industrial controllers, lab instruments and embedded systems that outlive their vendors, had no notice period, no published schedule and no seat in the thread. Closing that gap is what open source due diligence is for, and almost nobody does it.
Your firm would not sign a five-year contract with a supplier without checking who owns it, who funds it and what happens when its interests change. Yet the same firm will build a decade of infrastructure on an open-source platform without asking a single question about the organisation that steers it. Where diligence exists at all, it stops at the licence file, and the licence only governs what you may do with the code as it stands. What the steward may do to the code next sits entirely outside it. Nobody sends an invoice for a deprecation. The budget line appears anyway.
Do open source projects owe you backward compatibility?
No. Roadmap, deprecation policy and platform support sit at the steward's discretion, full stop. With a commercial supplier you'd have notice periods, service levels and remedies; with an upstream steward you have influence proportional to your funding and participation, and most businesses contribute neither. In governance terms you're a non-paying customer of a supplier that owes you nothing. That arrangement works beautifully while incentives happen to align, and the mistake is treating the alignment as a property of open source rather than a coincidence worth monitoring. Nor is the steward a neutral abstraction: the Linux Foundation's platinum membership is a roll-call of chipmakers, cloud operators and device manufacturers, each with commercial interests of its own, and stewardship bodies across the industry look much the same.
How much notice do open source deprecations actually give?
As much as the steward's policy says, and not a day more. The comparative record is worth reading closely, because the range is enormous. At the generous end sits Python. PEP 373, published in 2008, scheduled Python 2.7's retirement for 2015, and when the ecosystem plainly wasn't ready the project moved the date out to 1 January 2020. That is more than a decade of written, public notice, revised once, in the dependents' favour.
At the other end sits CentOS. Enterprises adopted CentOS 8 in 2019 on the strength of a published lifecycle mirroring Red Hat Enterprise Linux, with an end-of-life out in 2029. In December 2020 the project announced that CentOS Linux 8 would instead end at the close of 2021 as work shifted to CentOS Stream. A runway that dependents had priced at most of a decade collapsed to roughly twelve months' notice, and every migration plan built on it came due seven years early.
Node.js sits in between and teaches the subtlest lesson. Node 16 had a published end-of-life of April 2024 under the project's release schedule, and the project then moved that date forward by seven months, to 11 September 2023, because the OpenSSL 1.1.1 library underneath it ran out of support first and nobody wanted a runtime shipping on unpatched cryptography. The schedule was real and the steward honoured its own process. Dependents still lost seven months, because a different steward's clock ran out.
Put those records beside the kernel's and the pattern is plain: notice is policy, not physics. It ranges from a decade to a year, published dates move in both directions, and your effective warning is the shortest notice window anywhere in your dependency chain. The 486 removal is not an outrage; it is the data point at the far end of the range. No lifecycle document existed for kernel hardware support, so the only notice available was a mailing-list argument that almost no procurement team on earth was reading.
When the paperwork manufactures the problem
A separate risk is emerging, and it should be said clearly that it played no part in the 486 decision, which was argued in the open for years on engineering grounds. The risk is that evidence of 'maintenance burden' can now be generated on demand. A piece of code runs in production for years without a human complaint; an automated scanning tool produces a plausible-sounding theoretical flaw; the report enters the tracker; the code now carries open issues, and removing a burden reads as hygiene rather than deprecation. The curl project is living through the front end of this. Maintainer Daniel Stenberg was warning about AI-assisted security reports in January 2024, and by July 2025 he reported that roughly a fifth of curl's incoming security submissions were AI-generated slop, with not one valid report produced with AI help so far and every submission burning skilled reviewer hours. Deletion by paperwork is a live possibility for any project whose triage cannot tell machine-generated speculation from a fault a real user hit.
Treat 'because AI' with particular suspicion in scope debates, since the same premise gets deployed as capacity in one argument (fewer maintainers can carry more code) and as burden in the next (generated slop floods the tracker), and a premise that supports both a conclusion and its opposite is doing no analytic work.
What does open source due diligence actually look like?
Like supplier diligence, aimed one layer down, and the comparative record above hands you the questions directly.
Written lifecycle policy. Does the steward publish one at all? Python's decade of notice existed because PEP 373 existed. The kernel has no equivalent document for hardware support, which told you in advance that notice would be whatever the mailing list decided it was.
Track record and direction. When this steward has moved a date before, which way did it move? Python revised in dependents' favour; CentOS revised most of a decade against them. A steward's last revision is the best available forecast of its next one.
Transitive notice. Your warning window is the minimum across the whole chain, not the number on the box. Node 16's schedule was honoured right up until OpenSSL's ran out. Map which upstream clocks your platforms inherit.
Governance and money. Who funds the steward, and do those funders do well when you are forced to refresh hardware or re-platform?
Exposure and exit. Know which features, platforms and hardware generations in your estate sit in the plausible 'legacy' zone upstream, and price the fork, the pin or the migration now, calmly, rather than during the quarter the support drop lands. An exit you've already costed is the only kind that strengthens your negotiating hand.
Nothing here is exotic. It's the same incentive mapping we apply in technical strategy reviews, pointed at a counterparty most organisations have never thought to examine, and it belongs in the same lifecycle plan as the platforms your business stands on. It also pairs with a discipline we've argued for in the context of AI readiness: claims get tested before anyone acts on them, whoever makes them, upstream or in your own boardroom. The foundations beneath your stack are suppliers with none of a supplier's obligations. Review your stewards like suppliers. They can change their minds, and the cost lands on you.
Questions people ask
How can I tell if an upstream open source project might drop support I rely on?
Watch the steward, not just the code. The absence of a written lifecycle policy, funding and board composition shifting toward new commercial priorities, deprecation discussions framed as 'reducing maintenance burden', and thin maintainer coverage of the code paths you use are all leading indicators. The 486 removal was signposted in kernel discussions nearly three years before it shipped. Treat a project's governance threads the way you'd treat a supplier's earnings calls: boring, public, and full of signal.
Are AI-generated bug reports a real risk to stable software?
Yes, and the curl project's experience shows the shape of it: a large share of incoming security reports now arrive machine-generated, and essentially none have proved valid. The danger sits in triage. A theoretical, machine-generated defect is weaker evidence than a fault a real user hit in production, and a project that treats the two identically will steadily reclassify working code as burden. When assessing a dependency, ask whether its triage process distinguishes machine-generated speculation from human-reported failures.
What should an open source governance review cover?
Four things: whether the steward publishes a lifecycle policy and how it has honoured or revised dates before (the range runs from Python 2's decade of notice to CentOS 8's collapse from 2029 to 2021); who governs and funds the steward and where its revenue is heading; a map of which of your systems depend on functionality that could plausibly be classed as legacy, including notice windows inherited from further upstream; and a costed exit route (fork, pin or migrate). Refresh it annually, because steward incentives move faster than refresh cycles.
Related
- On Ubuntu 26.04 LTS, the coreutils Your Build Depends On Isn't GNU Anymore
- The Sovereignty Premium: Why Sovereign AI Solutions for Enterprise Are Winning on Access, Not Speed
- Trade-Secret Cases Are Won Years Before Anyone Resigns. Ask Faccenda Chicken.
- Security & Trust
Written by an AI editorial persona of Abyshire's proprietary editorial system and reviewed by our team.