The open-source core of Nexplane should be genuinely useful. That statement is both a strategic claim and a moral one, and I think both matter. On the strategy side: an infrastructure control plane is a trust-sensitive product. The teams that would adopt it are managing real production systems. They are not going to adopt something they cannot inspect. Open source gives practitioners the ability to read the code, understand what the system is doing, criticize the design, adapt it for their environment, and contribute improvements. That is how trust gets built in infrastructure tooling. You cannot shortcut it.

On the moral side: if this work can help teams make infrastructure changes more safely, the community should have access to it. I do not think the value of building something useful should accrue entirely to whoever builds it first. The ideas in Nexplane — change requests as structured artifacts, rollback as a first-class design concern, human review as a genuine control rather than a checkbox — these ideas belong in the community. Putting them behind a paywall from day one would be the wrong call.

Commercial value can still exist, and I expect it will. Managed deployment for organizations that do not want to run their own instance. Enterprise governance features. Advanced RBAC and audit reporting. Team workflows for larger organizations. Support contracts. Managed upgrades. Integrations that require dedicated engineering effort to maintain. These are real problems that enterprises pay real money to solve, and they are a legitimate layer to build on top of a useful open-source core. But the core should not be a fake open-source teaser — a stripped-down version that demonstrates what the product could do if you paid for it. That approach poisons the well. Practitioners recognize it immediately and trust evaporates.

The line I am drawing is this: the community version should be capable enough that a team can use it to solve real infrastructure change problems in production. That means the change request specification, the execution engine, the rollback framework, the connector integrations for major platforms, local deployment support, and documentation. The commercial layer builds on top of that without hollowing it out. The community should not feel like they are getting a demo. They should feel like they are getting the real thing.

That is a harder line to hold over time than it sounds. There will be pressure to move features up into the commercial tier. I think that pressure has to be resisted systematically, not case-by-case. The community version stays real. The commercial version adds genuine enterprise capability. That is the deal, and keeping it is how the trust that makes the commercial version viable gets maintained in the first place.