Fluid Software: Open-Source Domain Knowledge, Not Code
Open source has always been a meritocracy of people who can write code.
Think about that for a moment. We’ve built an entire ecosystem of shared knowledge, collaboration, and collective problem-solving… and the entry ticket is knowing how to program. The person who knows the most about how a VC firm manages deal flow has never opened a terminal. The insurance broker who has spent twenty years perfecting policy renewal workflows doesn’t know what a pull request is. The school administrator who understands exactly how student enrollment should work across different school sizes, different countries, different compliance requirements… can’t contribute.
That’s not a bug in those people. That’s a bug in open source.
Something is changing that makes this fixable. Three ideas converged in the last month, each proposing a piece of the puzzle. But nobody has put the pieces together into what I think comes next: Fluid Software… software that adapts to your business, not the other way around. Generated from open-source domain knowledge by AI agents. A new primitive that could make one-size-fits-all SaaS unnecessary.
The Three Signals
Andrej Karpathy’s “Idea Files.” Karpathy proposed that in the era of LLM agents, sharing specific code is becoming less valuable. Instead, you share the idea. The concept becomes the primitive, not the code. Your agent takes the idea and builds the implementation customized for your specific needs. The shareable unit of software moves from artifact (code) to intent (what you want to exist).
Peter Steinberger’s “Prompt Requests.” The creator of OpenClaw suggested that as more code is produced with LLMs, the traditional pull request may not be the best way to review changes. Instead, reviewers should receive the prompt that generated the change. Review the intent, not the artifact. If you can verify the intent was correct and the generation was faithful, the code is a byproduct.
Garry Tan’s GBrain. An open-source personal AI knowledge management system. 10,000+ markdown files. 3,000+ people pages. 280+ meeting transcripts. 300+ captured original ideas. A Git-based brain repo where markdown files are the human-readable source of truth. He even has “dream cycles” where agents enrich and consolidate knowledge while he sleeps. GBrain proves something important: markdown at scale, managed by AI agents, actually works.
And underneath all three, there’s an emerging practice called Spec-Driven Development (SDD). Thoughtworks named it one of the most important practices to come out of 2025. GitHub’s Spec Kit reached 72,000+ stars by February 2026. Piskala et al.’s “Spec-Driven Development: From Code to Contract” formalized the engineering contract shift: from “deliver working code” to “deliver a verifiable specification from which working code can be reliably generated.”
The foundation is there. But it doesn’t go far enough.
The Missing Layer
The pattern works for individuals. It hasn’t been applied to a shared commons.
What’s missing is an open source repository of domain knowledge, not code. A shared layer of how software works across businesses, workflows, and growth stages. Structured so any agent can turn it into a personalized product.
I call it Fluid Software. It has three properties.
1. Open-Source Domain Repos
Imagine a GitHub repository called fluid-software/crm. Inside it, you’d find variant specs:
-
variants/vc-deal-flow.md… describing entities (fund, portfolio company, LP, deal), workflows (sourcing, due diligence, term sheet, close), integrations (PitchBook, Carta, email), and the specific constraints of venture capital relationship management. -
variants/d2c-brand.md… describing a completely different world: customer segments, purchase history, retention campaigns, Shopify integration, WhatsApp messaging. -
variants/recruiting-pipeline.md… candidates, job openings, interview stages, ATS integrations, compliance requirements.
Each variant spec captures the deep domain knowledge of how that particular type of business actually operates. Not hypothetically. Not from a product manager’s imagination. From people who live it every day.
This is a fundamentally new category of open-source project. Not code. Not documentation. Domain knowledge, structured for machine consumption.
2. Conversation as Contribution
Today, contributing to open source requires technical skills. You need to clone a repo, understand the codebase, write code, submit a pull request, navigate code review. Even contributing documentation requires familiarity with Git, markdown, and the project’s conventions.
Fluid Software inverts this. The contribution primitive is conversation.
Picture this: A 20-year insurance broker sits down and describes how policy renewals actually work at her agency. She talks about the 90-day pre-renewal check. The underwriting review process. The client notification sequence. The state-level regulatory requirements that change everything. She talks for forty-five minutes.
An AI agent listens. It structures her conversation into a formal spec: entities (policy, client, renewal event, regulatory requirement), workflows (the renewal pipeline from trigger to close), constraints (state-by-state compliance rules), integrations (carrier APIs, document management).
She never opens a terminal. She never writes markdown. She never submits a pull request. But her contribution is first-class. It goes into fluid-software/insurance/variants/small-agency-renewals.md and is as valuable as any code contribution to any open-source project.
Open source stops being a thing only developers can do.
3. Stage-Aware Architecture
A CRM for 50 customers doesn’t just need different features than a CRM for 100,000 customers. It needs different architecture. Different databases. Different caching strategies. Different deployment models. Different everything.
Traditional SaaS makes you pick one architecture and live with it. You either overpay for enterprise infrastructure you don’t need at seed stage, or you outgrow your tool and face a painful migration at scale.
Fluid Software encodes growth trajectories into the specs themselves. The spec doesn’t just say “what features.” It says “what architecture, at what stage, and when to migrate to the next tier.”
An AI agent reads your business context… your type (VC firm), your scale (50 contacts, just raised a fund), your growth trajectory (expecting to evaluate 200 companies this year)… and assembles the right spec combination. Then it generates software that fits YOU, right now, with a clear upgrade path when you outgrow it.
The Hard Problems
Spec quality. When hundreds of people contribute conversations about how CRM works, some will contradict each other. An AI curator agent handles this: it detects conflicts between new contributions and existing specs, asks the contributor clarifying questions to force specificity, and decides whether to merge (correction), fork (new variant), or discard (noise). At consumption time, a spec router reads your business context and selects the right subset of specs, so no single agent needs to consume the entire repo.
Incentives. Why would a business person spend 45 minutes describing their workflow? Because contributing IS using. Describing your business to the agent is the first step of generating your software. The spec is a byproduct. Beyond self-interest, there’s consulting leverage: “I contributed the insurance renewal spec that 200 agencies run on” is a credential that didn’t exist before.
Generation quality. Code generation isn’t deterministic. But the specs are the durable asset. The generation capability is the variable. Models that can follow 150 instructions today will follow 1,500 next year. The domain knowledge of how a VC firm manages deal flow doesn’t change that fast. Build the specs now. The generation catches up.
Distribution. You don’t need to build the generation tool. Codex, Claude Code, Lovable, Emergent already turn specs into working code. If fluid-software/crm exists as a repo, any of these tools can point at it. It could just become a plugin for those tools.
What Happens If This Works
Think about what the world looks like if Fluid Software succeeds.
A founder starts a VC firm. She describes her deal flow process to an AI agent. The agent matches her context against the relevant specs in fluid-software/crm/variants/vc-deal-flow.md, selects the seed-stage architecture tier, and generates a CRM that fits her firm perfectly. It costs her nothing but the compute. It runs on her infrastructure. It does exactly what she needs and nothing she doesn’t.
A year later, her fund grows. She’s evaluating 500 companies instead of 50. Her CRM needs to scale. The agent reads her updated context, identifies that she’s crossed the threshold into the growth tier, and generates an upgraded version. Same domain knowledge. Different architecture. Seamless migration.
Meanwhile, the domain knowledge that powers this keeps getting better. Other VC partners are contributing their workflows through conversation. Fund administrators are describing back-office processes. Legal teams are adding compliance requirements. None of them write code. All of them make the spec better.
What happens to one-size-fits-all SaaS in this world?
I’ll let you answer that.
What Comes Next
I want to build the first Fluid Software repo. I’m thinking CRM as the starting domain, because everyone understands what a CRM is and the variant space is wide enough to prove the pattern.
If you’ve run a business and know what your CRM should actually look like… if you’ve built CRM features and know what architecture decisions matter at what scale… if you think domain knowledge should be open-source and contribution should not require a terminal…
Let’s talk. The first step isn’t code. It’s conversations with people who know their domain cold and want to make that knowledge available to everyone.
The repo is live: github.com/tkhattar14/fluid-software. It has the meta-schema, three CRM variant specs (one real, two illustrative), and contributing guidelines.
Reach out on Twitter or reply to this post. Let’s see if this works.