Maintaining FreeBSD in a Commercial Product – Why Upstream Contributions Matter

FreeBSD is a mature, secure, and high-performance operating system widely adopted across infrastructure, appliances, storage, and networking products. However, integrating FreeBSD into a commercial product isn’t just about technical excellence; it’s also about long-term sustainability. And that hinges on a company's upstream strategy. 

The Temptation of the Fork 

When building a product, it’s easy to start with a clean snapshot of FreeBSD and make local changes: 

• Add drivers 

• Implement new kernel features 

• Tune kernel parameters 

• Patch libc or system utilities 

• Integrate internal tooling 

This works great in the early stages, and often feels faster. You’re not waiting for upstream review cycles or coordinating with maintainers. You control your own fate. But over time, these local changes diverge. What starts as "a couple of patches" becomes a full fork. And when FreeBSD moves forward – with new security updates, performance improvements, or kernel features – reintegrating your changes becomes harder and more expensive. 

A good example the Klara team worked on is when client inherited such a fork. It had originally begun as a 12.1-based system with only three patches. By the time we got involved, it had over 70 changes across the kernel, rc scripts, and base utilities. Trying to move it to 13.2 required re-porting and retesting every patch, rebuilding CI pipelines, and reconciling upstream changes they’d never tracked. The estimated cost? Nearly 6 engineer-months. 

In technical terms, this increases integration cost, regression risk, and CI/CD complexity. More importantly, it delays access to upstream improvements — security updates, performance gains, and platform features that are actively maintained. 

Upstreaming as Cost Control and Tech Debt Avoidance 

Contributing code and improvements upstream is not just a matter of community engagement. It directly reduces operational and engineering costs: 

1. Lower Upgrade Friction - Changes maintained in upstream reduce the need to reapply, test, and adapt patches when moving to a new release. 
2. Easier Audit and Compliance - Security audits and certifications are streamlined when product behavior aligns with publicly maintained code and traceable commit history. 
3. Shared Maintenance - When contributions land in upstream, they benefit from the ongoing testing, review, and maintenance provided by the community. 
4. Developer Productivity - New engineers or external partners familiar with FreeBSD can contribute effectively without needing to ramp up on undocumented forks. 
5. Risk Reduction - Minimizing out-of-tree patches reduces the chance of silent breakage due to upstream changes, and avoids rework during regression cycles. 

Barriers to Upstreaming 

Despite the clear benefits, some organizations hesitate to upstream. Common concerns include: 

• Perceived slowdowns due to review cycles: In reality, most FreeBSD changes can be proposed incrementally. Many receive prompt feedback when scoped properly. 

• Code quality concerns: Upstreaming encourages higher standards, which ultimately improves maintainability. 

• Internal complexity: Not all business logic belongs upstream. The key is to isolate system-facing changes and submit those cleanly. 

• Unfamiliarity with community process: The FreeBSD community is small but responsive. Collaborating with experienced contributors streamlines the path to commit. 

A Practical Upstream Strategy 

A good upstream strategy begins with how changes are scoped and structured. Successful teams isolate system-level modifications — such as kernel interfaces, device drivers, or base utilities — from proprietary business logic. This separation ensures that components intended for upstream contribution remain portable, maintainable, and free of dependencies that would impede community acceptance. Designing for upstream from the outset means leveraging FreeBSD’s established mechanisms: sysctls for tunables, loadable kernel modules for hardware integration, and userland wrappers where abstraction is needed. 

Timely, incremental contributions are critical. Rather than batching large, monolithic diffs, organizations should submit discrete, logically-contained changes as soon as they are internally validated. This reduces review burden, increases the likelihood of acceptance, and helps identify potential regressions earlier. Submitting early also creates space for upstream maintainers to provide architectural guidance — especially relevant for changes touching kernel subsystems, security models, or cross-platform assumptions. 

Even in cases where upstreaming is delayed due to internal roadmap constraints, it’s essential to maintain a clear separation of changes that could be upstreamed in the future. Tracking these deltas independently, through modular patchsets or git branches, avoids rework and accelerates upstream readiness when priorities shift. Proactively engaging with maintainers — whether through review discussions, mailing lists, or dedicated FreeBSD working groups — ensures that contributions align with community expectations and streamlines the path to commit. 

Theory Into Practice 

Klara recommends an “Upstream First” approach to maximize the advantages and avoid potential delays when upstreaming. Developing the feature targeted to the upstream branch from the start acts as a sort of forcing function to design the feature with the general applicability, upstream code style, and review process in mind. Building the feature for upstream and then integrating it into the product ensures that the upstreaming process does not become a deprioritized task at the end of the project, where time may be short, upstream may have changed, and the temptation to accept technical debt is at its highest. 

Below are some examples of features developed and upstreamed by Klara on behalf of customers, so they could deploy the functionality in their product without adding to their local diff and creating future work each time they update to a newer FreeBSD base: 

• TarFS – mount a tar file directly as a filesystem, including support for seekable compression and veriexec. 

• Socket Splicing – Offload packet processing to the kernel for load balancers, proxies, and other applications that need to inspect or intercept some traffic while having some bulk traffic bypass the userspace application. 

• AES-GCM acceleration on ARMv8 – Improve cryptographic performance in the kernel on the ARMv8 architecture by taking advantage of platform specific hardware acceleration. 

• Debugger security restrictions – Limit the debugger to commands they cannot be used to leak secrets such as private keys by inspecting memory. Allows the debugger to be enabled on production appliance builds for better field support. 

• Vectorized AES Support – Leverage advanced instructions on newer generation x86_64 processors to double encryption performance 

Strategic Value 

Upstreaming is a force multiplier. It reduces total cost of ownership, improves product robustness, and aligns engineering practice with the lifecycle of the FreeBSD platform. For any organization building commercial software on FreeBSD, upstreaming isn’t optional overhead — it’s a strategic decision that enables scale and sustainability. 

About Klara Inc. 

Klara is a FreeBSD and ZFS development consultancy. We help organizations build, maintain, and scale products based on FreeBSD. Our team includes upstream contributors and committers who align product goals with open source best practices. 

If you’re building on FreeBSD and want to do it right — we can help you upstream what matters, and maintain what makes your product unique.