I. 造轮子成本很高，重复造轮子不是好办法

1. 一颗芯片从新适配一个OS到商用的成本约400W美金

    图：嵌入式软件全生命周期的投入模型

     把设备适配完成，系统跑起来，做到Demo状态，过XTS认证，难度不大，成本也不高，所以社区上有大量的设备过来认证，展会的站台上也能堆的满满的。但是真正达到商用水平，鲁棒性好，性能功耗都满足要求，这就要投入比Demo多几倍的资源。做到这里，我们从芯片公司，咨询公司，以及自身做项目的经验来看，估计在400W美金左右。

     这个投入少不了，轮子还必须得造，那我们只能解决“重复造”的问题。

2. 联合共建，摊平研发成本

     商用共建从形式上看也比较简单，就是大家都需要这个芯片，那就组成一个虚拟团队，由牵头单位做项目管理和需求分解，和共建企业一起承接，完成后大家各自持有产权。细节已经有文章讲述，这里就不赘述了。

3. 软件维护也需要新的模式

     软件维护的周期比开发要长很多，市场问题修复，安全补丁，基线升级，等等，这些都需要大量投入。我们假设，在共建之后，大家各自拷贝了一份代码，欢喜的去了，然后自己做产品，自己维护。如此一来，共建时候遗留的BUG，每个公司都会遇到，又会发生重复修改，如果某些模块出现安全问题，就需要各自修复，遇到底座发布大版本，企业想升级，那又要各自升级，依然是重复劳动。

     维护阶段的问题都发生在用户手里，复现和定位都比开发阶段困难，而且还要顶这巨大的市场压力，你搞不定，求助到共建团队成员，这时候大家不一定有时间，也没有办法处理，因为你的代码和他的已经不一样，如果共建结束，团队解散，大家也没有义务帮你。如此一看，如果真的要做商用，维护问题必须要解决，需要寻找合适的维护模式。

II. 分层分级，按利益归属分配维护责任

1. 分支间遵循类的继承关系

     软件设计中有个重要的概念是继承，分支维护也可以用这个概念来思考，按之前的论述，商用共建分支是继承自社区主干，并在主干上完成了特定芯片的适配，以及一些公共特性，比如：DFX，OTA等等，各企业的商用分支是继承自商用共建分支，并在商用共建分支的基础上添加针对自有硬件的适配，以及客户的定制需求，最终发布给客户。

      图：分支间的继承关系

2. 在继承基础上的分支策略

    OH Master是社区主干，一般每年会发布2个Release分支，商用共建会基于Release来开发，并跟随社区的Release分支进行升级，比如23Q4发布4.0Release之后，P7885商用分支会跟进升级，这个目前由牵头单位带领共建团队负责落地，但使能部只会对最新基线做主动维护。

    各企业自己根据自己的客户要求，选择性跟进商用分支，如果不需要新基线的特性，就可以不升级。如果发现共建分支问题，就可以反馈到共建分支，共建团队如果判定是主线问题，就会反馈到主线，主线修改后再回合到共建分支，企业再从共建分支回合到自己的商用分支。

    这就是源自社区，回馈社区的基本逻辑，也是一种共建，通过商用项目发现主线问题，修复后，所有人都收益。但是目前很多企业不是这么做的，大家拉出去之后，问题是不回社区的，敝帚自珍，当作竞争力，这格局便有些小了。

    如果说按收益来定责任，那么主线维护和共建分支维护其实还是有问题的，没有商业闭环。当前社区主线是华为在维护，共建分支是共建团队主导，团结大家一起维护，完全依赖华为对这件事情的投入。从长期来看，社区Release如果承载了某些企业的产品，那维护职责就应该这些企业中的大者来承担维护责任。至于共建分支，其最终归宿应该是芯片原厂自己看护，对其License客户提供OH的SDK。