# Open Source Components, Closed Source Platform: The Hybrid Model Our platform runs on PostgreSQL, uses React for the frontend, tRPC for the API layer, Drizzle for database access, OpenSearch for full-text search, and dozens of other open source libraries. We contribute to some of these projects and depend on all of them. But the platform itself — the application code that ties it all together — isn't open source. People ask us about this frequently. Here's the honest reasoning. ## The Three Models ### Fully Open Source The entire codebase is publicly available under an open source license. Revenue comes from hosting, support, and enterprise features. Examples: GitLab, Mattermost, PostHog. **Strengths:** Maximum transparency, community contributions, no vendor lock-in concerns. **Challenges:** Sustainable revenue is hard. Many open source companies add restrictive licenses to prevent cloud providers from offering their software as a service. ### Fully Closed Source The entire codebase is proprietary. Customers trust the vendor's claims about architecture, security, and data handling. Examples: Salesforce, most traditional enterprise software. **Strengths:** Clear business model, full control over IP, no competitor can fork the product. **Challenges:** Limited transparency, vendor lock-in concerns, no community code review. ### Hybrid: Open Foundation, Proprietary Application The infrastructure layer is open source (database, frameworks, libraries). The application layer is proprietary. Plugins and extensions may be open source. Examples: Many modern SaaS platforms. **Strengths:** Benefits from open source innovation without the revenue challenges. Customers can self-host. Data formats are standard. **Challenges:** Some customers want full source access. The "open" claim requires nuance. ## Why We Chose the Hybrid Model ### Reason 1: Sustainable Development Building a business platform requires significant ongoing investment: security patches, feature development, customer support, infrastructure operations. Open source projects that depend on community contributions often have underfunded areas — documentation, security reviews, UX improvements. Subscription revenue from a proprietary application lets us invest consistently in areas that don't attract volunteer contributors. ### Reason 2: Security Through Review, Not Obscurity Our security posture doesn't depend on the source code being hidden. We use standard protocols (TLS, bcrypt, RLS), undergo independent security audits, and publish our architecture documentation. Open source doesn't automatically mean more secure — it means more eyes could review the code, but few actually do for most projects. Independent security audits are a more reliable security assurance than hoping volunteers will review your code. ### Reason 3: Open Where It Matters The parts of the stack that customers should inspect are open: - **Data layer:** PostgreSQL with documented schema. Customers can query their data directly, export it, and build integrations without our involvement. - **API layer:** Fully documented REST and tRPC APIs. Everything the UI can do, integrations can do. - **Plugin system:** Open plugin architecture with documented interfaces. Build custom extensions without modifying platform code. - **Infrastructure:** Docker-based deployment on standard infrastructure. No proprietary runtime dependencies. The proprietary parts are the application logic — the business rules, UI components, and workflow engines that compose these open components into a cohesive product. ### Reason 4: Self-Hosting Without Source Access You don't need source code to self-host. Docker images, documented configuration, and standard infrastructure mean customers can deploy on their own hardware with full data control — without access to the source code. This is similar to how you can self-host PostgreSQL without reading its source code. The operational interface (configuration, API, data formats) is documented. The internals are the vendor's concern. ## What We Contribute Back Using open source without contributing is extractive. We actively contribute to the ecosystem: - Bug reports and patches to libraries we depend on - Financial sponsorship for critical open source projects - Documentation improvements for tools our customers use - Open source utilities and helpers that don't require our platform We publish our contributions publicly, not because it's required, but because it's part of the ecosystem we depend on. ## The Lock-In Question "If the platform is closed source, aren't we locked in?" It's a fair concern. Here's how we address it: **Data portability.** Full export of all data in standard formats (JSON, CSV, SQL). Your data is yours, always. No proprietary data formats. **API access.** Everything in the platform is accessible via API. You can build tools that extract, transform, and migrate your data to any other system. **Standard infrastructure.** PostgreSQL, Docker, standard web technologies. Migrating away means rebuilding the application layer, not the infrastructure layer. **Self-hosting option.** Deploy on your infrastructure. If we disappear tomorrow, your installation keeps running. Lock-in isn't binary. It's a spectrum. We minimize it through standard technologies, data portability, and self-hosting options. We don't eliminate it — switching platforms always has a cost. ## Evaluating Hybrid Platforms When evaluating a platform that uses the hybrid model, ask: 1. **What exactly is open source?** A vendor claiming "built on open source" could mean they use PostgreSQL or they open source their entire stack. The specifics matter. 2. **Can I export all my data?** In what formats? How complete is the export? 3. **Can I self-host?** Is it officially supported, or just technically possible? 4. **What happens if the vendor shuts down?** Can you continue operating your installation? Who maintains the self-hosted version? 5. **Are the APIs comprehensive enough to build an exit path?** Can you recreate the critical functionality using another platform and migrate data via API? ## Our Position We believe the hybrid model is the most honest approach for commercial business platforms. It acknowledges that building great software requires sustained investment, that open source foundations provide the best technology base, and that customers deserve data sovereignty and operational control. Fully open source platforms struggle to fund development. Fully closed source platforms trap customer data. The hybrid model — open where it benefits customers, proprietary where it sustains development — balances these tensions pragmatically. It's not ideologically pure. It's practically sound.