全文总结
快到这个文章的结尾了，虽然写了很多，但是总结起来的条目倒是不多：
l 随着公司迈向3000亿美元，公司软件的战略定位应该由硬件的附属转变为相对独立的平台化，由被动防守式的发展转为积极进攻的发展思路。由守住红海的战略转变为扩展蓝海的战略。
l 公司平台软件部门的战略目标应该是：让“业务连续性”成为其它公司的战略。
l 硬件PK指标，软件PK体系，软件发展的重点是四化：软件产品化，产品平台化，平台品牌化，品牌生态化。理念上，硬件平台怕被别人用，软件平台怕不被别人用。
l 平台软件最大的创新点是寻找到属于自己的东岸和西岸并快速架起桥梁。平台软件的最终目标是让所有东西岸的用户都通过这个桥梁。·
l 软件开发的流程管理应该从做加法转变为减法。将工程师的时间聚焦在工程实现上。尽量减少非代码以外的操作和时间消耗。
l 要逐步恢复工程师文化和协作精神。充分的信任工程师，遴选有激情，有理想，有能力的工程师，容忍错误，宽容时间。建立互信协作，开放包容的工程师生存环境。放下部门间指向对方的枪。
l 华为的发展前景依然光明。
回应文章开头的工商银行的提问。过去的20多年，软件部门做了工商银行信息处的工作，支撑公司在CT领域取得了辉煌的成就，下一个阶段，软件部门需要思考如何做出支付宝，微信支付这样改变世界，控制世界的系统和平台。这些系统和平台应该是华为公司的“中台战略”
让外部势力改变自己是危险的，最安全的模式是自己来改变自己。
然后呢？
首先还是要感谢华为，总体来说，华为还是一个很宽容的企业，特别是2012实验室层面。毕竟大量外招“砖家”经历了长久的职业生涯，各自已经形成了自己的思维方法和做事方式。很多方法和方式和华为格格不入，但是很幸运，如果你要坚持做什么的时候，公司还是有一定的容忍度的，这对华为这样体量的公司来说，是难能可贵的。
其次，大家对公司有着诸多的吐槽，我也会吐槽，边吐槽边看好公司是个什么逻辑？经历过不同的公司以后，还是有一些感觉的，借用我第一个公司的老板给我讲的一句话回答大家把：你所在的公司90%的情况下比你想象的要好，你要去的下一家公司90%的情况下比你想象的要糟。
总结也总结了，感谢也感谢了，吐槽也吐槽了，我们通常会问一句：然后呢？写了一大堆东西总得有个说法？
只抛问题，不给方案是很多知识分子耍流氓的一种方式。这显然不是我们码农的风格，我们的风格是：即使不知道问题在哪里，也会给出很多方案。
作为公司的平台部门，EulerOS会用我们的方式试着给出自己的方案---极客汇
广告时间—EulerOS团队&极客汇
我写了如此之多的内容，以至于自己都快忘记了这是一个广告帖的初心。
虽然在第一章我就写清楚了，这个系列是为了推广我们的网站和尝试下新的模式。但是经过那么长的铺垫，最后大家发现我是在认认真真做广告的时候，总还是有种翻车的既视感。不过anyway，广告的目标也是为了尝试解决问题，给出我们的一种实验方法和模式。下面就开始正式进入广告时间。
EulerOS团队
EulerOS是2014年开始组建的公司的基础设施平台，目前承担公司服务器OS和容器基础设施以及相关的底层基础设施的构建。经过这几年的打磨，虽然有不尽如人意的地方，但是也基本上建立起来了还算完善的基础设施。
整体上，EulerOS团队的目标是构建一个支持多种芯片的两层平台
l 第一层平台式以EulerOS和iSula为基础的OS+容器基础设施。对应的外部可以类比为redhat+docker
l 第二层是在这两个基础设施之上的特色软件，或者是垂直的软件栈，目的围绕这两层基础平台可以在一些领域再垂直做出一些平台。
我把这种模式称之为涟漪模式，涟漪的中心是核心的两个基础平台。然后在外延的部分逐步做出一些延展性的平台。形成一个技术群。而且这些软件之间是可分可和，独自演进，互相解耦。
我希望EulerOS和iSula能成为行业内有一席之地的平台品牌，能在一定程度上做到“外来的药方”一章中的层次三。打造类似redhat + docker这样的基础软件平台，在这两个基础平台之上的各种特色软件能够成为这两个基础平台的竞争力点。但是这些软件并不和EulerOS，iSula绑定，他们依然能够独立演进。
随着业务的发展，我们会逐步增加上层的软件扩展，实现小团队，精兵突进，快速成型，快速迭代，成品交付的模式。
这也是EulerOS团队希望能够在公司内部尝试一次新的模式和方法。试着提供一条解决前述文中所述的那些问题的探索之旅。
什么是极客汇
什么是极客汇，简单来说，就是我们将EulerOS所做的各种项目和软件，逐步以成体系的软件产品的形式展现给各个产品线。也为后续对公司外部开放做好准备。与此同时，我们会在这些项目中尝试着使用新的模式和方法来进行开发：
l 小团队：每个项目的开发团队不大，一般控制在4-5人以内。
l 快速迭代：快速设计，快速成型，快速验证。迭代交付。
l 荣誉感：每一个项目的技术负责人的头像都是大大的，项目就是他们的荣誉。
l 产品化：项目本身都是一个完整的，可安装的系统，而不是部件，包含完整的文档等。
l 开源化：所有的一切都开源，不会有一行代码隐藏起来。大家可以看到我们所有的开发活动。
l 开放化：欢迎外部的个人或者组织使用，提建议，提需求，甚至提交代码。
l 品牌化：我们希望这些项目能够孵化出后续甚至享誉世界的品牌。
l 货架化：我们希望每一个项目都是货架产品，做到产品线立等可取，由“你要什么”转变为“我有什么”
我们遴选了几个我们前几年开发和积累的软件项目，这些软件项目会以完整产品的形态呈现给大家，后续还分步有更多的项目上线。
极客汇项目简介
EulerOS
EulerOS自不必说，老本行了。目前EulerOS是以CentOS为蓝本开发（主要考虑与Redhat的兼容性，redhat是服务器OS领域中的工业标准）。未来我们会尝试一下新的结构和新的使用方式。没有什么能比把一个老迈的，已经存在了30多年的OS传统架构革命掉更有意思的事情了。
iSula：
全面替代docker的自研容器引擎和容器全栈。符合容器行业OCI和CRI等南北向接口，轻，快，小，能够符合从端到云全路径的应用场景。我们的目标是：让docker成为过去式。
Malluma：
超越VTune的系统级的profiling工具平台。任何一款芯片，一款机器都需要强大的profiling能力。Malluma就是这样的工具，我们致力于打造ARM领域最好的profiling工具体系。在架构层面做到模块化，为后续支持更多的体系架构打下良好的基础。
在公司平台ARM化的进程中，我们欢迎大家使用Malluma进行系统调优，和我们一起将Malluma打造成为最好用的profiler。
当然，如果谁能猜出来Malluma代表什么意思，洪光会请吃饭。
Siwise：
当下没有什么比AI更火的技术了，用AI来进行系统性能调优是一个有趣的想法，从想法到能跑起来只需要做一件事情，真正上手写一个出来。
Siwise的目标是能在性能优化领域帮助工程师提高效率。甚至是发现很多不为人知的一些潜在性能优化参数集。
Siwise内部使用的时候已经给了我们一些小惊喜。我们希望siwise能在更广阔的天地发现更大的惊喜。
没有惊喜也没关系。只是多耗了一点电而已。
Aoss：
性能卸载是一个热门话题，当HTTPS等应用需要更强劲的性能的时候，我们来搞一个Aoss吧，Advanced Offloading Service System。
既然是offloading service system，显然预示着我们希望能将他扩展到不同的offloading场景中。
这个项目也是唯一用C语言写的项目。
CloudFair:
最后一个呈现的项目是我认为真正能改变世界的小东西。无数人讨论过在未来的世界里，全互联OS长什么样子。我觉得，好像就应该长成cloudfair的样子。这个项目是我们和海思的兄弟团队一起做的系统。感谢两边长达两年多的爱情长跑。
在“危险的评论”这个章节中，我畅想了一下当每个人身边都围绕着华为设备的时候的美好情景。那么，当这一步实现以后，我们怎么用这些设备呢？也许，就是CloudFair所展现给大家的样子。
这个团队有试玩demo，欢迎尝鲜。不妨体验一下未来世界的模样。
CloudEnclave:
Online Soon
Memig
Under heavy development, online soon
更多精彩，敬请期待！
为什么要搞极客汇
就用我写在极客汇上的一段话来概括吧。
把这段话的每一句反过来理解就大概是华为做软件的现状。这次我们就尝试来改变一下。
极客汇有什么不同
l 所有的代码都是开放的，开放的，开放的，重要的事情说三遍，我们不会隐藏一行代码，所见即所得。
l 我们希望构建一个开放的平台，任何人，任何组织都可以针对这些项目提出自己的意见和建议。我们更欢迎码农们能参与到这些项目中，哪怕是一个注释的修正，我们都100%的欢迎和欢欣鼓舞。
l 我们欢迎有各种奇思妙想的码农同学来贡献自己的idea，我们最希望干的一件事情就是针对某一个有趣的idea一起设计方案并快速实现它，最终成为极客汇的新成员。我们十分欢迎码农的名字和他的项目一起改变世界。
l 我们希望工程师的荣誉和项目的成败息息相关。工程师由荣誉和爱好的驱动而非KPI的驱动去将软件做到极致。
为什么有SE的头像和工号
让这些无产阶级SE们拥有成（fang）就（bian）感（zhao）。后续我们会把核心的工程师的头像也放在各自的分网站上。
极客汇在哪里
http://geeklink.rnd.huawei.com/
为什么现在搞
四年了，总得在华为干点特别的事儿。
预算问题
大部分项目是公司投资的，有些纯粹是我们想这么做。当然，公司总会有好事者挑战，这不是说明工作不饱满么。随他去吧。
l 认认真真的“浪费时间”也比装模作样的忙忙碌碌要好的多，至少工程师的能力得到了提升，公司有收益。
l 留下哪怕是一段最烂的代码也好过只留下一个没有结果的完美PPT。
华为传统上都是论证多，动手少。我总觉得有论证的时间，我们可能活都干完了。这一次，就由着性子干点“有趣”的事情吧。
当然，还有一个层面的问题，因为有些领域，特别是面临未来的领域，如果要说服其他人同意你的看法是很难的，如果要说服一堆人，大多数时间都impossible了。未来，绝大多数时间，我自己都说服不了我自己，就别说说服别人了。唯一的方法就是：先试试看吧。至少比写PPT去论证未来还是靠谱的多。
如果这种方式能牵引公司的项目投资方式也有一定的改变，那就更好了。
团队和绩效
这也是一个严重的问题，现代软件系统都规模庞大，是一个协作的过程。如果团队里面的人并不认可这么做，我一个人其实也干不了啥。还好，还是有那么一些人愿意尝试尝试的。总要需要那么点人忘却绩效去试点新东西。
能成功么
这些项目能成功么：天知道，但是不试肯定不知道。
能帮助公司改变点啥么：做了，多多少少还是有点作用的。不做，只打嘴炮肯定是没作用的。
后记
终于写完了，这辈子都没有写过这么多汉字，粗略算了一下，7万多字，赶上一部小说了。春节前实际已经写完了。只是拆成一个个章节发出来，在拆的过程中做了少量的调整。毕竟是广告帖，所以控制了一下节奏，一周两篇。
整个极客汇的想法是在18年10月份左右开始成型的，人力有限，就一点点的搞到现在终于有一个模样了。里面各个项目的内容还是需要持续的进行演进。我希望这种模式能给华为尝试一种新的道路。
在这个过程中，公司突然出现了IPD2.0这样的项目，至少从我的角度看是一个好的趋势，很多提法和外部通用的做法是比较吻合的。显然公司也并不是不知道这个系列中所谈及到的问题，现在关键是除了谈论，得搞点啥尝试一下。
公司已经迈进了1000亿美元的门槛，这样一个体量的巨无霸公司，软件领域应该更relax一点，更自信一些。打法上也更应该主动一些，更具扩张性一些。这样才能把迈向3000亿的道路铺的更平整一些。
更进一步，现在的这个时代，个人，公司，乃至整个国家都面临巨大的挑战和变革。所谓预则立，不预则废，变革不以人的意志为转移，迎接变革最好的方式就是变革。
很庆幸春节前能有一周多时间把脑子里的东西写出来，我觉得这几乎是我能留给华为最精华的东西了。现代的IT技术一日千里，单纯技术的保鲜期是很短的。但是这些设计原则，这些软件的基本准则是长久有效的。
在发的过程中，许多同学做出了很多评论，我都没有回应。首先对这些同学的热心表示感谢。如果不是为了做广告，我个人是一个不乐意抛头露面的人。也不喜欢就一个具体的论点和别人争论。因此无论是什么样的评论，都没有回复。
在这里将比较有代表性的评论总结一下，统一回复一下。
评论回复
这个问题我想我在“从加法到减法”中已经做了一定的阐述。Committer机制的作用有点类似WR的Gate keeper机制。毫无疑问这是软件开发中非常重要的一种机制。但是这种机制能不能解决当然华为软件开发的问题呢？肯定不能。因为还有很多其他的问题要解决。
华为有一种很有意思的现象，整个公司很焦躁，对任何一个问题，特别是很复杂的问题，没有人能静下心把问题分析清楚，从来都是寄希望于一个“绝招”把问题摆平。但不幸的是，任何一个复杂问题之所以复杂是因为不存在一个绝招能搞定，复杂问题都是一个体系性的问题。某些单点的改变肯定是有效果的，但是不能解决全局性的问题。
即使有一个“绝招”，其推广方法也应该类似改革开放的特区模式，先某几个产品线试点，而且也不应该是全产品线，应该是某几个业务的几个小团队先试行，总结经验。然后结合各自部门的特色来设定相关的流程和规定，最后推广到全公司施行。而不是一刀切。比如那个著名的函数必须50行以内的规定。我一直想问规则的制定者，为啥不是49行？
“试点”这种在祖国大地行之有效，而且运行了40多年的方法好像在华为这个伴着改革步伐成长起来的公司里却不见踪影。
所以问题不是committer机制是不是正确，问题是用何种方式来推进这种机制。
Linus本人就是一个超级gate keeper，这个讲法很经典，懂行。
说的没错，WR的开发流程确实是建立在平均水平比较高的工程师的基础之上的。事实上，我所讲的内容绝非是说WR的流程完美无缺。本质上只是做一个介绍，任何的流程，机制都必须和自己公司的实际情况相结合。没有一劳永逸，一招鲜的方法。如果有人像你兜售一劳永逸的方法，那是“骗子”。
首先感谢你用产品经理这个称号来形容我，我没有做过产品经理和行销经理，不过我一直在一线做产品，和销售一起在一线打单子。所以有这些味道。我认为这是对的，我的一个观点是，没有见过标书的工程师是做不好技术的，没有挨过客户骂也是不懂技术的，特别是高端的技术人员。
在我的认知世界里，我不认为软件需要区分2B还是2C，所有软件都是2P的（to people），我更愿意把软件分为平台类软件和业务类软件。我个人认为华为这样的公司应该是去做平台类软件，就是去投资架桥，收过桥的红利，这是平台类软件，而不是去做装修队，去给别人一个个房子，一座座桥去装修，做装修的就是业务类软件。
这里提到了业软，这个几乎是我进公司后就耳熟能详的失败典型。很多人做了无数的分析，有人说是要做光盘，有人说要能复用，有人说定制太多了，等等。但是我的看法是业软的业务本身就是装修队的活。移动，联通是投资修桥的甲方，业软是给桥做装修的乙方，我总感觉适合干这个的应该是亚信，亿阳信通这样级别的公司。我似乎看不到华为能做很大的可能性。装修公司很难做大。
因为我不了解业软的历史，所以以上只是我个人看法，可能和实际情况完全不符，供大家参考。
这个系列文章实际上有两个版本，我姑且叫做A版本和B版本，面世的是B版本，A版本相对来说火爆的多，有更多华为业务的剖析，有更为激烈，苛刻的言辞和比喻。如果从做广告，推广网站的角度来说，似乎A版本更能引起轰动效应，广告效应更好。但斟酌了一下，还是删改为B版本，减少了华为内部的分析，减少了一些内容的篇幅，去除了很多“激烈”的措辞。
在华为，永远不缺乏观点和争论，缺乏的是上手去真正开始干一个事情。所以，没有必要用更为刺激性的语言引起更多的争论。努力去做一次尝试才是最重要的。不争论，上手干。
不用怀疑任何之前曾经做过的事情，华为做到现在的这个程度，说明之前做的事情是正确的，有意义的。追求极致性能本身就是华为致胜的法宝。
本系列文章不是在否定华为之前的做法，而是探讨在未来的发展道路上，如果仅仅还是依照老的模式，是否还能有效。
微信，Android，WRLinux都只是例子，并不是要我司去对标这些产品，华为不是互联网公司（暂时不是），华为也不是搜索公司（暂时不是），更不是OS厂商（永远也不可能是）。我用这三个看似毫不相关的case来进行解析的目的是要告诉大家，平台类软件，即使是不同的行业，其设计思路也是相近的。我想强调的是学习这种设计思路，而不是具体产品。
还是应该乐观一点，没有哪个公司能全产业链都占优，华为相对所有的公司，已经算是产业链把控能力非常强的公司了。而且越来越强。
不过，我前面提到过，在华为高歌猛进的道路上，公司的每一个人都一本正经，认认真真的“焦虑”和“紧张”是好事。只有每一个人的不乐观和反复自省，才能保证公司长久的乐观。
时间还是站在华为一边的。
代码和程序是两个维度，高内聚是指代码层面，尽量做好聚合，减少重复度，但是程序层面则需要做到低耦合，尽量分离开。
WindRiver的Gatekeeper机制是我亲身经历，亲手参与建立起来的机制，因此能说的清楚。但是并不是说所有公司都是同样的机制。他山之石永远都只能做参考，而不是照搬，具体的措施还要结合具体的公司，甚至是具体的业务部门来制定。另外可能的一点猜测是，通用公司可能和华为会比较类似，毕竟，汽车也是一个“大盒子”。
很有营养的回复，conan确实是C/C++的一种很好的代码管理机制，虽然用起来复杂了一点，但是对C/C++确实是能解决很大的问题，期望大量使用C/C++的团队能够真正用起来。
不过我个人还是认为，除非是强性能相关的，比如和芯片底层强相关的开发不得不选用C以外，一般性开发还是争取能尽量迁移到新语言中。比如对于内存管理，传统的C/C++是非常难于控制的，即使像我这样熟手，也不能说不出错，而且很繁琐，即使能做，也没人愿意把精力耗费在这上面。但是新型的语言，要么有GC帮码农处理这些繁琐的事务，如果觉得GC耽误事，也可以考虑rust这样对内存有生命周期定义的语言。甚至已经有外部公司开始用rust写OS，虚拟机，数据库等底层系统了。
所以我觉得一般码农需要至少掌握两门语言，一门是C，这是基础，只有纯熟掌握C，才能说得上对系统有理解，能随心所欲。一门是类似go, rust, python,java这样的快速开发的语言。我这里没有列C++是因为我个人非常拒绝C++，原因比较简单。太复杂，当一个人把自己写的C++程序，特别是混合了template等高级特性的程序交给第二个人以后，接手的人很难理解，接手成本非常高。所以，我衡量一个语言好坏的标准是：开发语言的优秀程度和接手的难度成反比。
你并没有抬杠，感谢这位同学的直白，但是直白的还不够，我稍微翻译一下：Windriver其实实力过人，高层经过深思熟虑，看准了时机，最终决定出手，因为vxWorks的成功，所以带动了WRLinux产品的成功，最后一击命中。
由于是B版本，相关的删节确实给“他山之石”这一章造成了一些误导，给人一个直观的印象似乎是工程团队引领了公司，是WRLinux成功的最大功臣。其实A版本中的这一章大体是这样的。
风河的创始人实际上是非常讨厌Linux系统的，很显然这个系统会逐步侵蚀vxWorks的市场空间，特别是重要的电信市场，所以公司一直抗拒Linux系统，直到2006年左右，Linux的趋势已经挡不住了，特别是大客户北电决定使用Linux，这时候公司才不情不愿的开始成立WRLinux部门，整个部门的起源是来源于北电的2 Million的一单。最开始是在北美做，但是后来由于成本根本cover不了，后来改为在印度成立了一个公司搞，但是印度分公司实在是不靠谱，完全交不了活，最后不得已印度公司给裁撤了，这才有了WindRiver又把Stephen Li老先生（原欧拉部的部长，也是风河很早期的元老）请回来，匆匆忙忙的在北京建立中国研发中心，这才有了那个打给我的猎头电话。
面试只有一轮，stephen老先生刚回国，在面试中，他混杂了一半广东话，一半英语的提问，我其实完全听不懂，我几乎不知道他在问什么，所以我只能即兴发挥的用中英文混杂的认真“作答”。读者可以自行脑补一下这个堪称史上最具喜感的面试场面，一个完全不知道问题是什么的应聘者在一本正经的认真作答，我估计面试官可能也没听明白我在回答什么，但是他偶尔点一下头，不置可否的继续发问。
从我收到猎头的第一个电话到我坐到风河的办公室里，前后一共一个月，这种入职速度堪称光速。也可以想见风河当时的急迫程度。进去第一个岗位是测试部门的负责人，一周以后，在我连部门人还没认全的时候又被调到开发团队，负责sustaining和产品的小版本开发，还有一些大客户定制化开发，这是一个在任何公司都是最苦逼的部门。后来老大说是当时面试的时候说好的，这也许是真的，因为面试的时候，每当他老人家说话结尾语调上扬的时候，我都会面带微笑的说“yes”。
然后就有了前半年每天凌晨两点的苦逼日子，然后才有了然后的一切。这个世界上，很多在外人看起来具有某种神圣感的事情，实际的过程却是连滚带爬，屁滚尿流。当你认为是一些“高人”的高瞻远瞩，信手拈来的时候，实际上的过程可能却是临时抱佛脚，狼狈不堪，迫不得已。
但是这并不妨碍我们在工程设计和实践上采取了争取的方法。正确的工程设计和实践是帮助产品成功的必要条件，但并不是充分条件。
回到产品本身，WRLinux有很多市场份额实际上是vxWorks出让的，是公司的左口袋换到了右口袋的过程。甚至这个产品线的起始本身就是源自于北电从vxworks切换linux。全球的嵌入式市场是极度狭窄的，总共也就几亿美元而已，而风河已经占了80%以上的市场份额，谁都能看的到只拘泥于嵌入式行业公司是没有更大发展的。因此，像我这样中层主管就开始不断向公司高层进言，进军服务器市场，云市场等具有更多潜力的市场空间，因为单纯从产品角度来说，WRLinux和Redhat并没有那么明显的界限区分。但是公司高层始终无动于衷。当我把这些归结于公司高层的愚蠢的时候，某年有一个VP再次来北京，我当面又提到这个话题，这个VP无可奈何的道出真相，大意是，公司其它的人也有类似的提议，但是Intel不允许我们这么做，redhat服务intel的服务器战略，WindRiver服务于intel的嵌入式战略，各自有各自的地盘，互相都不能越界。
那一瞬间，我如梦初醒，当二维生物TurboLinux在棋盘的角落争实地的时候，当三维生物WindRiver，Redhat在棋盘布局的时候，是四维生物Intel把它画好的棋盘递到我们手上的。
当市场上的四大架构很快的收缩成为2个架构，当众多的中小型芯片厂商死亡的时候，实际上WindRiver在衰败的路上就已经越走越远了。桥还在那里，过客没了。我们在帮助intel的同时也扼杀了自己的未来。
讲到这里，可能大家才会理解为什么这一节的名字叫做“成功的失败者”，谁是成功者，谁是失败者不言而喻。当然风河衰败的原因不止于此，不展开了。
以上内容我觉得和主题相差有点远，而且篇幅有点大，B版本的内容已经足够说明问题了，所以在B版本中删除了这些内容。既然有同学提到了，这里就再附上一部分吧。
真实的世界远比我写的更为精彩，也许A版更能体现这种精彩，但我不打算展示A版本了，没有什么事物是完美无缺的。缺憾也是一种美。
就用这个不完美最终结束整个系列吧。
最后，附上我几乎所有PPT的最后一页作为本文的结尾
愿华为越来越好