3 ms·

It's quite popular, the 'bazaar' approach in 'the cathedral and the bazaar'. I would say the number of projects with a cathedral approach nowadays is quite low.

It's quite popular, the 'bazaar' approach in 'the cathedral and the bazaar'. I would say the number of projects with a cathedral approach nowadays is quite low. That said, there is a sliding scale of difficulty of contributions to projects. I think, in general, a project that accepts more contributions is going to be more popular than one that doesn't, amongst users, because users will tend to prioritize features. So if you want people to use your software, you should make it easy to contribute. (I think for small projects which would like some help, accept-by-default makes a decent amount of sense. For larger ones, you want to have some process, but you also want to make sure that you help new contributors through the process, not just insist they figure it all out themselves)

moefh 2y ago
> It's quite popular, the 'bazaar' approach in 'the cathedral and the bazaar'. That's not the usual interpretation of "cathedral" and "bazaar" development models. The Linux kernel is the poster child of the "bazaar" style, and I don't think anyone sane would describe their model as "accept everything that comes" (for an obvious example, look at what's happening Rust in the kernel -- and even further: a lot of people tried adding C++ at various points, and we know what always happens[1]). "Cathedral" style is more commonly called "closed development" -- an example being the Lua language: it's fully open source (everyone is free to modify and distribute the changes), but the authors almost never show the development between releases and never accept patches. Neither of those fit "accept everything that comes". [1] https://lkml.org/lkml/2004/1/20/20 https://lkml.org/lkml/2004/1/20/20
- rcxdude 2y ago
  Yeah, it's a continuum: from an explicit "outside contributions not welcome" to "we'll accept more or less any contribution with little review" (zeromq, under the current maintainer, I know is an example of the latter when orginally it was much more the former). Most projects are somewhere in between (linux I'd say is relatively hostile to new contributions), and the extremes are rarer.
eptcyka 2y ago
Accept by default is what you do if you want to distribute malware.
- rcxdude 2y ago
  It doesn't mean you just click 'merge' on every request without ever looking at the code, just that you don't kick back to the submitter with a pile of extra work to do before you accept a bona-fide effort. (I don't think there's been any case of an open policy here causing a supply-chain attack)

moefh 2y ago

> It's quite popular, the 'bazaar' approach in 'the cathedral and the bazaar'. That's not the usual interpretation of "cathedral" and "bazaar" development models. The Linux kernel is the poster child of the "bazaar" style, and I don't think anyone sane would describe their model as "accept everything that comes" (for an obvious example, look at what's happening Rust in the kernel -- and even further: a lot of people tried adding C++ at various points, and we know what always happens[1]). "Cathedral" style is more commonly called "closed development" -- an example being the Lua language: it's fully open source (everyone is free to modify and distribute the changes), but the authors almost never show the development between releases and never accept patches. Neither of those fit "accept everything that comes". [1] https://lkml.org/lkml/2004/1/20/20 https://lkml.org/lkml/2004/1/20/20

rcxdude 2y ago
Yeah, it's a continuum: from an explicit "outside contributions not welcome" to "we'll accept more or less any contribution with little review" (zeromq, under the current maintainer, I know is an example of the latter when orginally it was much more the former). Most projects are somewhere in between (linux I'd say is relatively hostile to new contributions), and the extremes are rarer.

eptcyka 2y ago

Accept by default is what you do if you want to distribute malware.

rcxdude 2y ago
It doesn't mean you just click 'merge' on every request without ever looking at the code, just that you don't kick back to the submitter with a pile of extra work to do before you accept a bona-fide effort. (I don't think there's been any case of an open policy here causing a supply-chain attack)