开发者如何参与贡献——从SIG参与到核心维护者的完整路径前言截至2025年11月Harmony开源项目代码量已超1.3亿行开发者数量突破800万形成了完整的开源贡献体系。社区共有51家共建单位累计超过6200名贡献者产生24.2万多个PR59个SIG特别兴趣小组活跃在各个技术领域。深开鸿作为核心共建单位累计贡献代码超百万行主导4个SIG参与12个SIG共建。这些数字背后是一个怎样的社区治理模型在支撑作为普通开发者如何从零开始参与贡献代码提交后经历了怎样的评审流程又如何从Contributor成长为Committer乃至Maintainer本文将基于OpenHarmony官方治理文档、核心共建单位的实践经验以及社区贡献者的真实案例系统梳理OpenHarmony社区治理模式为想要参与开源贡献的开发者提供一份完整的行动指南。第一部分OpenHarmony社区治理架构1.1 项目群定位与愿景OpenHarmony项目群的愿景是打造一个开放的、全球化的、创新且领先的面向多智能终端、全场景的分布式操作系统构筑可持续发展的开源生态系统。其使命是托管操作系统技术和架构的核心代码及组件以开放治理的方式聚合各类开发者持续发展代码使用者和共建者。1.2 组织架构全景图OpenHarmony项目群的组织架构采用多层治理结构确保决策的科学性和执行的效率性┌─────────────────────────────────────────────────────────┐ │ 工作委员会Board │ │ 重大事项投票决策一家单位一票 │ └─────────────────────────────────────────────────────────┘ │ ┌─────────────────────┼─────────────────────┐ ▼ ▼ ▼ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ │ 技术指导委员会 │ │ 项目管理委员会 │ │ 生态委员会 │ │ (TSC) │ │ (PMC) │ │ │ │ 技术方向决策 │ │ 版本计划与发布 │ │ 生态建设与推广 │ └───────────────┘ └───────────────┘ └───────────────┘ │ ▼ ┌─────────────────┐ │ SIG特别兴趣小组 │ │ 技术领域实体单位│ └─────────────────┘1.2.1 工作委员会Board工作委员会由捐赠人、学术机构和非营利组织以及其他组织或个人构成。重大事项由工作委员会各成员单位代表用投票方式共同决定投票权利均等一家单位一票遵循公开明确的项目群管理制度规则。1.2.2 技术指导委员会TSC技术指导委员会负责技术方向的指导和决策是解决复杂技术问题的关键组织。TSC从全局视角审视技术架构的合理性确保各SIG的技术演进方向与整体规划一致。1.2.3 项目管理委员会PMCPMC项目管理委员会负责版本计划制定和发布管理。版本决策遵循明确及公开的项目群管理制度路标和版本计划由PMC决定讨论过程公开透明。SIG需要定期向PMC汇报进展PMC基于SIG运作情况给出指导建议。1.3 决策机制OpenHarmony社区的决策机制强调公开、透明、共识版本决策路标和版本计划由PMC决定讨论过程在邮件列表和例会中公开进行技术决策各SIG负责领域内的技术决策重大变更需提交PMC审议API变更决策API新增、变更、废弃需遵循严格的评审流程由Committer、Maintainer、SIG分层评审第二部分SIG工作机制与参与路径2.1 什么是SIGSIG全称Special Interest Group即特别兴趣小组是OpenHarmony社区贡献的基本单位。SIG在PMC项目管理委员会指导下负责OpenHarmony社区特定子领域及创新项目的架构设计、开源开发及项目维护等工作。截至2023年10月OpenHarmony社区共有59个SIG覆盖从内核、驱动、分布式软总线到ArkUI、图形图像等各个技术领域。2.2 SIG的职责与运作方式2.2.1 SIG的核心职责技术演进方向引领负责领域技术竞争力分析和关键技术识别及决策架构设计与维护负责领域内功能分解分配模块间接口定义与维护管理开源开发组织社区的工作实体是SIG组从基础设施到OS部件从测试系统到版本发布都是由不同SIG承担持续运作保障SIG组需要通过周期例会来保持其有效运作并定期向PMC委员会汇报进展2.2.2 SIG的组织结构每个SIG通常包含以下角色角色职责产生方式SIG Leader负责SIG整体运营、例会组织、对外汇报由SIG发起人或核心贡献者担任Committer负责代码评审、任务分配、社区答疑由SIG Leader提名PMC确认Contributor参与具体任务开发、提交代码任何开发者均可成为2.3 参与SIG的两种方式开发者参与SIG贡献有两种主要路径加入已有SIG和主导成立新SIG。2.3.1 加入已有SIG第一步找到感兴趣的SIG开发者可通过SIG列表查看感兴趣的SIG。OpenHarmony社区在community仓库维护了完整的SIG列表https://gitee.com/openharmony/community/tree/master/sig。第二步了解SIG动态订阅邮件列表通过SIG对应的邮件列表获取最新讨论动态参与SIG会议SIG定期召开例会会议纪要在SIG仓库中归档浏览Issue列表查看SIG仓库中的good first issue或help wanted标签第三步认领任务并贡献开发者通过认领SIG Leader发布的需求来承接共建任务按照需求分析、功能设计、代码开发、功能测试、功能交付等步骤进行任务开发。任务开发完成后提交PR把代码、文档等提交到社区完成最终的开源贡献。2.3.2 主导成立新SIG如果开发者的技术方向不属于已有SIG可以申请成立新SIG。成立SIG需要经过申请、孵化、毕业三个阶段。阶段一SIG成立申请申请准备在社区中寻找2-3个以上有共同兴趣及目标的人确定SIG Leader参考SIG章程模板创建SIG Charter提案包含以下要素创建SIG的背景信息创建SIG的业务范围创建SIG的业务目标适合申请创建SIG的情形发起孵化的技术项目能代表某一个领域的技术方向并最终能转化为OpenHarmony的新增部件不适合的情形发起的申请属于OpenHarmony社区已有的技术方向建议直接参与已有SIG共建提交申请SIG Leader以[SIG-Charter-Proposal-XXX]为邮件标题将申请材料以附件方式向devopenharmony.io发送邮件提交新建SIG申请。PMC评审PMC邮件回复同意后SIG发起人申报PMC例行会议新建SIG议题按时接入PMC会议介绍待新建的SIGPMC评审通过后形成会议纪要并附评审意见提交PR收到PMC评审反馈后执行以下操作fork OpenHarmony/community仓库到本地在OpenHarmony/community/sig仓库内新建SIG文件夹文件夹名为“sig-XXX”创建README.md、OWNERS.md文档参考其他SIG的格式更新sigs.json文档提交PR请求合入主干sigs.json文件格式示例sigs-List:[{sig-name:sig-python,projects:https://gitee.com/openharmony-sig/python,project-path:python/},{sig-name:sig-updates,projects:[https://gitee.com/openharmony/startup_appspawn_lite,https://gitee.com/openharmony/startup_bootstrap_lite],project-path:[base/startup/appspawn_lite,base/startup/bootstrap_lite]}]阶段二SIG孵化SIG成立后进入孵化阶段需要完成启动开发需求澄清、特性梳理、方案设计、代码开发、单元测试、功能测试自检完善对照Check List完成法务、门禁、OAT等问题自检孵化项目的代码统一存放在OpenHarmony SIG组织待孵化成熟后可申请合入OpenHarmony主库。阶段三SIG毕业孵化项目满足毕业要求后可申请毕业向架构SIG申请新SIG毕业向QA SIG申请新SIG准出仓库owner移仓至OpenHarmony主组织毕业评审需按照要求自检完成。2.4 SIG实践案例辅助工具SIG深开鸿主导的辅助工具SIG是SIG成功运作的典型案例。该SIG的宗旨是“降低重复劳动提高工作效率让专业的人做专业的事”。2.4.1 辅助工具SIG的三个核心工具1. NAPI框架代码生成工具痛点NAPI框架代码重复率高面对不同JS接口开发者需实现相似度高的框架代码NAPI学习成本高涉及JavaScript、C语言及编译脚本NAPI需求量大OpenHarmony已支持1万多个NAPI接口解决方案工具将C、JavaScript接口类型转换等代码抽取公共模块自动生成编译脚本。开发者只需实现业务代码调用即可。2. IDL转换工具痛点HDI开发难度大开发者熟悉C语言的.h文件不熟悉IDL语法HDI工作量大各子系统均涉及解决方案工具将开发者熟悉的.h文件自动转换为.idl文件开发者不需要关心IDL语法。3. 开机动画工具痛点资源格式要求高OpenHarmony 2.0只支持raw文件定制化需求大不同产品需求不同解决方案工具支持图片集或mp4等多种文件生成开机动画支持设置分辨率一键生成并支持在Windows上预览效果。2.4.2 辅助工具SIG的共建方向SIG提供三个共建方向供开发者选择方向适合人群具体工作文档资料擅长文档编撰使用指导、开发指导、集成指导测试用例测试人员UI用例、ST用例、测试框架工具开发开发者工具能力增强、VSCode插件、IntelliJ插件2.5 SIG参与的核心价值参与SIG贡献对开发者有多重价值技术深耕在特定技术领域持续深入成为领域专家社区影响力通过贡献积累声誉获得社区认可职业发展核心贡献者有机会晋升为Committer、Maintainer甚至成为SIG Leader商业价值参与根技术共建的企业可获得生态资源扶持第三部分代码提交与审查流程详解3.1 环境准备与协议签署在提交第一行代码前需要完成以下准备工作。3.1.1 注册码云账号访问 https://gitee.com/ 注册账号建议使用有意义的用户名如姓名全拼。3.1.2 配置SSH公钥# 生成SSH密钥使用你的码云绑定邮箱ssh-keygen-trsa-Cyour_emailexample.com# 查看公钥macOS/Linuxcat~/.ssh/id_rsa.pub# Windows用户在C:\Users\用户名\.ssh目录下找到id_rsa.pub将公钥添加到码云“设置”→“安全设置”→“SSH公钥”中。验证是否成功ssh-Tgitgitee.com# 返回 Welcome to Gitee.com, yourname! 即成功3.1.3 签署DCO和开发者原创声明DCO签署DCODeveloper Certificate of Origin保证贡献者原创。签署前需确保git全局配置的user.name与DCO签署姓名一致git全局配置的user.email与DCO签署邮箱一致必须使用码云绑定邮箱# 配置git全局信息gitconfig--globaluser.name你的名字gitconfig--globaluser.email你的gitee绑定邮箱# 查看配置gitconfig--global--list签署地址https://clasign.osinfra.cn/sign/Z2l0ZWUlMkZvcGVuaGFybW9ueQ开发者原创声明必须首先签署“开发者原创声明”才能参与社区贡献。3.2 完整代码提交流程3.2.1 Fork代码仓到私仓在目标仓库页面如https://gitee.com/openharmony/napi_generator 点击“Fork”将代码复制到自己的码云账号下。3.2.2 克隆代码到本地gitclone https://gitee.com/你的用户名/仓库名.gitcd仓库名3.2.3 添加上游仓库gitremoteaddupstream https://gitee.com/openharmony/仓库名.gitgitfetch upstream3.2.4 创建功能分支gitcheckout-bfeature/xxx# 功能开发# 或gitcheckout-bfix/issue-id-xxx# 缺陷修复推荐的分支模型main永远保持可用不在main上直接开发feature/topic功能开发分支fix/issue-id-keyword缺陷修复分支docs/topic文档分支3.2.5 本地开发和测试在本地完成代码开发、单元测试和功能验证。代码风格检查提交前需确保代码符合项目规范。建议配置pre-commit钩子自动运行格式化lint基本测试。3.2.6 Commit规范Commit Message推荐采用Conventional Commits格式type(scope): subject body - 变更动机为什么需要 - 技术方案如何实现 - 兼容性是否破坏性 - 关联Fixes #123常用typefeat新功能fix修复perf性能优化refactor重构docs文档test测试build构建ci持续集成签名要求gitcommit-s-mfix(renderer): 修复纹理加载性能问题# -s 添加Signed-off-by3.2.7 推送代码到私仓gitpush origin feature/xxx3.2.8 创建Pull Request在Gitee上进入自己的私仓点击“ Pull Request”选择源分支私仓的feature/xxx和目标分支上游的master/main填写PR模板包含变更类型Bugfix/Feature/Docs/Refactor问题背景问题是什么影响谁解决方案核心思路、兼容性测试说明覆盖用例、平台关联Issue如Fixes #I1TVV4点击“创建Pull Request”3.3 门禁检查与CI流程3.3.1 DCO检查PR创建后首先进行DCO检查验证提交记录中的Signed-off-by与签署信息一致。3.3.2 手动触发门禁OpenHarmony社区有一个特别流程需要在PR评论中手动输入“start build”来触发门禁检测。这是OpenHarmony社区比较特别的一点在其他开源项目中少见。3.3.3 门禁检测内容门禁检测包括静态检查代码风格、潜在错误代码编译能否成功编译功能测试自动化测试用例执行3.3.4 CI门户OpenHarmony提供了CI门户http://ci.openharmony.cn/ 方便开发者查看门禁和每日构建的执行结果。每日构建用于提前发现代码静态检查、编译、功能等方面的问题。3.4 代码审查流程3.4.1 角色与权限根据OpenHarmony API治理章程代码审查涉及以下角色角色API治理职责权限标识ContributorAPI设计和交付主体提交代码与设计文档提交代码CommitterAPI代码预审Review1Maintainer新增API评审Review2变更API预审Review1Review2新增SIG变更API评审Review2变更PMCAPI Version计划发布、章程修订最终决策3.4.2 评审流程API评审流程对其他代码修改也有参考价值Contributor提交代码API设计文档涉及API变更时Committer预审Review1如果一次提交涉及多个领域需所有对应领域Committer都Review1Maintainer评审新增APIMaintainer Review2即可合入多个领域只需一个Maintainer通过变更APIMaintainer Review1预审进入下一环节SIG评审仅变更APISIG Review2评审完成代码合入3.4.3 评审关注点评审者主要关注正确性代码是否解决了问题设计合理性方案是否优雅、可扩展兼容性是否破坏已有功能测试覆盖是否有足够测试用例性能/安全是否有潜在风险代码风格是否符合规范3.4.4 评审文化社区评审文化强调“被Review是礼物别把‘挑刺’当冒犯”。维护者通常是志愿者或“业余维护”需要耐心等待。遇到问题用事实和数据说话基准、日志、规范链接。3.5 代码合入与关闭Issue代码审查通过后由Committer或Maintainer合入主干。PR合并后回到关联的Issue中总结并关闭给后来者留下清晰的路标。第四部分从社区贡献者到核心维护者之路4.1 贡献者的成长路径OpenHarmony社区的贡献者成长路径可以概括为三阶成长模型入门阶段 → 成长阶段 → 成熟阶段 Contributor Committer Maintainer/PMC4.2 入门阶段迈出第一步4.2.1 选择适合的起点对于开源新手推荐选择good first issue或help wanted标签的任务。这类任务难度低、范围明确多为文档修复错别字、断链示例代码优化简单的UI显示问题测试用例补充4.2.2 建立开发环境建议采用“虚拟机开发板”组合方案虚拟机用于代码编译与调试开发板如润和Hi3516用于真机验证4.2.3 完成首次贡献按照第三部分的流程完成从Issue认领到PR合入的全过程。首次贡献的目标不是代码量而是熟悉整个协作流程。4.3 成长阶段成为Committer4.3.1 深度参与核心模块积累一定经验后进入深度贡献阶段重点参与核心模块开发与社区讨论。此时需结合自身技术专长选择方向如分布式技术、安全架构、AI能力等。4.3.2 从代码贡献到社区贡献贡献不仅限于写代码贡献类型具体内容代码修Bug、开发特性、性能优化文档完善README、教程、FAQ测试补充单元测试、集成测试社区答疑、代码评审、Roadmap讨论生态适配器、插件、工具链开发金句写文档和测试是“神中神”的贡献它们让项目可维护、可扩展。4.3.3 参与代码评审参与他人代码评审是提升能力的重要途径通过评审他人代码学习优秀编码技巧从评审反馈中发现自身不足逐步建立社区影响力4.3.4 成为Committer的条件成为Committer通常需要持续高质量贡献代码量、评审参与度在特定领域展现技术深度获得现有Committer/Maintainer认可SIG Leader提名PMC确认参与社区贡献的成员根据贡献度大小可以晋升为社区Committer或PMC拥有社区正式身份甚至拥有主干代码写权限和社区重要事务投票权限。4.4 成熟阶段成为Maintainer与生态共建者4.4.1 Maintainer的职责Maintainer是SIG的核心维护者主要职责包括新增API评审Review2代码合入决策技术方向把控社区人才培养4.4.2 主导SIG或项目当贡献者成长为领域专家后可以主导现有SIG的技术演进申请成立新SIG参考2.3.2节孵化创新项目4.4.3 生态共建与价值转化成熟阶段的核心是从“技术贡献者”向“生态引领者”转变开发行业解决方案智能家居领域基于OpenHarmony开发设备互联互通协议工业领域开发工业控制解决方案通过华为“鸿蒙生态合作伙伴计划”获得推广资源开展行业合作与芯片厂商瑞芯微等合作优化驱动程序与设备制造商美的、格力等合作开发搭载OpenHarmony的产品华为提供技术对接和资源支持参与生态推广撰写技术博客、录制教学视频举办线下培训、技术沙龙通过华为“开发者赋能计划”获得资金支持与品牌曝光4.5 成长案例深开鸿巴延兴深开鸿资深OS框架开发工程师巴延兴是社区成长的典型代表参与OpenHarmony社区共建带领一百余人提交PR个人累计向主干提交1.5W代码在辅助工具SIG、内核SIG等核心领域深度共建主导多个工具开发解决社区痛点他的经验表明OpenHarmony是每个人的OpenHarmony只要想参与共建都可以利用自己对应的技能做贡献。第五部分社区沟通与礼仪5.1 社区沟通渠道OpenHarmony社区提供多种沟通渠道渠道地址用途开发邮件列表devopenharmony.io开发讨论、技术交流CI邮件列表cicdopenharmony.ioCI构建通知PMC邮件列表pmcopenharmony.ioPMC内部讨论安全问题邮箱scyopenharmony.io安全漏洞上报文档邮件列表docsopenharmony.io文档相关讨论开发者论坛https://forums.openharmony.cn技术问答、经验分享5.2 社区礼仪有效的社区沟通需要遵循以下原则具体 可执行提问时给出关键信息系统版本、设备型号、日志、复现场景、期望vs实际先搜索避免重复提问在Issues/PR历史中找类似案例尊重时间维护者通常是志愿者耐心等待不要密集刷屏接纳反馈代码被指出问题是成长机会不要情绪化用事实和数据说话正向循环PR合并后回到Issue中总结并关闭给后来者留“清晰的路标”5.3 Issue提交规范高质量Issue应包含环境信息OpenHarmony版本、设备/模拟器、构建信息复现步骤1, 2, 3…可附脚本预期行为 vs 实际行为日志裁剪到关键片段脱敏处理截图/录屏对UI问题极其有用最小可复现代码或仓库MRE能提供则离解决只差一步5.4 PR描述规范PR描述应包含原始需求问题背景和影响解决方案如何解决、替代方案具体修改点变更的文件和内容测试说明覆盖用例、平台、结果关联Issue如Fixes #I1TVV4第六部分贡献者资源与工具6.1 官方资源资源地址用途OpenHarmony官网https://www.openharmony.cn项目信息、下载开发者文档https://docs.openharmony.cn开发指南、API参考代码仓库https://gitee.com/openharmony源码浏览、下载社区治理仓库https://gitee.com/openharmony/communitySIG列表、治理文档CI门户http://ci.openharmony.cn构建状态查看6.2 辅助工具SIG代码仓辅助工具SIG的核心工具代码仓NAPI框架代码生成工具https://gitee.com/openharmony/napi_generatorIDL转换工具https://gitee.com/openharmony/drivers_hdf_core/tree/master/framework/tools/idl-gen开机动画工具https://gitee.com/openharmony/graphic_graphic_2d/tree/master/frameworks/bootanimation/data/bootanimation_tool6.3 贡献者清单模板提交前检查清单代码已格式化符合.editorconfig/clang-formatlint检查通过单元测试通过且覆盖关键分支Commit message符合规范已添加Signed-off-byPR描述完整背景、方案、测试已关联相关Issue第七部分未来展望——OpenHarmony社区的演进7.1 社区规模持续扩大截至2025年11月OpenHarmony开发者数量已突破800万。随着生态繁荣社区治理机制也将持续优化。7.2 治理机制演进方向更精细的SIG划分随着技术领域扩展SIG将更加专业化更便捷的贡献工具辅助工具SIG将持续产出提效工具更完善的激励体系贡献者成长路径更加清晰商业价值转化通道更加通畅7.3 从贡献者到生态共建者未来的OpenHarmony社区将涌现出更多从代码贡献起步最终成为生态引领者的案例。正如深开鸿的开源策略“从开源中来到开源中去”。结语开源是一场长期主义开源贡献不是“天才才行”的游戏它是把细节做对、把节奏跑稳的长期主义。从签署DCO到提交第一行代码从认领good first issue到主导SIG技术演进每一步都在为OpenHarmony生态添砖加瓦。参与OpenHarmony社区贡献收获的不仅是技术能力的提升更是与全球开发者协作的经验、在开源社区积累的影响力以及见证国产操作系统成长的自豪感。欢迎你加入OpenHarmony开源社区从今天开始迈出贡献的第一步。附录术语表术语全称中文含义简要说明SIGSpecial Interest Group特别兴趣小组社区贡献的基本单位负责特定技术领域PMCProject Management Committee项目管理委员会负责版本计划、发布管理等TSCTechnical Steering Committee技术指导委员会负责技术方向决策PRPull Request拉取请求代码贡献的提交方式DCODeveloper Certificate of Origin开发者原创证明保证代码原创性的签署机制CIContinuous Integration持续集成自动化代码检查与构建Maintainer-维护者有代码合入权限的核心贡献者Committer-提交者有代码评审权限的贡献者Contributor-贡献者参与贡献的开发者