What Works Today Should Work Tomorrow: notes from a 23-year codebase
What the right to repair means in open-source, and how to keep it actually working over time.
Right to repair is usually a hardware story, but open-source infrastructure faces its own version: the discipline of keeping software actually working over decades. NetXMS started in 2003 and still runs on AIX, Solaris, older RHEL, Windows 7 kiosks, and a long tail of 32-bit ARM, FreeBSD, OpenBSD, and Alpine — users who didn't choose to be a long tail, but chose stability. For them, the contract is that the agent we shipped in February 2009 still talks to the server we shipped last week, and old config files still parse. This talk walks through three war stories from the last year — a 32-bit ARM crash from format-string mismatches, a 14-year-old GTK bug in SWT fixed upstream, and a Mastodon thread that unlocked Solaris SPARC for our Jenkins agents — and five concrete layers of backward compatibility we maintain in code. I'll close with what this approach costs, what it gains, and why software right to repair is inseparable from who we expect to be there when other things break.
On 30 March 2026 at 18:55, I wrote to my boss: "Server crashes every second build on 32-bit ARM. Caught it under gdb but I don't yet understand." At 20:39 the same evening I committed the fix: fifteen format-string changes in one file. A %u specifier with a uint64_t argument — harmless on 64-bit by design (every variadic argument occupies the same 8-byte slot, so the truncation doesn't shift the next argument's offset) but fatal on 32-bit ARM, where a uint64_t needs two slots and %u reads one, the offset shifts, and you end up calling wcslen(NULL). The kind of bug that only surfaces if you still build for 32-bit ARM in 2026, on a project that started in 2003.
Right to repair is usually a hardware story — schematics, parts, the right to open your toaster, or, in the European citizens' initiative now past first review, the right not to lose a video game when its servers go dark. Open-source can't be killed by decree: even if a team folds, the code survives, and someone else can keep it running. What stays harder is keeping it actually working over time.
That's the obligation I want to talk about. Banks and industrial systems running NetXMS on AIX or Solaris — specialist Unix platforms that never had a clean migration path. Customers still on older RHEL because the cost of moving is too high. Service kiosks frozen on Windows 7, bound to custom hardware that can't be re-certified. Plus a smaller open-source segment on 32-bit ARM, FreeBSD, OpenBSD, Alpine. They didn't choose to be a long tail — they chose stability. Right to repair, for them, means what's working today should keep working tomorrow, even after the rest of the industry has moved on.
This talk is about the discipline of holding that promise. Not by refusing to deprecate — we do that often, just carefully. By keeping the contract: the agent build from February 2009 — still downloadable from our public release archive — still talks to the server we shipped last week. Old configuration files still parse, including the export/import format that switched from XML to JSON last year — both readers ship side by side. The contract even survives our own deprecations: the HP-UX agent we last shipped in 2021 still talks to today's server, though we stopped building new HP-UX agents in 2022 after HPE wound the platform itself down. Old hardware in someone's bank doesn't go dark just because we move the build matrix forward.
I'll walk through three war stories from the last year — the ARM32 crash above, a 14-year-old GTK bug in SWT fixed through upstream collaboration, and a Mastodon thread with Peter Tribble (Tribblix) and Olaf Bohlen that pointed us to the community-built OpenJDK we needed to update our Jenkins agents on Solaris SPARC. I'll show five concrete layers of backward compatibility we maintain in code — NXCP wire protocol, database schema, configuration files, NXSL scripting, and the parallel XML and JSON parsers for export-import. I'll close with what this approach costs, what it gains, and why software right to repair is inseparable from who we expect to be there when other things break.
If you maintain or depend on infrastructure software that has to last — this talk is for you.
