Open, commercial, and a paid ecosystem where both coexist

EDA is almost a gimme

Let me start with a judgment I don't think even needs first principles — it holds up directly: EDA is a gimme.

Why? Because commercial EDA tools have already proven one thing for us — that all of this can be done in software. Commercial EDA isn't magic; it's software: a pile of algorithms, data structures, and decades of engineering experience written into a program. And if commercial software can do it, what reason is there that open-source software can't? As long as someone is willing to do the work, it can — basically, certainly — be done.

And right now the cost structure of "someone willing to do the work" has completely changed. AI has become genuinely professional at writing software — honestly, often better than I do. Once the act of writing software is itself dramatically accelerated by AI, then building — on top of open source — an EDA tool that stands shoulder to shoulder with today's commercial tools, or even surpasses them, becomes something natural, something that will happen sooner or later.

So let me set a common misconception straight up front: the gap between open-source and commercial EDA has never been a gap of "can it be done" — it's a gap of "has anyone finished writing it." It's a gap of investment, not a gap of possibility. And AI happens to be pushing the cost of that investment way down.

Open or commercial — both are usable

Having made that judgment clearly, I want to immediately add something just as important, so it doesn't get read as a stance of opposition: this is not a story about open source winning against commercial.

What Vibe-IC is trying to build is an AI-Native, end-to-end IC-design flow — from a complete set of design documents all the way to a chip. Along that flow, whether a tool is open-source or commercial, either can be used. Whichever tool does that step well, and does it correctly, is the one you use. What we actually emphasize is that the flow itself is end-to-end — not that we oppose commercial tools.

And further: if a commercial EDA vendor wants to plug its tool in and become part of this ecosystem, we warmly welcome it. Once it's plugged in, users pay to use it — exactly as natural as paying for an IP block placed on the platform. A commercial tool here isn't something to be pushed out; it's a paid, welcome link in the ecosystem. Open source completes the parts of the flow that open source should complete; commercial tools carry the parts they're good at; and the two coexist on one and the same end-to-end flow.

Don't become the very thing you set out to change

That said, as a software person, I reminded myself early of one thing: don't accidentally become the kind of thing I set out to change.

Picture it: I build a really capable AI IC platform, then wrap it into a walled cloud SaaS, charge a subscription, and lock users' data and flow onto my cloud. Then I've actually changed nothing — I've just put my own name in the same seat. Users go from being tied to one set of tools to being tied to another. That is not what I want to do.

So for me the point, from the very beginning, was never just "how powerful the features are" — it was "whether the shape of the tool is right." A genuinely open ecosystem has to be open in its very shape: anyone can take it, use it, change it, extend it, and contribute back. You can't retrofit that later; you have to choose it right on day one.

Why plugin + MCP + Apache-2.0

Bringing "shape" down to concrete engineering decisions, it comes to three things.

First, the whole thing is open-sourced under Apache-2.0. The code is at github.com/vibeic/vibe-ic; anyone can clone it, fork it, read every line of how it decides a verdict. Apache-2.0 has a property that matters a lot for IC: it's compatible with open PDKs (SkyWater, GF180MCU, and IHP are all Apache-2.0) and with open EDA, and it carries an explicit patent grant. More importantly, I hard-wired one principle: the RTL, netlist, GDS, constraints, and test vectors you produce with Vibe-IC are all yours. Apache-2.0 makes no claim on a tool's output — just as a binary compiled by GCC is not a derivative work of GCC. There is a clear firewall between the tool and your design.

Second, the shape is a Claude Code plugin + MCP, not a website of my own. Vibe-IC itself is a plugin; on install it automatically registers an MCP server that turns the whole row of underlying EDA tools into capabilities the AI can call directly. You drive it in natural language. Installing is just two lines:

/plugin marketplace add vibeic/vibe-ic
/plugin install vibe-ic

The meaning of this choice is: Vibe-IC does not put itself at the center. The center is Claude Code, an open agent runtime; Vibe-IC is just one piece plugged into it. In the same marketplace, someone else's plugin is its sibling node, not its subordinate. Nobody is collecting a toll from everyone.

Third, the core treats everyone the same — and it's guaranteed by code. Anyone can say "we're neutral"; what actually makes it hold is that we turned neutrality into a deterministic gate that blocks hard-wiring any specific vendor's private assumptions into the public core. The RTL generator recognizes categories — "this is an arithmetic primitive," "this is a command-driven interface" — not "this is company X's chip Y." Neutrality doesn't rest on a promise; it rests on a gate.

Five extension surfaces: plug your own thing in

An open ecosystem, in the end, comes down to this: when someone wants to add something on top, is there a clean path for it? Vibe-IC currently opens five extension surfaces, each with an explicit file contract:

These five surfaces map neatly onto the real assets different roles in the IC industry actually hold: foundries have PDKs, IP vendors have IP and generators, instrument makers have drivers, senior engineers have methodology, QA has sign-off rules. And a commercial EDA vendor can plug its tool in along these same five surfaces — packaged as a plugin parallel to vibe-ic, dropped into the marketplace, and a user connects to it with a one-line install and pays to use it. No need to come asking me to stuff it into the core, and no need to fork my core. It is precisely because the core treats every vendor the same that everyone has a reason to contribute their assets.

One end-to-end flow, not a confrontation

Pulling the view back: what I'm betting on with Vibe-IC has never been an "open vs. commercial" opposition, but something bigger — that every logical industry can ultimately have its flow completed by software plus AI, integrated end-to-end: from a complete set of design documents to a chip, with no more heavy human hand-offs and back-and-forth in between, extremely efficient.

Along that flow, open source is responsible for taking the part that open source should complete up to production, up to sign-off grade; commercial tools carry the parts they're good at, on a paid basis; and the two aren't replacing each other — they're jointly bringing the same flow all the way to running clean. That's what the ecosystem looks like in my head: open, coexisting, and the same set of rules for everyone.

Vibe-IC today is of course still far from complete. But its foundation — an open license, an open shape, one consistent gate for everyone — is there so that this force can be pushed by everyone together, rather than owned by any single person (myself included).

Next time, I want to lay the whole architecture out on the table: how I actually arranged these four months — first build the flow, then converge the front end, and finally converge the mid-to-back end — three parts, and how one end-to-end flow grew step by step.