alchi icon indicating copy to clipboard operation
alchi copied to clipboard

why open source sucks and how to fix it - teamwork in groups of four

Open milahu opened this issue 3 months ago • 0 comments

Maintainer Burnout Is Real – Why Open Source Is Stagnating

What Needs to Change

Shared Ownership: Projects need more distributed governance models, not hero maintainers carrying everything.

"Shared Ownership" -- yes, the actual problems are social problems.

instead of balanced teams, many projects are ruled by petty tyrants (or unbalanced teams) who abuse their power for their selfish needs (not for all users), and so useful progress (for all users) is blocked "because i dont need it" (because a "vocal minority" drags everyone else down).

so how to create balanced teams? all successful organizations have long solved this problem: they sort their workers by personality type (alchi-types) (alchi-test), and then somehow connect different personality types into balanced teams, balanced by personality type.

since there are four base personality types, every balanced team needs exactly four people.

how to apply this to open source projects? every project needs four maintainers. (or a multiple of four.)

where do we find maintainers? we all have some network of friends. we should use this network to recruit the "missing puzzle pieces" for our projects. "hey, youre a type 1, our project needs a type 1, can you help?"

these "teams of four" should be stable, so communications are efficient, and stress-tolerance is high.

every "team of four" maintains multiple projects. all team members get notified of all changes in all projects.

people should be open about their personality type, and projects should be open about the personality types of their staff, so projects can easier recruit new workers, and workers can easier find new projects.

in an atomized culture, people contribute only to projects they actually need, but in the "teams of four" culture, people contribute to all projects maintained by their team, which includes projects they otherwise would not contribute to, and in exchange, other team members contribute back.

different people have different activity levels. to balance this, active people can join more teams, and less-active people can join less teams.

somehow connect different personality types

this is the main focus of my alchi project. my proposed solution is the pallas pattern (alchi.pallas-pattern.svg) (alchi-maps). but that is an implementation detail, and i expect that each "team of four" will find its own ways to communicate. maybe my pallas-pattern is wrong, maybe there are better solutions

related

  • 2025-09-22.ChatGPT-Second-class-citizen-design.md
    • Gatekeeping → controlling who gets in and which ideas are allowed, usually framed as “protecting quality” but often just a power reflex.
    • most people are not aware of the actual reasons (incompatible personality types), so they throw around some high-level "reasons" to appear "rational", while the actual forces at play are low-level instincts (gut feelings, subconscious, emotions, hormones, ...)
    • most people misattribute the source of conflict. They say things like “I disagree with your API design because…” but underneath it’s: dominance struggle, personality mismatch, clashing instinctual needs. So the “rational reasons” are mostly post-hoc justifications. This is very consistent with cognitive psychology: humans often generate reasons after the fact to cover instinct-driven decisions.
    • Maintainer–contributor conflicts are a modern form of sublimated ritual combat, where instinctual drives and personality incompatibilities disguise themselves as rational debates about software.
    • the actual conflict is personal, not rational ("people focus" versus "task focus")
  • 2025-09-21.ChatGPT-Ego-and-culture-dynamics.md
    • any atomized culture is doomed to fail, because humans are social animals by nature. so the actual problems are that too many people are alone in this world, when they should be in some group.
    • all groups should have a balance of smart and stupid people. so when a stupid member of group A is irrationaly (wrongly) attacking a smart member of group B, then smart members of group A can step in to "pull back" to false aggressor from group A (like a dog owner would pull back a stupid dog trying to attack someone), and then the conflict can be settled in a "civilized" manner, because smart and smart people meet on eye level, so they can debate the actual issue, without all the unnecessary drama caused by stupid people
  • hate-maintainers-censored - some of my experiences with bad maintainers
    • of course "bad" is very subjective, and all humans are selfish, so we all think "of course i am right and he is wrong", which can work in an atomized culture, where everyone thinks "i am smart" and "i am a winner", because these self-images are never challenged, there are no real comparisons... but for a team to work, there must be clear boundaries between "this is my strength" and "this is your strength"
  • Tragedy of the commons
    • The tragedy of the commons is the concept that, if many people enjoy unfettered access to a finite, valuable resource, such as a pasture, they will tend to overuse it and may end up destroying its value altogether.
    • The principal concern of Hardin's essay was overpopulation of the planet. To prevent the inevitable tragedy (he argued) it was necessary to reject the principle (supposedly enshrined in the Universal Declaration of Human Rights) according to which every family has a right to choose the number of its offspring, and to replace it by "mutual coercion, mutually agreed upon".
  • The Dark Side of Open Source: When Maintainers Burn Out
    • 4. Decentralize Ownership
      • Avoid “bus factor = 1”—require multiple admins for critical projects.
      • Linux survives because thousands contribute.
  • And this is why I hate Open Source Sometimes...
    • in the majority of cases, the bug reports are swiftly dismissed and closed by certain maintainers. Their comments range from "Not a bug, just a UX problem" to "Please file a ticket in system XY first before reporting here" and even "Sorry, but no fix." It's baffling. When I inquire further and seek clarification, most maintainers—when they choose to respond—become defensive and, in some instances, impolite. It's frustrating.
    • Is your tone inadvertently sounding rude?

milahu avatar Sep 24 '25 13:09 milahu