Open Source Software Community - it's about ethics in Code of Conducts

[some guy with an opinion]

Public consent to a developer's changes are ultimately completely irrelevant in open source given that anyone can fork the tool and change it the way they like AND there are no warranties tied to anything. The sooner that developers realize that they're developing for their own benefit and not for social media upcummies again, this problem will largely stop.

I largely agree. The issue is that these project will generally get a lot less attention and, more importantly, developer time than bazaar projects.

So you might write the BEST piece of software devoid of political bullshit, but you're still going to be overtaken by the deluge of soydevs writing equivalents using whatever js framework is popular this week, by virtue of them having the numbers advantage.

Of course that shouldn't matter, but unfortunately there's no way to win the socialization game against these people, and socialization IS important for FOSS projects specifically because momentum is important. Popularity gets you access to linux distro repos, winget, and general press and recognition, which can then cause a snowballing effect. SQLite is very lucky because it's been popular regardless, but personally I think if more projects took the Cathedral approach, they would also doom themselves to obscurity, especially if they aren't doing something ultra unique.

As for my project, it's sort of a hybrid model. The source code is publicly available, including all commits in real-time, and PR's are open. However at the same time I am basically the monopoly opinion on what gets included/merged, and most discussion happens in an external private discord - PR's are ONLY really used for the actual merges, not discussion or anything. Since this is in a niche area and there aren't many developers overall, PR's are few and far between. Because of this it's technically a bazaar, but is "cathedral like", which I enjoy because it keeps things going completely off the rails.

 

[XL xQgg?QcQCaTYDMjqoDnYpG]

I'm going to try and write this out as a decision tree

Appreciate you taking the time to deliver, now I can clearly see how you and I reached opposite conclusions
The way I see it, the divergence is caused by a few assumptions that largely determine the outcome, the biggest one being

It's one round

I mean, if you model this as a one-round decision problem, I agree that "defect" is going to look like the safer choice, because you're only optimizing for immediate project survival rather than any longer-term incentive effects. The model I had in mind treats this as an interaction that repeats across projects over time, where behavior feeds back into future incentives.
Related to that, in the payoff structure in your tree, you build in the assumption that defecting keeps you "fine" whereas cooperating carries a real risk of project loss, which already biases the tree toward defecting from the outset. That may be true locally in some cases, but I think you're excluding the possibility that widespread defection sustains and reinforces the conditions that make those troon attacks viable in the first place. That is, the tree captures the immediate downside, but not the feedback effects.
In other words, we weren't getting opposite conclusions from the same reasoning, rather we have been analyzing different games. One-shot project-level risk minimization under uncertainty in your case, repeated interaction where aggregate behavior affects attacker incentives in mine. Under your framing, your conclusion makes sense, whereas under mine, any "neutrality" necessarily contributes to maintaining the environment that creates the troon pressure in the first place.

To end in a thought-provoking question: Which of these frames better reflects what is actually going on in the open source space?

 

[XL xQgg?QcQCaTYDMjqoDnYpG]

@some guy with an opinion looks like your messages only got through just now, presumably because of new account moderation queue?

I'll keep it brief
If the environment is truly as you describe it (public spaces are inevitably hostile, engagement only gives ammunition to enemies, principles are useless, the public is captured, resistance is futile, the likely result is project destruction or career harm) and your posts are just explaining why you can't act otherwise...
then why develop OSS in the first place? What you wrote is less of a rebuttal and more of a confirmation of my point
You're basically holding both "this space is structurally corrupted and unwinnable" and "I will continue operating in it, just quietly and carefully"
Strange equilibrium to settle into. Too pessimistic to resist, too invested to leave
Fighting, restructuring, withdrawing, those other options are on the table. Instead, you chose staying, complying, and keeping your head down, under the label of "realism"
Fair enough, but let's not pretend that's anything other than capitulation

 

[skunt]

https://gitlab.archlinux.org/pacman/pacman/-/merge_requests/353 lol

 

[SCV]

I mean, if you model this as a one-round decision problem,

I actually had a paragraph saying "I think I see where we differ and where your misunderstanding (in my view)" and describing a 100 round 2-party iterated prisoners dilemma with $3 ea. for both cooperating, $1 for both defecting, $5/$1 for defect/cooperate, and nothing for both defecting. I cut it after re-reading your post during "editing" and noticing you didn't explicitly say it was multi-round but I guess I should've left that in. I worked "It's one round" in elsewhere to be explicit for that reason.

you build in the assumption that defecting keeps you "fine" whereas cooperating carries a real risk of project loss,

I tried to get at that with the spherical cows bit but the real world is never going to be so black and white. IMO you could say defect gives you a 95% chance to have the project survive and the 1a. cooperate scenario has a 5% chance to have the project survive without really changing the logical outcome. I also at one point had several other options but felt that just muddled the point by getting bogged down in specifics about each option. The spoilers are what's left.

One-shot project-level risk minimization under uncertainty in your case, repeated interaction where aggregate behavior affects attacker incentives in mine.

I think we largely agree except for the trial being repeated or a one-off.

but I think you're excluding the possibility that widespread defection sustains and reinforces the conditions that make those troon attacks viable in the first place.

I'm not. In fact I think that is obviously the case. It's almost exactly the same as paying if your company gets hit with ransomware or paying off a patent troll. Doing so fixes the problem immediately but encourages more patent trolls or ransomware. But everyone has to deal with that in the long term, not just you. This is basically my entire point; The game theory of this makes it a tragedy of the commons so while it would be better for everyone to resist they don't.

To end in a thought-provoking question: Which of these frames better reflects what is actually going on in the open source space?

I think it's much closer to one-shot for a couple reasons. I already mentioned that I doubt people that get burned by this usually start another open source project only to get burnt again. I would add that if you were the (co)-founder of some important utility or project I imagine you care a lot more about keeping control of your project than vague things like the overall health/wokeness of open source in general. And of course if whatever project is someone's career and not just a hobby they have even more to lose.

 

[XL xQgg?QcQCaTYDMjqoDnYpG]

https://gitlab.archlinux.org/pacman/pacman/-/merge_requests/353 lol

funny description at the top, but unfortunately the discussion below moves from funny into horrifying as it turns out that the dev is either a comedian with a very strange sense of humor or deadly serious

---

Much clearer now indeed

In fact I think that is obviously the case.

If we agree that defection/neutrality sustains and reinforces the hostile conditions then we're not really disagreeing on the structure of the situation
Less "opposite conclusions" and more like a difference in what plans of action we yield from the situation

I think it's much closer to one-shot for a couple reasons.

The arguments you give seem to be about the individual maintainer's horizon, but not the structure of the environment itself. However, the environment (same actors, same tactics, same incentives, spillover across projects) is exactly what makes your ransomware/patent troll analogy work in the first place, and that is inherently not one-shot
Seems more accurate to say that the environment is repeated and exhibits a tragedy-of-the-commons dynamic + individual actors may still rationally behave as if it were one-shot from their own perspective
I reckon that's a fair description of what you're getting at
If that's the case, our disagreement is not in the realm of game theory, but on the level of whether "this sustains a bad equilibrium but is locally safer to do" is sufficient justification. And once it's framed that way, the space for disagreement becomes fairly narrow.

 

[wlan0]

These AI detection suites are completely useless.

That website's okay from my experience; it's not 100% spot on perfect but it detects my friends' well formatted, proofread writings as 100% human and LLM-assisted texts as partially assisted.

 

[Hakase Shinonome]

https://gitlab.archlinux.org/pacman/pacman/-/merge_requests/353 lol

I'm glad not EVERYONE on ArchLinux is a stupid maniac. What good would age verification even do on the fucking package side of all things? Like I've said before, is little Timmy going to install librapeandgore2.3? These niggers would "recite" 1984 (while not even having read it), but then go on to implement Orwellian garbage like this.

That website's okay from my experience; it's not 100% spot on perfect but it detects my friends' well formatted, proofread writings as 100% human and LLM-assisted texts as partially assisted.

I can concur that the words I wrote above are indeed from my own two hands. Probably because it contains very naughty words.

 

[LarpBait]

I largely agree. The issue is that these project will generally get a lot less attention and, more importantly, developer time than bazaar projects.

that's not even true, the vast majority of open source projects are maintained by one maintainer. This means that, for most projects, there is simply no actual utility in working with an open forum bazaar methodology outside of exposing yourself to potential harm.

Even for projects that do have multiple maintainers, it's wiser to take them, start a business or foundation, and work quietly together than it is to open the project up to contributions from the unwashed masses. SQLite can keep the lights on while the GNOME foundation cannot, both are software that respects the end users freedom, but one has far more gate keeping on contributors than the other, leading to a healthier development cycle (along side a methodology of funding, as there is a central group that contracts can be made with).

but you're still going to be overtaken by the deluge of soydevs writing equivalents using whatever js framework is popular this week

This is developing for upcummies, stop doing it. Why the fuck does it matter that some soidev is going to shit out a new js framework that gets hyped up and then abandoned a couple years later due to lack of stability? It's better to just develop the software you want to develop and maintain for you and the sake of the people you care about than to care about "competing" with retards fueled entirely by upcummies. Upcummies don't pay bills, they just get you clout on twitter to cancel people. I don't think you're interested in that, so there's no reason to pursue it.

Popularity gets you access to linux distro repos, winget, and general press and recognition, which can then cause a snowballing effect

How about you submit your own package to repos instead of waiting for others to do it for you? That tends to work to get your software in. Even if they don't accept it, just offering binaries in .deb, .rpm, and .flatpak formats tends to work for users who just want to install the software helps for adoption a lot (see Gitea). Appimage works too.

Furthermore, general press and recognition means nothing if it doesn't translate to dollars, otherwise its just upcummies, and i've been over why this is a useless thing to pursue.

an external private discord

this nigga cannot be serious about using discord for a FOSS project...

 

[mango_reseller]

most discussion happens in an external private discord

Thank you for keeping your product free of sensible people and only faggots that use discord may weigh in.

 

[SCV]

Fighting, restructuring, withdrawing, those other options are on the table. Instead, you chose staying, complying, and keeping your head down, under the label of "realism"
Fair enough, but let's not pretend that's anything other than capitulation

I think you could credibly say this is not capitulation but biding your time. If you pop your head up alone, get domed, and nothing changes that doesn't help anyone. But if you wait for some even/trigger or even just a general sentiment change as the troons continue alienating people then pop your head up when it has a chance to help then that was a good decision.

 

[GNU Abyss]

SQLite is very lucky because it's been popular regardless, but personally I think if more projects took the Cathedral approach, they would also doom themselves to obscurity, especially if they aren't doing something ultra unique.

Sqlite had a good head start thanks to being popular before homofags completely usurped the Internet. It also has a barrier of entry. The copyright page says:

Open-Source, not Open-Contribution​

SQLite is open-source, meaning that you can make as many copies of it as you want and do whatever you want with those copies, without limitation.But SQLite is not open-contribution. In order to keep SQLite in the public domain and ensure that the code does not become contaminated with proprietary or licensed content, the project does not accept patches from people who have not submitted an affidavit dedicating their contribution into the public domain.

While not ideal, this plus their conservative design philosophy of support through the year 2050 filters some of the trash out. Bazaar or Cathedral, I think more project authors should use their liberty to just say no to contributions from people they don't know or trust. Whether it's because the contribution looks like some soy golem's latest attempt at FOSS sabotage or feels like an injection of the latest CS academic masturbation aid into your code.

 

[estacks]

Google wins all code belongs to Google.

 

[Paul Revere Pantry Raider]

Apple has already bent the knee. https://support.apple.com/en-us/125662

(Clock me if I'm late. I don't want to catch up on 40 pages since the last shitpost.)

 

[estacks]

Apple has already bent the knee. https://support.apple.com/en-us/125662

(Clock me if I'm late. I don't want to catch up on 40 pages since the last shitpost.)

Apple wins the smartphone race tho.

 

[Dante Alighieri]

Apple has already bent the knee. https://support.apple.com/en-us/125662

(Clock me if I'm late. I don't want to catch up on 40 pages since the last shitpost.)

Well yeah, it costs them nothing to do what they already had the infrastructure for.

 

[Cherenkovblue]

Apple wins the smartphone race tho.

That's not hard when your only opponent is a one-legged man in an ass-kicking contest.

 

[Legalize Asbestos]

Think of it like trying to convince the average person in The Matrix that the real world is better because it's real. A decent number of people might decide to wake up, but the majority would prefer the happy fantasy anyway, and will resent you for presenting them with the truth. You would only be hurting your own cause by trying to convince everyone of the truth.

Or as I put it: 'sticking your neck out so you can be stabbed in the back.'

People keep imagining these cultural battles as if it's a siege of left v. right. It is not a siege. You have no ramparts, you have no castle. It's not even an occupation - because the majority (at least in the FOSS space) is not with you - which means the correct mental model for the game theorists in the audience is Insurgency. @some guy with an opinion is correctly behaving as an insurgent: blending in, biding his time, doing what he can. Maybe he could do more to actively dis-empower his foes (right now he is just dissident, not insurgent), but his assessment of the situation is correct.

 

[Ferryman]

Sqlite had a good head start thanks to being popular before homofags completely usurped the Internet. It also has a barrier of entry. The copyright page says:


While not ideal, this plus their conservative design philosophy of support through the year 2050 filters some of the trash out. Bazaar or Cathedral, I think more project authors should use their liberty to just say no to contributions from people they don't know or trust. Whether it's because the contribution looks like some soy golem's latest attempt at FOSS sabotage or feels like an injection of the latest CS academic masturbation aid into your code.

This model is probably the most resilient to capture when or if coupled with a BDFL. If you are the ruler or otherwise have a significant voice in any project, you should absolutely tell soy devs to fuck off unless their rationale and or code are of a high quality, or otherwise create a "personality filter", so to speak. This soylent idea of allowing anyone to contribute has always been retarded for the simple fact that not everyone deserves to be included, and the trannies are correct when they say that people need to be filtered from projects, except in the exact opposite direction. A trust-based system is ultimately the best, but isn't that how the CoC trannies and Red Hat/M$ corpoate spies find purchase in projects, too? Contribute, build trust, infiltrate into influential positions, push out original staff, EEE by the book. What needs to happen is that the project's core ethos is continualy maintained by people that you can somehow filter for low chance of EEEing it. If the project has a BDFL the decision is just a matter of direct inheritance, but when it comes to shared ownership, the water gets muddier. Having a group of like minded idealists that have a strong bond to the project is the only way to ensure it remains un pozzed.

Either way, allowing mediocrity to gain purchase is what lead to this sort of situation. I don't know who it was that said CoCs are a way to inject people with inadequate dev chops into ruling structures, but you're absolutely on the money, it is the OSS equivalent of having an HR middle manager that knows nothing about programming telling you what you can or cannot do. People need to learn to tell others to fuck off again without having to provide a 10 page rationale. When did giving mediocrity the time of day become the norm? Heavy filtering is the least one can do to resist tranny takeovers. The Bazaar only works when you have a strong sultan to remove subversive parasites as they crop up.

 

[Cherenkovblue]

Either way, allowing mediocrity to gain purchase is what lead to this sort of situation.

I blame Eric S. Raymond for this. People tolerating that brain-addled walrus-looking degenerate ass and his pants-on-head retarded notions are what led to people thinking they could somehow create software by committee.