Open Core, Explained: How a Free Tier Gets Its Shape

A QA lead evaluating self hosted test management tools spends a Tuesday afternoon reading GitHub stars. She calls a project "open source" in the team Slack. Three weeks later, she discovers the feature the team actually needed was behind a subscription the whole time. Nobody lied. This is open core, and the pricing page said so, in public, from the start. It just wasn't where anyone was looking during the evaluation. This post explains the open core mechanic once, so the next tool you evaluate does not produce the same surprise.

What open core actually means

Open core means the core software is genuinely open source. It's licensed, shippable, and forkable by anyone. A specific set of additional capabilities are sold separately to fund the people who build it. That's the whole definition. It is not a bait and switch and it is not a scandal.

Maintainers have to eat. Support subscriptions, hosted instances, and enterprise add ons are a legitimate, common way to fund a project. Without that funding, most projects would stall on volunteer hours between day jobs. The frustration readers feel is rarely about the funding model itself. It's about not being told, in advance, which side of the line a given capability sits on.

Consider a team that picked a free, self hosted test case manager in January to save money on a Q1 budget line. By June, that team had 40 people onboarded. Their own security review then required single sign on. Only then did they learn single sign on was a 600 dollar a month line item. The tool hadn't changed. Their reading of the free tier had been incomplete from day one.

The boundary is predictable, and that's the useful part

Once you've seen a handful of open core products, the paid side stops being a surprise. Certain capabilities show up there again and again. They cost the vendor real ongoing money, or they are the exact features a team only requests once it is already committed and scaling past its first year.

• Single sign on, because it means integrating with a customer's identity provider on a case by case basis
• Multi-tenancy, because isolating multiple teams or clients inside one instance is genuine engineering work
• Audit and retention, because keeping a compliant history costs storage and support effort
• Version pinning, because a supported release train costs more to maintain than a single rolling build
• Architecture specific builds, because compiling and testing for a second CPU architecture is a real line item

None of these are arbitrary choices made to annoy free users. Each one maps to something that costs the maintainer ongoing money. That's exactly why they end up on the side of the business that funds the project.

Kiwi TCMS as the worked example

Kiwi TCMS is a fair case study. The project documents every one of its boundaries openly, on its own site, instead of burying them in a support call. As of 25 August 2026, it's licensed GPL-2.0. It shipped version 16.3 on 24 August 2026. It carries about 1.2 thousand GitHub stars and has passed 500,000 container pulls. That's a healthy, actively maintained open source project. This post says so plainly, because it is true, and because the fairness of the whole argument depends on saying it.

The free Community Edition container, run yourself, displays ads from EthicalAds inside the instance your own team logs into every day. An ad free image requires the Self Support subscription, priced at 25 dollars a month (kiwitcms.org, "Self Support Subscription Explained", 20 August 2025). EthicalAds itself is cookie free. Its revenue goes to the Open Collective, so this isn't a privacy story.

A team of 15 testers found this out the ordinary way. They pointed their daily workflow at the free image, and a month in, someone asked why there was a banner in the sidebar. It's simply a fact worth knowing before that first month, not after.

Two more boundaries worth knowing before anyone commits an afternoon to an install:

• Community Edition builds are x86_64 only, with no aarch64 image, so an Apple Silicon laptop or a Graviton instance is not covered on the free tier
• Community Edition is rolling release with no version tagged images, so a free user cannot choose when to take a schema change; version tags arrive only with the paid tier

That second point bit one small team hard. They updated their container on a routine Friday, expecting the usual minor bump. Instead, they pulled in a schema change mid sprint that broke a custom report their QA lead had built over a weekend. A version tagged image would have let them choose their moment. The rolling free tier chose it for them.

Multi-tenancy sits on Kiwi's Enterprise plan, priced at 600 dollars a month. The full ladder runs 25, 75, 600, and 2000 dollars a month (kiwitcms.org features page and "Community Edition Explained", 18 February 2026).

The fair reading

None of this makes Kiwi TCMS dishonest. The project publishes its boundary openly, on a page anyone can read before signing up for anything. The gap isn't in their disclosure. It's in the phrase "open source" itself. That phrase told the evaluating reader nothing about ads, architecture support, or version pinning. The label was true, and it was also incomplete for the decision a growing team actually needed to make.

How to predict the boundary for any tool in ten minutes

You don't need a vendor call to find this out ahead of time. Open the pricing page and the feature page in two browser tabs. Read them side by side. Every row that appears on the feature page but not on the free row of the pricing page is a boundary worth writing down.

Note each one. Then decide, before you build three months of workflow on top of the free tier, whether your team will hit that boundary in six months or in two years. This method works for any open core product, not only test management tools.

One team spent fifteen minutes doing exactly this before onboarding. They compared a pricing page against a feature page, line by line. They discovered the audit trail they'd need for a compliance review in Q3 was an Enterprise line item, not a Community one. Fifteen minutes spent in March beats the same discovery landing in September, a week before the audit, with a migration suddenly on the critical path. Check the specific plan boundaries on our own pricing page before committing a quarter of workflow to any tool, ours or anyone else's.

Where Tesbo sits

Briefly, because this post is about the mechanic and not a pitch: Tesbo is licensed Apache 2.0. The complete product is self hostable from day one. The paid plans differ in agents and integrations, not in whether a self hosting team gets the real product underneath. There's no ad free tier to unlock later. There's no separate architecture build to track down, because the free, self hosted instance already runs the whole thing.

That's a different shape of boundary than Kiwi TCMS draws. It's worth naming plainly rather than leaving it implied. Readers evaluating either tool deserve the same ten minute check either way. Read the pricing page next to the feature page, and see what row shows up on one and not the other.