> 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"...
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…
Yep trust was always the issue here really. Don’t blame Jannis at all for being super careful about that.
> 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.
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.
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…
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.
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.)
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…
> 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.
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_
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.
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…
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.
> 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.
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” * ever…
> 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...
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” * ever…
> 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 lookin…
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.