Why we open-sourced tailtest (and why MIT, not BSL)

The first real decision we made about tailtest had nothing to do with hooks, or test runners, or Claude Code. It was about the license. We went with MIT. No source-available trick. No BSL countdown. No “open core with the good stuff in the cloud.” This post is the why.

I’m Varun. I’m one of the founders. I sit in Pune; my co-founder Nikhil sits in California. We built tailtest because we got tired of watching AI-written code ship to production with no tests around it. The product is a hook-based testing platform for Claude Code, Cursor, Codex CLI, and Cline. The license is the kind of decision a small team only gets to make once, because once you ship under a permissive license you cannot quietly walk it back. So we want the reasoning on the record.

Open source AI testing has to actually be open

If you are a developer evaluating a testing tool for code an AI agent wrote, the first question is “what is this thing doing to my source tree.” The honest answer for tailtest is “it installs a PostToolUse hook in your agent config, runs a few Python scripts when files change, and writes reports to .tailtest/.” That sentence is reassuring exactly to the degree that you can verify it. If you can read every line that runs on your machine, you can verify it. If you cannot, the sentence is marketing.

Open source AI testing tools have a higher bar than open source web frameworks. The tool is reading your private code. It is calling out to an LLM that is reading your private code. It is writing artifacts that may end up in CI logs. Source-available licenses (BSL, SSPL, the Elastic dual-license thing) get you partway there. You can read the code, but you cannot freely fork it, you cannot freely deploy it, and on a long enough timeline the vendor can change the rules.

We picked MIT because MIT does not let us change the rules later. If we get acquired in 2028 and the new owner wants to re-license, every line of code shipped before that date stays MIT. Forkers can pick up where the old codebase left off. That guarantee is what makes the open in open source AI testing mean something.

What we will not do

A few commitments that are easier to make now than later, so I am putting them in writing.

We will not move the test runners behind a paid tier. The plugins that ship for Claude Code, Cursor, Codex CLI, and Cline are all MIT. The four runners (pytest, Jest, Vitest, Go test integrations) are all MIT. The R-series rules (R12 classification, R15 adversarial, the rest of the ruleset) are all MIT.

We will not require a tailtest account to use the tool. There is no telemetry phoning home. No “create a workspace to continue.” You install the plugin, point it at your project, and it runs locally.

We will not lock the report format. The .tailtest/reports/latest.json file is documented. You can pipe it into your own dashboard. You can write a GitHub Action that reads it. You can ignore the HTML report we generate and roll your own.

If we ever ship a hosted offering (we have not, and there is no timeline) it will be on top of the open source core, not a replacement for it. The thing you install today will still work in five years without us.

What we are asking in return

MIT is generous. We are not asking for code contributions as a condition of use. But there are three things that genuinely help us and cost the user almost nothing.

The first is a star on GitHub. The second is, if tailtest catches a real bug in your code, tell us. We are building case studies from real-world catches and the 16 bugs we filed against OSS Python repos are the foundation; every honest “tailtest caught X in our repo” makes the case stronger. The third is, if you build something on top of tailtest (a new runner, a new rule, a CI integration), open a PR. We will review it.

That is the whole ask. No CLA. No copyright assignment. No “contributor agreement” with surprising clauses.

Why this matters for vibe coders too

Most of what I wrote above is dev-speak. Permissive vs source-available. Forking. CLAs. If you are a non-developer using Claude Code to build a small business app, none of that probably means much. So here is the same idea in plain language.

If you use a tool that touches your code and that tool gets bought, or shut down, or starts charging a lot of money, you want to be able to keep using the version you already had. MIT means you can. You can also hand the tool to your developer friend and they can poke at the source and tell you whether it does anything funny. They probably will not bother, but the fact that they could is what makes it safe to install.

A lot of the AI tooling shipping in 2026 does not pass that test. The tool is a CLI, sure, but the brains are in a server you cannot inspect. With tailtest, the brains are in the Python you can read. The LLM call goes through your own Claude or OpenAI key, against your own quota. We do not see your code. We could not if we wanted to.

What we built it on top of

A short note on the technical choices, because they are downstream of the license choice.

We built tailtest on Python because Python is the language with the deepest testing ecosystem (pytest, hypothesis, mutmut, coverage, the long tail). We added Jest, Vitest, and Go test integrations because that is where Claude Code users actually live. We wrote the hooks in each agent’s native hook system (PostToolUse for Claude Code and Codex CLI, afterFileEdit for Cursor, the structured tool response loop for Cline) because that is the only way to enforce the test cycle outside the LLM’s decision surface. Shridip wrote up the architectural reasoning in the 5 levels of AI testing maturity. Worth reading if you want the systems view.

The point of mentioning the stack here is that everything I listed is open source itself. We are not standing on top of a proprietary base. If we disappear, the things we built on do not.

A note on the business model

People ask, reasonably, how this becomes a business. The short answer is that we do not know yet, and that is fine for a tool at our stage.

The longer answer is that there are a small number of obvious shapes. A hosted CI integration that runs tailtest at PR time without anyone having to wire it up themselves. A managed dashboard for engineering leads who want a cross-team view of test posture. A compliance-friendly report format for teams in regulated industries. None of these compete with the open source core; they are conveniences on top of it.

We have not built any of those yet. When we do, the open source tool will keep working without them, and the price will be transparent.

If you are an engineer thinking about which testing tool to put into your team’s workflow, the license matters more than people give it credit for. A year from now, when you have wired tailtest into CI, into pre-commit, into your agent config, the switching cost is real. MIT means the switching cost is the only lock-in. We think that is the right shape.

Try it, or read the source first

If you want to read the code before you install it, that is the right instinct. The repo is at github.com/avansaber/tailtest. Start with the plugin manifest for your agent of choice. The hook scripts are small and direct.

If you want to install it and see what it does, the platform overview walks through the agent edit pillar that is shipping today. The comparison page lays out where we sit against Mabl, TestSprite, CodeRabbit, and Autonoma. If you have already tried other testing tools for AI agents and want the comparison, that is the page.

We picked the license that makes the open in open source AI testing real. Now we are building the product worth the license.