拆分为两套代码所存在的问题：
使用不同分支后，大型修改的合并将变得极为困难，不论是从上游合并到下游，还是下游合并到上游，都将成为一个耗时巨大的工程，以轻共享代码合并上游为例，历时3个多月，经历过大量测试，仍然出现风险不可控。如果只是禁绝了从下游合并到上游的可能，下游的客户也一样需要承担上游合并到下游所带来的功能异常风险，及下游代码丢失的风险，该风险从宏观和微观层面，都与下游合并至上游一致。
分析目前工作特性
需求差异
在没有强一致性的标准下，toB产品必然存在由于管理制度不同而导致的需求差异情况，那么针对某个企业的特异需求，如何考虑，转换成一个可以通用的配置性需求，是对大客户产品设计的一个必定要求。如果转换成了通用性的配置性需求，那么就可以认为是一个标准化的产品需求，那需要解决的问题就是由于交付压力而导致的交付时间问题，而交付压力在研发过程中就转换成为了团队资源差异，最终转变为代码差异。
三种服务扩展方式
对于一个已有服务的扩展应该分为三种类型：
- openapi式扩展
- 服务覆盖式扩展
- 代码式扩展
在目前的实践阶段，由于微服务化程度不够，主要的扩展方式为1、3两种，其中openapi式扩展由二开团队负责，代码式扩展由大客团队负责。
在深度微服务化后，可以增加一种服务覆盖式的扩展手段，以保证上游代码不变的情况下，下游代码实现新的接口，以新的逻辑提供服务，并不需要阻止有共性的服务，而可以由服务调用方进行逐渐的优选，详见亚马逊AwayTeams模式。
由于交付时间压力的存在，所以代码式扩展不可能被完全禁绝，所以代码质量管理成为目前最大的管理症结，例如之前提出的，责任田内代码被其他团队修改，导致最终的bug权责不清问题。
参考管理实践
对于大型团队的代码管理，参照了大型公司谷歌、亚马逊、脸书以及大型开源项目如Linux基金会的管理方案。
Amazon Away Teams架构剖析/解密：AWS的工程师如何开发和维护他们的内部技术
[转]facebook是如何管理代码的_trace的技术备忘专栏-CSDN博客
Participating in Open Source Communities - Linux Foundation
提取的共性：
Code Owner
Code Review
二开现状更类似于开源软件项目的上下游概念：
主产品作为上游。
二开部署代码作为下游，如果每个客户都存在只属于该客户的代码增量，需要投入大量的资源来保证下游代码稳定，如果所有大客户使用同一套代码作为下游，则与上游并没有根本区别。
优化方案
优化代码管理思想：
来自于其他团队的代码贡献不可避免，只需通过code review的方式避免低质量代码合并，下游贡献的高质量代码是对责任田能力的优质补充。
如果沿用现有组织机构，提升上下游意识，保证“上游优先”可以解决代码差异问题，通过CodeReview来提高其他团队修改代码导致的质量问题。