Same Fight, Different Language

HOST: Welcome back to Stake and Rope, from Goat Security. Today: the Python steering council has asked for development on the experimental JIT compiler to be suspended from the main branch, pending a new PEP, with a six-month deadline before the code gets removed entirely. The JIT was already in the Python 3.15 release notes, showing an eight-to-nine percent performance improvement, with full release expected in October. The Register wrote it up this week. The steering council’s position is that proper process wasn’t followed. The JIT team’s position is that the code is already merged and working. On the panel: the Legacy Sysadmin, who has watched open-source governance eat its own children for thirty years; the DBA, who has questions about what “proper process” means when the code is already in main; and the Founder, who I assume will defend the steering council as a paragon of mature community stewardship. Goat Farmer’s here too. Legacy, what does this remind you of?

LEGACY SYSADMIN: [sighs] All of it. Pick a decade. Perl 6 was announced in 2000 and shipped as Raku in 2019 because the committee couldn’t decide what it was. Python 2 to 3 took fifteen years to migrate because the steering structure didn’t enforce a sunset. systemd shipped because Lennart stopped asking. OpenSSL almost died because the foundation was three people and a Patreon. The pattern is always the same. The code works, somebody on a council decides the process didn’t work, and the code gets held hostage to a document nobody wants to write.

FOUNDER: Okay but hold on. This is actually healthy. This is exactly what mature open-source governance looks like, tbh. You have a steering council exercising oversight on a major architectural change. That’s the system working.

THE DBA: The code is in main.

FOUNDER: Right, and that’s the question — should it have been? PEP 744 is informational. There are open questions about maintenance, about success metrics, about third-party JIT compatibility. These are real concerns.

THE DBA: Who wrote the eight percent benchmark.

FOUNDER: What?

THE DBA: Who ran the benchmark. The release notes say eight-to-nine percent geometric mean improvement on x86 Linux. Somebody ran that. Somebody wrote it down. Somebody put it in the release notes. The release notes are public. The release is in October. What part of that process didn’t happen.

FOUNDER: I think the steering council’s point is more about the governance process —

THE DBA: The governance process is supposed to produce working code. The code works. That’s what the benchmark says.

HOST: Legacy, you’ve seen this specific pattern — a council pulling back on something that’s already shipped. What usually happens?

LEGACY SYSADMIN: Two things. Either the team writes the PEP under duress in three months, the council finds it inadequate, and another six months goes by while they bicker about success metrics. Or the team loses momentum, the contributors drift off to other projects, and in eighteen months somebody writes a blog post asking whatever happened to the Python JIT. I’ve seen both. I’ve seen the second one more.

GOAT FARMER: I don’t miss that.

HOST: Founder, you said this is the system working. The JIT contributor — Mark Shannon — said a moratorium risks losing the contributors they just gained. Is that the system working?

FOUNDER: I mean, look, contributor churn is a real concern, but I’d push back on the framing here. The steering council isn’t saying no. They’re saying show your work. That’s a feature, not a bug. If you can’t articulate the success metrics for a JIT compiler, maybe you shouldn’t be merging it into main.

THE DBA: [scoffs] The success metric is eight percent.

FOUNDER: That’s one metric.

THE DBA: It’s the metric that matters. You’re shipping a JIT. The JIT is faster than the interpreter. By eight percent. On the platform most people run. That’s the metric. What’s the other one.

FOUNDER: Maintenance burden. Code complexity. Compatibility with —

THE DBA: Have you ever shipped code under committee review?

FOUNDER: I’ve — I mean, our seed round had a technical advisory board —

THE DBA: That’s not the same thing.

FOUNDER: It’s adjacent.

THE DBA: It’s not.

HOST: Let me push on something. Pablo Galindo Salgado on the council said, quote, “we have not been as strict about following the process as a change of this complexity and reach deserves.” That’s the council admitting they let it through. The code didn’t sneak in. The council approved the merges and is now saying they shouldn’t have. Legacy, who owns that mistake?

LEGACY SYSADMIN: Nobody, in practice. That’s the magic of committees. The council that approved it last year isn’t the council saying it shouldn’t have been approved. Memberships rotate. Positions shift. The institutional memory is a Discourse thread. So the team that did the work gets punished for the council’s earlier decision, and the council that’s currently sitting gets to look responsible by reversing it. I watched Perl 6 die from this exact pattern. Larry Wall didn’t kill Perl 6. The community process did.

FOUNDER: I don’t think that’s a fair —

LEGACY SYSADMIN: I’m not saying it’s fair. I’m saying it’s what happens. Pablo Galindo Salgado is a serious Python contributor. He’s also on a council. Those are different roles. He’s doing the council role.

GOAT FARMER: Had that one in ‘04.

HOST: DBA, what does “proper process” mean to you in this context?

THE DBA: [exhales] It means whatever the people saying it need it to mean at the moment they’re saying it. If the code worked and shipped, the process was fine. If the code worked and they want to kill it, the process is the lever. Process is what you reach for when you can’t argue the technical merits. I’ve watched architects do this for twenty years at the enterprise. Somebody doesn’t want the work to happen, they don’t say “I don’t want the work to happen.” They say “we need to align on the governance framework.” Same move.

FOUNDER: That’s pretty cynical.

THE DBA: It’s accurate. Read the announcement. The council says they want a PEP. Then they say — and this is in the article — they want “a JIT infrastructure that can support multiple implementation strategies.” That’s not asking for a PEP. That’s asking for a different project. They already know what they want. The PEP is the path they’re making the team walk to get there.

HOST: Hold on, Founder, you defended this as oversight. Did you read the part where they say they want a different architecture?

FOUNDER: I — that’s a fair point. I think there’s room to interpret —

THE DBA: There’s not. It’s in the announcement.

HOST: Let me take a step back here. Legacy, you mentioned Perl 6 and Python 2 to 3. Walk through one of those for a minute. What did the failure look like in slow motion?

LEGACY SYSADMIN: [pause] Perl 6, the cleanest example. Larry announced it at the 2000 conference. The idea was a bigger, better Perl. The community had opinions. The committee had opinions. Different opinions. The implementation got handed around — Parrot, Pugs, Rakudo — because the spec kept changing because the committee kept changing what it was. By 2008, Perl 5 had stopped getting serious investment because Perl 6 was supposedly coming. By 2015, Perl 5 users had moved to Python and Ruby. By the time Raku shipped in 2019, the audience was gone. Nineteen years. The technical work was real. People did good work on it. But the process killed the moment, and once the moment is dead, the work doesn’t matter. Python 3 nearly went the same way. The only reason it didn’t is Guido eventually said “we’re cutting Python 2 off, deal with it.” He had standing to do that. The current council doesn’t have a Guido.

FOUNDER: That’s actually a really important point — about needing someone with standing to make the call.

LEGACY SYSADMIN: That’s not the point I made.

FOUNDER: Right, but the takeaway is that the council is trying to be the standing authority here. That’s the system maturing.

LEGACY SYSADMIN: The standing authority told the team to stop. Six months from now they’ll tell them to start over. That’s not maturity. That’s the same problem dressed up.

HOST: Founder, have you ever worked on a project that went through formal review and survived it?

FOUNDER: I mean, we did SOC 2.

THE DBA: [snorts] ha

FOUNDER: What.

THE DBA: SOC 2 isn’t review. SOC 2 is paperwork.

FOUNDER: It’s both, actually.

THE DBA: It’s paperwork. The auditor doesn’t read your code. They read your policies. The policies say you have review. Whether you have review is a separate question. You’re conflating two things.

FOUNDER: Okay, fair. But I think the broader point — that structured process is a feature for serious projects — still stands.

THE DBA: Sure. Show me one.

FOUNDER: One what?

THE DBA: One project where the structured process improved the code. Not the documentation. The code.

FOUNDER: [chuckles] I mean — Linux kernel, obviously.

LEGACY SYSADMIN: Linus runs the Linux kernel like a benevolent dictator with a mailing list. That’s not a committee. That’s a person with a temper and a final say.

THE DBA: That’s the answer. Every functioning open-source project I’ve ever used has had one person who could say no and mean it. Postgres has a small core team that acts like one person. SQLite is Hipp. Redis was antirez until it wasn’t, and the second the committee took over, the license drama started. The committee isn’t the structure that ships code. The committee is the structure that manages people who ship code. When the committee starts trying to ship the code itself, you get this.

HOST: Goat Farmer, you’ve been quiet.

GOAT FARMER:

Reason number 81. No goat analysis meetings.

GOAT FARMER: Followed by reason number 82. No goat control meetings. And 83. No meetings. I wrote those three together. They came out together.

HOST: Legacy, the JIT team has asked for a one-to-two month grace period to keep working while they draft the PEP. Council says they’re, quote, “not unreasonable.” Reasonable prediction — how does this play out?

LEGACY SYSADMIN: The grace period gets granted, informally. The PEP draft circulates in August. Two council members like it. One doesn’t. The one who doesn’t wants the multi-strategy infrastructure they mentioned in the announcement. Discussion thread hits two hundred replies by September. October release ships with the JIT still in main but flagged more aggressively as experimental. The JIT team writes a tired post in November about contributor burnout. Two of the four new contributors drift off by January. By next June, the JIT is either removed or grandfathered in a state nobody’s happy with. None of this is malicious. Everyone involved is acting in good faith. That’s what makes it work the way it does.

FOUNDER: That’s an awfully specific prediction.

LEGACY SYSADMIN: I’ve watched it before.

HOST: DBA, anything you’d add to that prediction?

THE DBA: No. He’s right. The only thing I’d add is that the eight percent stays eight percent the whole time. The benchmark doesn’t go away because the committee is arguing. The code works whether or not the PEP gets approved. That’s the part that’s hard to watch.

HOST: All right, let’s land it. Closing thoughts. Goat Farmer first.

GOAT FARMER:

Reason number 25. You don’t need to call a staff meeting to make sure everyone’s milking goats the same way.

GOAT FARMER: That’s the whole thing. The milking happens or it doesn’t. If it happens, you don’t need the meeting. If it doesn’t, the meeting won’t fix it.

HOST: Founder.

FOUNDER: Look, I hear the panel. I do. But I want to push back on the cynicism here, because I think there’s a real story about transparency and community process that’s getting lost. The Python steering council is doing this in public. On Discourse. With named members taking positions. That’s the model. That’s what mature governance looks like, and frankly, it’s a moat for Python as a language. Companies pick languages partly based on stewardship. The fact that there’s a council that can say “wait, slow down” — that’s a feature for enterprise adoption. I’m going to write this up. There’s a thread in here about how open-source governance is becoming a competitive differentiator.

HOST: Legacy.

LEGACY SYSADMIN: [sighs] I’ve been doing this long enough to have watched the same fight play out under four different banners. The names change. Perl, Python, OpenSSL, Node, even back to the GNU-versus-BSD arguments in the early nineties about how a free software project should be governed. The fight is always the same. Somebody does the work. Somebody else wants to make sure the work is being done correctly. Both sides are right, in a narrow technical sense. The work usually was a little sloppy on process. The process people usually do have a point. [pause] But the work shipped, and the process didn’t. That’s the part that doesn’t change. Thirty years from now somebody will write the same article about a Rust feature, and a council will say proper process wasn’t followed, and the contributors will drift away to whatever language is next. The code keeps working. The committees keep meeting. They’re separate streams. Don’t confuse them.

HOST: DBA, you’ve got the last word.

THE DBA: The JIT compiler ships in October. It’s eight percent faster. It’s gated behind an environment variable. The user has to opt in. There is no scenario in which this code hurts anyone who doesn’t ask for it. The steering council knows that. They also know the work is done. What they’re doing is not protecting Python users. It’s exercising authority because authority unexercised feels like authority lost. I’ve watched architects do this for thirty years. The team that wrote the code is going to spend the next six months writing about the code instead of improving it. At the end of those six months, the council will decide whether the writing was good enough. Whether the code was good enough was never the question. That’s the part to remember.

HOST: The work shipped. The process didn’t. Same fight, different language. We’ll see you next time.