ProBackend
agentic keyboards input
6 days ago7 min read

NextBSD Redux: AI Consumer Hardware and Apple's Darwin on FreeBSD

Joe Maloney's NextBSD Redux merges FreeBSD's robust kernel with Apple's open-source Darwin userland in a clean-room rebuild, using Anthropic's Claude as an official AI collaborator.

NextBSD Redux: Bringing Apple's Open Source Darwin to FreeBSD with AI Pair Engineering

Joe Maloney just did something that would've gotten him laughed out of any BSD conference ten years ago. He put Anthropic's Claude on the official NextBSD team page.

Not as a tool. Not as a dependency. As a collaborator. The project's homepage lists him alongside Claude, and when The Register asked how he was using it, his answer was refreshingly honest: "From my perspective, AI is a force multiplier here. It is my team of developers, but I am steering the entire thing."

The project he's steering — NextBSD Redux — is an ambitious attempt to merge FreeBSD's battle-tested kernel with Apple's open-source Darwin userland. It's clean-room. It's modular. And it's being built with AI pair engineering woven into every stage of development.

Whether that makes you excited or deeply suspicious, you can't deny it's interesting.

The NeXTSTEP DNA Running Through Every Apple Device

Here's the thing most people don't realize: Apple doesn't actually run six different operating systems. It runs one. Just dressed up differently.

macOS, iOS, watchOS, tvOS, visionOS — they all share the same foundation. XNU. A hybrid kernel that's been evolving for three decades, tracing its lineage back to Carnegie Mellon's Mach microkernel, BSD UNIX, and NeXTstep.

When Apple open-sourced Darwin in 2000, the community saw an opportunity. If Apple's core was free, why not build a real operating system around it? OpenDarwin tried (2002–2006). PureDarwin followed, releasing versions as recently as 2019 and 2024. Then there were GNU Darwin, DarwinBSD, helloSystem, and ravynOS — all chasing the same dream of making Apple's open-source userland run on PC hardware.

Most faltered. All shared code with each other. The ones that survived fed into the next attempt.

That's where NextBSD comes in.

The Original NextBSD and What Went Wrong

The original NextBSD project launched in 2015, founded by Jordan Hubbard — FreeBSD co-founder — and Kip Macy. Their plan was straightforward in theory: take FreeBSD's kernel (arguably the most capable free BSD kernel available) and replace its traditional, server-focused userland with Apple's Darwin components.

The goal? Port Mach IPC (the mach_msg system call, port rights, bootstrap server), launchd (Apple's init system), IOKit (the driver framework), Apple System Log and syslogd, and other Darwin userland primitives onto FreeBSD.

It made sense. FreeBSD had the kernel. Apple had the userland. Why not combine them?

The project got funding. Then the funding ended in 2016. The repository went quiet. Seven years passed.

NextBSD Redux: A Clean-Room Rebuild

Joe Maloney — known on GitHub as pkgdemon — didn't just pick up the old code and keep going. He started fresh.

In May 2026, he announced NextBSD Redux as a completely new project built across modular GitHub repositories. No fork of the 2015 codebase. Just the same overall vision, updated for a decade of evolution in both FreeBSD and macOS source trees.

Why clean-room? Because FreeBSD has moved substantially in ten years. So has macOS. The old assumptions no longer applied.

The current architecture retains FreeBSD kernel ABI compatibility while embedding:

  • Mach IPC (mach_msg, port rights, bootstrap server)
  • launchd-842.92.1 (the last open-source release of Apple's init system) as PID 1
  • libxpc (forked from ravynOS, acting as glue for launchd bootstrap)
  • libdispatch (Grand Central Dispatch with a Mach backend running on kqueue)
  • CoreFoundation (hybrid implementation using GNUstep libs-corebase for value types, swift-corelibs CF for CFMachPort, CFRunLoop, CFBundle, shipping with Apple ICU)
  • notifyd and Apple System Log (structured log records with BSD-text dual output)
  • netconfigd (network state, hostname, DNS — Apple's configd ported with Mach-RPC API)
  • mDNSResponder (Bonjour multicast DNS and DNS-SD service discovery)
  • IOKit registry simulation (replacing FreeBSD's devmatch/devd(4) with IOServiceWaitQuiet, IORegistryEntryGetBusyState, and IOKitWaitQuiet)

Most of these components are marked "Working" on the project site. DiskArbitration, bootstrap_cmds (including the Mach interface generator mig), network_cmds, file_cmds, shell_cmds, system_cmds, text_cmds, adv_cmds, and PowerManagement are all "In progress." A bootable disk image is also in progress — no graphical installer yet.

The Three Iterations That Got Here

Maloney's development process is worth studying. He ran through three distinct iterations before anything migrated to an org account.

The first iteration was "vibe coded" — a sockets-only version of launchd, without Mach, without LaunchDaemons for devmatch and devd. He documented everything extensively at pkgdemon.github.io, comparing FreeBSD's kernel module loading mechanisms to Linux and Darwin, identifying gaps, and confirming that Darwin had solutions for the gaps he wanted to fill — though he'd need Mach. This phase involved months of planning, researching, and refining with AI assistance.

The second iteration repeated the work with just a Mach kernel module and launchd in a single repository. He pulled in libxpc (last updated by ravynOS, originally created by the first NextBSD developers as glue for launchd bootstrap) and other components where ravynOS had continued carrying forward original NextBSD code. Everything else was clean-room. This is where he started using Claude Code interactively to review every code change and develop automated test suites — starting with just a Mach kernel getting loaded, then writing tests covering every part of it.

The third iteration broke everything into separate repositories: the kernel itself, modules converted to kernel extensions (kexts), and the superset of Darwin tooling. Now he's cross-building everything natively in GitHub with automated tests gating every change. AI tooling is involved in almost every stage, but so is he.

AI Pair Engineering: Force Multiplier or Red Flag?

Maloney's use of Claude Code is the aspect most likely to alienate traditional open-source purists. The project's Team page lists:

  • Joe Maloney — Maintainer & lead
  • Claude — AI collaborator · Anthropic

When asked about it, Maloney was candid: "I get and understand the skepticism around AI people have, because I am not sure how much I trust AI-generated code myself, especially without review from humans. In my case, AI has always been more of an effort to accelerate my knowledge of what code does faster, versus not learning anything. With that said, I would still understand the reservations people would have in production environments."

He's not replacing human judgment. He's using AI as a rapid prototyping and auditing layer — accelerating his understanding of complex code between BSD and Darwin, writing test suites, and maintaining automated cross-build CI pipelines. The human stays in the driver's seat. The AI accelerates the work.

It's a model worth watching. If this approach can produce a working, installable OS, it might reshape how small open-source projects get built.

The Desktop Future: Gershwin and Beyond

There's no graphical desktop yet. But it's underway.

Maloney's Gershwin desktop — a combination of GNUstep components and Xfce window manager elements — is being ported to NextBSD. The goal is a broadly macOS-like desktop environment built entirely from free software. The gershwin-on-nextbsd repository tracks current status.

Historically, Gershwin on GhostBSD wasn't the first effort to put a macOS-like desktop on a BSD kernel. helloSystem (based on FuryBSD, now shut down) and ravynOS (which at one point was essentially helloSystem) all contributed code that NextBSD Redux draws from. GhostBSD, GNUstep, Xfce, helloSystem, and PureDarwin all share architectural DNA. NextBSD Redux inherits from all of them.

Why This Experiment Matters

Most companies build different operating systems for different devices. Google has Android and ChromeOS. Microsoft has Windows and Windows IoT. Even Linux distributions fracture into phone, desktop, and server variants.

Apple? One kernel. One codebase. One team. That's why NextBSD Redux is interesting — it's trying to prove that you can take that unified approach and make it run on generic PC hardware.

Currently, NextBSD is more about experimentally assembling components from very different sources and getting them to work together. A bootable USB image exists. A graphical installer is planned. An updater is planned.

Whether it becomes a practical daily driver is another question. But as an experiment in combining FreeBSD's kernel with Apple's Darwin userland — using AI pair engineering as part of the development process — it's one of the most interesting open-source projects to emerge in 2026.

The old NextBSD died when funding dried up. NextBSD Redux lives because someone decided to start fresh, document everything, and try a new approach to building software.

That's worth paying attention to.


Sources: The Register, nextbsd.org, Open Source For You

NextBSD Redux: Bringing Apple's Open Source Darwin to FreeBSD with AI Pair Engineering

More blogs