Thoughts on production coverage being a paid feature

[OmerGronich]

Hey team — first off, fallow is an incredible tool. I've been evaluating it and the results have been genuinely impressive. The speed, the framework detection, the output quality — it's clear how much care has gone into this. I've been filing bug reports and sharing ideas because I believe in what this project is building.

That said, I want to share some honest feedback about the decision to make production coverage a paid feature.

What drew me to fallow

The ecosystem has plenty of paid code health tools (SonarQube, CodeClimate, Codacy, etc.). What made fallow exciting was that it was the open-source alternative that was missing — fast, local, no strings attached. That's a rare and valuable position.

Why the paid feature concerns me

Production coverage is a fully local feature. The sidecar runs on my machine, reads local coverage dumps, and writes local output. There are no servers, no cloud infrastructure, no ongoing costs to the project. The core logic — cross-referencing static findings with V8 runtime data and applying a decision table — is straightforward analysis code, not a complex service.

I understand that maintainers need to sustain their work, and I respect that. But gating a local-only analysis feature behind a license feels like it crosses a line from "open source tool" to "open-core product." And once that line is crossed, the natural question becomes: what's next?

Why this matters for adoption

When I evaluate tools for long-term adoption, trust in the project's direction matters as much as the current feature set. With a fully open-source tool, contributing bug reports and ideas feels like investing in a shared community resource. With an open-core product, it can feel like providing free QA for someone else's commercial roadmap.

I'm not saying fallow shouldn't have a business model. I'm saying that the specific choice of paywalling a local, zero-infrastructure feature — rather than, say, cloud-hosted dashboards or team management — undermines the thing that makes fallow special.

A genuine question

Is there a long-term commitment to keeping the core analysis features (dead code, complexity, duplication, static coverage gaps) permanently open source? Understanding the boundary between "always free" and "potentially paid" would help teams make confident adoption decisions.

Thanks for building something great. I hope this feedback is useful.

[BartWaardenburg]

Hi Omer,

Thanks for writing this, and for everything you've already contributed. Your feedback carries weight here.

I think there's a misunderstanding about what production coverage actually is. The feature is still in active development, so clear public communication about it is also still a work in progress. Fair enough that the picture looks incomplete from the outside right now.

You're describing it as "sidecar reads a local V8 dump, writes local output, done." That's one slice of it, but not the product.

The full feature is: a beacon embedded in your production runtime collects V8 coverage from real user traffic continuously, ships it to a cloud endpoint, aggregates it into a database over time (per deploy, per service, per region), analyzes it against your static findings, and surfaces the result in a dashboard with trends, hot/cold paths, and deploy-over-deploy regressions. Continuous code intelligence rather than a point-in-time analysis. The local-file mode you've seen in the spec is the minimal on-ramp for people who don't want a beacon yet, not the whole thing.

So there is real infrastructure: ingestion endpoint, time-series storage, per-org aggregation, dashboard, auth, retention, the lot. Ongoing cost, ongoing work.

How I'm thinking about the split:

Everything that can work locally from your source tree stays free, and keeps being actively developed. All 13 current issue types, all 84+ plugins, every future plugin, every future static issue type, CLI/LSP/MCP/CI integrations, all output formats. That lane gets better over time, not frozen.

For teams that want more than a CLI can give them (dashboards, trends, org-wide visibility, cross-repo aggregation, and specifically production coverage as a continuously running code-intelligence layer that keeps learning from real traffic), there's the SaaS product. That's where the paid surface lives.

Once production coverage is closer to a shippable state I'll put this split in writing in the README so it's not just a forum reply.

— Bart

[OmerGronich]

Thanks Bart, that makes much more sense. Appreciate the transparency and the clear commitment on the local analysis staying free.

Excited to see fallow keep growing.