Open core is a business model that gets abused. The pattern is familiar: a product is released as open source, but the parts that make it genuinely useful are commercial-only. The community version demonstrates what the product can do without actually letting you do it. Practitioners figure this out quickly, and when they do, trust evaporates. "Real, not decorative" is the standard I am trying to hold for Nexplane, and it is worth being specific about what that means in practice.

The open core should include the change request specification — the data model and schema that defines what a change request is, what fields it has, how intent is captured, how rollback is structured. It should include the execution engine — the machinery that takes a plan and runs it, with observable state and verification checks. It should include the rollback framework — the logic that enforces reverse-order unwind and gives rollback the same structure and observability as forward execution. It should include the connector integrations for major platforms: AWS, Azure, GCP, Active Directory, the systems that practitioners actually manage. And it should include local deployment support and documentation that is good enough to get a team productive without paying for help. If a team cannot use the community version to safely manage real production changes, the community version is not real.

Commercial value can live in a different tier without hollowing out the core. Hosted management — running the platform so the organization does not have to — is a legitimate enterprise offering. Advanced RBAC with fine-grained permission models is something large organizations consistently need and small teams rarely do. Compliance-grade audit reporting with the formatting and retention policies that satisfy SOC 2, ISO 27001, or FedRAMP reviewers is enterprise-specific work. Multi-team workflows with approval chains that span organizations and integrate with enterprise ticketing platforms. Support contracts. Managed upgrades. Dedicated integrations for enterprise platforms that require sustained engineering effort to maintain. These are genuine enterprise problems and genuine commercial value. They do not require stripping capabilities out of the community version to exist.

The line I am drawing is functional, not cosmetic. The question is not "is this feature visible in the community version?" The question is "can a team with real infrastructure problems use the community version to solve them?" If the answer is yes, the line is in the right place. If the answer is "yes, but only if you upgrade," the line has moved and the community version has become decorative. That drift is easy to rationalize and hard to reverse once it starts. The commercial tier should be defined by what enterprises specifically need, not by what can be withheld from everyone else.

I also think this line matters for the long-term health of the project beyond any business calculation. Practitioners who build on open-source tooling contribute bug reports, documentation improvements, community knowledge, and sometimes code. That contribution requires genuine engagement, and genuine engagement requires a product that is actually useful. A decorative open core does not generate that. A real one does. The community's trust is both the ethical foundation and the practical asset that makes everything else possible.