[andrewflnr]

Ah, of course, the "just fork a whole community" tactic, no big deal.

I mean, really, why would you bother trying to change anything as long as the hypothetical possibility exists of going elsewhere? Is there a single thing you don't like about your current circumstances? Just leave! That will definitely be better for everyone, and there definitely won't be any crippling ongoing costs that result.

[lcnPylGDnU4H9OF]

But actually, yes. His complaints are seemingly all about how the community is run.

> It should not take email chains that don't even fit on my screen to upstream a 1700-line patchset that implements 3 kernel modules.

> Between this and drive-by reviewers that make nitpick comments (most of which are wrong), no wonder stuff takes forever to upstream.

> It is very frustrating to have to defend it over hours/days/weeks/months ...

Regardless of the merit of these things, if this individual doesn't like it then I think it's totally appropriate to challenge them to do it better. Failing that, I'll risk erring on the thought that there are difficulties with running OSS communities that this person is downplaying.

[andrewflnr]

I don't think we disagree? My point is, "just fork it" is a ridiculous response to complaints about a community, and furthermore it's a special case of a broad category of ridiculous responses to complaints about how systems are run. It's just a cheap[0] way to avoid assessing the complaint on its merits, which we do both seem to think is necessary.

[0] Quite possibly a victim-blaming way, though not necessarily, depending first and foremost on the merits of the complaint...

[lcnPylGDnU4H9OF]

I suspect I was just unclear with my comment[0]. I do mean to say that even if there is merit to the person's complaints, it is a valid response to tell that person to go and do it themselves. I'm not convinced that they'll make something half as good and that's very relevant if they're going to be complaining. I'm less likely to take a person seriously if all they can add to a topic is, "This is bad and someone needs to make it better!" while remaining unwilling or unable to be that "someone". The minimum would be even just a suggestion of what to do instead.

Anyway, I actually think this is rather controversial with valid opposing perspectives, so I don't intend to invalidate yours! This is just where I land.

[0]

> if this individual doesn't like it then I think it's totally appropriate to challenge [said individual] to do it better

[andrewflnr]

Gotcha. A couple rejoinders. First: I think it's important to be able to name a problem, even if it's too hard to propose a solution right away, without people yelling at you to propose a solution or STFU. That just becomes, again, a cheap way to avoid acknowledging hard problems.

Second: that's still a much more reasonable objection than "just fork the community", which usually has costs ranging from obnoxious to crippling. The mere attempt could destroy lots of value for no benefit, and even if it succeeds things are likely to suck for a while for everyone involved. This is not an appropriate option to push just because there's an alleged process problem. Not even if the complainer genuinely should have proposed a solution, offered to do the work, or whatever.

[smoldesu]

What are the merits of the complaint, though? That it takes a long time for people to merge confusing code on undocumented hardware?

[andrewflnr]

I'm specifically not claiming anything about this particular complaint, only about your response.

[anikom15]

Forking whole communities is allowed, encouraged, and often has positive effects in open source. Does anyone suggest XEmacs (being both a code and community fork) or Wayland (being a community fork) as being wholly bad ideas?

[smoldesu]

The kernel developers and Asahi developers ultimately have the same goals, they just develop in different ways with different priorities. The kernel has always moved at a snails-pace, even for longtime contributors. Dealing with the quirks of unsupported hardware isn't their job, it's completely unsurprising that these maintainers don't take M1 support seriously in the same way they treat Intel or AMD-submitted patches.

If Apple wanted the Macbook to have quick Linux support, they should have merged the patches themselves. When you leave the community to do a corporation's job, things don't exactly move at a fast clip.