⚠️ 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-19 (Evening Edition)

1. The instruments, and their provenance. The Global Smart IoT Consortium (GIIC, 全球智慧物联网联盟) published two association standards in September 2026, both authored by the Harmony Ecosystem Promotion Committee’s Talent Development Group (鸿蒙生态推委会人才发展组):

  • T/GIIC 1003—2026 《鸿蒙生态人才能力评价规范 鸿蒙应用开发者》 (Harmony ecosystem talent capability evaluation specification — HarmonyOS application developer): version V1.0, released 2026-08-28, effective 2026-09-10. Scope: “capability grade classification, technical capability requirements and professional technical qualification certification rules for the HarmonyOS application development domain,” applicable to government departments, employers, industry organisations, training institutions and developers.
  • T/GIIC 1004—2026 《鸿蒙生态人才能力评价规范 开源鸿蒙(OpenHarmony)设备开发培训讲师》 (… OpenHarmony device-development training instructor): version V1.0, released 2026-08-28, effective 2026-09-10. Scope: “capability requirements, post requirements, grade classification, grade evaluation, certification management and supervision” for instructors; applicable to companies, training institutions and developers. This one was carried as a Shenzhen municipal standard-innovation practice “reveal-the-list-and-take-command” (揭榜挂帅) project for 2026.

2. Where they came from. The two drafts passed expert review on 2026-07-06, at a session convened by the same working group, with drafting-unit representatives from Harmony Ecosystem Services (Shenzhen) Co., Xunfang Technology (讯方技术), and Isofstone Education (软通教育), and reviewers from Zhongke Honglüe, Baithinks, Far Ben (法本信息), Talent Data (人才数科), Shenzhen Kaihong (深开鸿), Ruixi Zhilian and Shenzhen Polytechnic University. According to the conference-side account, the final texts were compiled by ten organisations and 26 experts including Harmony Ecosystem Services, Huawei, Tsinghua University, Isofstone Education, Xunfang Technology, Tuowei Information and Shenzhen University, after “large-scale industry research and empirical data analysis.”

3. What is actually being certified. The 1004 text is the more revealing of the two. It certifies instructors, not developers, and the reviewer summary states that it establishes “a complete capability-certification system from junior instructor to senior expert,” assessing “theoretical grounding and code practice,” and additionally “course design, hands-on guidance, and the ability to solve complex engineering problems.” In other words, the standard’s object is the quality of the training pipeline, not the quality of the software. The 1003 text’s object is the developer’s own graded capability — a ladder from entry level upward, with assessment dimensions spanning knowledge, project practice, engineering discipline and R&D thinking.

4. The institutional form this represents — a private standard creating a quasi-public credential. Read with the numbers the GIIC itself published at the Harmony Ecosystem Conference (2026-08-28, Shenzhen): 8,000万 HarmonyOS 6 terminal devices as of 2026-08-20 (expected to exceed 1亿 in Q4), 1,100万+ developers, 600,000+ developers already holding a HarmonyOS developer certification, 35 cities with talent-support policies, 650+ universities running Harmony-base or campus open-class programmes, and 700+ certified instructors at training-service providers, who account for more than 60% of all developer certifications issued. The 1003/1004 pair is the step that turns this into a standardised credential: before it, “HarmonyOS developer certification” was the vendor’s own instrument; after it, a consortium standard defines the grade levels, the review procedure, the evaluation criteria and the certification management regime.

5. Adjacent instruments showing the direction of travel. At the same 2026-08-28 conference the committee also released T/GIIC 0007—2026 《鸿蒙应用功能完备性评估要求》 (the first HarmonyOS application functional-completeness assessment standard, “cross-platform benchmarking” as its core), the Harmony ecosystem Kit series, Harmony ecosystem device unified-interconnection 2.1 series (device model, access-and-control interfaces, testing), and an SDK “ecosystem co-governance” milestone at 200+ certified SDKs. In parallel, the Shenzhen human-resources and social-security bureau told the talent sub-forum that the city would “deepen reform of the training, use, evaluation and incentive systems for technical skills talent,” and one industry partner described a nationwide-first “one exam, two certificates” (一试双证) model in which a national vocational skill level certificate and a HarmonyOS application developer certification are made mutually convertible, run out of the Yellow River Digital Talent Public Training Base.

Institutional Analysis & Commentary:

The useful question about a standard is never “is it good?” but “whose costs does it move, and onto whom?” On that test, T/GIIC 1003/1004 are unusually legible.

First: this is private ordering producing public-facing artefacts. A consortium standard (团体标准) is not a national standard (GB) and not a law. It does not bind by force of law. It binds because three scarce goods sit downstream of it: public procurement specifications, university credit and curriculum recognition, and employer screening. The standard is the upstream node through which all three later flows are calibrated. What a consortium can do that a ministry cannot is move fast and involve the actual employers; what a ministry can do that a consortium cannot is impose. The 1003/1004 pair is a deliberate combination — a consortium writes, and the state apparatus recognises. The Shenzhen “reveal-the-list” designation on 1004 is precisely the hinge: a municipal government designated a talent-certification standard as a 2026 innovation pilot before the standard had issued a single certificate.

Second: the certification ladder relocates the definition of competence from contribution to test-passing. Compare with the open-source world’s native mechanism: maintainers grant commit rights on the evidence of patches that survived review, and there is no grade above “committer” other than the work others choose to build on. A graded developer certificate is a different instrument for the same coordination problem — it lets an employer choose without reading code, at the cost of measuring what a test can see. That trade is legitimate, and every professional field makes it. The institutionally interesting part is that in this ecosystem the two instruments are being run by the same body: the GIIC’s talent group is legally the same organisation whose other working groups (technical standards, certification, industry development, ecosystem cooperation) set the device interconnection and application completeness standards. The certifier of people and the certifier of products sit inside one promotion committee.

Third, and the part worth following with rigour: what is not in the standard. Neither 1003 nor 1004 is a contribution standard. Neither requires evidence of merged pull requests, upstream review participation, issue triage, documentation work, security-disclosure handling, or any other artefact that a codebase can verify. A certification regime built on exams and instructor evaluation can be internally excellent and still measure capability to operate inside the ecosystem rather than contribution to the commons. This matters because, per the ecosystem’s own reporting, the depth of contribution is highly concentrated: 13,808 contributors and 644 community partners across six years and 11 releases, with committer rights clustered in a few vendors, one of which reported 4 PMC seats and 35 committers.

The link to this morning’s briefing. This morning’s edition documented Hunan’s province-level plan (湘制造强省办〔2026〕7号), whose only contribution-facing clause is a Changsha sub-committee plus a target of “national front rank in code contribution.” It also noted the six-city instrument matrix — Shenzhen, Wuhan, Guangzhou, Hunan, Chongqing, Fujian — each with adoption targets but almost none with contribution rules. The 1003/1004 pair fills the layer that matrix left blank: what a person is, and how you can tell. The matrix says how many developers a province must gather (Hunan: 50,000 by 2028; Wuhan: 100,000+; Guangzhou: 20,000). T/GIIC 1003 says what a developer is once gathered. The single clause running through all of them is that counting is specified and voice is not.

One measurable prediction, offered as such. If the “one exam, two certificates” route spreads, then within twelve months the marginal HarmonyOS developer’s career signal will be a state-recognised vocational skill level certificate rather than a merged-patch history — and the incentive to contribute upstream will have to be carried by something other than the credential. That something, in the FOSS tradition, is the thing this whole apparatus does not yet have an instrument for: the expectation that what you build gets reviewed by strangers and lands in a codebase you do not control. Whether the ecosystem develops a credential that requires that experience is the checkable question. The standards exist; the requirement does not.

One methodological caution. The 1003/1004 texts themselves are distributed through a members’ download portal (AllianceHub), not published openly. Everything above describes the published scope statements and the conference-side documentation of what the drafts contain, not the clause text. The clauses are what would tell you whether a grade can be earned without ever filing a pull request. That document is the one to obtain.

Sources:


🏗️ Institutional Change — The Adoption Matrix Has Six Instruments and One Vacancy: What Guangzhou’s June 2026 Action Plan, Hunan’s October Plan and openEuler’s September Operations Report Say When Read Side by Side

1. Guangzhou, not January. Hunan’s plan (2026-10-12) was not the second instrument in a two-step sequence, as this morning’s briefing’s municipal-predecessor framing (Wuhan, 武政办〔2026〕3号, effective 2026-01-05) might suggest. Guangzhou’s industry-and-information-technology bureau issued 穗工信函〔2026〕192号, 《广州市鸿蒙智城建设行动计划(2026-2028年)》 (Guangzhou Harmony Smart City Construction Action Plan 2026–2028), on 2026-06-25, published 2026-06-29, “with the agreement of the municipal government.” Guangdong’s provincial services plan (2026-06-19) had already named the provincial adaptation centre as the anchor. So the sub-national stack by mid-2026 read: Guangdong province (June 19) → Guangzhou city (June 25) → Wuhan city (January 5, published January 15) — three different administrative genres (provincial services plan, municipal action plan, municipal implementation plan) converging on the same codebase within six months.

2. What Guangzhou’s instrument has that the others do not. Targets to 2028: ≥2 industry-grade Harmony distributions, ≥100 high-quality demonstration scenarios, ≥100 replicable “Harmony + AI” cases, 3–5 chain-leader enterprises, 150+ ecosystem firms, 20,000+ Harmony developers. Then three things structurally distinctive:

  • A “regulatory sandbox” clause (探索"监管沙盒"模式) — a fault-tolerance mechanism and dynamic supervision-evaluation mechanism, with the province/city adaptation centre’s testing-and-certification function used to run ongoing evaluation of the plan’s own implementation. This is the only instrument in the matrix that provides for evaluating the evaluator.
  • A “subsidy converted to investment” clause (落实"补改投"政策,以"先投后股"模式) — public support for early “Harmony + AI” projects structured as equity-convertible investment rather than grants, plus a proposed dedicated Harmony industry-development fund. This converts a fiscal expenditure into a claim on future enterprise value — a governance choice with real consequences for who ends up owning the resulting firms.
  • A standardisation-power clause — “actively participate in the formulation of national and industry standards for the Harmony ecosystem, and enhance Guangzhou’s voice (话语权) in the national Harmony ecosystem.”

3. The instrument that measures system health rather than adoption. openEuler’s September 2026 operations report (published 2026-10-07) gives the other side of the ledger: users over 10 million, 29,000+ developers, 2,199 member organisations, 112 SIGs, cumulatively 340.8K PRs, 167.5K issues, 6.2254M comments; 643 security advisories issued in September alone, with 94 vulnerabilities fixed (6 Critical, 27 High, 61 other); 2,854 products through software/hardware compatibility assessment (41 added in September: 24 northbound ISV, 16 southbound IHV, 1 OSV); 194 container images upgraded and 54 added. And 26.09 shipped on 2026-09-30 as a dual-kernel (6.6 + 6.18) innovation release with 834 contributing developers, adding Agent-side observability and governance (AcTrail bypass observation/control framework; AgentCensor non-intrusive policy enforcement for agent runtimes), SkillHub as an OS-native AI skill hub with automated security review of listed skills, and KPBot — a Kunpeng performance-optimisation agent — open-sourced and hosted at openEuler.

4. The vacancy that recurs. None of the six sub-national instruments reviewed here specifies: a licence obligation, a CLA/DCO rule, a copyright-assignment rule for local-origin code, a committer-election procedure for anyone the plan creates, a security-disclosure channel, or a commitment to publish the province’s or city’s own Harmony-origin code. Guangzhou comes closest with its standards-participation clause — and it asks for voice in standards, not publication of code.

Institutional Analysis & Commentary:

The comparison that matters is between instruments that measure demand and an instrument that measures risk. A city plan can promise 100 scenarios; it cannot promise that the system will still be patched in 2031. openEuler’s September report is the only document in this set that reports the cost of being infrastructure: 643 advisories and 94 CVE fixes in 30 days. That number is what a real commons produces when strangers depend on it — it is the maintenance obligation discharging itself. No sub-national plan in this series contains a maintenance-cost line. The plans buy adoption; openEuler pays for maintenance.

This is where Ostrom’s design principles become a diagnostic rather than a slogan. Her framework asks whether a commons has (i) clearly defined boundaries, (ii) rules matched to local conditions, (iii) collective-choice arrangements for those affected, (iv) monitoring accountable to the participants, (v) graduated sanctions, (vi) cheap conflict resolution, (vii) recognised right to organise, (viii) nested enterprises for larger systems. Apply it to the sub-national Harmony instruments and most of the cells come back empty — not because the authors were careless, but because a procurement plan is not designed to answer those questions. Apply it to the provincial-level adaptation centres (广东’s “one centre, three bases”: Guangzhou/Huangpu headquarters plus Dongguan etc.) and something interesting appears: the adaptation centre is a conflict-resolution and conformance-monitoring institution, just one whose accountability runs upward to the provincial government rather than outward to contributors.

And the sharpest asymmetry in the whole set is a data point that should be embarrassing for the “ecosystem by numbers” frame. Per the ecosystem’s own 2026-08-28 figures, contributors were 13,808, but the city of Wuhan committed to gathering 100,000+ developers — over seven times the number of people who have ever contributed code to the project across six years — while Hunan, a province, committed to 50,000. Guangzhou, a city again, committed to 20,000, roughly 1.4 times the actual contributor base. Targets for “developers gathered” and magnitudes of “contributors who exist” are not merely different quantities; in these documents they are different kinds of quantity. The first is an administrative headcount (anyone who registers, attends, or certifies). The second is a property of a codebase. A provincial plan can raise the first by decree. It cannot raise the second by decree, which is exactly why Hunan’s plan reaches for a community sub-committee — the only available mechanism for converting headcount into committership.

The Guangzhou sandbox clause deserves separate attention because it is the only self-evaluating provision in the matrix. A regulatory sandbox is a well-understood institutional form: bounded, time-limited permission to deviate from a rule under supervision, with the deviation logged and reviewed. Applying it to the plan’s own implementation — “combine the adaptation centre’s testing and certification functions to conduct ongoing assessment of the plan’s effectiveness, and dynamically optimise” — is institutionally interesting in two directions. It admits that the plan’s targets may be wrong. And it assigns the assessment to the body that also certifies the products the plan’s targets measure. A sandbox that lets the sandbox owner grade the sandbox is a real design choice, not a rhetorical flourish; whether it functions as self-correction or as self-certification depends entirely on whether the assessment outputs are published.

The checkable questions for the next twelve months — three of them, each observable.

  1. Does Guangzhou’s sandbox publish? If the 2028 mid-term assessment is released with scenario-level results including failures, the clause is doing institutional work. If only the 100 “replicable cases” are published, it is doing communications work.
  2. Does any sub-national instrument adopt a contribution rule? The test is a clause naming a specific verification procedure — merged-patch counts, PMC seats, upstream-maintainer sign-off — rather than a rank. None exists today. One appearing would be a genuine institutional novelty in this series.
  3. Does the credential layer and the contribution layer ever connect? T/GIIC 1003 grades developers; openEuler grades systems. If a Harmony credential eventually requires evidence of upstream contribution, the whole architecture acquires a feedback loop. If the two remain parallel, the ecosystem will keep producing both certifications and maintainers, and the second will keep being supplied by a handful of vendors who already have seats.

One caution. “开发者” (developer) in these plans is not a defined legal or statistical category; each city’s count will be assembled from its own registration, training, and certification records. Cross-city target comparisons (20,000 vs 50,000 vs 100,000+) therefore compare definitions, not people. Anyone citing these numbers comparatively is borrowing precision that does not exist.

Sources:


🔍 Commentary — Credentials Are Cheap to Standardise and Expensive to Make Meaningful

Two documents sit on this desk. One is a standard that says what a HarmonyOS developer is. The other is a monthly operations report that says what it costs to keep an operating system alive: 643 advisories, 94 vulnerabilities, 6 critical, in thirty days.

Only one of them is about the thing open source is actually made of.

This is not an argument against the standards. Every large ecosystem needs a way to hire; every university needs a way to grade; every procurement office needs a way to write a specification. Credentials are the least-bad instrument for that, and the GIIC’s group has done the unglamorous work — ten organisations, twenty-six experts, a review session, a municipal pilot designation. It is competent institutional construction.

But the question a credential standard has to answer is not “what can a certified person do?” It is “what does the certificate commit the holder to that they would not otherwise have done?” In medicine, licensure commits the holder to a standard of care and a duty to report harm. In law, admission commits the holder to a duty to the court. In FOSS, the equivalent commitment has never been written as a certificate — it is written into the act of sending a patch to strangers and accepting that they may reject it, and into the practice of reviewing someone else’s patch when there is nothing in it for you.

The Harmony ecosystem has 13,808 contributors. It also has 600,000+ developer certifications. Those two numbers describe a real and healthy division of labour — most people who use a platform will never modify it, and that is true of Linux too. The concern is not the ratio. The concern is what happens to the ratio when the credential becomes the recognised route into the ecosystem and the contribution route becomes structurally invisible: uncredentialed, and therefore uncounted in the very statistics the provinces are committing to.

There is a design that would resolve this, and it is not novel. Make the highest grade of the developer credential require an upstream contribution that a maintainer chose to merge, verified by repository record rather than by examination. That single clause would convert a testing regime into a participation regime, and would cost nothing to write. It is absent from both standards. Whether its absence is an oversight or a policy is the thing to watch — because an ecosystem that certifies consumers brilliantly and contributors not at all has not solved the hard problem. It has measured the easy one.

Sources: