The new definition of open must consider implementation, specification, and governance as three critical factors that must be woven together.
Open source has never been just a licensing model. Rather, it’s also a philosophy about shared effort, shared transparency, and shared agency. The shared goal is to make an impact in the world. In the age of AI‑assisted development and agents, there is a line of thinking that AI slop, specifically mass-produced and submitted code, is the downfall of open source projects. On the contrary, I think open source is headed for a resurgence like we’ve never seen before, as long as we emphasize the aspects of open source beyond code submissions.
In this new world, the philosophy, ethics, and morals of open source are more relevant than ever. However, the focus of open source needs to evolve past raw code: Specification files (spec files) and governance documents (constitutions) are becoming as important as the source itself. The challenge is not to choose between open source and AI, but to recognize that open source is now a community-based control and scope mechanism for open technologies.
Let me break this down further. Specs describe intent and outcomes, while code shows how that intent is actually realized. When something goes wrong, you still need to trace the path from spec to implementation. Trust is earned, not inferred, so the promise that, for example, an app values your privacy or that an agent never sends data to third parties must be backed by code and built on pipelines that anyone can inspect and verify (e.g. Acquacotta Constitution).
Governance complements spec files, in showing how a spec is created, enforced and followed. It’s the “people decisions” around a project — who makes the final decision? If there’s a vote on something, who votes? How do they vote? It’s these seemingly pedantic yet crucial decisions that emerge from governance, and they are the backbone for how spec files are created and followed when code contributions become as simple as writing a basic agent prompt.
Open means open, even for AI
The main criticism of AI with open source is that code contributions become open to everyone, not just those with deep technical knowledge. This makes the pillars of an open source community outside of the code more important than ever. Users fundamentally become contributors when anyone can create code, which means they need agency in specification. Additionally, this new class of community members needs to be able to help influence and change governance and spec, just like “normal” contributors in the pre-AI days. The spec files submitted with their AI-generated code must be open for inspection and reproducible, just like a more traditional code contribution. The ability to fork the implementation and run it on outside infrastructure also remains, enabling contributors to further refine their own customizations, integrations, and optimizations.
This is how organizations retain real agency in an era where code is a commodity. In other words, spec files broaden what we need to keep open; they do not replace the need to keep code, build systems, and dependency trees open and inspectable. The future is not specs instead of open source; it is open source plus open specs and open governance.
You version, review, and discuss specs in the same way you review and discuss code. You make architecture and governance artifacts part of the public record so that others can learn from, reuse, and improve them. This creates a richer set of open source assets. The repository does not just contain code; it contains the constitution of the project, the architectural reasoning, and the guardrails that keep AI tools and AI-driven code contributions on the rails.
This lowered barrier cannot be overstated. Truly anyone can now contribute, not just those who understand the code-based components of a project. Domain experts, designers, and operations specialists can propose changes at the spec level that AI agents then help implement. For a community that leads with open source values, and robust testing frameworks (coded in the constitution), this fuels the creation of high‑quality software while preserving the transparency, reviewability, and forkability that open source depends on.
‘Real’ open source
We do risk the convergence of open source and specs turning into a two-sided purity test. Some argue that if AI wrote most of the code, it is not “real” open source. This argument implies that the provenance of each line of syntax matters more than whether the system as a whole is transparent, forkable, and governed in the open. Meanwhile, the opposing side suggests that if we can regenerate the implementation from a spec, we no longer need to worry as much about licensing and code openness — as if an elegant constitution makes inspection of the actual machinery optional.
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.
It’s this ability for individuals and organizations to dream bigger that makes it possible to tackle problems that were previously too big, too weird, or too niche to justify a full project team. A UX designer who’s never committed a line of code can suddenly create a serious tool. A security engineer can prototype a new threat‑hunting pipeline end‑to‑end. An architect can stand up a reference implementation of a safer integration pattern, then let others clone and extend it. In each case, AI doesn’t replace expertise; it amplifies it. The most valuable people in the room spend less time grinding out boilerplate and more time on intent, constraints, and trade‑offs.
AI tooling isn’t a one way street
However, there’s one really important thing to remember about dreaming bigger with AI tools: You are not the only one who has easy access to them — so do your competitors. Perhaps more importantly, the bad guys have them too.
When it comes to the former, dreaming bigger means dreaming bigger than the folks who would take business away from you. It’s about making sure that your customers stay your customers and that you can attract new ones on a continual basis.
When it comes to the latter, it means considering that the people who would do you and your customers harm have these same tools. And, if anyone dreams bigger, it’s the people who want to break your systems, defraud your customers, and manipulate your users.
That’s one reason the traditional “open source = open code” framing is starting to feel too small. If attackers can continuously remix powerful AI tooling in the shadows, defenders need open, inspectable patterns for detection, response, and governance that anyone can adopt and improve.
Open source’s big tent
The same openness that once turned a loose collection of hackers into the engine of the modern software stack can now be applied to a new layer of specs and agents. This is a new way forward to make open source even more accessible to a new type of contributor. For open source, it’s not about fighting AI slop. Instead, we as a global community need to push the positives of AI-driven contributions forward, so that the good far outweighs the bad.
—
New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.
