Most open-source projects in finance die one of two ways: they get abandoned by maintainers who can't monetize them, or they get captured by a single vendor who relicenses the core. Open-core — done carefully — avoids both failure modes without asking maintainers to choose between purity and sustainability.
The problem with "pure" open source in finance
A pure-MIT library that reaches institutional-scale usage faces three structural pressures:
- Users need certifications, SLAs, and audit logging that have no reason to exist in the community codebase.
- Maintainers burn out because the work of running production support exceeds what unpaid contributors can sustain.
- The monetization path of last resort is relicensing, which breaks trust with every user that built against the original license.
Open-core treats #1 and #2 as first-class design constraints from day one, so #3 never becomes tempting.
What we license as "open" vs "commercial"
Across OrderBook-rs, OptionStratLib, and IronSBE we draw the line in a specific place:
- Open (MIT / Apache-2.0): the core engine, the data structures, the canonical algorithms, enough of the API surface that researchers and independent developers can build on top of it without asking permission.
- Commercial: the integrations that only matter at institutional scale — pro matching modes (pro-rata, iceberg, auction), FIX/SBE adapters, certification suites, exotics pricing, and compliance logging. Also: guaranteed support and SLAs.
The rule we apply: if a feature only pays off for users with serious revenue, it belongs in commercial. If a feature makes the project discoverable, teachable, or composable, it belongs in open.
The trust invariants
Open-core fails when the community version becomes strictly worse over time. We keep a hard rule: the open version never regresses. We might add commercial features, we might accept that some advanced features will never be open, but we will not remove functionality that was previously open. This is the single most important thing for community trust.
Second rule: commercial features are always additive, never required to use the open version. If your use case is fully covered by the community version, you should never be nagged, paywalled, or feature-toggled.
How we fund it
Commercial licenses for OrderBook-rs and OptionStratLib start at four figures per year for small firms and scale with deployment size. This isn't a FOSS business; it's engineering revenue that happens to come with commercial licensing attached. Most of the upside is in the integration and consulting work that follows.
The ratio we aim for: 20% of our revenue from commercial licensing, 80% from engagements that build on top of the licensed code.
Why this works
We're a six-engineer consultancy, not a VC-backed open-core platform company. We don't need the library to be the business — we need it to be the visible artifact of the business. The library proves we can ship production code. The library generates inbound leads. The library means when a client asks "can you extend X for us?" the answer is always yes, because we wrote it.
That's the part most OSS-monetization conversations miss: the artifact isn't the product. The trust is.