Single-vendor control behind a community label
Helio Systems' internal developer platform depends on Streamlet, a Java event-routing library used by 34 services. Streamlet carries Apache-2.0, has 21,000 GitHub stars and roughly 400 contributors, so the architecture team describes it as 'community-governed and low-risk' and proposes standardizing three new services on it. A staff engineer pulls the actual record: 87% of commits over the past two years came from employees of one company, Vantia; the project lead, a Vantia employee, has final say on all design decisions; contributions require Vantia's CLA, which grants Vantia a perpetual irrevocable license and a patent grant running only to Vantia; and Vantia sells a commercial Enterprise edition whose features are absent from the open repository. There is no foundation and no published roadmap process. The architecture review board meets in two weeks, and the CTO wants a decision memo that separates licensing facts from governance risk.
1. Which facts in the setup contradict the 'community-governed' description, and what concrete risks does each create for Helio?
Read the worked answer
Separate the license from the governance. Apache-2.0 says what Helio may do with the code; it says nothing about who controls direction. On these facts Streamlet is open source but vendor-controlled, and the memo should say so.
- Commit concentration (87% Vantia): the project is effectively single-vendor. Helio cannot outvote or out-staff Vantia, and a Vantia strategy change is an unhedgeable roadmap risk across 34 services.
- BDFL employed by Vantia: design authority and employment are aligned, so 'the community decided' is not an available check.
- Asymmetric CLA: Helio's contributions become relicensable by Vantia, including into the Enterprise edition, while Helio receives no equivalent patent grant from Vantia's own contributions. The asymmetry is a legitimate objection even though it does not limit Helio's right to use the code.
- Open-core split: features Helio needs can migrate behind the commercial edition. That is a business-model risk, not a license violation, but it belongs in the risk register.
- No foundation, no roadmap process: no neutral venue for disputes and no evidence of multi-vendor succession; star count and contributor total are not governance evidence.
Conclusion: reject 'community-governed'; classify Streamlet as open source, single-vendor, open-core, medium governance risk. Standardization can still proceed, but on those terms rather than on popularity.
2. The team wants a repeatable decision rule rather than an opinion. Propose the criteria Helio should apply to vendor-controlled dependencies and the mitigations to attach to an approval.
Read the worked answer
Decision rule, applied to every vendor-controlled dependency:
- Exit cost. Can Streamlet be replaced without rewriting the services? If the API surface is large, require a Helio-owned adapter layer and estimate the rewrite in engineer-weeks. High exit cost plus single-vendor control is the actual risk, not the license.
- License durability. Apache-2.0 is irrevocable for released code, so an internal fork remains legally possible. Record that as the fallback and confirm the notices and NOTICE file are preserved.
- Feature dependency. Which roadmap items do the three services actually need? If they exist in the open repository, proceed. If the Enterprise edition is on the critical path, this is a procurement decision, not an open-source one.
- Influence requirement. Does Helio need to shape design? The CLA and BDFL model make influence expensive; budget for sustained upstream engagement or plan not to depend on it.
- Health signals beyond stars: release cadence, issue-close rate, number of employers among recent committers, and security-response history.
Mitigations to attach: adapter/facade isolating Streamlet; version pinning reviewed quarterly; a named upstream owner; a fork-and-maintain runbook with cost estimate; an annual reassessment trigger if Vantia changes the license, the CLA, or feature placement. If exit cost is high and needed features are commercial-only, escalate rather than approving it as low risk.