Both positions miss the point. If you care about user agency, security, and long‑term sustainability, as all open source projects should, you need both open code and open build pipelines, so anyone can inspect, reproduce, and harden what is running. You need open specs and governance, so anyone can understand what the system is supposed to do, how it is supposed to behave, and how decisions get made over time.
The new “definition” of open must consider implementation, specification, and governance as three critical factors that must be woven together. Open implementation means the source, dependencies, and build system are available under an open source license so you can rebuild, audit, and run the software yourself. Open specification means the requirements, architecture, and project constitution are documented, versioned, and public, so others can reuse them, learn from them, and adapt them to their own needs. Open governance means the processes by which changes are proposed, reviewed, and accepted — whether at the spec level or in code — are transparent and participatory.
The path forward for open source communities is not to retreat from spec‑driven, AI‑assisted development, nor to declare the old mission obsolete. It is to lead in defining and practicing what open specification, governance, and implementation look like together in an AI‑first world — and to do so with the confidence to dream bigger than incremental automation.
