4 ms·

I think the best, and most traditional, comparison is the Cathedral and the Bazaar[1]. Pretty much every observation the author makes can be framed in this comp

by hacknat 10y ago

I think the best, and most traditional, comparison is the Cathedral and the Bazaar[1]. Pretty much every observation the author makes can be framed in this comparison. BSD has built-in libraries, and has a cohesive architecture. Linux is popular precisely because of its chaos. It is incredibly easy to hack some feature together in Linux. It will probably start out as ugly, but if enough people glom onto it, it will become great and maybe even secure. It is pretty clear that Linux became popular not because it was the best, but because it was the fastest development path. Obviously BSD has its uses, but if you're looking to develop a new feature and get it out the door (in OS development) Linux is the easiest choice. [1]ESM https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar Edit: I remember reading somewhere that Netflix uses BSD for all of its net-intensive servers as network performance tuning on BSD is, at least by reputation, better, but they use Linux as their workhorse. They employ some FreeBSD committers though (obviously not everyone can do that).

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

by hacknat 10y ago

groovy2shoes 10y ago

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.