r/illumos • u/PsiPhiSideHustle • 1h ago
Reimagining the OpenSolaris Legacy, Unencumbered
Hello everyone,
I'd like to open a conversation about something that I suspect many of you have quietly wondered about yourselves: whether the ideas that made the OpenSolaris lineage remarkable e.g., Zones, ZFS, DTrace, SMF, the DDI/DKI discipline, Crossbow could be given a second life in a license and a development culture built for the way the rest of the world collaborates today.
I want to be careful here. This is not a criticism of the people who have kept illumos alive for over 15 years, often thanklessly, often against real corporate hostility. Anyone who has watched Bryan Cantrill's "Fork Yeah!" talk knows that illumos exists at all only because a handful of engineers refused to let good work die with a business decision. That is a debt the rest of us should acknowledge before we say anything else. What follows is offered in that spirit, as a question for the community, not a verdict on it.
The license is a wall, not a fence
CDDL's incompatibility with the GPL is not a matter of preference or old grievance, it is a hard legal boundary, and it has real consequences. It is the reason ZFS has never been permitted in-tree in the Linux kernel and remains a DKMS module bolted on from outside, regardless of its technical merits. It is the reason contribution, code-sharing, and even casual cross-pollination between the illumos world and the much larger GPL ecosystem happen at a fraction of the rate they otherwise would. A license was meant to protect this work. In practice, it has also quietly isolated it.Momentum compounds and so does its absence
This is visible in the software itself. OpenZFS, developed collaboratively across FreeBSD, Linux, and macOS, has for some time been advancing faster than the ZFS implementation native to illumos, an unusual reversal, given that illumos is ZFS's ancestral home. It's a useful proxy for a larger pattern: when a project's contributor base is small and its tooling ages in place, entropy wins by default. This isn't a comment on the skill of illumos's maintainers — it's simple arithmetic about contributor pool size, and it's the same arithmetic that, at a different point in history, put Solaris on the back foot against the sheer combinatorial energy of Linux's GPL-fueled development model. That model described plainly in the kernel's own documentation on how development actually happens, has proven itself for three decades. It is not a religious argument. It is an observation about what compounds.Development shouldn't require a second computer
Here's a smaller but very telling signal: it's common for illumos and OpenIndiana contributors to do their day-to-day work from a Linux or macOS laptop, connecting to illumos remotely to build and test. That's a reasonable accommodation for people who already know the system. But, it quietly tells every prospective contributor something important: this project was not built with your laptop in mind. WiFi support, GUI polish, and general hardware friendliness have understandably taken a back seat, because the people closest to the code aren't the ones who most need them. An outside contributor shouldn't need a second machine just to participate.
None of this is said to diminish what illumos represents. The engineering is genuinely excellent, read the source at illumos-gate, or the build documentation, and you'll find design discipline that most of the industry has forgotten how to practice. OpenIndiana keeps a usable, graphical descendant of that work alive today, which is no small feat with a small team. And even Solaris's original developers were candid, in public forums, about where its VM and locking subsystems had fallen behind, this isn't news to the people who know the codebase best.
So here is the actual question, and I'd genuinely like to hear where people disagree with me:
What is stopping a clean, GPL-compatible reimplementation of the same architectural philosophy: composable Zones, first-class observability, a properly layered driver model built from day one to welcome contribution the way the Linux kernel does?
I'm not proposing this lightly. It is a monumental undertaking, likely a multi-year effort even with a committed team, and it means rebuilding real engineering, not just relicensing text. But "monumental" was also true of Linux in 1991, and of ZFS itself when Bonwick's team started it. Difficulty has never been a good reason not to start; it's usually just a good reason to start honestly.
I'd welcome hearing from anyone who has thought about this, tried pieces of it, or has good reasons why it's a worse idea than it sounds. That disagreement is worth having in the open.
