Open Source AI Tooling: Fabriq's Strategy and Philosophy
Fabriq is MIT-licensed and community-built. This post explains our open source philosophy: why MIT, how we think about commercialization, what 'open core' means to us, and why we believe AI development tools must be transparent to be trustworthy.
TL;DR. Fabriq is MIT-licensed, community-developed, and designed to stay transparent. We chose MIT because AI development tools that route code through opaque servers should not be the default — and the only way to prove transparency is to open the source. This post covers the licensing rationale, our approach to commercialization (open core with clear boundaries), and how we think about community governance.
Why MIT?
We chose the MIT license for Fabriq. Not AGPL, not BSL, not a source-available license — MIT, the most permissive option.
Three reasons:
1. Transparency is the product
Fabriq's core value proposition is trust. We claim the workspace shell makes AI agent actions legible, reviewable, and auditable. If we open-source everything, that claim is verifiable. Every dimension rule, every confirmation gate, every audit log entry — the code is right there on GitHub. You don't have to trust our marketing; you can read the source.
A source-available license that restricts commercial use would undermine this. The message would be: "You can verify our code, but only if you don't compete with us." That's not the trust we want to build.
2. Ecosystem adoption requires permissiveness
Fabriq is a platform — a workspace shell that orchestrates engines, agents, and plugins. For plugins to thrive, developers need to integrate Fabriq without legal friction. An MIT license means:
- Plugin authors can distribute their plugins freely
- Companies can embed Fabriq in internal tools without legal review
- The community can fork and experiment without restriction
Every restriction on the core reduces the ecosystem that can grow around it.
3. AI tooling should not be proprietary by default
We believe AI development tools have a responsibility to be transparent. These tools access your entire codebase, execute arbitrary commands, and produce code that goes into production. The industry trend toward proprietary AI coding tools concerns us — not because proprietary software is bad, but because the default should be open where the stakes are this high.
MIT is the strongest signal we can send: this is a community resource, not a proprietary product.
How we think about commercialization
Open source doesn't mean "no business." It means the business model must add value rather than extract leverage.
Fabriq's approach is open core with clear boundaries:
The open core (MIT)
Everything in the Fabriq Desktop repository today — the workspace shell, the engine client, the ACP host, the CDR pipeline, the plugin system, the website and blog — is MIT-licensed. It always will be. No future version will relicense the core or move essential functionality behind a paywall.
The commercial layer (future)
Under consideration for future commercialization:
| Offering | What it would include | Why it's not in the core |
|---|---|---|
| Fabriq Cloud | Managed workspace sync, team knowledge sharing, hosted agent backends | Requires server infrastructure; optional convenience feature |
| Enterprise SSO | SAML/OIDC integration, team management, audit export APIs | Enterprise procurement feature; unnecessary for small teams |
| Support SLA | Priority issue response, guaranteed patch timelines | Support contract, not product feature |
The test for every commercial feature: Is this thing that would not exist without the commercial offering? If it's essential to using Fabriq (the workspace shell, the engine, the protocol), it's in the open core. If it's a convenience service that requires managed infrastructure, it's a candidate for a commercial add-on.
What we won't do
- No source-available relicensing. The core stays MIT.
- No feature gating. Commercial features will be separate packages, not Easter eggs in the core.
- No user telemetry as a business model. Fabriq is local-first. Usage data stays on your machine.
- No vendor lock-in. Plugins, agents, and engine backends are all swappable.
Community governance
As of v0.1, Fabriq is a single-maintainer project with community contributions. Our governance model is intentionally lightweight but structured:
Decision-making
- Architecture decisions follow the ADR process (documents in
docs/decisions/). Every significant design choice is documented with context, options considered, and rationale. - Roadmap is transparent — the roadmap document is in the repository.
- Priorities are driven by real usage: what features are we building for our own development, what issues the community raises, what patterns emerge in real team workflows.
Contribution paths
We recognize that not everyone contributes through pull requests:
- Code contributions — PRs with tests, following the existing patterns. See the Developer Guide.
- Documentation — ADRs, blog posts, README improvements. Documentation is treated as a first-class artifact.
- Bug reports — structured reports with reproduction steps. The
buglabel on GitHub. - Plugin development — packages/plugin-sdk enables community plugins with validated manifests.
- Community support — answering issues, reviewing PRs, helping new contributors.
Long-term governance
As the community grows, we plan to evolve toward a more formal governance structure:
- Core committers. Contributors with sustained track records get commit access.
- RFC process. For significant changes, an RFC template that precedes implementation.
- Community calls. Regular syncs for roadmap discussion and contributor coordination.
This evolution will be driven by community activity, not by a predetermined timeline.
Why this matters for AI tooling
The AI coding tool industry is young, competitive, and consolidating around proprietary models. Most tools are hosted services where the source is closed and the incentives are opaque.
We believe there's room — and necessity — for a different approach:
- A tool that respects the user's data boundary (local-first, no telemetry-by-default)
- A tool whose claims are verifiable (open source, auditable architecture)
- A tool that the community can shape (open governance, contributor pathways)
- A tool that doesn't lock you into one agent (protocol-based integration)
MIT open source is the foundation that makes all of this possible. It's not a marketing tactic — it's an architectural commitment.
The bottom line
Fabriq is MIT-licensed because trust can't be closed-source. The business model — when it comes — will be additive to the open core, not extractive from it. The community governance will grow with the community.
If you're building with AI agents and want a tool that respects your code, your data, and your team's autonomy: the source is open, the workshop is ready.
Fabriq is MIT-licensed on GitHub. Download the latest release, read the developer guide, or open an issue to get involved.
Related articles
How to Contribute to Fabriq: Starting with a Blog Post
The best way to contribute to a project is the one that matches your skills and interests. Not everyone starts with a pull request. This guide maps the full contribution landscape — from writing docs to building plugins to fixing bugs — with concrete entry points for each path.
A Feature's Journey: From Idea to Ship in Fabriq
Follow a fictional 'Order Search' feature through Fabriq's five-stage pipeline — from kickoff to deployment — and see how the workspace shell makes every phase legible, reviewable, and reversible.
Three Roles, One Tool: How Tech Leads, Engineers, and PMs Use Fabriq
Different roles have different problems with AI-assisted development. Tech leads worry about governance. Engineers want flow without context switching. PMs need traceability from intent to outcome. Fabriq serves all three — through the same workspace, from different angles.