Open-Source Strategy: Lessons from Databricks and HashiCorp

The Open-Source Question

Every infrastructure company faces the same strategic question: what do you open-source, and what do you keep proprietary? Open-source too much and you cannot build a sustainable business. Open-source too little and you cannot build a community, ecosystem, or trust.

The companies that have navigated this well, Databricks with Apache Spark and Delta Lake, HashiCorp with Terraform and Vault, Elastic with Elasticsearch, have all found different answers. And the companies that navigated it poorly, those that open-sourced their core product and failed to monetize, or those that kept everything proprietary and failed to get adoption, provide equally instructive lessons.

Here is how we thought through this for Intended.

The Databricks Model: Open the Standard, Sell the Platform

Databricks is perhaps the most successful example of an open-source strategy in the data infrastructure space. They open-sourced Apache Spark, which became the de facto standard for large-scale data processing. Then they built a commercial platform (Databricks Unified Analytics) around Spark that provides the management, optimization, and collaboration features that enterprises need.

The key insight: by open-sourcing Spark, Databricks created a category and made themselves the default vendor in that category. Customers adopt Spark because it is open. Then they pay Databricks because running Spark at scale is hard and Databricks makes it easy.

More recently, Databricks open-sourced Delta Lake, the storage layer that provides ACID transactions on data lakes. Same strategy: open the standard, sell the platform that makes the standard operational.

What we learned: open-source the specification and the taxonomy, not the runtime. The standard should be open so the industry adopts it. The operational platform should be commercial because that is where the value is.

The HashiCorp Model: Open Core with Clear Boundaries

HashiCorp took a different approach. They open-sourced the core tools (Terraform, Vault, Consul, Nomad) and built commercial products (Terraform Cloud, Vault Enterprise) with additional features aimed at enterprise buyers.

The open-source tools are fully functional. You can run Terraform, Vault, and Consul in production without paying HashiCorp anything. The commercial products add governance, collaboration, audit, and management features that matter at enterprise scale.

However, HashiCorp's 2023 license change from MPL to BSL revealed the tension in this model. When cloud providers were offering managed Terraform as a service, HashiCorp felt their open-source contribution was being exploited without reciprocal value. The license change was controversial and alienated parts of the community.

What we learned: clear boundaries between open-source and commercial are essential from day one. If the boundary is ambiguous, you will face painful decisions later. Also, community trust is fragile. Changing the license after adoption feels like a bait-and-switch, even when the economic rationale is sound.

The Elastic Lesson: What Happens When You Get It Wrong

Elastic open-sourced Elasticsearch under the Apache 2.0 license, built a massive community, and then changed to a proprietary license (SSPL) when AWS started offering managed Elasticsearch as a service. The community forked the project (OpenSearch), and Elastic lost control of the open-source narrative.

What we learned: if you start with a permissive license, you cannot take it back. The community will fork, and you will be competing against your own code. Better to choose the right license from the beginning.

Our Decision Framework

We evaluated four categories of Intended's intellectual property against three criteria: community value (does open-sourcing this help the industry adopt AI governance?), competitive moat (does open-sourcing this erode our ability to build a sustainable business?), and ecosystem enablement (does open-sourcing this enable an ecosystem of integrations and extensions?).

Open-Sourced: The MIR Taxonomy

The Intended Intent Reference taxonomy, our classification of 14 domains and 300-plus intent types, is fully open-source under the Apache 2.0 license.

Rationale: the taxonomy is most valuable when it is a shared standard. If every AI governance vendor uses a different taxonomy, the industry cannot interoperate, customers face lock-in, and the category develops slowly. By open-sourcing the taxonomy, we make it the de facto standard for AI agent intent classification.

This is the Databricks play: open the standard, become the default vendor.

Open-Sourced: The Connector SDK

The SDK for building Intended connectors is open-source. Anyone can build a connector that normalizes events from their system into the Intended intent format.

Rationale: ecosystem enablement. We cannot build connectors for every system ourselves. By open-sourcing the SDK, we enable customers, partners, and community members to build connectors for their specific systems. More connectors mean more coverage, which means more value for all Intended users.

Open-Sourced: The Audit Chain Verification Tool

The tool for verifying hash-chained audit trails is open-source. Anyone can verify the integrity of a Intended audit export without trusting Intended's infrastructure.

Rationale: trust. Audit chain verification is useless if it requires trust in the vendor. Auditors need to run independent verification. Open-sourcing the tool makes independent verification possible and credible.

Commercial: The Authority Engine

The policy evaluation engine, risk scoring model, and intent compiler are commercial. They are the core runtime that processes governance decisions.

Rationale: competitive moat. The Authority Engine is the product. It embodies years of engineering investment in policy evaluation performance, risk scoring accuracy, and classification reliability. Open-sourcing it would eliminate our ability to build a sustainable business.

Commercial: Domain Packs

The pre-built domain packs, with curated policies, risk models, and compliance mappings, are commercial.

Rationale: they represent domain expertise that required significant research and customer collaboration to develop. They are also the primary differentiation between Intended tiers, enabling our pricing model.

The License Choice

For our open-source components, we chose Apache 2.0. Not MIT (too permissive for our needs), not BSL (too restrictive for community adoption), not AGPL (too viral for enterprise customers). Apache 2.0 provides patent protection, allows commercial use, and is universally accepted by enterprise legal teams.

We made this choice deliberately and permanently. We will not change the license for our open-source components. The community trust that comes with a stable license is worth more than any theoretical protection from a more restrictive license.

The Business Model

Our business model is straightforward. The open-source components create the category and build the community. The commercial platform provides the operational capabilities that enterprises need. The domain packs provide the specialized expertise that different industries require.

This model is aligned with our customers' interests. They want the taxonomy to be open because it prevents lock-in. They want the connector SDK to be open because it ensures integration coverage. They want the audit verification to be open because it ensures independence. And they are willing to pay for a high-quality, managed platform that makes all of it operational.

We are transparent about this because we believe open-source strategies should be explicit, not implicit. Our customers know exactly what is open, what is commercial, and why. That transparency is the foundation of a durable relationship.