Sure, the roots of FOSS came from collaboration, with people sharing code between universities and whatnot. But the process has always been “here are my changes, take them if you like.” So even the term “collaboration” is a bit of a stretch, since it was almost always a bunch of solo efforts and people would pull in the changes they like. The idea of any kind of structure to FOSS development was added later to help organize it, but the foundation was always someone working on a thing and then advertising those changes for others to pull, if they wanted.
A collaborative project would work something like Python where a core team decides which features to add (i.e. PEPs), and people on the dev team or the community at large would develop those features, and any development that’s not part of those approved features tend to be rejected until it goes through the review process.
Linux isn’t particularly collaborative in that sense, it’s more like the old-school FOSS development process where individual developers would build a thing, use it themselves, and then submit their changes for upstream consideration. I worked on a team where we maintained our own kernel patches separate from upstream for years before trying to submit them upstream, and every time we’d upgrade the kernel, we’d have to reapply the patches, occasionally fixing some things that had changed. The network of maintainers is largely a convenience for working in this more chaotic model, where maintainers are responsible for reviewing and passing along changes for a certain area of the kernel, they don’t actually guide development in any meaningful way.
So the main change here is that Russian contributors can still contribute, they just aren’t trusted as inner-circle reviewers. It’s still collaborative in the same sense that it has always been, there’s just a bit more scrutiny over which reviews to trust.
Sure, the roots of FOSS came from collaboration, with people sharing code between universities and whatnot. But the process has always been “here are my changes, take them if you like.” So even the term “collaboration” is a bit of a stretch, since it was almost always a bunch of solo efforts and people would pull in the changes they like. The idea of any kind of structure to FOSS development was added later to help organize it, but the foundation was always someone working on a thing and then advertising those changes for others to pull, if they wanted.
A collaborative project would work something like Python where a core team decides which features to add (i.e. PEPs), and people on the dev team or the community at large would develop those features, and any development that’s not part of those approved features tend to be rejected until it goes through the review process.
Linux isn’t particularly collaborative in that sense, it’s more like the old-school FOSS development process where individual developers would build a thing, use it themselves, and then submit their changes for upstream consideration. I worked on a team where we maintained our own kernel patches separate from upstream for years before trying to submit them upstream, and every time we’d upgrade the kernel, we’d have to reapply the patches, occasionally fixing some things that had changed. The network of maintainers is largely a convenience for working in this more chaotic model, where maintainers are responsible for reviewing and passing along changes for a certain area of the kernel, they don’t actually guide development in any meaningful way.
So the main change here is that Russian contributors can still contribute, they just aren’t trusted as inner-circle reviewers. It’s still collaborative in the same sense that it has always been, there’s just a bit more scrutiny over which reviews to trust.