2 ms·

It's a good thing for the BBC that Mellanox didn't agree with you, eh? #1 is trivially true for all products. #2 is essentially saying "if your code is crap,

by dsr_ 9y ago

It's a good thing for the BBC that Mellanox didn't agree with you, eh? #1 is trivially true for all products. #2 is essentially saying "if your code is crap, you will get crappy contributions". Well, if your code is crap, maybe you want to fix that? #3 is valid. You don't necessarily get great results without putting in a little effort.

alacombe 9y ago
#1 is not true for bazaar-style (ie. rather few inertia) open-source projects, say the Linux kernel. At best, subsystem maintainers can push their own agenda, but even this level of control is rather limited. However, I do concede that it's rather true for non-profit focused cathedral-style (ie. lots of inertia) projects, say, the BSD. #2 does not mean that code is crappy at all, unless you consider that not writing down every single assertion made by a developer who wrote the whole subsystem as "crappy". In which case, I can assure you that all software is crappy. This might sounds as a huge generalization, but unless infinite amount of time and money, everything is a compromise, especially when deliveries are constrained. Devs who are working daily on the codebase tends to know these compromises way better than newcomers. That's my point.
- bogomipz 9y ago
  >"#1 is not true for bazaar-style (ie. rather few inertia) open-source projects, say the Linux kernel. " Can you elaborate on what you mean here? Is this reference to "the cathedral and the bazar?" What is meant by "rather few inertia"? Thanks.
  - alacombe 9y ago
    Yes, less inertia. If the Linux folks decides to change a central datastructure, they do it, don't care if anything break with some proprietary module. With the BSD... well, they can't even agree on a modern DCVS, changing any central kernel datastucture is pretty much a lot fight (I tried...). Same logic with risk-averse companies.

2 ms·

It's a good thing for the BBC that Mellanox didn't agree with you, eh? #1 is trivially true for all products. #2 is essentially saying "if your code is crap,

by dsr_ 9y ago

alacombe 9y ago
#1 is not true for bazaar-style (ie. rather few inertia) open-source projects, say the Linux kernel. At best, subsystem maintainers can push their own agenda, but even this level of control is rather limited. However, I do concede that it's rather true for non-profit focused cathedral-style (ie. lots of inertia) projects, say, the BSD. #2 does not mean that code is crappy at all, unless you consider that not writing down every single assertion made by a developer who wrote the whole subsystem as "crappy". In which case, I can assure you that all software is crappy. This might sounds as a huge generalization, but unless infinite amount of time and money, everything is a compromise, especially when deliveries are constrained. Devs who are working daily on the codebase tends to know these compromises way better than newcomers. That's my point.
- bogomipz 9y ago
  >"#1 is not true for bazaar-style (ie. rather few inertia) open-source projects, say the Linux kernel. " Can you elaborate on what you mean here? Is this reference to "the cathedral and the bazar?" What is meant by "rather few inertia"? Thanks.
  - alacombe 9y ago
    Yes, less inertia. If the Linux folks decides to change a central datastructure, they do it, don't care if anything break with some proprietary module. With the BSD... well, they can't even agree on a modern DCVS, changing any central kernel datastucture is pretty much a lot fight (I tried...). Same logic with risk-averse companies.