Open-Source Software Architecture
Table of contents:-
The kernel: the engine at the centre
The layered stack: from hardware to applications
Licensing: the architectural glue of open source
Open-source hardware and the expanding ecosystem
There is a quiet elegance to the way open-source operating systems are put together. Whether you are running FreeBSD on a production server, Debian on a workstation, OpenBSD on a firewall, or a custom Linux distribution on an embedded device, the same fundamental architectural ideas run through all of them. Understanding those ideas is not just for kernel hackers — it is genuinely useful for anyone who installs, administers, builds on, or simply relies on open-source software. So let us walk through it properly.
The kernel: the engine at the centre
Every open-source operating system is built around a kernel — the privileged core of software that owns the hardware and mediates everything else. The kernel is what runs in protected mode, managing the CPU, memory, storage, and networking, and making those resources available to user processes through a well-defined interface called system calls.
The Linux kernel is classified as a monolithic kernel architecturally, since the entire OS runs in kernel space, yet its design is modular — it can be assembled from modules that in some cases are loaded and unloaded at runtime. That combination of qualities is rather clever. A monolithic kernel defines a high-level virtual interface over computer hardware, and most of them enforce a logical separation between subsystems, especially between the core kernel and device drivers, with relatively strict APIs that must be used to access services offered by one subsystem or another.
The BSD family — FreeBSD, NetBSD, OpenBSD, and DragonFly BSD — shares the same architectural heritage. The 4.4BSD kernel provides four basic facilities: processes, a filesystem, communications, and system startup. The kernel is the part of the system that runs in protected mode and mediates access by all user programs to the underlying hardware — including the CPU, disks, terminals, and network links — as well as software constructs such as the filesystem and network protocols.
BSD projects maintain the entire operating system, not only the kernel. This is a meaningful distinction. The BSD kernel handles process scheduling, memory management, symmetric multiprocessing (SMP), and device drivers, while the C library — which in BSD systems is derived from Berkeley code rather than the GNU project — forms the base API for all of userland. Utilities like shells, file tools, compilers, and linkers are developed and released together with the kernel as a coherent whole, which simplifies compatibility testing and system coherence.
Microkernels take the opposite approach. A microkernel is one where large parts of the kernel are protected from each other, usually running as services in user space. Because significant parts of the kernel are now running in user mode, the remaining code that runs in kernel mode is significantly smaller. In a microkernel architecture, the kernel contains just enough code to allow for message passing between different running processes — practically, implementing the scheduler and an IPC mechanism in the kernel, as well as basic memory management to set up the protection between applications and services. Real-time systems like QNX use microkernel designs, trading raw performance for fault isolation. Most general-purpose open-source operating systems — Linux, FreeBSD, NetBSD, OpenBSD — are monolithic, because the performance benefits of keeping everything in a single address space outweigh the modularity advantages of splitting it up.
DragonFly BSD takes an interesting middle path. DragonFly belongs to the same class of operating systems as other BSD-derived systems and Linux, based on the same UNIX ideals and APIs and sharing ancestor code with other BSD operating systems, but it provides an opportunity for the BSD base to grow in an entirely different direction. Its kernel makes heavy use of per-CPU messaging and lock-free data structures to achieve very high SMP scalability, and its flagship HAMMER2 filesystem brings instant, mount-writable snapshots, compression, and deduplication at the filesystem level.
The layered stack: from hardware to applications
The diagram above captures the essential reality: open-source systems are layered, and each layer communicates with its neighbours through defined interfaces. The hardware sits at the bottom. Above it come device drivers and hardware abstraction. Above that, the kernel. And above the kernel, the C library bridges kernel space to user space, after which all applications, daemons, and desktop environments live.
Unix systems use a centralised operating system kernel which manages system and process activities. All non-kernel software is organised into separate, kernel-managed processes. Unix systems are preemptively multitasking: multiple processes can run at the same time, or within small time slices and nearly at the same time, and any process can be interrupted and moved out of execution by the kernel.
The Virtual File System (VFS) is one of the most architecturally elegant pieces of this stack. A VFS is an abstract layer on top of a more concrete file system. Its purpose is to allow client applications to access different types of concrete file systems in a uniform way — for example, to access both local and remote file systems through the same interface. A file object represents a file opened by a process — also known as an "open file description" in POSIX parlance — and this is how the VFS can manipulate an open file. This abstraction is why a Linux system can mount ext4, XFS, Btrfs, NFS, and FAT all at once, with user applications none the wiser about which underlying system they are hitting.
The Filesystem in Userspace (FUSE) mechanism extends this even further. FUSE allows userland code to plug into the virtual file system mechanism in Linux, NetBSD, FreeBSD, OpenSolaris, and macOS. FUSE was merged into the mainstream Linux kernel tree in kernel version 2.6.14. Today, FUSE powers everything from SSHFS (mounting remote directories over SSH) to distributed object-store filesystems at petabyte scale.
The C library is the final mediating layer between applications and all of this. The C library — such as glibc or musl — wraps system calls and implements POSIX APIs. Applications rarely invoke system calls directly; they use library wrappers. On x86_64, the syscall instruction transitions from user mode to kernel mode, executing the requested service and returning a result. This is the contract that makes an application portable across distributions and BSDs: write to the POSIX interface, and you can reasonably expect it to run anywhere that honours it.
Licensing: the architectural glue of open source
Architecture is not just technical. The legal and social architecture of open-source software — its licensing — is equally foundational. Licensing determines who can use, modify, and redistribute the code, and whether derivative works must remain open.
The most popular open-source licences include the MIT licence, BSD licences (3-clause and 2-clause), the Apache 2.0 licence, and the GNU General Public Licence (versions 2.0 and 3.0). These licences continue to lead the way as the go-to choices for countless open-source projects worldwide.
There are two broad camps. Permissive licences — MIT, BSD, Apache 2.0 — place minimal restrictions on how code is used or distributed. Anyone can take the code, modify it, and even incorporate it into proprietary products, as long as they preserve attribution. This is why the BSD-licensed networking stack from 4.4BSD ended up in macOS, and why MIT-licensed libraries are found throughout the commercial software industry. Copyleft licences — primarily the GNU General Public Licence in its various versions — require that any derivative work distributed to others must also be released under the same terms. The Linux kernel is licensed under the GNU General Public Licence version 2, with an exception for system calls that allows code calling the kernel via system calls not to be licensed under the GPL.
The OpenBSD project emphasises portability, standardisation, correctness, proactive security, and integrated cryptography. OpenBSD maintains a strict licence policy, strongly preferring ISC and BSD licences. The project has, on more than one occasion, replaced or removed code that did not meet its licence standards, even writing fresh implementations of critical tools from scratch when necessary. The OpenSSH suite — now arguably the world's most widely deployed secure shell implementation — was one such effort, and it is licensed under a BSD-style licence that makes it freely usable on virtually any platform.
The Apache Licence 2.0 adds explicit patent grants to the permissive model, which matters considerably in commercial and enterprise contexts where patent exposure is a real legal concern. Choosing between these licences is not merely a philosophical exercise — it shapes who will contribute to a project, how it gets adopted commercially, and how it interacts with dependencies.
Open-source hardware and the expanding ecosystem
Architecture does not stop at software. The same philosophy that drives open-source software — freely available specifications, collaborative improvement, no vendor lock-in — has been applied with increasing seriousness to hardware instruction set architectures.
RISC-V is the most significant outcome of this movement. It is a free and open instruction set architecture (ISA) based on reduced instruction set computing principles, governed by the RISC-V International foundation. Operating system support exists for the Linux kernel, FreeBSD, NetBSD, and OpenBSD. The preliminary FreeBSD port to the RISC-V architecture was upstreamed in February 2016 and shipped in FreeBSD 11.0. As one of only seven CPU architectures, Debian Linux has officially supported RISC-V since Debian Trixie, which was released in August 2025.
The FreeBSD Foundation's 2024 development report confirmed active ongoing investment. The RISC-V 64-bit Support project, driven by Mitchell Horne, Ruslan Bukin, and Jari Sihvola, focuses on enabling FreeBSD to run efficiently on the RISC-V architecture, with work including improving kernel and user-space compatibility and optimising performance for RISC-V-based systems.
RISC-V is particularly compelling because it is open at the ISA level — meaning anyone can design a processor that implements it without paying royalties. This has energised a wave of development across industrial, research, and hobbyist communities. From server-grade SoCs with dozens of cores to microcontrollers for IoT devices, the same operating systems that run on x86 and ARM are being actively ported to RISC-V, with Linux and the BSD family at the leading edge.
NetBSD is especially notable here for its portability philosophy. NetBSD aims to provide a freely redistributable operating system that professionals, hobbyists, and researchers can use in any manner they wish, with a main focus on portability through the use of clear distinctions between machine-dependent and machine-independent code. It runs on a wide variety of 32-bit and 64-bit CPU architectures and hardware platforms, and is intended to interoperate well with other operating systems.
Independent Linux distributions add yet another dimension to this ecosystem. Distros like Debian, Arch Linux, Alpine Linux, and Gentoo each make distinct architectural choices — in their init systems, package managers, C library implementations (glibc vs musl), update cadences, and security hardening approaches — while all building on the same kernel and GNU/POSIX foundation. This diversity is a strength: it means the ecosystem as a whole explores a much wider design space than any single project could.
The emergence of Rust as a systems programming language is reshaping the architectural future of this entire space. Rust support was merged into the mainline Linux kernel with Linux 6.1 in December 2022, valued for its memory safety guarantees — eliminating entire classes of bugs such as use-after-free and buffer overflows that are common in C and have caused serious security vulnerabilities. By 2026, Rust-written subsystems and drivers are actively being merged and refined. BSD projects are watching this closely, with several already experimenting with Rust in their toolchains and userland utilities.
Conclusion
Open-source software architecture, at its heart, is about layered abstraction, clearly defined interfaces, and the freedom to study, modify, and build upon what others have created. The monolithic-but-modular kernel design that Linux and the BSDs share, the VFS abstraction that lets a dozen different filesystems coexist transparently, the POSIX interface that keeps applications portable, the licensing frameworks that govern how all of this flows between projects and organisations — these are not separate concerns but interlocking parts of a coherent whole. Add the rise of open-source hardware through RISC-V, and it becomes clear that the open-source architectural tradition is not standing still. It is actively expanding, taking on new platforms, new languages, and new challenges, driven by the same global community that has always been its engine.
Disclaimer
All product names, operating system names, trademarks, and registered marks referenced in this article — including but not limited to Linux®, FreeBSD®, OpenBSD®, NetBSD®, DragonFly BSD, RISC-V®, GNU®, Debian®, Ubuntu®, and others — are the property of their respective owners. The Distrowrite Project has no affiliation with, nor endorsement from, any of these organisations or projects. Every reasonable effort has been made to ensure the accuracy and factual integrity of the information presented, drawing only from official and reputable public sources; however, open-source ecosystems evolve rapidly and readers are encouraged to consult primary project documentation for the most current details. The Distrowrite Project does not endorse, promote, or support any activities involving malware, viruses, exploits, or any harmful content that may compromise the security, integrity, or availability of networks, devices, systems, or other infrastructure.
References
The Linux Kernel Archives — https://www.kernel.org/
Linux Kernel Documentation — https://docs.kernel.org/
Linux Kernel Subsystem APIs — https://docs.kernel.org/subsystem-apis.html
Overview of the Linux VFS — https://www.kernel.org/doc/html/next/filesystems/vfs.html
The FreeBSD Project — https://www.freebsd.org/
Explaining BSD — FreeBSD Documentation Portal — https://docs.freebsd.org/en/articles/explaining-bsd/
The Design and Implementation of the 4.4BSD Operating System — FreeBSD Docs — https://docs.freebsd.org/en/books/design-44bsd/
FreeBSD Foundation: A Year of Sponsored Development in 2024 — https://freebsdfoundation.org/blog/freebsd-foundation-a-year-of-sponsored-development-in-2024/
OpenBSD — https://www.openbsd.org/
DragonFly BSD — https://www.dragonflybsd.org/
Comparison of BSD Operating Systems — Wikipedia — https://en.wikipedia.org/wiki/Comparison_of_BSD_operating_systems
Unix Architecture — Wikipedia — https://en.wikipedia.org/wiki/Unix_architecture
Virtual File System — Wikipedia — https://en.wikipedia.org/wiki/Virtual_file_system
Filesystem in Userspace (FUSE) — Wikipedia — https://en.wikipedia.org/wiki/Filesystem_in_Userspace
RISC-V — Wikipedia — https://en.wikipedia.org/wiki/RISC-V
Open Source Initiative — Licences — https://opensource.org/licenses
Top Open Source Licences in 2025 — Open Source Initiative — https://opensource.org/blog/top-open-source-licenses-in-2025
Linux Kernel Introduction — linux-kernel-labs — https://linux-kernel-labs.github.io/refs/heads/master/lectures/intro.html
Monolithic Kernel — Wikipedia — https://en.wikipedia.org/wiki/Monolithic_kernel
⚙
Comments
Post a Comment
Hello and welcome to The Distrowrite Project! We appreciate your engagement and value diverse perspectives. Our community thrives on respectful and constructive discussions. Please ensure your comments align with our guidelines: no hate speech, personal attacks, or spam. Let us foster a positive environment where everyone feels comfortable to share their thoughts and insights. Kindly direct any complaints and suggestions for any software/hardware directly, clearly and politely to the respective developer(s). Thank you for being a part of our community!