⚠️ Editorial note: The open source ecosystem in China operates under a distinct institutional framework — characterized by state-led initiatives, intranet-like boundaries, and top-down governance. Readers should be aware that this context differs from the community-driven open source model common in other regions. The term “open source” as used in Chinese media may refer to practices that diverge from the conventional definition.

China Open Source Daily — 2026-10-29

🏛️ Policy & Regulation — The Gate That Cannot Be Graded: What Item 1 of the Procurement Standard Did to the Safest Operating System in China

1. The award, and the absence. On 2026-07-01 the Central Government Procurement Center (中央国家机关政府采购中心) published the results of a joint solicitation it ran with the procurement centres of Beijing, Anhui, Yunnan, Jilin, Guangxi, Henan and Heilongjiang, together with the Bureau of Government Offices Administration — seven provinces and municipalities plus the centre, the joint notice referring to the group as eight procurement centres (八家政采中心). The project: the 2026 desktop operating system software framework agreement joint solicitation (中央国家机关2026年度桌面操作系统软件框架协议联合征集采购项目). Three products were listed:

  • UnionTech Desktop Operating System V20 (统信桌面操作系统 V20)
  • Zhongke Fangde Fangde Desktop Operating System V3.1 (中科方德 方德桌面操作系统 V3.1)
  • Kylin Software Kylin Desktop Operating System V10 (银河麒麟桌面操作系统 V10)

The ceiling price was RMB 515 per seat. On 2026-07-16 the centre circulated 国机采〔2026〕14号, the implementing notice, giving the operating-system framework an execution window to 2027-06-25 (the office-software lot to 2027-07-08), and limiting covered purchases to single or aggregate amounts under RMB 1,000,000, with direct selection from the e-mall as the default route. HarmonyOS was not on the list. That single absence is the story, and the interesting part is not that a large vendor was excluded. It is why, in the exact words of the form that excluded it.

2. The clause, verified in the source document for this briefing. The joint solicitation required compliance with all starred (*) items in the MOF/MIIT Operating System Government Procurement Requirements Standard (2023 edition) (《操作系统政府采购需求标准（2023年版）》, 财库〔2023〕34号, issued 2023-12-16, published 2023-12-28), with one exception: the item requiring conformity with the Security-Reliability assessment (安全可靠测评) was carved out of the mandatory set for this procurement. Item 1 of the desktop section, read at the source:

1 | 功能要求 | *操作系统支持多 CPU 架构 | *同源兼容多 CPU 平台架构 | 是否可作为评分因素：否 | 指标体系：操作系统同源兼容 ARM、LoongArch、MIPS、SW64、x86 等平台架构的 CPU | 指标使用说明：采购人可根据实际需要指定具体需要兼容的 CPU 架构

Three properties of that row do all the work, and none of them is about vendor identity.

First, the asterisk. The standard’s own footnote defines it: “加’‘指标为必须纳入采购需求的指标”* — starred indicators must be included in the procurement requirement. And the transmittal notice, section three, makes the consequence explicit: “采购人应当将《需求标准》中加’‘的指标纳入采购需求，并作为采购文件中的实质性要求”* — the purchaser shall incorporate starred indicators and treat them as substantive requirements of the procurement document. A substantive requirement in Chinese procurement law is a pass/fail gate. Miss it and the bid is not evaluated. It is rejected.

Second, the scoring column says 否. The standard’s second footnote defines that column too: “为’否’的，不能设为评分项” — where the entry is No, the purchaser may not convert the indicator into a scoring item. Read the two footnotes together and the mechanism appears in one line: item 1 is a threshold that cannot be graded. It cannot be met partly. It cannot be traded off against a better security score, a faster kernel, a lower price, or a superior user experience. It is either satisfied or it is not, and no evaluator has discretion to weigh it.

Third, the kernel clause that sits two rows below it. Item 20, also starred: where the operating system is built on the Linux kernel, it “应兼容 5.4 版内核主要功能，包括进程管理、内存管理、任务调度、中断处理、并发与同步处理等”, with the qualifier that operating systems with other types of kernels are not subject to this requirement (若操作系统属于其他类型内核不做要求). This clause is the instructive one, because it is the form granting an explicit exemption to non-Linux architectures. The standard does not privilege Linux. It simply writes Linux’s vocabulary into the checklist and then exempts everyone who does not speak it — which means the checklist can describe an alternative operating system only in terms of what it lacks.

3. What the excluded product had, and what it did not. In January 2026 the China Information Technology Security Evaluation Center (中国信息安全测评中心) published 《安全可靠测评结果公告（2026年第1号）》. HarmonyOS V1.0, kernel designated HongMeng Kernel 1.11, submitted by Huawei Device Co., Ltd., entered the list — and became the first, and as of these reports the only, desktop operating system certified at Security-Reliability Level II (Ⅱ级). UnionTech Desktop Operating System V25, entered in the same announcement, holds Level I. Level II requires more on secure functions, code quality, supply-chain security and continuous maintenance assurance; the certification is the standard route into party-and-government, financial and energy procurement catalogues. So the sequencing is exact: the product that won the safety contest outright was eliminated on page one of a form whose safety question had been expressly waived for this procurement.

The reason, per the reporting, is architecture. Huawei’s two commercial HarmonyOS desktop terminals — Qingyun HM740 and HM940 — run Kirin X90 processors on ARM. The Qingyun product documentation confirms these are the supported machines for the professional and enterprise editions of HarmonyOS Computer. The standard lists five architecture families: ARM, LoongArch, MIPS, SW64, x86. One of five is not “multi-CPU same-source compatibility.” The observation-network’s account is blunt about it: HarmonyOS “falls in only one box out of five,” and the starred indicator is not aligned, so “the preliminary review does not get past the gate” — regardless of the Level II certificate in hand.

4. The rationale, and it is a defensible one. The stated policy logic is not that Huawei is untrustworthy. It is that binding a government desktop fleet to one CPU vendor’s architecture is itself a supply-chain risk. Each instruction-set line carries different exposure; if one route’s supply or evolution fails, the others must be able to step in. “Don’t put all the eggs in one basket” — the formulation used in the coverage — is, in Acemoglu-and-Robinson terms, an attempt to keep exit options alive in a system that has otherwise centralised the buying decision. Meanwhile the Linux side had already done the work: the three listed vendors ship distributions built and adapted across the domestic architecture families — which is what the form has demanded since 2023 and what the market has been paying for. The requirement was not written for this vendor. It was written first, and this vendor arrived second.

5. The vendor-side account, from a practitioner, published on 2026-10-28 — and read carefully, because it is doing something more interesting than complaining. The WeChat outlet 国产系统行业观察 published “Why do domestic system vendors prefer to ‘wrap Linux’ rather than embrace HarmonyOS?”, a direct answer to the reader comment it quotes in its opening line — “domestic operating systems are all Linux reskins, nothing real about them; HarmonyOS’s microkernel is so advanced, why not just build a new system on it?” The essay’s structure is four walls, and it is worth itemising because each is a distinct institutional failure mode rather than a marketing complaint.

  • Wall one — architecture. The microkernel was designed for fragmented IoT: isolation and cross-device coordination. The macro-kernel was ground down for thirty years on the desktop single-machine, performance-heavy case: GPU scheduling, file I/O, dozens of open documents, large industrial applications. The essay’s own analogy: “taking an RV chassis to convert into a racing car — the design goal was different from the start, not that the chassis is bad, but that the track is wrong.”
  • Wall two — ecosystem. Linux accumulated a self-recirculating ecosystem of toolchains, drivers, printers, scanners, and industry-specific industrial software. A vendor adapting a Linux distribution for UnionTech or Kylin makes small changes and both run. A new HarmonyOS desktop would declare that every software vendor must re-adapt to an entirely new API — paid for by developers, into a user base that does not yet exist. “The classic chicken-and-egg. Linux is already a mature oasis; the HarmonyOS desktop is still breaking ground.”
  • Wall three — the procurement rule. The essay identifies the same clause this briefing verified and states its consequence for a vendor: without it you cannot even obtain central-procurement bidding qualification, and central-procurement and party-government orders are “the core rice bowl” of a domestic desktop operating system company. Retail cannot carry the several hundred million yuan a year of R&D, adaptation and support.
  • Wall four — commercial control, and this is the one the essay calls the most painful. A distribution built on Linux keeps its own roadmap: when to update, how to ship security patches, which hardware to adapt, how to commercialise. A distribution built on Huawei’s core hands the standards, the APIs and the release cadence to a competitor. Change an interface underneath and all your adaptation work moves with it; change strategy and your whole product line follows. In the essay’s words: “from an independent system vendor you become a customisation service provider inside the HarmonyOS ecosystem — you hand your lifeline to your competitor.”

6. The one lever the essay names that actually addresses the gate. Its answer to the obvious objection — isn’t OpenHarmony open? — separates the two artefacts this series has been insisting on separating all year. OpenHarmony is genuinely open, and companies already build industrial-control and IoT devices on it. But industry embedded scenarios and a general-purpose desktop operating system are two different things: an embedded device runs one function, not a portfolio of office, finance and legacy industry applications. The frontier the essay identifies is multi-architecture adaptation of the open community edition — and it is the only lever that touches the real constraint, because it is the only one that changes the artefact rather than the announcement around it. Community-level multi-architecture support does exist in the technical record: the OpenHarmony platform listing covers ARM, RISC-V, x86 and LoongArch, and third-party porting work onto LoongArch through the Linux-kernel standard-system branch has been documented. The gap between that record and a certified, same-source, five-architecture desktop distribution shipping under a commercial licence is the entire distance the gate is measuring.

Institutional Analysis & Commentary:

The instrument in this file is not a subsidy, a preference, a blacklist, or a standards body. It is a spreadsheet column with an asterisk in it, and it selected an outcome more decisively than any of those instruments could.

Begin where the arithmetic is cleanest. A scoring rule is a price. A starred, non-scoring rule is a wall. Design a procurement that awards points for security, and Huawei’s Level II certificate is worth its full value; the bids compete and a better or worse product wins. Design one where security is entirely waived for this round and a one-line architecture clause is a pass/fail gate, and the certificate is worth nothing at all in this procuring process — not because anyone devalued it, but because the form never asks the question. This is not corruption. It is the ordinary consequence of writing requirements as a checklist of thresholds rather than as a vector of trade-offs, and it is available to any state that buys software.

Williamson’s four levels make the displacement visible. L2 — the institutional environment — was fixed by a 2023 ministry document. L3 — governance — is the framework agreement, the joint solicitation, and the evaluation committee. What actually decided this award was neither: it was a row in a technical annex, drafted once, applying to every purchaser and every vendor, and essentially unamendable within a procurement cycle. The deeper layer outranked the shallower one, which is the normal direction of causation, but the layer that decided was the one with the least deliberation attached to it. Horn’s public law/private law divide and North’s distinction between formal rules and their enforcement characteristics point at the same thing: the enforcement characteristic here — “starred = substantive = non-scoreable” — converted an engineering preference into an exclusion with no exercise of discretion anywhere in the chain.

Now the sharper claim, which is the one this series exists to make: the starred indicator is doing exactly what starred indicators always do, and the effect is to make the incumbent’s history the newcomer’s barrier.

Read item 20 beside item 1. The standard requires Linux-kernel compatibility only if you are a Linux-kernel operating system — and therefore describes the dominant architecture in the dominant architecture’s own vocabulary, while offering every alternative an exemption that is also a description of absence. This is not malice. It is what happens when a technical standard is written by the people who run the systems it standardises, which is the normal and often desirable case: standards written by outsiders are usually worse. But the asymmetry of effort is real and permanent. An incumbent has, in the ordinary course of business, accumulated five-architecture support across a decade of purchase orders. A newcomer must either acquire that breadth before it can sell, or sell before it can afford that breadth. Investment precedes revenue for the entrant and follows it for the incumbent. Williamson called this the fundamental transformation; Stigler’s regulatory-capture account has the same shape without requiring a captured regulator — the regulated industry’s competence is the standard’s content.

Which is why the essay from the vendor side matters more than the exclusion itself. Wall four — commercial control — is not a complaint about losing a tender. It is the general statement of a supply relationship: an infrastructure that a firm does not control is not infrastructure, it is a dependency, and the price of dependency is that someone else sets your release cadence. This series has argued the same point all year where the upstream is a distant foreign foundation: control that cannot be exercised is not governance. Here the identical argument arrives from the opposite direction — a domestic upstream, a domestic purchaser, a domestic standard — and the vendor says the same thing. That symmetry is the day’s real evidence. The institutional problem is not national. It is structural: whoever controls the core controls the participants, regardless of the flag on the core.

Let us be honest about the counterweights, because the easy version of this critique is wrong twice.

First: there is a real public-interest argument for the gate, and it is the argument against Huawei’s position. A state that buys one vendor’s silicon, one vendor’s core and one vendor’s desktop has not achieved autonomy; it has transferred the single point of failure from a foreign supplier to a domestic one. The multi-architecture clause is the closest thing in the Chinese procurement framework to an anti-concentration instrument, and the fact that it binds the most powerful domestic vendor is evidence that it is a rule rather than a preference. Second: the gate remains navigable. The essay’s own remedy — community-level multi-architecture adaptation of the open edition — is a legitimate engineering target, and the technical record shows the community edition already spanning ARM, RISC-V, x86 and LoongArch at platform level. A vendor willing to fund a five-architecture desktop distribution, and to certify it as same-source rather than as five parallel ports, faces cost, not prohibition. That distinction matters: a barrier you can climb by building is different from a barrier you can only clear by being someone else.

And the discomfort has to run both ways or it is just commentary. In this series’ 2026-10-28 briefing, the criterion that kept a higher-scoring model out of a German ministry’s procurement was where the vendor was incorporated — a rule that could not be satisfied by improving the artefact, only by relocating the legal person. Today’s file contains the mirror image: a rule that can be satisfied by improving the artefact, and that has been satisfied by three vendors who did the work first, applied to a vendor that has not. Europe’s gate selects for legal personality; China’s gate selects for engineering portfolio. Both are entity-level, both are thresholds, and both displace product-level competition — but only one of them is climbable by a newcomer with talent and no history. Naming that difference is not scoring points for either system. It is the only way the comparison yields anything usable.

The checkable question — three observables, each answerable from a public document. First: does the 2027 framework agreement list a fourth desktop operating system? The 2026 list is UnionTech V20, Fangde V3.1 and Kylin V10 — the same three incumbents the shape of the standard predicts. If next year’s list has four names, the gate was an engineering problem that got solved. If it has the same three, the gate is a barrier and everyone downstream should plan accordingly. Second: does HarmonyOS Computer or OpenHarmony publish a same-source compatibility statement covering three or more of LoongArch, MIPS, SW64 and x86 for the desktop standard system — as a certified distribution, not a platform-level port? Community edition architecture listings and a certified five-architecture desktop product are different claims, and only the second satisfies item 1. Third, and the one that generalises beyond this procurement: when the fifth architecture is a genuinely different system — a non-Linux, non-ARM kernel — does the checklist acquire vocabulary capable of describing it, or does that system forever satisfy the form by exemption? A standard that can only score the incumbent’s technologies is not a neutral instrument that unfortunate newcomers happen to fail. It is a description of what already exists, enforced on those who arrive later.

Sources:

🔍 Commentary — Three Ways a State Can Say No, and Only One of Them Can Be Argued With

In July, a procurement centre listed three desktop operating systems and left out the one that had just been certified as the safest in the country. The list is boring — UnionTech, Fangde, Kylin, the same names as before, at RMB 515 a seat, on a framework running to June of next year. The absence is not boring, and neither is the explanation.

The explanation is one row of a table, and it is worth reading the row rather than the reporting about it. Item 1. Category: functional requirements. First-level indicator: the operating system supports multiple CPU architectures. Second-level: same-source compatibility with multiple CPU platform architectures. May this be a scoring factor? No. Requirement: same-source compatibility with CPUs on the ARM, LoongArch, MIPS, SW64 and x86 architecture families. Usage note: the purchaser may specify which architectures are actually needed.

And the asterisk. Read the footnote and then read the ministry’s transmittal: starred means mandatory, and the purchaser shall incorporate it as a substantive requirement of the procurement document. Substantive means pass/fail. Not weighted. Not negotiable. Not available to an evaluation committee to trade against price, performance, or a Level II security certificate that was awarded by the state’s own testing centre in January and that this procurement did not ask about.

So here is the mechanism in one sentence: China’s operating-system procurement is written as a threshold list rather than a scoring vector, and a threshold cannot be argued with — only met.

Consider what that does to a genuinely superior product. UnionTech V25 holds Level I. HarmonyOS V1.0 holds Level II, the only desktop system at that level, with the enterprise device management and data-safety architecture that level is meant to certify. In a procurement that weighted security, that certificate would be worth points. In a procurement that waives the security question entirely and gates on architecture, it is worth zero — and the zero is not a judgment about the certificate. It is the arithmetic of a form that never asked.

Now the harder part, because the satisfying reading of this story is wrong. The satisfying reading is that an incumbent coalition used a technical annex to shut out a competitor. It is satisfying because it is cynical, and it is wrong because the clause was written in December 2023, two and a half years before this award, when the question was not who would win a desktop tender but whether Chinese government desktops would run on one chip family or five. The rule predates the contest. The vendors who satisfy it have been satisfying it since then, in the ordinary course of selling into a market that demanded it. This is not capture. It is the incumbency effect that any demanding technical standard produces over time — and Stigler’s account does not need a bribe to explain it. The industry’s accumulated competence becomes the standard’s content, because the industry is the only party who can write it.

Which is why the Linux exemption is the clause to stare at. Item 20, two rows down: if the operating system is built on the Linux kernel, it must be compatible with kernel 5.4’s main functions — process management, memory management, task scheduling, interrupt handling, concurrency and synchronisation — and operating systems of other kernel types are not subject to this requirement. Written by people standing inside the Linux world, for the Linux world, in the Linux world’s nouns. There is no malice in it. There is also no way for a non-Linux system to be described by it: it can only be exempted by it. A checklist that can only read one architecture’s shape will score the incumbent’s portfolio at face value and score the newcomer’s absence.

And then the part that makes this file more than an exclusion story. On 2026-10-28 a practitioner outlet published the answer it gives to readers who ask why domestic vendors “reskin Linux” instead of building on HarmonyOS. Four walls: the microkernel was designed for fragmented devices and the macro-kernel was ground down for one machine doing heavy work; the Linux toolchain, drivers and industry software are a self-recirculating ecosystem while a new desktop API means every vendor re-adapts into a user base that does not yet exist; missing the starred indicator removes central-procurement bidding qualification, and central and party-government orders are a desktop vendor’s core revenue; and — the wall the author calls the most painful — control. On Linux, a distribution vendor sets its own release cadence, patch policy and hardware adaptations. On Huawei’s core, the standards, the APIs and the rhythm belong to a competitor.

Read that fourth wall again, because it is this series’ argument arriving from the other side of the table. For a year this briefing has argued that an infrastructure whose roadmap someone else controls is not an infrastructure but a dependency — usually where the someone else is a distant foreign foundation whose governance the Chinese contributor cannot vote in. Today the same sentence is being said by a Chinese systems vendor about a Chinese upstream, in a Chinese outlet, to a Chinese readership. The problem is not national. It is structural. Whoever holds the core holds the participants, and the flag on the core changes almost nothing about the dependency.

So what would a better instrument look like, on this evidence? Not the absence of the clause — the clause is doing real work, and a state that standardises on one vendor’s silicon has merely relocated its single point of failure from abroad to home. The improvement is procedural, and it is specific: write architecture breadth as a weighted criterion with a declared, scheduled trajectory rather than as a binary gate. A weighted indicator can be improved into; a gate can only be arrived at. If the same policy goal — do not bind the fleet to one instruction set — were expressed as “demonstrated same-source compatibility with at least two of five families, rising to three within two procurement cycles,” the incumbents would still win this round, the entrant would have a stated path, and the rule would produce the information the state says it wants rather than an award that answers a question nobody asked. Thresholds are cheap to administer and expensive to comply with. Weights are the reverse. The choice between them is a governance decision, and it is almost never made explicitly.

The honest counterweight, and it must be stated or the argument is worthless. There is no evidence in any source reviewed for this briefing that the joint solicitation was drafted to exclude anyone. The excluded party’s own community documentation lists ARM, RISC-V, x86 and LoongArch at platform level, and third-party LoongArch porting on the Linux-kernel standard-system branch has been documented. A five-architecture certified desktop distribution is an engineering programme with a price tag, not a forbidden thing. The rule is climbable. The complaint is about the ladder’s length, and that is a legitimate complaint but a different one.

Which brings the comparison to where it has to end, and it is not a comfortable place for anyone. Yesterday’s file described a German ministry requiring that a model’s vendor be developed in an adequate jurisdiction — an entity rule that no engineer can satisfy by improving the artefact, only by moving the legal person. Today’s file describes a Chinese procurement requiring that a desktop operating system support five instruction-set families from one source — an artefact rule that any vendor can satisfy by building, given time and money, and that three vendors did satisfy before the gate was pointed at anyone. Both gates displace product competition with entity qualification. Only one of them can be answered by engineering. The distinction is not a compliment to either jurisdiction; it is the only distinction that lets a party outside the process know whether to hire lawyers or engineers.

The checkable question, answerable from three documents. First: what is the fourth name, if any, on the 2027 desktop framework list? Three incumbents again means the gate has stabilised into a barrier — plan for that. A fourth name means the engineering got done. Second: does any HarmonyOS desktop artefact publish a same-source compatibility statement across three or more of LoongArch, MIPS, SW64 and x86, certified as one codebase rather than as parallel ports? Platform-level architecture listings are not that claim; the standard’s word is same-source, and the word is load-bearing. Third, and this is the one that decides whether the instrument is a standard or a wall: can the checklist be amended to describe a system it was not written for? A rule that can only be met or failed by parties who already exist is not neutral in its effects, whatever it says on its face. The measure of a procurement standard is not the list it produces this year. It is whether the list can ever change by means other than someone deciding to.