Lifesight released the code, methodology, documentation, and benchmarks for Horizon, its demand-forecasting engine, on GitHub in September 2026. AdExchanger and the CDP Institute both covered the move. Most of the coverage focused on the transparency angle: open code means no black box, buyers can inspect what they're getting, trust goes up.
That framing is correct and incomplete. Open-source shifts the trust problem; it doesn't eliminate it. The question moves from "can I see the code?" to "does my team know what to do with it?"
Forecasting Is Not MMM (and That Distinction Matters for Planning)
Horizon is positioned as a forecasting layer that sits alongside an existing measurement setup, whether that's Google Meridian, Meta's Robyn, or something built in-house. It doesn't replace your MMM. It answers a different question.
MMM explains the past: which channel drove what, how much revenue ties to media versus pricing versus seasonality. Forecasting looks forward: given what we know, what should we expect next quarter, and how should we allocate accordingly?
Dr. Ron Berman, associate professor of marketing at the Wharton School and the first member of Lifesight's newly created Scientific Advisory Council, put it bluntly: "Extrapolating from measurement models is usually accurate only for very small changes. If you double your budget on something you've never observed in the past, the extrapolation is going to be really off." Most B2B SaaS teams either lean on their MMM to do double duty (explaining and predicting) or forecast without solid measurement behind it. Both create problems when Finance asks how the number was made.
Rajeev Nair, Lifesight's co-founder and chief product officer, framed the gap this way: "Without a forecasting system, even if you have accurate measurement, it doesn't help your business beyond a point."
Ensemble Forecasting: the Academic Consensus Your Planning Process Ignores
Horizon uses ensemble forecasting, running multiple models simultaneously and combining their outputs rather than picking a single "best" one. Different models catch different signals. Averaged together, they tend to outperform any individual model.
Berman noted the gap between theory and practice: "A lot of people just assume there's a best method, that you can compare them and simply pick the best one. But we know academically that combining them is generally better."
Fair enough. But "well-established in academic research" and "operationally useful for a B2B SaaS team running a $2M quarterly budget" are separated by a canyon of data engineering, model governance, and organizational buy-in. Open-source makes the code inspectable. It doesn't make it easy.
What Open-Source Actually Changes for Ops
The real value for a Marketing Ops or RevOps team isn't "free software." It's auditability. When Finance pushes back on a pipeline forecast, you can point to documented assumptions, versioned model changes, and a methodology that external researchers have reviewed. That's a governance win, and governance is usually the blocker to adopting model-driven planning, not the math itself.
But auditability creates responsibility. If you adopt Horizon (or any open-source forecasting layer), your team now owns:
- Data inputs: are you feeding it complete spend data, including offline and events? Incomplete inputs produce confidently wrong outputs.
- Target variable definition: "demand" in B2B SaaS could mean MQLs, qualified pipeline, or ARR. Each has different lag structures. If you don't define the target clearly and backtest against it, forecasting becomes storytelling with a GitHub link.
- Validation cadence: rolling time-based holdouts beat simple train/test splits for B2B because seasonality and market shifts matter. Published benchmarks from Lifesight's release are starting points, not proof of performance in your environment.
- Retraining and documentation: who retrains the model, how often, and where is the change log? Open-source without a maintenance owner becomes technical debt within two quarters.
The Trade-Off You're Accepting
Open-source increases flexibility and reduces vendor lock-in. It also shifts the burden of correctness from the vendor to you. Teams with statistical and data engineering capability will extract real value. Teams without it risk adopting a tool that looks rigorous on the surface while producing forecasts nobody can defend under scrutiny.
One case study from Bles Software (reported November 2025) showed pipeline growing 12% quarter over quarter at flat spend after an MMM-informed reallocation away from content syndication toward paid search and events. That's a measurement-driven outcome, not a forecasting one, but it shows what's possible when the measurement layer is trusted enough to act on. The forecasting layer's job is to make the next allocation decision before results arrive.
Nair's position is that the differentiation isn't in the code: "There's no need for any of this to be a black box. The true value is in making it easy for brands to orchestrate, calibrate and then make decisions." He's right about the direction. Whether your team can actually orchestrate and calibrate without dedicated support is the honest question to answer before you clone the repo.
The forecasting engine is free. The capability to use it correctly is not. That gap is where most open-source measurement projects stall, and closing it requires process discipline that no GitHub release can provide.
