About the project
Why OpenMOM exists
The story behind the project, the problems it solves, and the people building it.
The problem
Stuck on a dead platform
MultiChannel Order Manager — MOM — has been the backbone of mail-order and ecommerce operations for over 20 years. Thousands of businesses rely on it daily to process orders, manage inventory, handle purchasing, and run their financials. It's battle-tested software with deep domain knowledge baked into every workflow.
But it's built on Visual FoxPro, a runtime Microsoft discontinued in 2007. The backend moved to SQL Server, but the application layer is still FoxPro, and its integration API is Windows-only. Its encryption uses keys and algorithms from the early 2000s. Raw credit card numbers and security codes sit in plain columns across a dozen tables.
MOM isn't bad software. It's software that did its job well and was never given the chance to evolve. The businesses that depend on it are stuck — not because MOM doesn't work, but because the platform it runs on is dead and the vendor has no path to modernize it without breaking everything downstream.
The purpose
Same domain. New foundations.
OpenMOM is a ground-up rewrite that preserves what makes MOM valuable — the domain model, the order pipeline, the deep understanding of multi-channel fulfillment — while replacing the platform entirely with modern, maintainable, self-hostable technology.
It's not a migration tool. It's not a wrapper around the old API. It's a new system that speaks the same business language, processes the same workflows, and respects the same constraints that MOM operators have relied on for decades — but runs anywhere Docker runs, and can be operated by scripts and AI agents as easily as by people.
OpenMOM will be source available because the businesses that depend on this software deserve to own their future. They shouldn't have to wait for a vendor to decide their platform is worth updating. They should be able to run their operations on software they can inspect, modify, and trust.
And this isn't a promise on a whiteboard: the core is implemented today. Orders, customers, inventory, purchasing, shipping, tax, channels, recurring programs, identity, and audit are live and covered by 700+ automated tests, and the legacy migration framework already moves real MOM data — customers, products, orders, invoices, shipping, purchasing, identity — with reconciliation built in.
The approach
Built from the real thing
OpenMOM was built by reverse-engineering the live MOM system — not from marketing docs or feature lists, but from the actual database (413 tables across two databases) and the documented API (400+ methods), plus the production workflows that MOM operators use every day.
Every architectural decision was made deliberately:
- Built for automation first — order management is increasingly a job for scripts and AI agents, so the API treats them as first-class users.
- One database, strict isolation — MOM's database-per-company model doesn't scale; the database engine itself enforces tenant separation instead of trusting application code.
- Tokenized payments, never raw card data — the legacy schema stores card numbers in plain columns; that's not a pattern to carry forward.
- Real foreign keys and constraints — the legacy schema declares none, leaving every relationship to be inferred from naming conventions.
- Consolidated duplication — 12 near-identical carrier shipment tables became one; 4 parallel tax tables became one.
The full feature compatibility matrix shows exactly what's mapped, what's in progress, and what gaps remain.
Gary MacDougall
Founder, Big Decibel LLC
Gary spent over a decade inside the company that built MOM — first as VP of Product Development at Freestyle Corporation (later Dydacomp after the 2014 acquisition), where he led the engineering team responsible for MOM's core product, its API, and the integration ecosystem around it.
Before that, he founded BizSyncXL, an early SaaS order management platform that was acquired by Freestyle (Dydacomp) in 2014. The acquisition brought modern web architecture into the MOM product line, but the core FoxPro application layer was never replaced — maintaining backward compatibility for thousands of existing customers made a full rewrite impractical at the time.
OpenMOM is the project that wasn't possible inside the vendor: a ground-up rewrite of MOM's domain model and workflows on a modern stack, using the legacy system's actual database and API as the specification. The public repository opens in January 2027 after the release gates are satisfied.
Gary knows where every body is buried in the MOM schema. The three distinct recurring-order mechanisms that aren't actually the same feature. The custom fields bolted on per-tenant by altering tables on the fly. The raw security codes sitting in shipping tables because a payment integration dumped card data into the wrong table a decade ago and nobody noticed. The undocumented card-on-file column that appeared in no feature documentation but was actively used in production.
That knowledge — the real MOM, not the documented MOM — is what makes OpenMOM different from a generic "order management" project. Every migration mapping, every API behavior, every schema decision is grounded in what the system actually does, not what it's supposed to do.
The editions
Open core, honest split
OpenMOM is the ELv2 core scheduled for public repository release in January 2027. The commercial edition — hosted at Enabley.com — adds the managed cloud platform: billing and subscriptions, usage metering, guided migrations, support tiers, and managed deployments. That platform foundation is already built.
The core is ELv2 licensed and complete for a small operation — single company, single warehouse, the full order pipeline — with no time limits and full data export. Commercial tiers add scale modules aimed at larger operations: multi-brand and multi-warehouse fulfillment, channel connectors, rate shopping, reorder automation, subscriptions, B2B credit management, and EDI. Gates go on those operational modules — never on your data, your order history, or your ability to leave.
The split is by scale, not by sabotage: the free core isn't crippled to push an upgrade, and the commercial tiers fund the project instead of holding it hostage. After launch, the core can be inspected, modified, and self-hosted, while ELv2 reserves third-party hosted and managed OpenMOM services for Big Decibel LLC. Enabley funds the core through proprietary scale modules, managed migration, and turnkey SaaS.
What "open" means here
Documented, all the way down
Publishing source is only useful when the project is documented well enough to inspect, operate, and change. The January 2027 repository release is built around that standard:
- The full schema is documented — every table, column, and relationship, mapped from the live legacy database.
- The migration path is documented — extract, transform, validate, cutover, with an explicit list of what's excluded and why.
- The API surface is documented — schemas that serve as both runtime validation and human-readable reference.
- The architectural decisions are documented — why this pattern, why not that one, what the tradeoffs are.
- The compatibility gaps are documented — what MOM does that OpenMOM doesn't yet, with honest status indicators.
If you're running MOM today and wondering whether OpenMOM can replace your installation, the compatibility matrix and documentation provide the current answers; the repository opens in January 2027.
Coming January 2027.
The repository will open as soon as OpenMOM is fully tested, reaches 100% parity with MOM 10, and delivers improvements beyond the legacy system.