开放原子开源基金会有哪些项目？开放原子开源基金会杨涛简历
开放原子开源基金会简介及现状
开放原子开源基金会是我国首个开源基金会，据官方消息开放原子开源基金会是一个致力于开源产业的全球性非营利公益机构，业务范围包括开源软件、开源硬件、开源芯片与开源内容等。我们可以将其理解为中国软件开源项目的孵化器、连接器与倍增器，即为，通过对开源代码的开放治理以便形成标准，连接生产、学习、研究的正向生态，为开源项目找到更多的应用场景。该基金是以工信部为主管的基金会，仅代表业务主管单位是工信部，并非隶属于工信部，其是以效仿国外开源社区为主，由阿里巴巴、百度、华为、浪潮、腾讯、360、招商银行等企业发起，为各类开源项目提供中立的知识产权托管，保证项目的持续发展不受第三方影响，通过开放治理寻求更丰富的社区资源的支持与帮助。目前概况如下：
1）中国开源项目现状：在中美科技竞争加剧的大形势下，美国不断增加针对中国实体的管控名单，是中国科技发展面临的最大挑战，具体在开源使用层面，中国开源软件应用目前仍存在断供风险，而我国开源生态发展尚未完善，开源供应链风险突出，如中国本土开源项目托管平台、开源社区孵化平台、开源风险综合防控平台等还非常薄弱，导致中国很多重点领域的开源技与开源项目发展，还处于追赶阶段
2）开源基金会立意：我国很多互联网企业或机构一直都是把自己的开源软件放到美国基金会运行，主要原因是软件不能独立成为一个完整的系统，要跟其它基础开源软件对接或协作，只能选择通过美国基金会的力量协同开发，保证实用性。华为消费者业务软件部总裁王成录表示：如果中国没有自己的开源社区去维护管理这些代码，那么一旦发生发生不可抗的因素，我们中国的所有的软件行业将是非常危险的。随着开放原子开源基金会的成立标志着中国开源事业上了一个新台阶。
3)目前基金会拥有八个孵化项目：其中有3款操作系统。包括百度超级链 XuperChain、华为分布式操作系统OpenHarmony（鸿蒙）、腾讯的 Kubernetes 发行版 TKEStack 和物联网终端操作系统 TencentOS tiny、360 的类Redis 存储系统 Pika、浪潮的低代码开发平台 UBML，以及阿里的物联网嵌入式操作系统 AliOS Things。这意味着完全自主研发的中国开源技术未来将依托于国际级开源组织，以全新组织形态运作，并作为中国最具代表性、具备国际影响力的区块链开源技术培育和运营，在全球区块链市场上展开技术力、生态力的竞争
02
基金会成员及架构梳理
开放原子开源基金由阿里巴巴、百度、华为、浪潮、腾讯、360、招商银行等企业于2020年6月份发起，是国内唯一的一家开源基金会。从投入运营至今备受国内外开源界关注，当前项目伙伴包括：
1）白金捐赠人：阿里巴巴、百度、华为、浪潮、360、腾讯、招商银行、中软国际、趣链科技、京东。
2）金牌捐赠人：PATEO博泰（省广集团、东风汽车参股）、华软集团、亿咖通科技、OSCHINA、华秋电子（深圳华强）。
3）银牌捐赠人：极客邦科技、润和软件、思必拓（新大陆参股）、好叭科技。
4）一般捐赠人：哈尔滨工业大学、中国科学院软件研究所（中科软）、深圳大学、中国信通院。
目前企业通过捐赠项目给开源基金会，以开放治理的开源方式，吸引更多开发者参与，实现共建、共治、共享，开源基金会让所捐赠的知识产权及资金发挥应有的社会价值；开发者则可以通过直接参与开源基金会的开源项目开发工作，让自己的劳动成果为全人类所共享。
一：中国开放原子开源基金会
如果对你有帮助，望采纳。基金的起始资金最低单笔是1000元,定投200元起投
二：中国开放原子开源基金会会长
9月28日，欧洲最大的开源组织Eclipse基金会和中国第一个开源基金会OpenAtom基金会共同宣布，双方建立合作伙伴关系，专注于OpenAtom旗下的OpenHarmony操作系统。这里所说的OpenHarmony操作系统，就是最开始由华为开发并捐献给OpenAtom（开放原子开源基金会）的那个Harmony操作系统。合作目标是共同建立一个全球性的、供应商中立的、独立的开源社区，让开发人员、供应商、系统集成商能够在一个统一的生态系统中扩大其全球影响力。
这个合作，显示出欧洲最大的开源组织Eclipse基金会对OpenHarmony操作系统的认可。这，显然打脸了国内不少人对OpenHarmony操作系统的各种无脑的怀疑和污蔑。两个开源组织的合作，必将快速推进OpenHarmony操作系统的国际化。
其实，OpenHarmony操作系统最大的价值就在于生态体系打造，这次合作命中要害，目标就是打造这样一个统一的、有全球影响力的生态系统。
不少人对OpenHarmony操作系统和近期华为手机（及部分老荣耀手机）正在火爆升级的HarmonyOS2智能手机操作系统的关系搞不清楚。显然，HarmonyOS2系统是华为在开源的OpenHarmony操作系统基础上开发的属于华为的系统，而开源的OpenHarmony操作系统已经不属于华为，而是完全属于开放原子开源基金会，任何人、任何企业都可以参与、使用的开源系统，这与开源的安卓操作系统是完全一样的。
HarmonyOS2系统手机升级用户已超过1.3亿，经过了大量机型、用户的长时间验证，HarmonyOS2系统的性能、功能都已被证实很强大。但是之前几个月国内很多人却一直不信任HarmonyOS、OpenHarmony操作系统，现在却被国外开源组织打了脸，这真是个悲哀。
实际上，早日加入OpenHarmony操作系统这样的先进的面向未来的物联网操作系统，对自己是有利的，而不是给“华为做嫁衣”！有识之士、有远见的企业，应该早日加入OpenHarmony操作系统的开源体系。
HarmonyOS3系统据称也会很快推出了，华为的步伐一直在坚定地前行。OpenHarmony操作系统也必能更快发展，而且国际化进程也提速了，这为中国操作系统走向世界开了个头。显然，一个领先的新秀操作系统HarmonyOS，已成为全球最大操作系统之一，好戏这才刚刚开始。
三：开放原子开源基金会成员
这两天包括中国银行、广发银行和中信银行都接入了鸿蒙系统，这个事情引起了不小的反响。
那这三大银行接入鸿蒙系统释放出什么信号呢？其实我觉得这只不过是银行正常的操作而已，大家没必要做过多的解读。
首先、银行加入鸿蒙系统只不过是正常的适配而已。
对各大银行来说他们都有自己的app，但是银行的用户多种多样，有的人使用华为，有的人使用小米，有的人使用OV，有的使用苹果，这些不同的手机使用的系统是不一样的。
之前大家最常见的两种手机操作系统就是安卓跟苹果的IOS，所以银行在开发APP的时候，其实都会有两个项目组，一组是负责开发安卓APP，还有一组是负责开发IOS的，这两个不同的系统所使用的开发环境都不一样。
而现在华为推出了独立的鸿蒙系统，而且有很多华为用户已经升级到鸿蒙系统，这时候为了能够让银行的APP更加适应鸿蒙，银行肯定会对现有的APP做一些调整，通过对APP进行适配接入鸿蒙。
而且按照鸿蒙系统跟安卓的兼容性来看，现有的安卓APP只需要稍微做些调整，其实很快就可以接入鸿蒙，其实这里面并不需要很复杂的工序。
而且我相信在这三大银行之后，包括其他银行以及其他应用软件，都会逐渐适配鸿蒙系统的，毕竟华为在国内的用户量并不在少数，有几亿的华为手机用户量，这些用户未来都有可能逐渐升级到鸿蒙系统，对应的各大银行以及其他应用也只能推出适配鸿蒙的APP来顺应用户的需求。
其次、可以借势营销。
鸿蒙系统自从诞生开始就备受
所以在鸿蒙系统出来之后，其实很多企业也会根据这一波热点来借势营销，比如现在这三家银行宣布接入鸿蒙系统，很多网友出于好奇就有可能会
再次、表明立场。
其实对鸿蒙系统，我是不希望大家选择站位的，鸿蒙系统它也只不过是一个正常的市场行为，所以对于众多企业来说，你觉得鸿蒙系统好用，那你就用，你觉得不好用那也没有必要迫于道德压力而接入。
但是面对广大网友来自凶猛的一些评论，其实很多企业都招架不住，所以很多企业要么不表明任何态度，要么就积极表明要拥抱鸿蒙系统，这样至少不会引起广大网友的反感。
当然就我个人分析，现在之所以有越来越多的企业，包括厂家愿意接入鸿蒙系统，有一个很重要的原因是华为把鸿蒙的底层代码捐给了第三方公益基金，也就是开放原子开源基金会，以后鸿蒙系统的开源项目发展以及维护，都将由该基金成员共同完成。
华为这么做可以大大降低大家对鸿蒙系统的防备和排斥，之前很多企业或者厂家之所以不愿意加入华为，因为华为本身就是鸿蒙系统的开发者，同时他们也有手机以及其他设备跟竞争对手产生冲突，所以很多人都认为华为这是既当裁判员又当运动员，不太合适。
现在华为把鸿蒙系统捐出去之后，那跟华为就没有关系，它完全就是一个开放的系统，这个系统可以由多个厂家和多个企业来共同维护和发展，并不完全由华为说了算。
这样各大企业和手机厂家就不用担心自己被华为限制，这也是最近一段时间有越来越多的厂家主动加入鸿蒙的重要原因，而且随着鸿蒙系统的不断开放，我相信未来会有越来越多的厂家会接入鸿蒙系统的。
四：开放原子开源基金会是国企吗
IT之家 6 月 3 日消息 开放原子开源基金会是致力于推动全球开源产业发展的非营利机构，于 2020 年 6 月正式获得民政部批准在北京成立，由阿里巴巴、百度、华为、浪潮、360、腾讯、招商银行等十家龙头科技企业联合发起，由工信部作为业务指导单位。开放原子开源基金会拟通过共建、共治、共享的方式，系统性打造信息产业和工业开源开放框架，搭建国际开源社区，提升行业协作效率，赋能千行百业。目前开放原子开源基金会业务范围主要包括为各类开源软件、开源硬件、开源芯片、开源内容提供中立的知识产权托管、战略咨询、法务咨询、项目运营、品牌营销和教育培训等服务。
今天，OpenHarmony 2.0 孵化和运营者开放原子开源基金会发布了孵化项目毕业标准 v1.0。
1. 代码与文档 (Code and Document)
OA-CD-10
【中】项目代码是易于找到的，并且能被公开访问。
【EN】The project's code is easily discoverable and publicly accessible.
OA-CD-20
【中】可以使用常用的标准工具对项目代码进行重复构建。
【EN】The code can be built in a reproducible way using widely available standard tools.
OA-CD-30
【中】应通过源代码管理系统保留项目代码的完整变更历史，所有已发布版本都可以被重新构建。
【EN】The full history of the project's code is available via a source code control system, in a way that allows any released version to be recreated.
OA-CD-40
【中】每一行代码必须由具备强认证机制的提交者通过源代码管理系统建立，当提交第三方贡献时，提交备注中要包含可靠的代码
【EN】The provenance of each line of code is established via the source code control system, in a reliable way based on strong authentication of the committer. When third-party contributions are committed, commit messages provide reliable information about the code provenance.
OA-CD-50
【中】项目必须有最终用户文档，例如：API、CLI、仪表板、安装部署、配置等。
【EN】The project must have end-user docs in place such as API use, CLI use, Dashboard use, Deployment use, Configuration use.
OA-CD-60
【中】项目应具有可证实的用户支持历史，可以是在邮件列表或 issue 系统中的答复。
【EN】The project should have a proven history of providing user support,such as replies in mailing list or issue systems.
2. 流程 (Process)
OA-PR-10
【中】项目需要有符合业界最佳实践的代码提交流程。
【EN】The project requires a code commit process that meets industry best practices.
OA-PR-20
【中】项目团队应该与营销团队一起确定合适的官方名称。
【EN】The project should have engaged with marketing team to check suitable official name.
OA-PR-30
【中】项目需要通过独立的第三方安全审计。
【EN】The project should have completed an independent and third party security audit.
OA-PR-40
【中】项目必须使用基金会基础设施团队认可的任务、缺陷和设计跟踪工具。
【EN】The project must use task, defect and design track tools that approved by infrastructure team of OpenAtom Foundation.
3. 许可证与版权 (Licenses and Copyright)
OA-LC-10
【中】代码发布需要满足项目所采用开源许可证的合规性 / 兼容性要求，且符合开放原子开源基金会的知识产权政策。
【EN】The code is released under the open source license that project used, meets the compatibility requirements，and complies with OpenAtom Foundation's IPR policy.
4. 发布 (Releases)
OA-RE-10
【中】发布要包含源代码，分发时需要采用标准开放的打包格式，以便长期保持可读性。
【EN】Releases consist of source code, distributed using standard and open archive formats that are expected to stay readable in the long term.
OA-RE-20
【中】发布由项目的项目管理委员会批准。
【EN】Releases are approved by the project's PMC (Project Management Committee).
OA-RE-30
【中】发布需要进行数字签名或带有哈希摘要，以校验
【EN】Releases are signed and/or distributed along with digests that can be reliably used to validate the downloaded archives.
OA-RE-40
【中】发布必须包含源代码，也可同时发布二进制文件。
【EN】Release must include source code; convenience binaries can be distributed alongside source code.
OA-RE-50
【中】发布过程必须有详细的文档说明，并且是可重复进行的。根据文档指引，任何人能够独立生成发布所需的所有制品。
【EN】The release process is documented and repeatable to the extent that anyone is able to independently generate the complete set of artifacts required for a release.
OA-RE-60
【中】项目必须有清晰的版本计划，并且必须制定至少 2 个常规的后续里程碑。
【EN】The project must have a clear roadmap and must have followed at least two common milestones.
5. 质量 (Quality)
OA-QU-10
【中】项目对代码的质量要开放且诚实。
【EN】The project is open and honest about the quality of its code.
OA-QU-20
【中】项目的安全性是最高优先级的。
【EN】The project puts a very high priority on secure software.
OA-QU-30
【中】需要提供一套规范化的安全响应流程。
【EN】The project requires a standardized security response process.
OA-QU-40
【中】项目要重视兼容历史版本，尽可能将所有不兼容的变更文档化，并提供工具和使用说明帮助用户过渡到新的特性。
【EN】The project puts a high priority on backwards compatibility, aims to document any incompatible changes and provides tools and documentation to help users transition to new features.
OA-QU-50
【中】项目应该努力及时响应已上报的 BUG。
【EN】The project strives to respond to documented bug reports in a timely manner.
OA-QU-60
【中】该项目必须具有合理的 CI 流程 / 工具、单元测试及测试代码覆盖率。
【EN】The project must have decent CI process/tools, unit test and test code coverage.
OA-QU-70
【中】项目对登记的 issue 应进行合理的分类、分级。
【EN】The project should have a decent record of triaging incoming issues.
6. 社区 (Community)
OA-CO-10
【中】项目有一个众所周知的主页。
【EN】The project should have a well-known homepage.
OA-CO-20
【中】社区欢迎所有出自善意、行为受尊重、为项目增添价值的参与者的贡献。
【EN】The community welcomes contributions from anyone who acts in good faith and in a respectful manner and adds value to the project.
OA-CO-30
【中】贡献包含但不局限于源代码，也可以是文档、建设性的错误报告、建设性的讨论、市场推广或者其他任何会为项目增值的内容。
【EN】Contributions include not only source code, but also documentation, constructive bug reports, constructive discussions, marketing and generally anything that adds value to the project.
OA-CO-40
【中】社区要符合贤能治理的精神，随着时间的推移，为项目增值的贡献者会被赋予更多的权利和责任。
【EN】The community strives to be meritocratic and over time aims to give more rights and responsibilities to contributors who add value to the project.
OA-CO-50
【中】社区的运作基于具有决策权的成员的共识，避免一言堂。
【EN】The community operates based on consensus of its members who have decision power. Dictators, benevolent or not, are not welcome in projects.
OA-CO-60
【中】项目致力于及时解答用户的问题。
【EN】The project strives to answer user questions in a timely manner.
OA-CO-70
【中】项目需要在项目网站或 Readme 显示项目的孵化状态。
【EN】The project should list project’s incubation status prominently on website/readme.
OA-CO-80
【中】项目有一定数量的活跃提交者和相当规模的代码提交数量和合并数量。
【EN】The project should have a healthy number of committers, and demonstrate a substantial ongoing flow of commits and merged contributions.
OA-CO-90
【中】项目应明确定义项目治理和提交者的管理流程。
【EN】The project should explicitly define a project governance and committer process.
OA-CO-100
【中】项目应至少在主要代码仓库中提供公开的使用者列表（例如提供 ADOPTERS.md，或在项目网站上展示采用者的 Logo 列表）。
【EN】The project should have a public list of project adopters for at least the primary repo (e.g., ADOPTERS.md or logos on the project website).
7. 共识建立 (Consensus Building)
OA-CS-10
【中】该项目维护着具有决定权的贡献者的公开列表 - 项目管理委员会由这些贡献者组成。
【EN】The project maintains a public list of its contributors who have decision power -- the project's Project Management Committee consists of those contributors.
OA-CS-20
【中】决策由项目治理委员会成员的共识形成，并在主要的沟通渠道中记录。要考虑社区意见，如有异议，项目管理委员会拥有最终决定权。
【EN】Decisions are made by consensus among Project Management Committee members and are documented on the project's main communications channel. Community opinions are taken into account but the Project Management Committee has the final word if needed.
OA-CS-30
【中】无法通过讨论形成共识的情况下，可以使用文档化的投票规则来达成目标。在项目中，否决权只对代码提交有效，且否决要求有合理的技术性理由。
【EN】Documented voting rules are used to build consensus when discussion is not sufficient. In projects, vetoes are only valid for code commits and are justified by a technical explanation.
OA-CS-40
【中】所有重要的讨论都应该以书面形式在项目的主要沟通渠道上异步进行。对项目会产生影响的线下、面对面或私下的讨论也应在该渠道记录下来。
【EN】All important discussions happen asynchronously in written form on the project's main communications channel. Offline, face-to-face or private discussions that affect the project are also documented on that channel.
8. 中立性 (Independence)
OA-IN-10
【中】项目独立于任何公司或组织。
【EN】The project is independent of any company or organization.
OA-IN-20
【中】项目必须有不少于三方的核心评审团队。
【EN】The project must have a diverse core reviewers team (at least 3).
OA-IN-30
【中】贡献者的社区角色权限不应受雇佣关系变化而影响。
【EN】The role & permissions of contributors in the community should not be affected when their employment relationship changes.
OA-IN-40
【中】项目毕业需要至少三位 TOC 成员提名进入毕业流程。
【EN】The project should require at least 3 TOC members to step forward as sponsors to enter graduation process.
9. 成熟度 (Maturity)
OA-MA-10
【中】至少三个独立用户成功将项目用于生产环境，TOC 根据质量和范围判定用户是否有效。
【EN】The project should be used successfully in production by at least 3 independent end users which, in the TOC‘s judgement, are of adequate quality and scope.
10. 其它 (Others)
OA-OT-10
【中】项目毕业需获取全部 TOC 席位 2/3 的赞同票。
【英】To enter graduation, the project should receive the affirmative vote of two-thirds of the authorized TOC.
OA-OT-20
【中】上述指标由于项目的类型、范围和大小不同有一定的偏差，因此 TOC 对上述指标有一定的自由裁量权。
【EN】Since these metrics can vary significantly depending on the type, scope and size of a project, the TOC has final judgement over the level of activity that is adequate to meet these criteria.