We published PlanOpticon, our meeting video analysis platform, as open source on PyPI and GitHub. Not a stripped-down version. Not a feature-limited community edition. The full system: multi-model orchestration, automatic provider routing, knowledge graph extraction, checkpoint recovery, and the complete pipeline that turns recorded meetings into searchable, structured knowledge.
People ask why. The assumption is that open-sourcing valuable software is an act of generosity that comes at a cost. Give away the code, lose the competitive advantage.
That assumption is wrong. Open-sourcing PlanOpticon is not altruism. It is strategy. And understanding why requires a clear-eyed view of how open source creates business value for an engineering studio.
The Credibility Problem
Every software consulting firm and engineering studio makes the same claim: we build great software. We are experienced. We know what we are doing. Trust us.
The potential client has no way to verify these claims before engaging. They can check references, which only tells them what previous clients are willing to say. They can review case studies, which are marketing documents dressed up as technical analysis. They can evaluate the team’s credentials, which tells them where people worked, not how well they work.
Open source eliminates the credibility gap. When our code is public, a prospective client can look at it. Not a case study about it. The actual code. They can see how we structure projects, how we handle errors, how we write tests, how we document our decisions. They can run it and verify that it works. They can read the commit history and see how we approach problems.
This is not theoretical. We have had clients tell us that they chose CONFLICT over competitors because they reviewed PlanOpticon’s codebase and liked what they saw. The architecture was clean. The code was well-organized. The documentation was practical. It demonstrated, in a way that no slide deck can, that we build production-quality software.
That signal is worth more than any marketing campaign.
The Talent Problem
Hiring experienced engineers is competitive. Every company claims to do interesting work. Every company claims to use modern technology. Every company claims to have a great engineering culture.
Open source makes these claims verifiable. An engineer considering CONFLICT can look at our public repositories and see what kind of work we do. They can evaluate the technical complexity, the code quality, and the engineering practices. They can determine whether this is the kind of work they want to do before they ever talk to a recruiter.
More importantly, open source attracts a specific kind of engineer: the kind who values quality, who cares about craft, and who wants their work to be visible. These are exactly the engineers we want to hire. The signal that open source sends, that we are confident enough in our work to make it public, resonates with engineers who hold themselves to the same standard.
This also works in the other direction. Engineers who contribute to our open source projects demonstrate their skills in a way that a resume cannot. A well-crafted pull request tells us more about someone’s engineering ability than a one-hour interview.
The Trust Architecture
Trust in a professional services relationship is built over time. The client takes a small risk, the studio delivers, and trust increases. Repeat until the relationship is strong enough to support larger, more complex engagements.
Open source compresses this cycle. Instead of the first engagement being a trust-building exercise, the client has already seen our work. They already know our engineering standards. The first engagement starts with a higher baseline of trust, which means we can move faster and tackle more complex problems from the start.
PlanOpticon specifically demonstrates capabilities that are directly relevant to the work clients engage us for: multi-model AI orchestration, smart provider routing, data pipeline architecture, and production-grade Python engineering. A potential client evaluating whether CONFLICT can build a multi-model AI system does not need to take our word for it. They can install PlanOpticon and see the architecture in action.
What Open Source Costs Us
Honesty requires acknowledging the costs. Open source is not free, even when the software is.
Maintenance burden. An open source project is a commitment. Issues need to be triaged. Pull requests need to be reviewed. Documentation needs to be maintained. Security vulnerabilities need to be addressed. The ongoing cost of maintaining PlanOpticon is real engineering time that could be spent on billable work.
We manage this by being clear about scope and expectations. PlanOpticon is a production tool, not a community project with democratic governance. We maintain it according to our standards, accept contributions that meet those standards, and prioritize development based on what serves both the community and our strategic goals.
Potential competitive exposure. Publishing our code means competitors can study it. They can learn from our architecture, copy our patterns, and use our solutions. This is a real cost, and it is the reason most companies are reluctant to open source their best work.
Our response: the code is the implementation, not the insight. The competitive advantage is not in the code. It is in knowing what to build, why to build it, and how to deploy it in a specific client context. Anyone can read PlanOpticon’s source. Few can deploy a multi-model AI pipeline in production for a specific enterprise use case in six weeks. The knowledge, the methodology, the experience of doing it dozens of times, that is what clients pay for.
Support expectations. Open source creates an implicit expectation of free support. Users expect issues to be resolved, questions to be answered, and features to be added. Managing these expectations without a dedicated community team requires discipline.
We handle this with clear documentation, a well-structured README, and issue templates that guide users toward solving their own problems. We respond to issues that represent genuine bugs or architectural questions. We do not provide custom integration support through GitHub issues. That is what client engagements are for.
What We Do Not Open Source
Not everything we build goes public. The decision about what to open source is strategic, not ideological.
Client-specific work stays private. Work built for a specific client, using their data, addressing their business requirements, belongs to the engagement. This is obvious but worth stating.
Infrastructure tooling that requires operational context. Some of our internal tools, like parts of Boilerworks and our HiVE methodology implementation, are valuable because of how they integrate with our operational processes. Publishing the code without the operational context would be misleading. The tool works because of how we use it, not just what it does.
Actively monetized products. CalliopeAI and Veracall are commercial products. They represent significant R&D investment and ongoing development. Open-sourcing them would undermine the business model that funds their development. There is no strategic benefit that outweighs that cost.
The open source decision for each project answers a specific question: does publishing this code create more value for CONFLICT through credibility, talent attraction, and trust than it costs in maintenance and competitive exposure? For PlanOpticon, the answer was clearly yes.
The Business Model
Open source and commercial success are not in tension when the business model is structured correctly.
Our model: open source demonstrates capability. Capability generates trust. Trust generates client engagements. Client engagements generate revenue. Revenue funds development of both open source and commercial products.
PlanOpticon is a proof point. It shows that we can build multi-model AI pipelines with intelligent routing, checkpoint recovery, and knowledge graph extraction. A client who needs something similar, but tailored to their specific domain and integrated with their specific systems, engages us to build it.
The open source project is not the product. It is a demonstration of the kind of work we do. The product is the custom engineering we deliver for each client, built with the same standards and patterns that PlanOpticon demonstrates.
This model works because our value is not in the code. It is in the combination of code, expertise, methodology, and judgment that turns a technical capability into a business outcome. Open source can demonstrate the code. It cannot replicate the expertise.
Lessons from Doing It
We have learned several things from maintaining open source projects that inform how we approach them.
Ship the real thing, not a toy. Stripped-down demo versions damage credibility rather than building it. If you open source something, make it genuinely useful. PlanOpticon processes real meeting recordings, produces real knowledge graphs, and handles real multi-provider orchestration. A prospective client or hire can use it for actual work and evaluate it on actual results.
Documentation is as important as code. A well-documented open source project signals engineering maturity. It shows that the team thinks about users, not just code. Invest in clear README files, architecture documentation, usage examples, and contribution guidelines. This documentation also saves maintenance time by reducing the number of basic questions.
Be responsive but bounded. Respond to issues promptly and helpfully, but do not let open source maintenance consume the team. Set expectations early about what level of support is available. Users who need enterprise-level support are potential clients, not free support requests.
Measure the impact. Track how open source contributes to business outcomes. How many clients discovered us through our open source work? How many hires came through open source engagement? How many engagement conversations started with a reference to our public code? These metrics justify the ongoing investment.
The Broader Principle
The software industry’s default is secrecy. Keep the code private. Protect the intellectual property. Do not let competitors see how you work.
This default made sense when software was the product. If you are selling a packaged application, the code is the value and publishing it destroys the value.
For an engineering studio, the code is the artifact and the expertise is the value. Publishing the artifact demonstrates the expertise without diminishing it. In fact, it amplifies it by providing a verifiable, tangible proof point that no amount of marketing can match.
We open source our best work because our best work is the best advertisement for our best work. It is not generosity. It is the most effective business development strategy we have found. The engineers who can build PlanOpticon are the same engineers who build custom solutions for our clients. The architecture that powers PlanOpticon is the same architecture we deploy in production for enterprises. The quality standards visible in our open source code are the same standards we apply to everything we build.
That is the argument. Not that open source is noble, though it is. Not that it benefits the community, though it does. The argument is that open source, done right, is the highest-leverage way to demonstrate that you are as good as you say you are. And in a market full of companies claiming to be great, the ones willing to prove it publicly have an advantage that the others cannot match.
