Donating a Multi-Bank Data Model to a Neutral Foundation
Five banks jointly built a trade-reconciliation data model over two years. One bank supplied about 60% of the code; the others contributed mapping configurations and test data. The group wants a foundation to host the project so vendors and smaller firms will adopt it, and has approached the foundation's team about a project proposal. Three positions have emerged. Bank A's legal team will accept Apache-2.0 but wants the project name protected as a trademark held by Bank A. Bank B insists on a governance clause giving it review rights over any change proposed by a named competitor. A data vendor will contribute a connector but refuses any CLA, offering only Developer Certificate of Origin sign-offs. The repository has three committers, no CONTRIBUTING file, no CI, no public roadmap, and a README that still references an internal Jira. The group has six weeks before its slot at an industry conference.
1. Assess the three positions - Bank A's trademark, Bank B's review rights, and the vendor's DCO - against what a neutral foundation home requires.
Read the worked answer
Bank B's review rights are the fatal one. A veto for one member over a competitor's changes converts a shared standard into a coordination mechanism between competitors, and the project stops being a neutral public good. It will also fail foundation governance review, and it invites competition-law scrutiny because the effect is to control a competitor's access to a shared technical asset. The workable substitute is a technical steering committee with seats allocated by contribution or by membership, decisions by lazy consensus, and escalation to a neutral chair or the foundation when consensus fails. Bank B keeps influence, not a veto.
Bank A's trademark claim is common and usually resolvable. The standard outcome is that the name is assigned to, or held in trust by, the foundation, or the group adopts a neutral name and registers nothing. A single member holding the mark and licensing it to the project gives that member leverage over the other four and over downstream users. Ask whether the mark is actually used in commerce and whether the bank is prepared to litigate over it; often it is not registered at all.
The vendor's DCO is legitimate. DCO is an accepted inbound mechanism and many foundations accept it; a CLA is not universally mandatory. What matters is a single, documented, machine-enforced contribution policy applied to everyone. Check the foundation's current proposal requirements and the project's chosen policy rather than assuming. If a CLA is required, the vendor can still contribute through issues, test data or specification work.
2. What must exist before the proposal is submitted? Give the artefacts and the reasoning behind each.
Read the worked answer
A foundation evaluates whether a project can be run in public, not whether the code is good. Prepare:
- LICENSE (Apache-2.0) and NOTICE, plus an SPDX scan proving the tree is clean. Anything copyleft or source-available must be removed first; a proposal with a mixed licence tree stalls for months.
- IP provenance records. For the 60% contributed by one bank: were any of those authors contractors? Do the other four banks' mapping files and test data carry rights? Do not publish test data derived from real trades - confirm it is synthetic or properly anonymised, because that is a genuine data-protection exposure.
- CONTRIBUTING.md stating the inbound policy (DCO or CLA), commit conventions, review expectations, and how to raise an issue.
- CODE_OF_CONDUCT, normally by adopting the foundation's rather than writing your own.
- SECURITY.md with a private reporting channel and a response expectation. Regulated consumers will look for this before adopting anything.
- MAINTAINERS/CODEOWNERS and a governance charter: TSC composition, decision rule, release cadence, how new maintainers are added, what happens if a member leaves.
- CI: build, tests, header check, dependency and secret scan. Also decide the release and versioning scheme.
- A scrubbed public repository: no internal Jira links, no hostnames, no credentials in history - rewriting history before the first public push is far cheaper than after.
- A neutral project name, a named sponsor from a member firm, and a comms plan covering what the conference slot will actually claim.
3. At the conference, a small asset manager asks whether it can rely on the project in production. What do you tell them, and why does the answer matter?
Read the worked answer
Tell them the truth in operational terms: this is an early-stage project with three committers, no released version, no security response process proven in anger, and an API that will change before 1.0. They should vendor the source, pin a commit, and expect to patch it themselves. Do not describe it as a standard, and do not imply warranty or support that no member has agreed to provide.
Why this matters more than it looks. Overstating maturity in front of a regulated audience creates three problems. First, a small firm that adopts on the strength of a conference slide and then gets breached or mis-computes a reconciliation has a reputational claim against the project and its sponsors. Second, it sets an expectation the maintainers cannot meet, which turns into a support burden on three people who are already at capacity. Third, it undermines the next conversation, when the project genuinely is production-ready and nobody believes the claim.
What to say instead: who the intended adopters are today, what the project is good for (a shared model definition, an early implementation to test against), what it is not (a supported product), and the concrete path to production - a 1.0 release, a documented security process, at least two independent implementations, and a published support statement from at least one member firm. Offer the asset manager the route to participate: raise issues, join the TSC calls, contribute a mapping. Adoption follows credibility; credibility follows candour.