3 ms·

Hardly anything non-obvious or controversial in there, how boring ;) This one though: > The true open source way: accept everything that comes I never heard

Hardly anything non-obvious or controversial in there, how boring ;) This one though: > The true open source way: accept everything that comes I never heard this said about open source development, or experienced this in open source projects myself. PS: My pet theory is that big teams create big code bases in short time and under bureaucratic code-design rules which leave little room for personal initiative. E.g. also known as 'enterprise software development'.

lawn 2y ago
Accepting everything that comes in an open source project is a sure way to get scope creep, ever more demanding users, and most likely burnout. Horrible advice I'd say.
mytailorisrich 2y ago
I think he is being a little facetious to make a point, based on the open source mantra that there can be no restriction on code modification.
praptak 2y ago
> Hardly anything non-obvious or controversial in there, how boring ;) Good advice tends to be boring (and hard to implement!) ;)
relistan 2y ago
Pretty sure it’s a reference to ideas like this: https://felixge.de/2013/03/11/the-pull-request-hack/ https://felixge.de/2013/03/11/the-pull-request-hack/ which have been popular for a long time in open source.
rcxdude 2y ago
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)

lawn 2y ago

Accepting everything that comes in an open source project is a sure way to get scope creep, ever more demanding users, and most likely burnout. Horrible advice I'd say.

mytailorisrich 2y ago

I think he is being a little facetious to make a point, based on the open source mantra that there can be no restriction on code modification.

praptak 2y ago

> Hardly anything non-obvious or controversial in there, how boring ;) Good advice tends to be boring (and hard to implement!) ;)

relistan 2y ago

Pretty sure it’s a reference to ideas like this: https://felixge.de/2013/03/11/the-pull-request-hack/ https://felixge.de/2013/03/11/the-pull-request-hack/ which have been popular for a long time in open source.

rcxdude 2y ago

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)