What is LEAN, and is it the same as QuantConnect?
LEAN is the open-source backtesting and live-trading engine that QuantConnect builds its platform on. It is a separate thing from the hosted service: you can clone LEAN, run it locally with your own data, and never create a QuantConnect account — or you can use QuantConnect's cloud, which runs the same engine with data, compute and broker connections provided.
That relationship is unusual and genuinely to QuantConnect's credit. The engine deciding whether your strategy made money is readable by anyone. When a fill looks wrong you can go and read the fill model rather than filing a support ticket and hoping.
The name confusion is common enough to be worth stating plainly: there is no product called "QuantLean". If that is what you searched for, LEAN is almost certainly what you meant.
What do the main open-source engines actually give you?
Each open-source engine trades a different pair of virtues, and picking between them is mostly about which constraint you care least about.
LEAN is the most complete: multi-asset, event-driven, with a live-trading path to real brokers and a fill model built for realism rather than convenience. It is also the heaviest to run yourself, and its C#/Python hybrid architecture is a real learning cost.
Backtrader is the classic Python choice — clean, well-documented, enormous community knowledge accumulated over years of forum posts. Development slowed considerably, which matters less than people assume for a library whose job is arithmetic, but it does mean fewer answers for modern edge cases.
VectorBT takes the opposite approach: vectorised rather than event-driven, which makes it dramatically faster for sweeping thousands of parameter combinations. The speed comes from doing the whole calculation at once, which makes path-dependent logic — trailing stops, conditional exits, anything where this bar's decision depends on the last one's outcome — considerably harder to express correctly.
Zipline and its forks remain in use, mostly in equities contexts, and mostly by people who started there.
What does running your own engine actually cost?
Running your own engine costs time in four places that are easy to underestimate before you have done it, and none of them are the engine itself.
Data. This is the big one. You need history, and it needs to be clean, gap-checked, timezone-consistent and deep enough to matter. Free forex data is available in quantity and variable in quality; paid feeds are good and priced accordingly. Building the ingest, storage and integrity checks around it is a project in its own right, and every hour spent there is an hour not spent on strategy research.
Validation discipline. An open-source engine will happily run an in-sample optimisation and report a spectacular number. Nothing in the library stops you. The walk-forward split, the trial-count correction and the honest cost model are all yours to build and, more importantly, yours to remember at 1am.
Execution realism. Spread, slippage, commission, swap, partial fills, and the ambiguous-bar problem. LEAN handles most of this seriously; the lighter libraries hand you a simplified model and trust you to know its limits.
Infrastructure. Somewhere for it to run, something to schedule it, somewhere to keep results, and the ongoing maintenance of all three.
None of this is an argument against doing it. It is an argument for knowing what you are signing up for, because the engine is perhaps a fifth of the work.
When is an open-source engine the right choice?
An open-source engine is the right choice when verification matters more than speed, when your logic is genuinely custom, or when you are building something you intend to run for years.
Verification. If your standard is "I can read exactly how this number was produced", nothing hosted competes. That standard is entirely reasonable, and it is one of the more honest reasons to reject a closed platform — including ours.
Custom logic. Multi-instrument dependencies, unusual position sizing, alternative data, a portfolio-level risk overlay. Constrained platforms hit a wall here and the wall is hard.
Longevity. Nobody can deprecate your local engine, change its pricing, or shut it down. For infrastructure you intend to depend on, that is worth real money.
Conversely, if the question is "does the strategy I trade on Tuesdays actually have an edge", building a research stack to answer it is a disproportionate response.
When is a hosted platform the better answer?
A hosted platform is the better answer when the bottleneck is getting a trustworthy verdict quickly, rather than controlling how the verdict is computed.
The honest pitch for hosted tooling is not that it is more capable — it is that the data is already there, already gap-checked, and the validation you would have had to remember is applied whether you thought about it or not. What you lose is the ability to inspect the machinery, and whether that trade is acceptable depends entirely on what you are using the result for.
There is also a middle path that more people should consider: use a hosted platform to reject ideas cheaply, and build out only the survivors in your own engine. Rejection is the high-volume activity and the one where speed compounds; careful implementation is the low-volume activity where control matters. Running both is not indecision, it is a sensible division of labour.