内部治理的运营工作

版本火车的概念

开源软件的引入和退出

开源社区的版本发布，通常的规律是：在发布正式版本之前，会发布一些预览版或beta版，例如：1.0-beta之后，才是1.0，然后是1.0.1。

在1.1发布之后，1.0.2、1.0.3这样的1.0.x版本可能还会发布一段时间。

从开源软件选型的角度来说：我们不应该选择太新的版本，因为还不稳定。也不应该选择太老的版本，因为可能已经不再有人维护了。

一个比较常见的策略是：我们会在1.0版本正式发布后一段时间，观察稳定之后，再选择使用【引入】。并在2~3年之后，决定不再使用【退出】。

用版本火车管理多款软件的生命周期

在社区里的开源软件，有多个软件的多个版本，可供选择。例如：A 1.0、 A 1.1；B 1.2、B 1.3；C 2.0、C 2.1

在公司内部有多个产品，都会有各自的开源软件选型过程。例如：上半年（P1 1.0、P2 2.0、P3 2.1），下半年（P1 1.1、P2 2.1、P3 2.2）

在一个时间周期内，这些产品需要共同协商自己的开源软件选型，并确定一组选型版本。例如： A 1.0、B 1.2、C 2.1。这就被称为一趟版本火车（版本火车 202201）。

在这趟版本火车上，P1、P2、P3这样的产品，上半年（P1 1.0、P2 2.0、P3 2.1）就都上版本火车 202201。到了下半年，就都上版本火车 202202。

开源软件Owner的职责

在公司内部，需要分配不同的专人，负责看护不同的开源软件。这些人就被称为开源Owner。他们的职责包括：

• 开源软件选型：
  • 对标社区，定期对产品单向发布开源版本火车，负责版本火车中的开源软件的选型。
  • 负责将版本火车中的开源软件录入中心仓，并维护其开源元数据信息。
• 开源软件维护：
  • 跟随社区，通过升级社区版本、或回合漏洞补丁修复开源软件漏洞。
  • 看护公司内部的开源软件定制版本，批准新增维护分支的申请。
  • 对开源软件的定制化修改由产品自行负责维护，并回馈至社区。

运营工作的分类

• 开源软件统一上中心仓
• 元数据质量维护
• 版本火车定期发车
• 推动漏洞治理
• 推动法务合规
• Owner能力提升
• 开源文化建设