> A new model for open source: closed to pull requests
That's how SQLite operates since decades. And it might be good for them. It is specific project with billions of running instances (handling long-term preserved and modified data contrary to curl), but it doesn't apply generally.
Allowed pull requests is not equal to obligation to review them and to accept. Some disclaimer about how much time one has for this work is very useful for a potential contributor to know in advance what one can expect.
I think OP is saying that github, and forges like it, making pull requests so easy, have created a situation where the users bother them too much with said requests. This wasn't always the case with open source, back before community web-based forges were a thing, and it was much more difficult to collaborate from outside the project (where the project has their own regular contributors that do most of the work).
But I don't think most people actually want to just turn off pull requests like they are suggesting... I think that would be disastrous for the open source community as it operates now, and may push people further away to other (maybe even closed) projects.
> All right, I'm going to open up a history lesson because it's been a couple of generations of software engineers since this essay
> It created really weird social-structure expectations: that someone who releases code has an obligation to maintain it and get paid nothing for the work.
Fundamentally, yeah that is why it took off. Big tech doesn't sell software anymore, they made it a commodity through open source. Now they sell cloud services or consulting, or ads or your data.
> It seemed clear to us in retrospect that the term "free software" had done our movement tremendous damage over the years. Part of this stemmed from the well-known "free-speech/free-beer" ambiguity. Most of it came from something worse--the strong association of the term "free software" with hostility to intellectual property rights, communism, and other ideas hardly likely to endear themselves to an MIS manager.
The intention was to find a business model and market it. That's why they distinguished themselves from FOSS in the first place. It's what you see big tech doing today (that's the business model).
The outcomes being observed and complained about are literally just the expected outcomes of making software a commodity, which is that businesses need to make money and they don't do it by selling software.
Upstreaming fixes has always been awesome so you don't need to care for your special snowflake fork, and it just took time, and effort, and so on.
Sure, people who are all in on AI will say "no worries, we will just somehow get all the security fixes from upstream by letting the agent cherry-pick stuff" and I'll just wish them good luck.
Me? Every time I can sunset a personal project of mine and replace it with a tool with a (even tiny) community and trying to improve that over doing everything from scratch, I'm very happy. (The opposite has happened as well, of course, but rarer). Maybe this is different for people who like to create new stuff, build communities, amass fame. I'm the rando who just shows up and collaborates with you for a few days/weeks/years and vanishes again.
Sounds like the OpenBSD model to me. Actually, if I'm honest, that's really just the Freeware model of Andrew Fluegelman. You get the program, the source code, the right to make modifications and release them, just don't expect upstream to incorporate them. (If confused, go look up PC-TALK.)
there is so much drama around open source and pull requests, mostly because people somehow became fork-phobic.
so the new model is just great: fork the repo and do whatever you want. git a distributed system so best case scenario the original repository owner can still merge the changes. also if the original developer used a decent license they will also have legal rights to do so.
Afaik LLM-generated code cannot be copyrighted in the USA, and therefore cannot be licensed. It's automatically public domain. This makes it incompatible with most OSS licenses. Several of my personal favorite projects have already prohibited LLM-generated code. That doesn't mean the frequency and quality of contributions won't still increase. I use my LLM harness for all kinds of grunt work that would have sucked up hours. Git surgery, code exploration, PM. But we don't need a whole new paradigm for a brave new world. I've heard that'd boil the sky and poison the water anyway. Too expensive.
The context around copyright of LLM code, at least in the US, is currently more complicated than clear. See for example [0] and the comments on the article it's responding to.
This is not true... many prominent OSS projects based in the US currently use LLM-generated code, including the Linux kernel, many distros, BSDs etc.
Remember that if there is a complaint such as copyright infringement, that still must go through the normal court process. Only the copyright holder can sue, and not everyone chooses to do so.
They must prove how/why the code is infringing, and then a judge/jury makes a subjective determination on things like fair use, transformation etc. to determine just how similar/different the code is, how obvious it is, if a human is likely to have come up with the same code independently, if there are any monetary damages to collect/etc.
There is no blanket law that says LLM-generated code cannot be copyrighted. And how the model got the code in the first place is largely irrelevant here.
> A new model for open source: closed to pull requests
That's how SQLite operates since decades. And it might be good for them. It is specific project with billions of running instances (handling long-term preserved and modified data contrary to curl), but it doesn't apply generally.
Allowed pull requests is not equal to obligation to review them and to accept. Some disclaimer about how much time one has for this work is very useful for a potential contributor to know in advance what one can expect.
Hasn’t this always been the case with forks?
I think OP is saying that github, and forges like it, making pull requests so easy, have created a situation where the users bother them too much with said requests. This wasn't always the case with open source, back before community web-based forges were a thing, and it was much more difficult to collaborate from outside the project (where the project has their own regular contributors that do most of the work).
But I don't think most people actually want to just turn off pull requests like they are suggesting... I think that would be disastrous for the open source community as it operates now, and may push people further away to other (maybe even closed) projects.
It's how I currently do Open Source. I like to think of it as a strong form of indirect collaboration - https://johnoestmannmusic.com/indirect-collaboration/
> All right, I'm going to open up a history lesson because it's been a couple of generations of software engineers since this essay
> It created really weird social-structure expectations: that someone who releases code has an obligation to maintain it and get paid nothing for the work.
Fundamentally, yeah that is why it took off. Big tech doesn't sell software anymore, they made it a commodity through open source. Now they sell cloud services or consulting, or ads or your data.
Just read what Eric Raymond said about it: https://www.oreilly.com/openbook/opensources/book/raymond2.h...
> It seemed clear to us in retrospect that the term "free software" had done our movement tremendous damage over the years. Part of this stemmed from the well-known "free-speech/free-beer" ambiguity. Most of it came from something worse--the strong association of the term "free software" with hostility to intellectual property rights, communism, and other ideas hardly likely to endear themselves to an MIS manager.
The intention was to find a business model and market it. That's why they distinguished themselves from FOSS in the first place. It's what you see big tech doing today (that's the business model).
The outcomes being observed and complained about are literally just the expected outcomes of making software a commodity, which is that businesses need to make money and they don't do it by selling software.
On a large scale this sounds like a nightmare.
Upstreaming fixes has always been awesome so you don't need to care for your special snowflake fork, and it just took time, and effort, and so on.
Sure, people who are all in on AI will say "no worries, we will just somehow get all the security fixes from upstream by letting the agent cherry-pick stuff" and I'll just wish them good luck.
Me? Every time I can sunset a personal project of mine and replace it with a tool with a (even tiny) community and trying to improve that over doing everything from scratch, I'm very happy. (The opposite has happened as well, of course, but rarer). Maybe this is different for people who like to create new stuff, build communities, amass fame. I'm the rando who just shows up and collaborates with you for a few days/weeks/years and vanishes again.
Sounds like the OpenBSD model to me. Actually, if I'm honest, that's really just the Freeware model of Andrew Fluegelman. You get the program, the source code, the right to make modifications and release them, just don't expect upstream to incorporate them. (If confused, go look up PC-TALK.)
I'm carrying so many patches these days. I need a term for it. This feels like an ok go at it, a remix.
Mentioned this just the other day, the want for a term for this:
> mercy it's not even a fork. we don't even have a word for this! i'm juggling a bunch of patches atop opencode. sort of a fork. a running fork? https://bsky.app/profile/jauntywunderkind.bsky.social/post/3...
Out of curiosity, what is the reason for all these patches?
in a way i'm happy this is happening.
there is so much drama around open source and pull requests, mostly because people somehow became fork-phobic.
so the new model is just great: fork the repo and do whatever you want. git a distributed system so best case scenario the original repository owner can still merge the changes. also if the original developer used a decent license they will also have legal rights to do so.
Afaik LLM-generated code cannot be copyrighted in the USA, and therefore cannot be licensed. It's automatically public domain. This makes it incompatible with most OSS licenses. Several of my personal favorite projects have already prohibited LLM-generated code. That doesn't mean the frequency and quality of contributions won't still increase. I use my LLM harness for all kinds of grunt work that would have sucked up hours. Git surgery, code exploration, PM. But we don't need a whole new paradigm for a brave new world. I've heard that'd boil the sky and poison the water anyway. Too expensive.
The context around copyright of LLM code, at least in the US, is currently more complicated than clear. See for example [0] and the comments on the article it's responding to.
[0]https://news.ycombinator.com/item?id=49354482
This is not true... many prominent OSS projects based in the US currently use LLM-generated code, including the Linux kernel, many distros, BSDs etc.
Remember that if there is a complaint such as copyright infringement, that still must go through the normal court process. Only the copyright holder can sue, and not everyone chooses to do so.
They must prove how/why the code is infringing, and then a judge/jury makes a subjective determination on things like fair use, transformation etc. to determine just how similar/different the code is, how obvious it is, if a human is likely to have come up with the same code independently, if there are any monetary damages to collect/etc.
There is no blanket law that says LLM-generated code cannot be copyrighted. And how the model got the code in the first place is largely irrelevant here.