NextBSD redux returns with Joe Maloney and Claude Code powering Darwin ports

NextBSD is back, and the person steering it is not a legacy maintainer. Joe Maloney, known on GitHub as pkgdemon, says he is running the revival and that the project’s “team” includes Anthropic’s Claude Code. He opened the restart publicly in May, after earlier iterations lived on his personal GitHub account, and he is framing this as a new project rather than a straightforward continuation of the decade-old plan.

The core idea is also the headline’s real stake: NextBSD redux is not a from-scratch operating system. It is a cherry-pick and combine mission. The plan uses the FreeBSD kernel, but replaces FreeBSD’s traditional, server-focused userland with relevant parts of Apple’s publicly available Darwin code. Darwin is the Unix foundation behind macOS and many other Apple operating systems. That means the project is trying to reassemble a puzzle that includes components like launchd, IOkit for device handling and drivers, Apple System Log facilities, and syslogd-like logging behavior, while acknowledging that the lower-level kernel and drivers are built purely for Apple hardware in the original Apple stack.

Why this is interesting now is not just nostalgia for BSD variants from the 2010s. It is that “Darwin for non-Apple hardware” efforts have repeatedly stumbled. The source lays out the timeline: OpenDarwin started in 2002 and ended in 2006, then PureDarwin shipped releases in 2015 and 2019 and was still maintained as recently as 2024. There were other attempts such as GNU Darwin and DarwinBSD. In the background, Apple’s OS lineage got more complex and more integrated with hardware, even as large parts of Apple’s software moved toward open source. That tension is exactly why NextBSD redux stands out: it tries to use modern FreeBSD, not just the original NextBSD recipe, because FreeBSD, macOS, and Darwin have all evolved since the original 2015 effort.

The original NextBSD project was started by FreeBSD co-founder Jordan Hubbard in 2015. Maloney’s role in the old work was relatively minor, as the original commit history shows, but he now has ownership of the direction. Maloney previously put together the Gershwin desktop in GhostBSD. After The Register covered Gershwin on GhostBSD, he asked the NextBSD maintainers if he could take over the NextBSD project. NextBSD redux continues that same “Mac-like environment on BSD” impulse through its Gershwin desktop work, which is described in a separate repository, gershwin-on-nextbsd.

Here is where the story gets more than technical and into governance and risk management. Maloney says he is using AI. The Team section of the NextBSD redux homepage lists Maloney and Anthropic’s Claude Code. When The Register asked how and why, Maloney replied that AI is “a force multiplier” for him as the steering developer, and that he sees AI as accelerating knowledge of what code does faster, “versus not learning anything.” He also directly acknowledged the skepticism: he “doesn’t trust AI-generated code myself,” especially without human review in production environments. He added that he understands reservations, even if the project outcome matters to him personally and he wants it to exist for his own use.

For execs and boards, that answer is a useful reality check. NextBSD redux is early (the oldest commits in nextbsd-redux are only two months old), so this is not a shipping product with enterprise guarantees yet. Still, the process is a case study in how teams might treat AI as an accelerator rather than an authority, including documentation-heavy planning before code migrations into an org. Maloney told The Register that he had “two iterations of this work” before moving outside his personal GitHub account. The first iteration was “vibe coded” to test a sockets-only version of launchd without Mach and LaunchDaemons. He says he documented extensively at pkgdemon.github.io, comparing FreeBSD’s kernel module loading to Linux and Darwin, identifying gaps, and confirming Darwin solutions but determining he would need Mach.

In the second iteration, he repeated work with a Mach kernel module only and launchd in a single repo. He then pulled in pieces from earlier experiments, including libxpc, which the source notes came out of the original NextBSD project and also appears in today’s NextBSD redux. The dependency trail matters because it shows that open-source “Darwin-ish” projects borrow from one another. The source links this ecosystem to helloSystem and ravynOS. helloSystem, reported on in 2021 and again in 2023, was based on FreeBSD graphical distro FuryBSD (which shut down in 2020). Its creator, Simon “ProbonoPD” Peter, later helped Gershwin development. Meanwhile ravynOS, which started around 2022 as a fork of helloSystem, aimed at limited macOS binary compatibility through Darling and is described as starting with Darwin 19.6, corresponding to macOS 10.15 “Catalina.” NextBSD redux uses some ravynOS libraries like libxpc, which highlights a practical dynamic in OS engineering: teams reuse proven components, but integration remains the hard part.

So what should decision-makers take away? Not “BSD is the next consumer platform.” The strategic stake is about development velocity, code safety, and how open-source projects earn trust when they mix low-level system work with AI-assisted iteration. NextBSD redux is essentially daring the community to watch how AI is used in the weeds of launchd-like behavior, sockets, Mach needs, and kernel-adjacent plumbing. If it works, it could set a template for accelerating difficult engineering without turning review into a checkbox. If it stumbles, it will still teach the market something: that AI can compress exploration time, but the responsibility for production-grade correctness stays human, documented, and reviewed.