5 ms·

> it makes your product much more attractive to people who will improve and promote your product for free This is a huge myth. 1) even if you open-source, the

> it makes your product much more attractive to people who will improve and promote your product for free This is a huge myth. 1) even if you open-source, the company retains control over the project, and push their priorities first. 2) codebase can be huge and intricate, very few external contributors would actually put the time to learn it, leading to poor contribution (ie. might fix a given problem, but breaks other subsystems) 3) even if there is external contributors, is the company willing to put the manpower to process the changes and handle community interaction ? Ie. do you really want to handle bikeshed'ing style patches, potentially costing time to actual paid devs ? Most of the time, niche opensource contributions are merely are more of a marketing tool (or HR tool ala. "your profile looks great however we're too greedy to hire you, please contribute to our software for free").

dsr_ 8y 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 8y 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 8y 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 8y 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.

dsr_ 8y 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 8y 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 8y 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 8y 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.