Opensource has some scalability limits. A recent blog post shows that e.g. Gentoo is suffering from similar effects as Debian.

I believe this is a matter of size, so I doubt that Ubuntu will be immune to this just by it’s Code of Conduct and similar things.

There is this well-known idiom: “too many cooks spoil the broth” - I think this applies to Opensource work, too.

Given that we all want “democratic” work, without having a cabal do the important decisions, I see only one way to resolve this.

Subprojects. Just like a distribution doesn’t inherit all the software package communities problems, we should try to avoid “aggregating” all the issues at a distribution level.

And if you take for example Gnome, many developers are involved only in a few applications, and the communities in each application are probably not of the “critical mass”.

Examples of such subprojects in Debian include:

  • installer work
  • architecture porters
  • team maintainance of large package sets

Maybe we can find a way to make more use of these effects, that smaller groups usually work together much better. I’m not sure yet how to add extra “sub-communities”. Some like team maintainance oranize themselves, which is probably best. Some parts can move to freedesktop, becoming “upstream”, and joining efforts with other distributions. Some were created on “alioth”. So I think Debian is already on the right track here.

Anyway, I’m not a “key player” in Debian, and I’m probably not going to change this. But I’ll personally try to follow some simple guidelines to make life nicer for everyone.

  • I try to not participate in flame wars. If a mailing list is frequently ridden by flame wars, it’s best to leave it alone. There will just be new flamewars coming up again and again. Instead, I try to use mailinglists with fewer people, that maybe are more on-topic.
  • I don’t read threads that obviously got out of hand.
  • I don’t read debian-devel. It’s a waste of time.
  • I try to keep out of other peoples work. Either I become a “serious” contributor, or I let them do what they think it’s best. I’m likely less capable of seeing how it all works together if I’m not closely involved. Pinging or filing “wishlist” bugs is of course okay, but you have to accept the decision of those doing the actual work.
  • I try to keep stuff away from the full community. Discussing it within a smaller group (the people who actually do the job) is more productive, and you probably won’t get much extra results from asking a larger group - but you’ll end up with lots more fighting.