I agree that maintenance is always an issue, and should
always be an issue. So it's certainly a valid concern.
At the same time, I have to say, that at least for the kernel, I believe that at least part of the reasons we have gotten so many developers involved (and the Linux kernel probably has one or two orders of magnitude more people involved than most other projects) is twofold:
(1) we have lots of "independent" things that people can help maintain and aren't really horribly core code, and that don't make core people nervous.
For the kernel, this is mainly drivers. Most of our developers come from people working on some random detail in a driver. Some people never do anything else. Others end up becoming major developers (eg Greg KH started with "small driver details").
Quite frankly, we'd never fidn new developers if all our code was like the VFS layer or the VM code, which is really subtle and has horribly complicated rules wrt locking etc. A project needs
(2) we've never limited the project to one vision. There are lots of different users. Supercomputer people have different goals than mobile people, who have different goals from desktop people, who in turn have different goals from other
I wouldn't call the kernel exactly "inclusive" - we do have very high technical standards, and it's probably not the easiest project to get started with, but at the same time I do claim that the kernel has always been open to new uses and the fact that different people and organizations have different expectations and requirements.
Quite frankly, I think the gnome project has failed horribly wrt that second thing. I can tell from personal experience that it was what turned me off the project. Even before the whole "original gnome 3" disaster, I sent in a patch to make my two-button mouse more configurable and usable. It got rejected because it was "too confusing" to users, just for adding a new option in the mouse setup.
I'm not sure about the first point. There are certainly various different gnoma apps you can get involved with, but I also think that something like the extensions would be an excellent way for people to get their toes wet. So it's not at all clear that encouraging extensions would be a maintenance headache - it could equally well be the exact reverse, and be a vehicle to bring more people in.
(Of course, having lots of developers is also its own headache. Some of the most painful times in kernel development have been when the developer community grew and scaled, and me and my process didn't scale with it. So don't get me wrong: "more developers" can very easily mean "more headaches").