⚠️ 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-22
🏛️ Policy & Regulation — Six Programme Items and Not One Question Being Investigated: What the 2026 OSCAR Conference Shows About How a Standards Body Accumulates Authority
1. The instrument. On 2026-10-20, the WeChat account OSCAR可信开源 (OSCAR Trustworthy Open Source) — CAICT’s own publication channel for its open-source evaluation work — announced the 2026 OSCAR Open Source Industry Conference (2026 OSCAR开源产业大会), to be held on 2026-11-10 at the Zhongguancun National Independent Innovation Demonstration Zone Exhibition and Trading Centre convention hall in Beijing, under the theme “开源无界 智创未来” (Open Source Without Boundaries, Intelligence Creating the Future). The announcement names two organisers and no others: hosted by the China Communications Standards Association (CCSA, 中国通信标准化协会) and organised by the China Academy of Information and Communications Technology (CAICT, 中国信息通信研究院). Registration is by QR code; the named contact is a CAICT staff address.
The framing sentence sets the mandate explicitly: the conference exists to “deeply implement the Party Central Committee and State Council’s decision-making deployment on building an open-source system (构建开源体系) and deeply implementing the ‘AI+’ action,” and 2026 is identified as “the opening year of the Fifteenth Five-Year Plan.”
2. The six programme items, in the announcement’s own order. These are the whole of the published agenda:
- (i) Release of the latest trustworthy open-source evaluation results (可信开源评估结果重磅发布) — covering, in the announcement’s words, the trustworthy open-source governance maturity assessment and compliance testing against the national open-source security standard, offered as “a comprehensive and scientific reference basis” for enterprises making decisions on governance, technology selection and risk control.
- (ii) Launch of the “Six Networks Synergy Open IoT Standards System” (六网协同 开放物联标准体系建设启动仪式) — implementing the national “six networks” construction deployment, with priority work on IoT operating-system technical architecture and thing-model standards, and the concurrent release of a China Institute of Communications (CIC, 中国通信学会) standard: 《电力物联网终端软硬件与操作系统兼容性技术要求》 (Technical requirements for hardware, software and operating-system compatibility of power-IoT terminals).
- **(iii) Founding of the Open-Source AI Infrastructure (AI Infra) Software Expert Group (开源人工智能基础设施软件专家组), plus a keynote on open-AI evolutionary trends — and the release of two further CIC standards: 《开源大模型透明度等级划分方法》 (a method for grading the transparency of open large models) and 《企业开源大模型应用治理能力成熟度模型》 (a maturity model for enterprise governance capability in open-LLM applications), both framed as clarifying “technical routes and governance rules” for regulated, systematised AI development.
- (iv) Authoritative interpretation of the 《“人工智能+软件"发展研究报告》 — produced to implement MIIT’s “AI + Software” special action implementation plan, summarising how AI is reshaping software R&D paradigms, product form and industrial structure.
- (v) Compilation of the 《人工智能开源安全发展洞察报告(2026)》 — an AI open-source security outlook report, to be interpreted at the conference.
- (vi) “Peak practice” recognition (尖峰实践) — a batch of “innovative, demonstrative and replicable excellent practices” published across six directions: open source + AI, open source + industry practice, open source + commercial application, open-source security, open source + enterprise governance, and Agentic AI tools and platforms, plus intelligent software products, AI-native software and AI Infra.
3. The sequencing this series has already documented. On 2026-10-12 CAICT launched the 2026 OSCAR Open Source Peak Practice application call, which this series covered on 2026-10-16. That call’s screening was scheduled for 2026-10-26/27, with defence in late October and results announced at this same 2026-11 OSCAR conference — and its third listed privilege was priority inclusion in Cloud Computing Open Source Industry Association (CCSIOA) research outcomes. Read in order, the sequence is: application call (10-12) → screening and defence (late October) → recognition announced at the conference (11-10) → the recognised practices reappear in CAICT research outputs. That is a single pipeline, and today’s announcement is its terminal stage.
Institutional Analysis & Commentary:
The temptation here is to inventory the items. The more useful move is to notice their grammatical form. Read the six items and ask of each one: what is being asserted that could turn out to be false? The answer is close to nothing. Item (i) announces that results will be released — not what was found. Item (ii) announces that a standards system will be launched. Item (iii) announces that a group will be founded and that two standards will be published. Items (iv) and (v) announce that reports will be compiled and interpreted. Item (vi) announces that practices will be recognised. Every item is an act of institution-building; none is a finding. A conference programme in which the output is the apparatus itself is a programme that cannot be wrong, and that is worth noting not as a criticism but as a description of a particular institutional technology.
What that technology produces is visible in a detail most readers will skip. The standards to be released at this conference are not released by CAICT or CCSA. They are China Institute of Communications (CIC) standards. A working-group founding is also CIC-adjacent. A second body, CCSIOA, whose research outcomes confer a privilege on recognised practices, exists alongside both. So the OSCAR apparatus is not one organisation doing one thing: it is four distinct bodies — CAICT, CCSA, CIC and CCSIOA — distributed across the roles of assessor, standard-setter, recogniser and research publisher, and the conference is the annual moment at which the four hand work to each other in public view. Mancur Olson’s insight about small groups applies to institutional layering as it does to lobbies: a field’s rules are set by whoever can assemble the smallest group that can act, and four co-located bodies with a shared annual calendar and a shared secretariat are a very small group indeed relative to the number of projects they will describe.
Here the comparison with last year’s version of this series becomes unavoidable, so let it be made. This series has, since July, documented a steady stream of numbers from this ecosystem: provincial plans specifying how many developers a jurisdiction must gather by 2028, how many standards it must issue, how many scenarios it must land; adoption targets expressed as a percentage of a single operating system’s installed base; talent-evaluation standards made of two industrial standards and no code. The pattern across all of them was that measurement attaches to the adopter and never to the assessor. Today’s announcement adds the missing half of that picture, and it is more interesting than the first half: item (i) is an explicit, scheduled, public, annual release of evaluation results, and item (iii) introduces a maturity model by which an enterprise’s governance capability is graded. Both are instruments directed at the assessed rather than at the assessing. So the correct observation is not “this ecosystem measures without being measured” — it is the sharper and less comfortable one: the apparatus has now been built to grade maturity, transparency and governance, and there is no corresponding instrument in the public record that grades the grading. No published methodology revision history, no assessor-accreditation route, no appeal procedure, no register of which enterprises were assessed and declined.
This matters for a reason internal to open source rather than to politics. A licence allocates rights without allocating judgement. Anyone may use, modify and redistribute under the conditions, and no one is required to certify that they have done it well. The governance layer that grew around licences — foundations, technical steering committees, maintainer authority — exists to settle disputes about code, not to issue maturity grades to adopters. A grading instrument, once it exists, becomes a selection device: procurement officers, state-owned enterprises and provincial plan authors will read a maturity tier where there used to be a README, and the tier will travel farther than the code. Item (i)’s own justification states the mechanism openly — the results exist to give enterprises “a reference basis” for technology selection and risk control. That is precisely a transaction-cost reduction, which is what standards are for, and it is also precisely how a voluntary technical community acquires a gate.
The checkable question. Everything rests on whether the evaluation apparatus is a description or an admission ticket. The observable that decides it is not the conference. It is the 2027 procurement record: when a provincial or SOE open-source tender specifies a governance requirement, will it name the OSCAR trustworthy open-source governance maturity assessment, and will projects without a tier be excluded or merely ranked lower? If tiers are cited but never exclusionary, this is an information market and the apparatus is doing the work standards bodies are supposed to do. If a missing tier can disqualify, then a CAICT assessment has become the permission step that an open-source licence was designed to remove — and the correct name for what has been built is not an evaluation system but a licensing regime with a different licensor.
Sources:
- OSCAR可信开源 / 中国信通院 (2026-10-20) — 2026 OSCAR开源产业大会正式启动,“开源无界 智创未来”: conference 2026-11-10, Beijing Zhongguancun Exhibition and Trading Centre; hosted by China Communications Standards Association (CCSA), organised by CAICT; six headline items — trustworthy open-source evaluation results release (governance maturity assessment, national open-source security standard compliance testing), Six Networks Synergy Open IoT standards system launch, Open-Source AI Infra Software Expert Group founding, two China Institute of Communications standards (开源大模型透明度等级划分方法; 企业开源大模型应用治理能力成熟度模型), 《“人工智能+软件"发展研究报告》, 《人工智能开源安全发展洞察报告(2026)》, and Peak Practice recognition across six directions
- China Open Source Daily — 2026-10-16 — CAICT’s 2026 OSCAR Open Source Peak Practice application call: launched 2026-10-12, three participant categories, five directions, screening 2026-10-26/27, defence late October, results at the 2026-11 OSCAR conference, and the third privilege of priority inclusion in CCSIOA research outcomes
- China Communications Standards Association (中国通信标准化协会) — association site, listing CAICT among its linked standardisation bodies and its standards-approval and compliance-verification functions
🏗️ Institutional Change — A Downstream That Diverged, Not a Downstream That Rebuilt: What openEuler’s Prague Booth Separates About Where a Project’s Authority Comes From
1. The observation, from the outside. On 2026-10-20, The Register published a hands-on report from Open Source Summit Europe 2026 in Prague, whose opening observation is the institutional fact: “Surprisingly few organizations were promoting Linux distros at Open Source Summit Europe. The only dedicated stands we found belonged to two Chinese projects, with openEuler occupying the larger booth.” The report’s own framing of the project’s history is precise and worth quoting: openEuler “is the modern free community version of Huawei’s EulerOS,” a variant of which achieved official UNIX certification from The Open Group, and “openEuler is no longer a solely Huawei project, though. Since then, it’s been opened up, and it is now run by the OpenAtom Foundation.”
2. The technical surface documented at the booth. The Register’s inventory: Intelligence BooM, the project’s own LLM development/deployment/runtime stack; x2openEuler, a CentOS-to-openEuler migration tool; Kubernetes support alongside Docker and Podman, and a proprietary container engine, iSula; a dual-strand release cycle — LTS plus annual “innovation” releases — explicitly described as Ubuntu-like rather than RHEL-like; five installation ISO families, including a 3.3 GB and a 25 GB “DevStation” desktop variant; a bespoke installer named Heolleo; GNOME 49 with Dash to Panel and Arc Menu preinstalled, plus Deepin, UKUI, MATE, Xfce and Kiran desktop options; and English-language materials that “mention Chinese CPU makers rather than western ones” — Hygon, Phytium, Kunpeng. The Register also notes that the 22.03 LTS release supported SW-64, the SunWay RISC architecture, and cites LWN’s characterisation of that work as “a non-upstream kernel port.”
3. The comparison the report makes, which is the point. Two communities faced the same shock. In December 2020 the CentOS Project announced the shift from CentOS Linux to CentOS Stream; in June 2023 Red Hat restricted source access to customers. The western response was reconstruction: Rocky Linux and AlmaLinux rebuild from Red Hat source to stay as close to RHEL as possible, Rocky by building its own build service and finding a workaround for kernel source, Alma by retaining older device and CPU support. The Chinese response, per The Register, was structurally different: vendors offering CentOS-based systems “clubbed together, dropped their rival versions and their UNIX compatibility efforts, and instead are working on new tools and subsystems.” The report’s closing judgement: “Half a decade after it was cut off from its upstream sources, the openEuler platform is thriving and growing, even if few in the western world pay any attention at all.”
4. What the same week shows on the governance side. At the same summit, Xinwei Hu, chairman of the openEuler Technical Committee, delivered a keynote on SuperPoD OS and agentic scaling — the proposition being that an operating system should treat an entire AI cluster as one machine (iFOSS coverage, 2026-10). Separately, OpenAtom’s own account has reported that openEuler and OpenHarmony both reached Graduation status in the foundation’s project lifecycle, a milestone defined as comprehensive maturity in technical iteration, community governance and ecosystem development.
Institutional Analysis & Commentary:
The word that organises this story is downstream, and it is a legal word before it is a technical one. Both communities were downstreams of Red Hat source. Both lost the inflow. What they did next differs, and the difference is not one of capability or of effort — it is a difference in what the community believed its product was.
Rocky and Alma believed their product was RHEL compatibility. Their asset was proximity to an upstream, and their institutional problem after 2023 was how to preserve that proximity against an upstream that had closed. Every decision follows: build your own build service, find a lawful path to kernel source, hold the ABI stable, strip out what diverges. Their success metric is a distance — how far from RHEL are we? — and a metric of distance is a metric of dependence. A downstream that measures itself against its upstream has chosen a benchmark it does not control.
openEuler’s community, on the same evidence, believed its product was an operating system for a particular hardware estate. Once that is the product, RHEL proximity ceases to be an asset and becomes a constraint: it is the reason the code assumes x86 and Arm, assumes a certain device-support window, assumes a packaging and build story built for another vendor’s release cadence. Dropping “rival versions and UNIX compatibility efforts” is not an act of estrangement from open source; it is the abandonment of a benchmark. What replaced it is measurable and it is visible in the booth inventory: a multi-architecture unified build system and a shared QA standard rather than per-vendor trees; an own container engine rather than only the widely governed one; an own AI inference stack rather than only the upstream frameworks; a migration tool that treats CentOS as a source to be left behind rather than a parent to be tracked. On the RISC-V evidence, the same logic appears at its sharpest: an ISCAS presentation documents openEuler RISC-V reaching 6,000-plus SRPMs, community-native RISC-V support in the mainline branch, EulerMaker enabled for the architecture, and one shared codebase and one build system and one QA standard across x86, Arm and RISC-V — with a stated compilation success rate of 0.3% x86, 0.5% Arm and 1.5% RISC-V. That is a build-and-test apparatus owned by the community, which is the thing a downstream normally rents.
The honest counterweight, and it is substantial. This divergence has a cost that the Register names and that no amount of growth cancels: work that does not go upstream does not come back. A “non-upstream kernel port” is real engineering carrying a permanent maintenance liability — every upstream change must be reconciled by hand, forever, by whoever holds the port. There is also a measurable loss of the reciprocity that makes a commons a commons: if your architecture support never enters the kernel, you consume the kernel’s maintenance and contribute none of your divergence to it. A commons is sustained by contribution flow, not by installed base, and the growth the Register observes is an installed-base fact. So the correct reading is not “China built a better downstream.” It is: the project traded upstream standing for upstream independence, and independence is cheaper to hold only as long as you are willing to keep paying the reconciliation bill yourself.
Which brings the analysis to the governance question that the Register’s phrasing opens and does not close. “It is now run by the OpenAtom Foundation” is a statement about asset custody, and it is accurate: in November 2021 Huawei donated the openEuler code, brand trademarks, community infrastructure and related assets to OpenAtom, and the foundation’s Graduation milestone is a lifecycle judgement about the project. But custody is one institutional layer and contribution flow is another, and the two are documented by different evidence. The trademark, the domain and the release authority moving to a foundation is a fact about who may speak for the project. Whether the engineering capacity moved — who chairs the Technical Committee, where the majority of commits originate, which companies fund the release engineering — is a fact about who in fact maintains it, and the same governance structure can be foundation-held at layer one and single-vendor-funded at layer two without any contradiction. Ostrom’s design principles for common-pool institutions put the boundary between provision and appropriation at the centre for exactly this reason: a commons can be owned in common and provisioned by one party, and that arrangement is stable right up until the provisioning party’s priorities change.
The comparison worth making across today’s two stories, and this is the reason they are in one briefing. The OSCAR apparatus and the openEuler booth are two rival mechanisms for acquiring authority over a technical field. The first accumulates authority by certifying others: build the assessment, publish the tier, let procurement cite it. It is fast, it scales, it needs no code, and it produces standing that is entirely dependent on the certifier being believed. The second accumulates authority by having been unable to keep depending on upstream: five years of reconciliation paid in exchange for a codebase whose release cadence, architecture matrix and QA standard are its own. It is slow, it is expensive, it needs no certification, and — critically — the authority is portable, because a downstream that has diverged can go to Prague, rent the largest distro booth in the building, and be judged by people who read code. One of these mechanisms travels. The other requires the room.
The checkable question. The Register notes that few in the western world pay attention. That is a claim about attention, and it is testable in a way that will settle the larger question: does openEuler’s divergence ever round-trip? Specifically, over the next two years, does architecture-enablement work originating in this community — RISC-V, LoongArch, SW-64, or the SuperPoD clustering interfaces — appear as accepted patches in the Linux kernel mainline or in governed upstream projects, rather than as maintained ports? A downstream that diverges and returns contributions has joined the commons on new terms and strengthened it. A downstream that diverges and never returns has left the commons while continuing to consume it, whatever its licence says. The licence permits both, and only the patch record distinguishes them.
Sources:
- The Register (2026-10-20) — “openEuler brings China’s enterprise Linux ambitions to the desktop”: OS Summit EU 2026 Prague; only dedicated distro stands belonged to two Chinese projects, openEuler the larger; openEuler as modern free community version of Huawei EulerOS, no longer solely Huawei, “now run by the OpenAtom Foundation”; Intelligence BooM, x2openEuler, iSula, dual-strand release cycle, DevStation ISOs, Heolleo installer; Hygon/Phytium/Kunpeng references; SW-64 support and LWN’s “non-upstream kernel port”; western response as Rocky/Alma reconstruction versus Chinese vendors dropping rival versions and UNIX compatibility efforts
- opensourceForU (2021-11) — Huawei donates openEuler to the OpenAtom Foundation at the Operating System Industry Summit 2021: full code, brand trademarks, community infrastructure and related assets; Wang Tao (Huawei executive director); community then ~10,000 developers, ~100 SIGs, ~300 partner companies
- HuaweiCentral — OpenAtom Foundation statement that openEuler and OpenHarmony reached Graduation status, defined as comprehensive maturity in technical iteration, community governance and ecosystem development
- Yanjun Wu, Institute of Software, Chinese Academy of Sciences (2025-05-14) — “openEuler for RISC-V Servers: Challenges & Roadmap,” RISC-V Summit Europe: 6,000+ SRPMs for openEuler 24.03 LTS RISC-V, community-native RISC-V support, EulerMaker enabled for RISC-V, one shared codebase / build system / QA standard / ISO image across architectures, master-branch compilation success rates x86 0.3%, Arm 0.5%, RISC-V 1.5%
- It’s FOSS (2026-10) — “openEuler Wants Linux to Treat an Entire AI Cluster Like One Single Machine”: Open Source Summit Europe 2026 keynote by Xinwei Hu, chairman of the openEuler Technical Committee, on SuperPoD OS and agentic scaling
- Luca Berton (2026-10) — Open Source Summit Europe 2026 Prague coverage, including the 2026 State of Open Source in Europe report presented in the same keynote track and the kernel-maintainer sessions held alongside
🔍 Commentary — Two Ways to Hold a Field, and the One That Needs a Room
The two documents in today’s briefing were published within five days of each other and have nothing to do with one another. One is a conference announcement. One is a conference report. Put them next to each other and the institutional choice of this decade becomes legible.
The OSCAR programme of 2026-11-10 will release an evaluation result set, launch a standards system, found an expert group, publish two China Institute of Communications standards — one of them a transparency grading method for open large models — and recognise a batch of practices. Its six items are all apparatus. Nothing in it can be contradicted by evidence, because nothing in it claims anything about the world. The openEuler booth in Prague in the same month showed an operating system whose community had been cut off from upstream, chose divergence over reconstruction, paid five years of reconciliation, and now owns its own build system, QA standard, container engine, AI stack, architecture matrix and installer — and turned up at a European summit with the largest distro stand in the hall.
The asymmetry between these two ways of holding a field is not about honesty or competence. It is about what each one is made of. An evaluation regime is made of judgements. Its stock in trade is a tier, a maturity level, a compliance result, and its authority is borrowed from the standing of whoever issues it — which means it must be re-issued every year, because a judgement is only as fresh as its last publication. A diverged codebase is made of artefacts. Its authority is the ISO image, the package set, the build log, the accepted patch — objects that can be downloaded, run and falsified by anyone with a machine, and that do not require the issuer to be believed. Judgements need a room; artefacts travel. And when the same week produces both, the interesting question is not which is more legitimate but which of them will still be doing work in ten years. An assessment from 2026 will be a historical document in 2036. A fork of the kernel that nobody reconciled will simply be dead code.
There is a real and underrated advantage on the assessment side, and intellectual honesty requires naming it. Artefacts do not solve coordination problems by existing. A works-cited image does not tell a procurement officer whether an upstream project will still be maintained in three years, whether its governance will survive its founder’s departure, or whether using it creates a licence obligation the organisation cannot discharge. That is precisely the transaction cost that standards and assessments exist to reduce, and it is not a bureaucratic invention — it is what certification bodies, insurers and credit raters do in every economy with specialised suppliers and non-expert buyers. A trustworthy open-source governance maturity assessment is, in principle, a genuine public good: it converts an unobservable into a comparability. The problem is not the instrument. The problem is what happens to a comparability that has exactly one producer.
That is where Ostrom’s boundary question bites, and it bites in a specific place. Common-pool institutions survive on monitoring that is accountable to the monitored — the ones who are assessed have a route to contest, and the assessor’s method can be inspected. A single-producer assessor with no accredited competitors, no published revision history and no appeal route is not a monitoring arrangement in that sense; it is a licensing function wearing a monitoring function’s clothes. And once procurement cites the tier, the difference stops being theoretical, because the tier becomes the permission step. Open source’s original institutional move was to make the permission step disappear. Anything reintroduced at the procurement layer has not been defeated by the licence — it has simply moved one floor up, to the layer where nobody thinks to look for it.
There is one more thing in the week that deserves to be said plainly, because it is what the two stories jointly reveal about the ecology of authority. The assessment apparatus and the codebase community are not competitors; they operate on different objects and they need each other’s absence to grow. openEuler’s standing was not produced by any assessment — it was produced by a release cadence, an architecture matrix and five years of unglamorous reconciliation, and it was demonstrated in Prague where the currency is a downloaded ISO. The OSCAR apparatus’s standing is produced by the citation — the provincial plan that names a maturity level, the SOE tender that requires a compliance test, the practice that is recognised and then appears in a research report. These two forms of capital do not exchange. A project can hold all of one and none of the other indefinitely, and this week two Chinese institutions did exactly that, in the same seven days, without either mentioning the other.
The checkable question. Hold both stories to the same test and the test turns out to be the same test. Does the work leave the room? For the conference: are the evaluation results, the transparency grading method and the two CIC standards published in a form that someone outside the room can read, replicate and dispute — a methodology document with a version number, not a tier in a slide? For the booth: does the divergence round-trip — do RISC-V, LoongArch or SuperPoD interfaces reach mainline, or do they remain ports maintained by whoever paid for them? In both cases the question is whether authority is held by an object that can be inspected or by a judgement that must be trusted, and in both cases the answer will be public within two years. The difference between growing a commons and administering one is whether the artefact, or only the verdict, is allowed out the door.
Sources:
- OSCAR可信开源 / 中国信通院 (2026-10-20) — 2026 OSCAR开源产业大会 programme and the six headline items
- The Register (2026-10-20) — openEuler at Open Source Summit Europe 2026 Prague; downstream divergence versus Rocky/AlmaLinux reconstruction; “non-upstream kernel port”
- Yanjun Wu, ISCAS / RISC-V Summit Europe (2025-05-14) — openEuler RISC-V unified build system, shared QA standard and multi-architecture compilation rates
- opensourceForU (2021-11) — Huawei’s donation of openEuler code, trademarks and community infrastructure to the OpenAtom Foundation