Architecture, Community, and the Spirit of Plan 9

In recent days, I attempted to contribute a discussion to the 9fans mailing list regarding the architectural direction of 9front. The post was carefully written and presented in good faith. It raised questions about the project's focus on single-user workflows and the apparent decline in emphasis on distributed computing, a hallmark of the original Plan 9 design.

The post was rejected by moderators. My account was banned under the claim that the message was AI-generated. It was not. While I occasionally use writing assistants to refine grammar and clarity, the ideas and arguments were entirely my own. The banning effectively closed the door on any opportunity for clarification, correction, or productive debate.

This reaction highlights a deeper issue. In certain communities, critique of direction—particularly from outside core maintainers is met with defensiveness rather than discussion. Questions about design decisions, even when rooted in a sincere appreciation for the system's philosophy, may be dismissed not on their merits, but on assumptions about the messenger.

To be clear, I do not oppose 9front. I respect its technical accomplishments and the immense effort behind it. My concern lies with architectural choices that, from my perspective, shift the system away from Plan 9's founding ideas, ideas worth preserving, extending, and, where necessary, challenging.

One such example is the replacement of cpu(1) with rcpu(1). This move, while practical in some respects, avoids rather than addresses the deeper problem of latency in the 9P protocol. A more ambitious path might have explored optimising 9P itself. Similarly, changes in tooling and community discussion reflect a growing emphasis on local workflows and standalone use cases, diverging from the distributed ethos outlined in the Plan 9 papers.

That divergence is not inherently wrong. Systems evolve, and community priorities shift. But it should be acknowledged clearly. If a project is no longer following the original architecture or design philosophy, calling it “Plan 9” without qualification becomes misleading, especially to newcomers expecting a distributed system by default.

A project being “Plan 9-like” is not a criticism. It is a description. And it need not diminish the work being done. But clarity matters, and open discourse matters more.

I continue to believe in the value of Plan 9’s namespace model, per-process resources, and network-transparent design. If creating a new distribution or derivative is the only way to preserve and extend those principles, then so be it. Let that work proceed openly, without presuming consensus where none exists.

And if a community like 9fans cannot host such dialogue, others will.

- Thales