this post was submitted on 24 Oct 2024
1059 points (96.9% liked)
Technology
59566 readers
4828 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Fair on your part, I might've gone too far with my argument.
I was talking more about collaborative nature and what happens to it when the major open-surce project decides to gatekeep based on something highly arbitrary.
Linux is long past a simple hobby project, and it should be managed responsibly and with respect to the people that make this all happen.
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.