[HN Gopher] Sunsetting Jazzband
___________________________________________________________________
Sunsetting Jazzband
Author : mooreds
Score : 117 points
Date : 2026-03-14 17:40 UTC (5 hours ago)
(HTM) web link (jazzband.co)
(TXT) w3m dump (jazzband.co)
| zahlman wrote:
| Unfortunate.
|
| > 60% of maintainers are still unpaid.
|
| That's actually not as bad as I would have guessed.
| VladVladikoff wrote:
| Yeah, I had the same thought. Expected it to be like 95%.
| tux3 wrote:
| Wait, y'all are getting paid?
| japhyr wrote:
| 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.
| johncolanduoni wrote:
| 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.
| benatkin wrote:
| 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.
| BeefySwain wrote:
| What is happening with Ghostty?
| righthand wrote:
| 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.
| benatkin wrote:
| No, that Ghostty is improving much more rapidly than it
| would be without agentic coding, In spite of a painful
| transition.
| slopinthebag wrote:
| Have you listened to Mitchell Hashimoto talk about how he
| uses AI? He is not a vibe coder by any definition of the
| term.
| slopinthebag wrote:
| You mean when AI caused the Ghostty maintainer to close PRs to
| outsiders?
| benatkin wrote:
| Exactly, and open them back up with a vouching system.
| iqihs wrote:
| 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.
| idle_zealot wrote:
| 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.
| indymike wrote:
| > 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".
| doublerabbit wrote:
| > 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.
| indymike wrote:
| Yes, it is precisely misguided, and will be in five
| years, too. Software lasts way longer than people think
| it does.
| vova_hn2 wrote:
| > 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.
| sublinear wrote:
| 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.
| idle_zealot wrote:
| > 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.
| mentalgear wrote:
| 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.
| colesantiago wrote:
| 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.
| satvikpendem wrote:
| What new license would you make that isn't already covered
| by existing ones?
| bpavuk wrote:
| 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?
| rglullis wrote:
| 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.
| bdcravens wrote:
| 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)
| indymike wrote:
| > 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.
| Eridrus wrote:
| 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.
| satvikpendem wrote:
| 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.
| stavros wrote:
| Just use the AGPL.
| actionfromafar wrote:
| It's called "taxation" but it's not very popular.
| Ferret7446 wrote:
| 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.
| grim_io wrote:
| Jazzband have done the world a lot of good. They deserve better.
| sc68cal wrote:
| 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.
| mey wrote:
| 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/
| comet_browser wrote:
| 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.
| vova_hn2 wrote:
| > 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"...
| rtpg wrote:
| 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
| vova_hn2 wrote:
| > 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.
| frankwiles wrote:
| Yep trust was always the issue here really. Don't blame
| Jannis at all for being super careful about that.
___________________________________________________________________
(page generated 2026-03-14 23:00 UTC)