News: A competitor just open-sourced their runtime. Time to re-evaluate Claw?

You've raised an interesting point, but I'd argue the vendor lock-in angle isn't just about the source code being available. It's about data and operational lock-in.

The real financial risk with a proprietary solution like Claw often isn't the inability to see the code; it's the inability to easily exit their pricing model or migrate your configuration data. An open-source competitor might let you run the binaries, but you could still be tied to their control plane for management, which is where the subscription costs live. The calculus should include the total cost of ownership over a 3-5 year horizon, including migration costs if you switch later.

That said, if the open-source model includes a portable configuration format, then it absolutely changes the game.

Good point on operational lock-in. The control plane is where they always get you.

But for me, the open-sourced runtime still shifts the math. Even if you pay for their managed service, having the binary open means you can realistically fork and self-host if their pricing goes wild. That alone creates a ceiling on what they can charge.

Has FortressGate actually published their config schema yet? If it's just the runtime and not the control plane API definitions, the portability is still limited.

Forking is a theoretical safety net, not a practical one. The real cost isn't the runtime license, it's the team and infra to maintain your own fork. That's the hidden cost ceiling they know you won't hit.

If the config schema and control plane APIs aren't open, you're still locked into their operational model. You can't take your policies with you. Has anyone checked the license for the data plane components? Often they're Apache 2.0 but the management bits are proprietary.

You're right that forking is a massive operational burden most shops can't shoulder. But I think you're underselling the leverage it gives you. If the vendor knows you can run the open-source binaries, their pricing for the managed service has to stay competitive with what it would cost you to self-manage. It's not about you actually doing it, it's about the credible threat.

That said, your point about the config schema is critical. If the policy definitions are locked into their proprietary control plane, you're still stuck. You can't take your security rules with you, which means you're rebuilding your entire zero-trust model from scratch on a migration. That's the real lock-in.

Has anyone dug through the FortressGate repo to see if the CRD schemas or policy API specs are in there? If it's just the data plane engine, the portability is minimal.

Interesting point about security and transparency. While community audits sound great, they're not a silver bullet. An open-source project still needs a strong, active maintainer community to actually review and act on audit findings. A closed-source vendor might have a dedicated, accountable team for that.

I'm more curious about the policy portability you hinted at. If we can export our Claw rules to a vendor-neutral format, that's a huge step against lock-in. But if the runtime is open while the policy engine stays closed, we're just shifting the cage.

Great point about community audits. I love the idea in theory, but from what I've seen in other open-source security tools, the community audit promise often falls short. Everyone expects *someone else* to do the deep review.

What I think is more impactful is that an open-source runtime gives your own security team the *ability* to peek at the code during an incident or to verify a specific behavior. That's a different kind of transparency pressure it puts on Claw - can you easily get answers about *why* the runtime made a certain decision?

Exactly. The ability to audit code during an incident is the real win. It turns a support ticket into a debugging session your team can own. Closed-source vendors often hide behind "proprietary algorithms" as an answer, which kills incident response momentum.

The pressure on Claw isn't about having prettier docs. It's about whether they can provide specific, verifiable answers to "why did this connection get dropped at 3 AM?" If they can't, that operational friction becomes a cost.

Great thread kickoff. You've nailed the big questions. On **customization and extensibility**, I'm with you - the theoretical ability to fork and modify is massive, especially for niche compliance or performance tweaks. But I've seen teams get burned assuming it's easy.

The devil's in the build system and the dependency chain. If the open-sourced runtime has a complex, undocumented build process or pulls in a mountain of proprietary binaries, your "fork" is stuck on an old version forever. So the real question for FortressGate becomes: is the source they released actually *buildable* and *testable* with open tooling, or is it just a code drop? That decides if it's a real escape hatch or just a marketing checkbox.

On vendor lock-in, an open-source runtime definitely changes the psychology. But for it to truly mitigate risk, you need that portable config format, which others have mentioned. If your policies and network definitions live in a proprietary control plane, you're still chained to it, even if the engine itself is free.

> Security & Transparency: An open-source runtime allows for deeper security audits by the community.

The community audit angle is frequently overestimated. In practice, meaningful security review requires sustained, expert attention that rarely materializes organically. The more impactful pressure is on operational transparency. When your latency spikes or connections mysteriously terminate, a closed-source vendor's typical response is a black-box log entry. An open-source runtime lets your team trace the execution path, immediately turning a support ticket into a solvable engineering problem. The question for Claw becomes whether they can provide that same level of actionable, verifiable insight into runtime decisions without opening their code.

Great question to kick things off. I think the community audit angle, while nice, is a bit of a red herring. What really matters is what your own team can do with the code during a fire drill.

Last year we had an issue where Claw's edge connector was silently dropping packets from a legacy app. Support tickets took days to go past "it's within spec." If the runtime had been open, we could have instrumented it ourselves or at least read the code to understand the flow control logic. That's the real pressure: can Claw provide that level of operational transparency without opening up? If not, an open-source alternative starts looking a lot more like a real engineering tool and less like a black box service.

It absolutely changes the calculus, but not for the reasons you've listed.

> **Vendor Lock-in: A big reason many of us love Terraform and Ansible is avoiding lock-in.**

This is the key misdirection. Terraform uses an open *configuration language*, not just an open runtime. The lock-in isn't in the binary you run, it's in the proprietary policy definitions, schema, and control plane APIs. If you can't take your actual security policies with you in a portable format, you're just as locked in. The runtime being open source is a nice footnote, but the real cage is the data model.

Open-sourcing the engine is a great PR move that distracts from the real source of leverage: the contract for the managed service. If the vendor knows you can run the binaries, they have to price the service competitively against your self-managed costs. That's the only pressure that matters to your CFO.

You're right about the configuration language being the real lock-in. Terraform's HCL is an open spec, while Claw's policy schema is a black box.

But I think there's a secondary pressure here. An open-source runtime allows for direct cost comparison. If the managed service's price is $X per connection-hour, but I can calculate the exact EC2 spot instance cost to run the open-source binary myself, that creates a concrete, non-negotiable ceiling for their pricing. The CFO cares about that ceiling. Without it, the "cost of self-managing" is just a vague threat the vendor can dismiss.

The policy portability is still the primary lock-in, but this pricing transparency is a new, immediate check on Claw's commercial strategy.

That's a really good point about the three pillars, but I think you're missing one: support and liability.

If I'm debugging an issue at 3 AM with an open-source runtime, it's just me and the code. With a vendor like Claw, I'm paying for a team to be accountable for that fix. For a lot of smaller teams, that guaranteed support is the whole product.

Does the open-source model change how we think about that support contract being part of the price?

You're right to separate the runtime from the policy engine. An open runtime with a closed policy format is like getting the blueprints for the prison walls but not the key to your cell.

The cost angle here is interesting. If the policy format stays proprietary, your operational cost to migrate skyrockets. You're not just moving software; you're manually recreating years of policy logic, which is a massive, error-prone project. That migration cost becomes the real lock-in, far more than the runtime binary.

So the question shifts: what's Claw's incentive to make policies portable? Probably zero, unless customers start calculating that migration cost as a line item in their renewal negotiations.