They also get much more control. If they employ most of the core FreeBSD devs they basically have their own OS that they can do what they like with. If they want some change that benefits their use case at the detriment of other people they can pretty much just do it.
The flip side is of course that in this scenario they would have to finance most improvements. In Linux land the cost of development is shared across many, which one might expect to yield a generally better product.
When netflix was founded the only viable commercial linux vendor was rhel and the support contract would have been about the same as just hiring the fbsd core team at salary.
People really do not remember the state of early linux. Raise a hand if you have ever had to compile a kernel module from a flash drive to make a laptops wifi work, then imagine how bad it was 20 years before you tried and possibly failed at getting networking on linux to work, let alone behave in a consistent manner.
The development costs were not yet shared back then, most of the linux users at the vendor support level were still smaller unproven businesses and most importantly if you intend to build something that nobody else has you do not exactly want to be super tied to a large community that can just take your work and directly go clone your product.
Hiring foss devs and putting them under NDA for everything they write that doesn't get upstreamed is an excellent way to get nearly everything upstreamed aswell, and the cost of competitors then porting these merged upstream changes back down into their linux is not nothing, so this gives a competitive moat advantage.
Netflix, the online service, launched in 2007. The previous business, doing DVD mailing, had no such high bandwidth serving requirements. You're exaggerating the timeline quite a lot.
> When netflix was founded the only viable commercial linux vendor was rhel and the support contract would have been about the same as just hiring the fbsd core team at salary.
AFAIK, currently, Netflix only uses FreeBSD for their CDN appliances; their user facing frontend and apis live (or lived) in AWS on Linux. I don't know what they were running on before they moved to the cloud.
I don't think they started doing streaming video until 2007 and they didn't start deploying CDN nodes until 2011 [1]. They started off with commercial CDNs for video distribution. I don't know what the linux vendor marketplace looked like in 2007-2011, but I'm sure it wasn't as niche as in 1997 when Netflix was founded. I think they may have been using Linux for production at the time that they decided to use FreeBSD for CDN appliances.
> Hiring foss devs and putting them under NDA for everything they write that doesn't get upstreamed is an excellent way to get nearly everything upstreamed aswell, and the cost of competitors then porting these merged upstream changes back down into their linux is not nothing, so this gives a competitive moat advantage.
I don't think Netflix is particularly interested in a software moat; or they wouldn't be public about what they do and how, and they wouldn't spend so much time upstreaming their code into FreeBSD. There's an argument to be made that upstreaming reduces their total effort, but that's less true the less often you merge. Apple almost never merges in upstream changes from FreeBSD back into mac os; so not bothering to upstream their changes saves them a lot of collaborative work at the cost of making an every 10 years process a little bit longer.
At WhatsApp, I don't think we ever had more than 10 active patches to FreeBSD, and they were almost all tiny; it wasn't a lot of effort to port those forward when we needed to, and certainly less effort than sending and following up on getting changes upstream. We did get a few things upstreamed though (nothing terribly significant IMHO; I can remember some networking things like fixing a syncookie bug that got accidentally introduced and tweaking the response for icmp needs frag to not respond when the requested mtu was at or bigger than the current value; nothing groundbreaking like async sendfile or kTLS).
The only patch to FreeBSD I maintained was hacking up FreeBSD 2.x to embed Hughes mSQL to back getpwnam etc and radius/tacass. I also needed to exceed the uid limit and came up with hacky uid for the customer and gid as the account letting each customer have the 30k or whatever account ids. I shared the idea with friends at Teleport ISP in Portland who ended up doing something similar with Oracle I think. I think the same sort of thing lead to vservers that best.net used with BSDi and eventually FreeBSD jails was developed and significantly better than my hack job so I migrated the isp over to using jails.
This development, but not all of the other things that go into a kernel and distro. If they pocket the whole core team, then they end up paying for all of the work, not just the few optimizations they really care about.
> In Linux land the cost of development is shared across many, which one might expect to yield a generally better product.
And you have more cooks in the kitchen tweaking things that you also want to work on, so there's a higher chance of simply conflicts, but also folks that want to go in a completely different direction technically/philosophically.
That's not really possible with Linux.