When a post loving FreeBSD crests 500 points on Hacker News with 250 comments, the discussion reliably splits into two camps: developers who have run FreeBSD in production and nod along, and developers who have only heard of it and ask why anyone would bother when Linux works fine. Both camps mostly miss the most interesting thing about FreeBSD’s staying power, which is not any particular feature but the organizational feedback loop the BSD license makes possible.
What the BSD License Actually Permits
The BSD 2-Clause and BSD 3-Clause licenses allow anyone to take the code, modify it, ship it in a commercial product, and keep their modifications proprietary. There is no copyleft requirement. You do not have to publish what you changed.
This is the opposite of the GPL’s model, where modifications to GPL-licensed code must be made available under the GPL if you distribute the software. The GPL is a deliberate design choice that has produced enormous amounts of open-source software. The BSD license is a different deliberate design choice, and it has produced something specific: a class of commercial users who build core infrastructure on FreeBSD because they can.
Juniper Networks’ JunOS is built on FreeBSD. It runs on virtually every Juniper router and switch in production. NetApp’s ONTAP storage operating system is built on FreeBSD. Dell EMC’s Isilon OneFS is built on FreeBSD. Sony’s Orbis OS (PlayStation 4) and Prospero OS (PlayStation 5) are built on FreeBSD. None of these companies were required to publish their changes.
But several of them have contributed back anyway, and understanding why is where the interesting dynamics are.
The Virtuous Cycle
Netflix’s Open Connect CDN runs on FreeBSD. They serve a substantial fraction of North American internet traffic from FreeBSD appliances, and they have invested engineering resources in FreeBSD’s network stack in ways that the project could not have funded internally.
Drew Gallatin and others at Netflix developed kernel TLS (kTLS) for FreeBSD. The problem they were solving was specific: sendfile(2) can move file data from the page cache to a network socket without copying it through userland, which is extremely efficient for serving large files. But once TLS enters the picture, you need to encrypt the data somewhere, and the obvious place is userland, which breaks the zero-copy path. kTLS moves TLS encryption into the kernel, so sendfile can encrypt data in-place as it moves from the page cache to the NIC, without touching userland at all. The result, as Netflix has described publicly at EuroBSDCon, is over 100 Gbps from a single commodity server.
This work was contributed back to FreeBSD. It is now in the base system. It later informed the Linux kTLS implementation as well.
Netflix contributes because the contribution is in their interest. Every time freebsd-update ships a new release, their appliances benefit from base system improvements. Their engineers can spend time on network stack work knowing it will be maintained by the broader FreeBSD project rather than becoming a proprietary fork they have to carry forever. The BSD license does not require this; it permits it, which is different. The incentive structure is what produces the contribution.
Sony has contributed code to FreeBSD over the years, and Sony is a FreeBSD Foundation donor. Juniper has historically employed FreeBSD committers. These are not charities; they are organizations managing a dependency. Contributing upstream is cheaper than maintaining a fork, and the BSD license makes the decision to contribute purely a business calculation rather than a legal obligation.
The GPL Alternative and What It Produces
Linux’s GPL licensing produces contributions too, from Intel, AMD, Red Hat, Google, Meta, and hundreds of others. The mechanism is different: GPL requires that modifications to GPL code be published if you distribute the software, so companies that ship Linux-based products often have legal reasons to contribute upstream beyond just managing fork maintenance costs.
This has been enormously productive. The Linux kernel has thousands of contributors and moves extremely fast. The trade-off is that some commercial users who would prefer not to publish their work choose different stacks instead. The BSD license is a bet that commercial adoption creates better technical outcomes than copyleft requirements do, at least in certain domains.
For network infrastructure and storage operating systems, the BSD bet appears to have been correct. JunOS, ONTAP, and the PlayStation OS exist because their authors could build on FreeBSD without publishing proprietary internals. These deployments at scale create pressure and funding for FreeBSD quality that the project’s volunteer base alone could not sustain.
The Base System as a Contribution Surface
FreeBSD’s unified base system, where the kernel, libc, the network stack, the ZFS subsystem, the jail framework, and core utilities are all maintained in one source tree, makes commercial contributions more tractable than they might otherwise be. A change to the sendfile path, the TLS layer, and the socket API can land in a single review cycle because those components are all in the same repository under a coherent governance structure.
Since FreeBSD 13.0 migrated to OpenZFS 2.0 in 2021, the ZFS implementation has been the OpenZFS shared codebase rather than a separately-maintained port. The OpenZFS project now spans both Linux and FreeBSD, with the FreeBSD variant serving as a reference platform for testing because FreeBSD’s kernel interfaces are more stable across versions. Companies that care about ZFS quality, including storage vendors, have reason to test on FreeBSD and reason to fix issues they find.
The current stable branch, FreeBSD 14.2 released December 2024, ships with OpenSSH 9.9p1, OpenSSL 3.0.x, and Clang/LLVM 16 as the system compiler on amd64 and arm64. These are all components that commercial users depend on and that the FreeBSD base system guarantees are tested together before release. The update path is freebsd-update upgrade, which patches the entire base system atomically, followed by pkg upgrade to bring third-party software current. The two operations are independent and do not interfere with each other because base system software lives in /usr and third-party software lives in /usr/local, a boundary the package infrastructure enforces strictly.
Why This Matters for Infrastructure Decisions
If you are choosing a foundation for infrastructure that will run for a decade, the license of the underlying system is not a minor detail. It shapes who invests in the system, what they contribute, and whether those contributions land back in a place your systems can benefit from.
FreeBSD’s answer is: we will attract commercial users who can build proprietary products on us, and some of them will contribute improvements back when it suits their interests, and over time the system will be better for it. The kTLS work is the clearest example because it is both technically significant and publicly documented.
The FreeBSD Foundation provides institutional support, employs developers, and manages the project’s infrastructure. Its funding comes significantly from commercial users who have a stake in FreeBSD’s quality. That is a different organizational model from the Linux Foundation, which is larger and has different dynamics, but it is a coherent one.
None of this means FreeBSD is the right choice for most projects. The package ecosystem is smaller, consumer hardware support lags, and the community is narrower. For a Discord bot running on a rented VPS, the OS choice barely matters. But for the infrastructure that the bot’s hosting provider runs underneath it, or the CDN that serves its assets, or the storage system holding its database, FreeBSD’s particular combination of permissive licensing, unified base system, and commercial-user feedback loop has produced something durable. The original article is a personal account of that durability from someone living with it daily.