Sunsetting Jazzband(jazzband.co)
jazzband.co
Sunsetting Jazzband
https://jazzband.co/news/2026/03/14/sunsetting-jazzband
60 comments
Jazzband maintained some incredible Django packages and tools that made it possible for me to build a system at my $JOB that would have been impossible to do on my own. It is a true tragedy of the commons situation where I was expected do more with less, and I didn't have the ability to contribute back/donate anywhere near the value that these projects provided to $JOB or myself. I did contribute personally, but it's very clear how all of this value has been extracted and used by large companies to build higher and higher walls for themselves, and none of the people that actually make any of this work get more than crumbs.
By this point, this take is old to the point of being tiresome.
People should get what the deal is with open-source maintainership at this point. They should’ve gotten it back when Jazzband started. Nothing has changed since then. If you don’t want big companies using your stuff and not pay for it, don’t publish OSS. If you have some expectation that Google is going to write you a fat check, put it in the license—even if it’s practically unenforceable, it’s loads more than what 99% of OSS projects do right now.
If people go into OSS maintainer positions expecting anything other than what has time and time again happened…it’s like that little comic of the guy poking a stick into his bike wheel spokes and falling over.
The implication that OSS maintainers get nothing for their time is also laughable. If you were doing it for the money you wouldn’t be doing it in the first place. If they actually cared about making the world a better place and wanted to volunteer their time toward it they should go donate down at the soup kitchen. The reality is not everyone is so financially focused, but that shouldn’t be mistaken for altruism. It’s more that some people get their rocks off through other means. The reality is that OSS maintainers often find that they’re more financially focused than they thought they were—the novelty of their code running at Google wears off, the novelty of microcelebrity wears off, etc—and they get tired of it.
It was an insane mistake to disdain the GPL.
Jazzband's model was interesting precisely because it tried to solve the bus factor problem by distributing maintainership across a community. The fact that it's sunsetting suggests the problem runs deeper than just individual maintainer burnout.
The real gap is that there's no natural mechanism for projects that are critical infrastructure for many companies to capture even a tiny fraction of the value they create. pip, Django, and the whole ecosystem that Jazzband helped steward are worth billions in aggregate business value. Their maintenance costs a few thousand dollars a year in volunteer time.
I don't think licensing changes alone fix this. Companies have legal teams that can route around them. What might actually work: large package registries (PyPI, npm) implementing a voluntary but strongly encouraged funding mechanism where companies self-report their usage and contribute to a foundation pool. It would need to be opt-in and friction-free, but even 10% adoption from mid-sized companies would transform the economics.
The real gap is that there's no natural mechanism for projects that are critical infrastructure for many companies to capture even a tiny fraction of the value they create. pip, Django, and the whole ecosystem that Jazzband helped steward are worth billions in aggregate business value. Their maintenance costs a few thousand dollars a year in volunteer time.
I don't think licensing changes alone fix this. Companies have legal teams that can route around them. What might actually work: large package registries (PyPI, npm) implementing a voluntary but strongly encouraged funding mechanism where companies self-report their usage and contribute to a foundation pool. It would need to be opt-in and friction-free, but even 10% adoption from mid-sized companies would transform the economics.
> Jazzband's model was interesting precisely because it tried to solve the bus factor problem by distributing maintainership across a community. The fact that it's sunsetting suggests the problem runs deeper than just individual maintainer burnout.
Indeed, but it also failed due to the same reason: a bus factor of 1 in terms of who administrates the whole thing.
Each project could have multiple maintainers, but Jazzband itself (e.g.: the infrastructure, org, etc) had a single person responsible, and this didn't scale.
I don't mean to bash on the person who took charge on this BTW, I'm merely describing the situation. I greatly appreciate the enormous effort taken during so many years!
Indeed, but it also failed due to the same reason: a bus factor of 1 in terms of who administrates the whole thing.
Each project could have multiple maintainers, but Jazzband itself (e.g.: the infrastructure, org, etc) had a single person responsible, and this didn't scale.
I don't mean to bash on the person who took charge on this BTW, I'm merely describing the situation. I greatly appreciate the enormous effort taken during so many years!
is it unrealistic to think the companies that benefit from orgs such as this could donate a fraction of a percent of their wealth to keep them going? the responsibility always seems to fall most on those with the least resources.
It seems the open-source experiment has failed. Hundreds of billion-dollar companies have been built on millions of hours of free labor, on the backs of ten thousands of now-burnt-out maintainers. Yet, apart from token gestures, these exploiting entities have never shared substantial or equitable profits back.
For the next generation of OSS, it would be wise to stand together and introduce a new licensing model: if a company builds a product using an open-source library and reaches a specific revenue threshold (e.g., $XX million), they must compensate the authors proportional to the library's footprint in their codebase and/or its execution during daily operations.
For the next generation of OSS, it would be wise to stand together and introduce a new licensing model: if a company builds a product using an open-source library and reaches a specific revenue threshold (e.g., $XX million), they must compensate the authors proportional to the library's footprint in their codebase and/or its execution during daily operations.
> It seems the open-source experiment has failed
People have been saying this since the 80s. Reality is that without open source, this industry would be tiny compared to what it is. So many times open source has enabled an entire sub industry (i.e. ISPs in the 90s, Database, SaaS in the 2010s, now AI). And most of it is someone solving a problem that was worth solving for their own use, and for whatever reason made no sense to commercialize by selling licenses.
> on the backs of ten thousands of now-burnt-out maintainers.
Money isn't the motivation for most "free" open source. If it was, the authors would release as commercial software and maybe as "source available". That someone can use open source to build businesses has been the engine for the entire industry. In other words, the thought that maintainers quitting maintaining is some problem that can be fixed if we only paid them is non-sequitur. A lot of it is that people age out, get bored with their project, or simply want to do something else. Not accepting money for maintaining open source is a good way to ensure it stays something you can walk away from and something where the people attached to the money have zero leverage.
I do think that a lot of maintainers struggle with pushy and sometimes nasty people that take the fun out of what is a "labor of love."
> exploiting entities have never shared substantial or equitable profits back.
If I want to make money, I sell commercial software, SaaS or PaaS.
> they must compensate the creators proportional to the library's footprint in their codebase and/or its execution during daily operations
One of the more interesting uses of open source is to level the playing field. For example, there was a time when database was silly expensive. Several open source products emerged that never would have been viable commercially without the long term promise of "free" and the assurance of having source code. To have a license with a cost bomb on it would just ensure that people would use another choice.
People have been saying this since the 80s. Reality is that without open source, this industry would be tiny compared to what it is. So many times open source has enabled an entire sub industry (i.e. ISPs in the 90s, Database, SaaS in the 2010s, now AI). And most of it is someone solving a problem that was worth solving for their own use, and for whatever reason made no sense to commercialize by selling licenses.
> on the backs of ten thousands of now-burnt-out maintainers.
Money isn't the motivation for most "free" open source. If it was, the authors would release as commercial software and maybe as "source available". That someone can use open source to build businesses has been the engine for the entire industry. In other words, the thought that maintainers quitting maintaining is some problem that can be fixed if we only paid them is non-sequitur. A lot of it is that people age out, get bored with their project, or simply want to do something else. Not accepting money for maintaining open source is a good way to ensure it stays something you can walk away from and something where the people attached to the money have zero leverage.
I do think that a lot of maintainers struggle with pushy and sometimes nasty people that take the fun out of what is a "labor of love."
> exploiting entities have never shared substantial or equitable profits back.
If I want to make money, I sell commercial software, SaaS or PaaS.
> they must compensate the creators proportional to the library's footprint in their codebase and/or its execution during daily operations
One of the more interesting uses of open source is to level the playing field. For example, there was a time when database was silly expensive. Several open source products emerged that never would have been viable commercially without the long term promise of "free" and the assurance of having source code. To have a license with a cost bomb on it would just ensure that people would use another choice.
we have a solution for that: GPL + commercial dual-licensing. the problem is that a) there is an entire anti-GPL crowd; although I'd just not give a shit about them, it's worth mentioning, b) who's gonna enforce the license?, c) how are you going to monetize internal use? what if your tech (e.g. a build system) is only really useful internally?
Good idea.
The MIT license and other "pushover" licenses was built in the pre-LLM era.
I don't think it is fit for purpose anymore since now maintainers are getting burnt out and most code is now being generated from OSS.
A new OSS license for the AI age must be made for newer libraries, projects and existing projects that want to change licenses.
The MIT license and other "pushover" licenses was built in the pre-LLM era.
I don't think it is fit for purpose anymore since now maintainers are getting burnt out and most code is now being generated from OSS.
A new OSS license for the AI age must be made for newer libraries, projects and existing projects that want to change licenses.
The AI companies claim that training is fair use, so no license can prevent what is happening with AIs. It would require a clarification in copyright law that AI models are considered derivative works, and that AI generated code is a derivative work of the model and the prompt. That seems unlikely to ever happen though.
What new license would you make that isn't already covered by existing ones?
This mostly just sounds like a poison pill that commercial entities wouldn't use, and if you want that you can already use AGPL.
Especially as the cost of producing code drops, the value of libraries decreases.
Especially as the cost of producing code drops, the value of libraries decreases.
> Especially as the cost of producing code drops, the value of libraries decreases.
Does it? If the cost of slop that (1) no one understands, and (2) no one can be sued for if it misbehaves drops to zero, what have we gained? A "library" is code plus reliability and accountability. (Yes, GPL disclaims liability, but that's why consultants exist.)
Does it? If the cost of slop that (1) no one understands, and (2) no one can be sued for if it misbehaves drops to zero, what have we gained? A "library" is code plus reliability and accountability. (Yes, GPL disclaims liability, but that's why consultants exist.)
Reliability is important for sure, but as you noted, there is no accountability for library maintainers.
I'm not saying all libraries will go to zero values, just that their value is decreasing.
I'm not saying all libraries will go to zero values, just that their value is decreasing.
And then you'd be getting things like Hollywood accounting, where companies will claim that the "footprint" is not that large or simply find ways to hide their usage of FOSS.
Without teeth (and the resources to initiate the bite), companies will just freeload. Any attempts to monitor will require some degree of telemetry or proprietary solutions, with the associated blowback that generates.
The only model I've seen work in reality is open core (aside from the very few projects that have been successful with patronage)
The only model I've seen work in reality is open core (aside from the very few projects that have been successful with patronage)
Keep in mind giving stuff away for free is going to be much more popular than any other price. Don't discount that these projects are popular _because_ they are OSS, and if you introduce another model then one potential outcome is that no-one with money actually uses them.
Just use the AGPL.
There are licenses like that, just don't call them open source. They're just another form of proprietary software albeit sometimes also being source available.
If you want to make money, make commercial software and sell it. It's funny to see people complain about people taking what they gave out for free, it's like having a lemonade stand with a huge sign saying "free" and being surprised people take the lemonade.
If you want to make money, make commercial software and sell it. It's funny to see people complain about people taking what they gave out for free, it's like having a lemonade stand with a huge sign saying "free" and being surprised people take the lemonade.
Especially since it's just a disguised and unenforced bait-and-switch - FREE OSS LIBRARY that DOES EVERYTHING YOU NEED for FREE!
Oh, by the way, when you use it and are dependent on it, give me big bucks.
Oh, by the way, when you use it and are dependent on it, give me big bucks.
Not big bucks. Small bucks would fix the problem.
The decision of the market seems pretty clear. We've been able to co-operate and build a software commons for decades, iterating on and improving shared infrastructure and solutions to problems common and niche. The work done for these commons, though, benefits everyone, and that's a hard sell for a profit-driven organization. So the commons are enriched with
a) volunteers
b) brief windows in which corporate decision makers are driven by ideology and good intentions, where those decisions carry momentum or license obligations (see Android, and how Google tries to claw it back)
c) corporations attempting to shape the larger landscape or commoditize their complement, see Facebook's work on React, or contributions to the Linux kernel
Of the above, only (a) or rarely and temporarily (b) are interested in collective wellbeing. Most of the labor and resources go into making moats and doing the bare minimum to keep the shared infrastructure alive.
Now companies selling LLM coding agents enter the scene, promising to eliminate their customers' dependence on the commons, and whatever minimal obligations they had to support it. Why use a standard solution when what used to be a library can now be generated on the fly and be part of your moat? Spot a security bug? Have an agent diagnose and fix it. No need to contribute to any upstream. Hell, no upstream would even accept whatever the LLM made without a bunch of cleanup and massaging to get it to conform with their style guides and standards.
Open source, free software, they're fundamentally about code. The intended audience for such code is machine and human. They're not compatible with a development cycle where craft is not a consideration and code is not meant to be read and understood. That is all to say: yes, it is unrealistic to expect companies to donate anything to the commons if they can find any other avenue. They prefer a future where computer programs are purchased by the token from model providers to one where they might have to unintentionally help out a competitor.
a) volunteers
b) brief windows in which corporate decision makers are driven by ideology and good intentions, where those decisions carry momentum or license obligations (see Android, and how Google tries to claw it back)
c) corporations attempting to shape the larger landscape or commoditize their complement, see Facebook's work on React, or contributions to the Linux kernel
Of the above, only (a) or rarely and temporarily (b) are interested in collective wellbeing. Most of the labor and resources go into making moats and doing the bare minimum to keep the shared infrastructure alive.
Now companies selling LLM coding agents enter the scene, promising to eliminate their customers' dependence on the commons, and whatever minimal obligations they had to support it. Why use a standard solution when what used to be a library can now be generated on the fly and be part of your moat? Spot a security bug? Have an agent diagnose and fix it. No need to contribute to any upstream. Hell, no upstream would even accept whatever the LLM made without a bunch of cleanup and massaging to get it to conform with their style guides and standards.
Open source, free software, they're fundamentally about code. The intended audience for such code is machine and human. They're not compatible with a development cycle where craft is not a consideration and code is not meant to be read and understood. That is all to say: yes, it is unrealistic to expect companies to donate anything to the commons if they can find any other avenue. They prefer a future where computer programs are purchased by the token from model providers to one where they might have to unintentionally help out a competitor.
> Now companies selling LLM coding agents enter the scene, promising to eliminate their customers' dependence on the commons, and whatever minimal obligations they had to support it.
This is misguided. Maintenance of LLM code has a far greater cost than generating it.
> They prefer a future where computer programs are purchased by the token from model providers to one where they might have to unintentionally help out a competitor.
I don't think that's even a thought. The thought is that "no one can tell me no".
This is misguided. Maintenance of LLM code has a far greater cost than generating it.
> They prefer a future where computer programs are purchased by the token from model providers to one where they might have to unintentionally help out a competitor.
I don't think that's even a thought. The thought is that "no one can tell me no".
> This is misguided. Maintenance of LLM code has a far greater cost than generating it.
In corporate reality they don't care. They have their product, requirement. As it starts to rot it's easier to rebuild than to maintain.
If you can ask for an LLM with a skeleton crew team now they can do it all again in five years time with the next level of LLMs.
In corporate reality they don't care. They have their product, requirement. As it starts to rot it's easier to rebuild than to maintain.
If you can ask for an LLM with a skeleton crew team now they can do it all again in five years time with the next level of LLMs.
Yes, it is precisely misguided, and will be in five years, too. Software lasts way longer than people think it does.
The longevity of code depends at least on whether it's a product or a service.
Services are what the majority of devs already work on and maintain. There's almost no incentive for anyone to use LLMs for that outside of startups. They do indeed last a long time because the code is as fundamental to the recurring revenue of the business as their legal or accounting or marketing. Devs make changes according to the evolving needs of the business, and "productivity" isn't as much of a priority as accuracy and reliability. The implementation details are very relevant to the business, especially for B2B services that need to meet compliance requirements.
Products, however, have always been disposable code written by people being thrown into a meat grinder. I don't think LLM-generated code is better, but it's probably not that much worse either.
Services are what the majority of devs already work on and maintain. There's almost no incentive for anyone to use LLMs for that outside of startups. They do indeed last a long time because the code is as fundamental to the recurring revenue of the business as their legal or accounting or marketing. Devs make changes according to the evolving needs of the business, and "productivity" isn't as much of a priority as accuracy and reliability. The implementation details are very relevant to the business, especially for B2B services that need to meet compliance requirements.
Products, however, have always been disposable code written by people being thrown into a meat grinder. I don't think LLM-generated code is better, but it's probably not that much worse either.
> Software lasts way longer than people think it does.
It was true, but I'm not sure if it's still true in the age of LLMs. Maybe we are moving into the era of disposable software.
It was true, but I'm not sure if it's still true in the age of LLMs. Maybe we are moving into the era of disposable software.
> This is misguided. Maintenance of LLM code has a far greater cost than generating it.
I agree. I'm just observing what they're doing.
> I don't think that's even a thought. The thought is that "no one can tell me no".
I doubt there's any one thought driving things. I didn't mean to imply the existence of some grand strategy or scheme. The preference I speak of isn't of any person, it's the direction pointed at by incentives and circumstance. Companies will make decisions to steer clear of helping competitors. Separately, they signal great interest in replacing costs spent on labor with costs spent on services. See the transition to cloud. The result is the preference of a world where code is like gasoline, purchased from a handful of suppliers for metered cost.
I agree. I'm just observing what they're doing.
> I don't think that's even a thought. The thought is that "no one can tell me no".
I doubt there's any one thought driving things. I didn't mean to imply the existence of some grand strategy or scheme. The preference I speak of isn't of any person, it's the direction pointed at by incentives and circumstance. Companies will make decisions to steer clear of helping competitors. Separately, they signal great interest in replacing costs spent on labor with costs spent on services. See the transition to cloud. The result is the preference of a world where code is like gasoline, purchased from a handful of suppliers for metered cost.
We really need to stop this misconception about FOSS. Free software is provided as is, with no obligations on either party (minus the viral clause of copyleft). The user is not obligated to "contribute" in any way, and the provider is not obligated to support in any way. It is a single one off donation of work from the author to the public.
Yes.
Companies optimize for profit, all else be damned, no matter the damage they cause to the world around them.
In that sense, I fully expect companies to extract all value they can from Open Source without paying not contributing nothing in return.
The world would be saner if more people understood that.
Companies optimize for profit, all else be damned, no matter the damage they cause to the world around them.
In that sense, I fully expect companies to extract all value they can from Open Source without paying not contributing nothing in return.
The world would be saner if more people understood that.
It's called "taxation" but it's not very popular.
Jazzband have done the world a lot of good. They deserve better.
I don't know how many maintainers that are impacted by this, or what they are getting from Jazzband (I was not previously familiar), but the Apache foundation may be something to look into.
https://apache.org/
https://apache.org/
Unfortunate.
> 60% of maintainers are still unpaid.
That's actually not as bad as I would have guessed.
> 60% of maintainers are still unpaid.
That's actually not as bad as I would have guessed.
I'd be curious to know what portion of that 40% makes any meaningful income from their open source work. I would guess that most of those people are being paid a small appreciation amount for the work they're doing, not something resembling a living wage.
They may be including maintainers who are explicitly employed to maintain the respective projects (e.g. some RedHat employees). This is not common, but not vanishingly rare either.
Yeah, I had the same thought. Expected it to be like 95%.
Wait, y'all are getting paid?
> Jazzband was always a one-roadie operation. People asked for more roadies and offered to help over the years, and I tried a number of times to make it work – but it never stuck.
Not sure what exactly prevented him from accepting more people into the role of "roadies"...
Not sure what exactly prevented him from accepting more people into the role of "roadies"...
The level of trust required is immense. We’re talking about a position where you get the keys to the kingdom to a very large number of projects
I would say that having roadie level access is equivalent to having access to Django core. I have never seen a recent Django project that isn’t pulling something from jazzband
Despite this I think it’s important to highlight that even in that world jazzband had a lot of infra so that projects could do things like releases cleanly and safely (we aren’t doing direct project releases to pypi but going through jazzband infra to do the release). So release maintainers have a lot less access despite releases “coming from” Jazzband
I would say that having roadie level access is equivalent to having access to Django core. I have never seen a recent Django project that isn’t pulling something from jazzband
Despite this I think it’s important to highlight that even in that world jazzband had a lot of infra so that projects could do things like releases cleanly and safely (we aren’t doing direct project releases to pypi but going through jazzband infra to do the release). So release maintainers have a lot less access despite releases “coming from” Jazzband
Why are we assuming that there were lots of volunteers in the first place? If this is such a high-trust position, it should be called something other than "roadie". I thought it was common knowledge that the term "roadie" is considered mildly derogatory, and that the modern word was more specific and skill-based, i.e. "stage manager", etc.
As an N=1 example, I myself have some experience with various Django packages including some Jazzband ones. Around 7 years ago I looked at this organization, thought about volunteering to be a "roadie", and specifically decided not to do so due to the terminology. I'm pretty sure that something like "Looking for trusted co-maintainers with a history of FOSS contribution" would draw in more folks than "Looking for roadies".
If you're going to say "well no one complained", guess what, I didn't either. People will just quietly decide to not volunteer due to stuff like this; leading to a shortage over time.
Summary: Branding and acknowledgement matters, so check carefully what you call the volunteers that you're expecting tens of hours of free work from.
As an N=1 example, I myself have some experience with various Django packages including some Jazzband ones. Around 7 years ago I looked at this organization, thought about volunteering to be a "roadie", and specifically decided not to do so due to the terminology. I'm pretty sure that something like "Looking for trusted co-maintainers with a history of FOSS contribution" would draw in more folks than "Looking for roadies".
If you're going to say "well no one complained", guess what, I didn't either. People will just quietly decide to not volunteer due to stuff like this; leading to a shortage over time.
Summary: Branding and acknowledgement matters, so check carefully what you call the volunteers that you're expecting tens of hours of free work from.
> The level of trust required
Maybe it could be mitigated by having some kind of council and requiring m out of n signatures to do anything?
I know that people on HN hate Bitcoin, so I'm always a bit vary to use it as an example.
But I think that in such cases having something similar to Bitcoin multisig could help.
Maybe it could be mitigated by having some kind of council and requiring m out of n signatures to do anything?
I know that people on HN hate Bitcoin, so I'm always a bit vary to use it as an example.
But I think that in such cases having something similar to Bitcoin multisig could help.
That requires a lot of infra that isn’t built into _any_ of our tooling.
It’s not so much about decision making as it is about the practical reality that people at that level basically need at least read access to a lot of secrets.
You could say “maybe jazzband can infra its way out of those problems” but that’s a looooot of work! “N out of M consensus on making a GitHub API request to set who is a maintainer” * every single action roadies need to do
It’s not just about bad actors either. Imagine a jazzband roadie getting credentials stolen via some npm-y attack. Obviously this problem exists in the project in the current form but _that problem gets worse just onboarding people_
It’s not so much about decision making as it is about the practical reality that people at that level basically need at least read access to a lot of secrets.
You could say “maybe jazzband can infra its way out of those problems” but that’s a looooot of work! “N out of M consensus on making a GitHub API request to set who is a maintainer” * every single action roadies need to do
It’s not just about bad actors either. Imagine a jazzband roadie getting credentials stolen via some npm-y attack. Obviously this problem exists in the project in the current form but _that problem gets worse just onboarding people_
> maybe jazzband can infra its way out of those problems
Maybe jazzband can't infra their way out of the problem, but maybe we can create some tools that will help orgs that encounter this problem in future...
... that's a software engineer in me talking. I have no idea how to organize communities, but I may know a thing or two about making software. And when you've got a hammer in your hands everything starts looking like a nail...
Maybe jazzband can't infra their way out of the problem, but maybe we can create some tools that will help orgs that encounter this problem in future...
... that's a software engineer in me talking. I have no idea how to organize communities, but I may know a thing or two about making software. And when you've got a hammer in your hands everything starts looking like a nail...
yeah tbqh I think the biggest challenge with tooling on that front is that this really is a problem mostly limited to community projects. The problems jazzband need to solve don't exist nearly as much in a universe where everyone is in a company on some payroll
In most corporate environments while it might make sense to do N of M in the high security case it's not really a thing that people will jump for for the first... uhhh 10k employees of a company's lifetime.
In most corporate environments while it might make sense to do N of M in the high security case it's not really a thing that people will jump for for the first... uhhh 10k employees of a company's lifetime.
Yep trust was always the issue here really. Don’t blame Jannis at all for being super careful about that.
One proposed strategy to try and deal with this.
https://freeasinweekend.org/
https://freeasinweekend.org/
Wow, this is unfortunate and a loss for the Python community. I have been impressed with the quality of everything under Jazzband.
Bad smells were coming from Jazzband from well before people started churning out vibe-coded PRs. Jannis should’ve let this blog post sit for a few days before publishing it. The post basically says “why is Jazzband shutting down? AI! It’s AI’s fault! Also here’s my little rant about it being trained on open-source code!”, but he then proceeds to walk things back a little bit, “well actually it started a whole lot earlier”. Jazzband’s mismanagement wasn”t the butterfly flapping its wings that AI turned into something unsustainable. It was broken regardless, beyond the usual “oh the maintainers are burnt out”. It’s obvious that he’s got a more philosophical bee in his bonnet about AI, and is attributing more of Jazzband’s demise to it than can really be justified.
All I’ll say is, there’s a reason that Django Commons now exists.
The Register post about the Slopocalypse to me feels tongue in cheek while this post seemingly takes it at face value. What's happening on GitHub is a mixed bag. I love what AI is doing to Ghostty.
What is happening with Ghostty?
https://github.com/ghostty-org/ghostty/tree/main/.agents/com...
Is my best guess. The GP is perhaps referring to ghostty repo adding helper files for Llm agents to operate as a cursory look at issues to placate issue submitters.
Is my best guess. The GP is perhaps referring to ghostty repo adding helper files for Llm agents to operate as a cursory look at issues to placate issue submitters.
No, that Ghostty is improving much more rapidly than it would be without agentic coding, In spite of a painful transition.
Have you listened to Mitchell Hashimoto talk about how he uses AI? He is not a vibe coder by any definition of the term.
You mean when AI caused the Ghostty maintainer to close PRs to outsiders?
Exactly, and open them back up with a vouching system.