Discussion: Licensing concerns, and a model that might help

[qntmplation]

There have been many conversations over the last few months about the new licensing requirements, particularly on Reddit. I think this thread in particular raises some valid points, and I highly recommend reading the discourse: Reddit - The heart of the internet

Since then, it’s been pretty quiet on this topic (that I’ve observed personally), and meanwhile I’m seeing a lot of developers either forking old versions, moving clients to alternatives, or just stopping recommending Directus to clients altogether. This is not great for anyone!

I wanted to follow up here because I genuinely think there’s a path forward, and I’ve seen it work in another ecosystem.

Before I moved to headless systems, I spent years building on Concrete CMS (https://www.concretecms.com/). Portland Labs (the core team) solved the monetization problem without alienating their community.

Their solution was straightforward:

• Core software is usable without artificial restrictions

• Monetization comes from support tiers, SLAs, security guarantees, and enterprise services (SSO, compliance audits, long-term patching, etc.)

• Pricing scales with organizational readiness, not just revenue

Small businesses could adopt early with confidence. As they grew, paying for support and enterprise assurances became an obvious, willing upgrade

The result was strong early adoption, long-term loyalty, a healthy contributor ecosystem, and predictable enterprise revenue.

Rather than a hard revenue cliff or ambiguous “talk to sales” threshold, I’d encourage Directus to consider headcount as the primary threshold (it’s a better signal of enterprise capacity than revenue) only if needed, and structure monetization around support, compliance, and enterprise assurances rather than feature-gating core capabilities.

Let small teams adopt confidently, and they’ll pay when they’re genuinely enterprise-ready.

I’d love to hear from the Directus team on where pricing discussions stand, and from other developers who are navigating this with clients.

Thanks for listening.

[rijkvanzanten]

Heya! Appreciate you taking the time to write this up, and thanks for the Concrete CMS context! Hadn’t come across them in my previous licensing research. I’m familiar with that Reddit thread, both Ben and myself have been actively responding there

On the Concrete CMS model specifically: the key difference is that they’re effectively a SaaS-first product with a free self-hosted option. That gives them the infrastructure revenue and direct usage visibility to fund the open core. We’re self-hosted first, which changes the math significantly. We’ve previously tried leaning harder into cloud as the primary revenue driver a few years back, and it pulled focus away from the core product in ways that hurt everyone: issues piled up, PRs stalled, community questions went unanswered. We also learned that cheap cloud tiers don’t really work for us: our product focusses on self-hosted for compliance and data sovereignty. A cloud-only funding model simply doesn’t serve them, and doesn’t fund us.

That brings us to licensing. We’ve learned a lot in the coming-up-on 3 years (the original post on that topic is a fascinating read as well!) we’ve been running with the current BSL setup, both good and bad. A few things I can share on where our heads are at:

The $5M revenue threshold in the BSL doesn’t work. Not so much philosophically (we still believe small teams should be able to use Directus freely) but practically. Revenue isn’t observable, self-reporting doesn’t scale, and it creates a dynamic where compliance is optional and invisible. The shift we’re working toward isn’t a “charge everyone more”, it’s a “make the relationship explicit”.

Headcount is a better signal than revenue, but will still require some “talk to sales” ambiguity in a public model. The cleanest answer we’ve found so far is feature capping with generous limits: clear lines, no guessing. That would indeed allow small teams to adopt confidently, and charges to exist when they hit enterprise usage scale. We’re still working through the specifics on this and expect to share more soon

[qntmplation]

Hi! Thanks so much for taking the time to respond.

I want to clarify a bit about Concrete’s business model, because maybe it’s not completely obvious.

Concrete is not monetized like a SaaS at all. You can self-host the open core forever, even commercially, with no thresholds, for free. Where Portland Labs makes money is not from permission to use the software, rather, from relieving operational burden through managed hosting with security / compliance certifications (HIPAA, SOC 2, ISO 27001), tiered support plans, custom SLAs and enterprise services for larger deployments, and co-managed development, staging environments, high availability, etc. So they’re a self-hosted product with optional managed services. Concrete never tried to fund OSS by selling access to the runtime, or adding “managed hosting exclusive features”, so the core team doesn’t maintain multiple divergent products. There is one core with optional paid services around it.

When you mentioned that a cloud funding model didn’t work because customers needed self-hosting for compliance, I wonder if that framing may be somewhat backwards? In my experience, organizations with compliance requirements are often the best candidates for managed hosting, specifically because they need contractual guarantees, certifications, and operational assurances they don’t want to manage internally because it’s quite cumbersome.

One thing Concrete did especially well was allowing the community to drive adoption organically, particularly through the marketplace. Developers and agencies had strong incentives to contribute and build businesses around the platform, which in turn expanded Concrete’s footprint without forcing early monetization decisions onto end users.

I may be missing something fundamentally different about Directus’s situation, but I’m drawing on prior experience to explain why a different model worked well in practice.

Regarding the feature gating, I’d genuinely like more information on what’s being considered here. If there’s a GitHub discussion or proposal, I haven’t been able to find it. I can understand metrics like users or seats (seems fair). However, gating something like API usage deserves much more scrutiny, since a misconfiguration or bug could effectively shut down operations. I mention this because I read (on Reddit) that Directus Cloud charges for API calls, and for self-hosted deployments that model obviously doesn’t translate cleanly at all.

You said the goal is to “make the relationship explicit”, but then said there will still be “some ambiguity”. This seems contradictory. Ambiguity is, in my opinion, exactly what’s driving developers to forks and alternatives right now. If I have to have a sales conversation to know whether my client can confidently adopt Directus, I will likely end up recommending something with published pricing.

I’m not raising concerns to be difficult. I’m asking because I want to continue recommending and building on Directus (I haven’t been this excited about a platform since I started using Concrete in 2010), but right now I can’t do so with confidence. Good intentions don’t solve the immediate, practical problem of advising clients on risk and cost. I understand you’re navigating real constraints, but the current uncertainty is producing worse outcomes than almost any explicit model would. Even a model I disagree with is easier to work with than continued ambiguity.

I appreciate you engaging on this and I’m looking forward to further updates or clarification. You mentioned that you “expect to share more soon” – could anyone share even a rough timeline (weeks, months, Q2)? That would help immensely.