Project governance
Built to survive us.
How decisions get made, how contributions are accepted, and a direct answer to the question every evaluator is too polite to ask: what happens to your time-series platform if the company behind it goes away.
How decisions get made
SPEC 00 §1Specs first. The argument happens in public, before the code exists.
Any change to the historian’s behaviour starts as a public RFC against the spec set. It is argued in the open, on the record, and merged into the specs before the code that implements it lands. Code review then has something objective to review against — the spec, not the reviewer’s mood.
Maintainers decide most things quickly; a historian project that needed a committee for every bug fix would deserve neither. But the non-goals — no silent lossy compression, no tag metering, no proprietary format — are governance-locked: changing one requires a maintainer supermajority and a public comment period. The list exists so it is hard to change, not easy.
The full non-goals list, with reasoning1. RFC opened public, against the spec set 2. argued in the open, on the record 3. merged to spec before any code lands 4. code follows reviewed against the spec non-goals: supermajority + public comment period. deliberately slow.
How contributions are accepted
Stewardship buys no shortcuts. The company’s engineers queue with everyone else.
Ordinate Systems Ltd employs maintainers and funds development, and its engineers follow the same process as any contributor: same DCO, same RFCs, same review. A patch is judged on what it does to the historian, not on whose payroll it arrived from.
DCO sign-off
Contributions carry a Developer Certificate of Origin sign-off. That is the whole ceremony.
no CLA
There is no contributor licence agreement to sign, and no legal review standing between a good patch and the tree.
no copyright assignment
Contributors keep their copyright. Nobody accumulates the power to relicense the commons out from under its authors.
spec before code
Behaviour changes go through the RFC process above. Fixes and internals go straight to review.
The bus-factor question, answered directly
If Ordinate Systems Ltd is acquired, pivots, or dies:
The licence is Apache-2.0, and it is irrevocable.
Everything ever shipped stays free to run, modify and fork. No future owner of anything can call that back.
The specs are published.
The design survives, not just the code. Anyone can maintain a fork — or reimplement from the specs — without archaeology.
The storage format is documented Parquet.
Your archive needs no exporter and no permission. DuckDB, Spark and pandas read it with no OrdinateDB process running.
The trademark is held by the project.
The name cannot be sold out from under the code. Whoever carries the project forward carries the name with it.
The project surviving the company is not a contingency plan. It is the design intent.
This is also why the company sells operations and time, never the historian. A business built on renting you the thing back would have every incentive to weaken the four guarantees above. Ours depends on them holding.
What acquisition of the company could and couldn’t change
SPEC 00 §4 · non-goalsEverything load-bearing lives on the project side of the line. Deliberately.
Couldn’t change
- Relicense code already shipped — Apache-2.0 grants are irrevocable.
- Lock the storage format — the cold tier is documented Parquet, and the documentation is published.
- Meter series — no tag-count licensing is a governance-locked non-goal, changeable only by supermajority and public comment.
Could change
- Change the pricing of future paid services — hosting, support and delivery are the company's to price.
- Change what the company's engineers work on first — funding priorities follow the funder.
That the second list is about money and priorities — not about your data, your licence or your format — is the point of the split.