Next time management asks why the driver for your product should be open source, point out that it makes your product much more attractive to people who will improve and promote your product for free.
That is, sales will improve.
That is, sales will improve.
Imagine you are google and you have created your own custom build system. You now want to hire more people that are familiar with it. Unfortunately the potential applicant pool is exactly 0 because nobody outside of google can even start to learn how to use the google specific tools because they simply don't exist outside of google.
1. People knowing about it.
2. People needing it.
3. People trusting it.
Like a fire needs heat, oxygen and fuel, new products survive only when they get all three corners of the triangle. If your product is cheap enough, some people will try it when they think that they have a need for something like that; trust comes eventually. Open source builds trust that in the worst case, people using your product will have a glide path out instead of a sudden brick wall.
In the instant case, Mellanox gets a highly visible, reputable customer telling everyone in their industry that Mellanox NICs are high-performance, are trusted, and can be adapted to their needs. Anyone who reads this article and thinks about high-performance NICs will have a bit more trust in the Mellanox brand as a flexible system.
It is a very different application from what the BBC is describing. Rather than 1 80Gb/stream, we have tens of thousands of several Mb/s streams. And rather than kernel bypass, we use heavily optimized kernel path, via sendfile and in-kernel TLS.
One thing to note on topic, we developed a driver framework called 'iflib' in FreeBSD that is somewhat similar in scope to NDIS on Windows. If you write an iflib driver, you automatically get netmap support on FreeBSD. So we have support for all of Intel, and newer Broadcom as well, without potentially unfamiliar corporate devs having to understand the intricacies of soft ring management for userspace networking.
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").
#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.
#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.
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.