I disagree with you on both counts. Cathedral development is not about source availability (Wall uses emacs and GCC as an example of Cathedralism for heavens sakes), it's about source modibility. Theoretically two different projects under the same license could have different approaches. Very few high level architectural decisions are made by the Linux maintainers (unless they are coding it), they're there to say, "yes" or "no". Some of the most important features in Linux, cgroups, namespaces, etc, came from outside the maintainer team. By comparison, NetBSD has a highly top-down approach. The source might be readily available, but good luck landing a big patch.
At the time ESR wrote the essay, both Emacs and GCC did use the Cathedral development model I speak of. They've only opened up since due to forks like XEmacs and EGCS which started to eat GNU's lunch. The FSF eventually had to cave in to the Bazaar model because it works.
Furthermore, people without committer access land patches in the BSD's all the time. In fact, that's how you get committer access: you first start contributing patches to the appropriate mailing list where existing committers can review them, discuss them, and perhaps merge them. It's not terribly different from sending a pull request on GitHub, and afaik it's pretty much the same process used by the Linux kernel.
