4 ms·

BSD development versus Linux development is not an example of the Cathedral and the Bazaar. That essay was about development process: under the Cathedral proc

BSD development versus Linux development is not an example of the Cathedral and the Bazaar. That essay was about development process: under the Cathedral process, development happened "behind closed doors" and the only time the public got access to source code was at release time; under the Bazaar process, development happened "in the open" and the in-development source tree was always available to the public (typically via a source control system). To see why the various BSDs are not an example of the Cathedral process, you only need to look at their source control. In fact, OpenBSD pioneered the idea of anonymous CVS -- before that, you needed an account to check out from the CVS repository: "When OpenBSD was created, de Raadt decided that the source should be easily available for anyone to read at any time, so, with the assistance of Chuck Cranor, he set up the first public, anonymous CVS server. At the time, the tradition was for only a small team of developers to have access to a project's source repository. Cranor and de Raadt concluded that this practice "runs counter to the open source philosophy" and is inconvenient to contributors. De Raadt's decision allowed "users to take a more active role", and signaled the project's belief in open and public access to source code." [1] [1]: https://en.wikipedia.org/wiki/OpenBSD#Open-source_and_open_documentation https://en.wikipedia.org/wiki/OpenBSD#Open-source_and_open_d...

hacknat 10y ago
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.
- groovy2shoes 10y ago
  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.

hacknat 10y ago

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.

groovy2shoes 10y ago
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.