目前因为开源组件的一些bug或者开源组件没法满足我们的业务诉求，需要针对性二次开发，针对这部分的二次开发产生的版本，是否形成管理标准？
我觉得有两点要考虑：
1、这部分的源码管理机制，针对内部如何开源？
2、二开后，需要跟随开源版本升级方面的工作如何推进？
是改的开源项目吗？
是的 我们现在有需求要求修改 google的Aviator里面的东西
1、如果吸收回KOCA平台，由KOCA项目组统一维护；没吸收之前，可能还是由产品单位自行维护；
2、源码级别的改动，版本升级，只能基于文本进行比对升级了
有几点需要考虑一下的：
1、是否二开的发布物都要有相应标准出来，比如 groupId 添加kingdom字眼、版本号如何确定，不然maven上会变得很杂乱。
2、源码的存放方式，是否单独git配置库管理、集团内部对这部分源码的访问机制(走maven source？)。
3、源码修改的记录记载，需要在KOCA平台文档中详细记载各个开源组件的changelog，具体需要记载哪个类的哪几个方法，同时要在代码中留下修改记录说明，而且针对这部分修改做更加严格的评审。
4、开源版本升级后，需要安排人跟进合并版本