This project started because I repeatedly encountered the same problem across different organizations, different environments, different teams: we have more infrastructure changes to make than we have safe ways to make them. Keys that need to rotate. Systems that need patching. Networks that need segmentation. Access patterns that need tightening. The work is clear. The machinery for doing it safely — planning, simulation, review, execution, verification, rollback — either does not exist or exists inconsistently, scattered across runbooks and tribal knowledge and the memory of whoever has been around longest.

Over the years I built tooling to address that problem. Not in a clean, abstract way — in the way you build things when you have a real problem in front of you and you need it solved for a real production environment. The early versions were rough. Some of them still are. But the core ideas have survived contact with real infrastructure. Real key rotations. Real network changes. Real rollbacks under pressure. That durability matters more to me than elegance.

I am open sourcing the core because I do not know whether Nexplane becomes a commercial company, and I think that is okay. I genuinely believe the community should have access to these ideas regardless of how the business side resolves. If this project grows into something larger — enterprise customers, a managed offering, a team — great. If it simply helps practitioners automate difficult infrastructure work more safely, that is already a success. Both outcomes are worth pursuing. Neither outcome requires keeping the core closed.

There is also something specific I believe about this moment. AI is making it easier to generate plans, scripts, and proposed changes. That is genuinely useful. I use it constantly. But it is also dangerous if the surrounding change machinery is weak. The question should not be "How do we give AI root?" The question should be "How do we let AI help while preserving accountability, review, simulation, verification, and rollback?" That is the question Nexplane is trying to answer. Opening the source means the community can see the answer, criticize it, improve it, and adapt it — rather than taking it on faith.

I have watched organizations spend years and real money on security and infrastructure tooling that either did not survive contact with their actual environment or could not be adapted when requirements changed. Closed systems that required vendor involvement for every customization. Opaque platforms where the organization could not understand what the tool was actually doing or why. That is a bad deal, especially for infrastructure work where trust is the entire foundation. If practitioners cannot inspect the system that is managing their infrastructure, they should not trust it. Open source is how you earn that trust.

My belief about infrastructure change is simple: the outage at the end of the deferred-change queue is not inevitable. It is the predictable result of not having the machinery to change safely. That machinery can be built. It can be systematic rather than personal. It can be available to teams that have not yet paid the expensive lessons that teach you why it matters. That is what I am trying to build, and it should be something the community can see, adapt, and improve.

So that is why. Not because open source is a marketing strategy. Not because I have a clever business model that requires it. Because the problem is real, the ideas have been tested, and the right thing to do with tested ideas is share them.