商用开源的故事

虚构的故事又来了。

背景与经过

我们是个海外客户甲的软件外包项目团队，客户付全职工作的钱，通过我们公司乙间接雇佣了我们这个10人团队。
近期项目上有一个任务，在软件主体功能之外需要一个小工具，比如说txt文本转换成pdf文档这样的。
队员A在了解pdf转换工具的需求之后，觉得这个需求其实很普遍，不是甲方客户的行业领域，也与当前的软件功能不强相关，所以可以进行开源，先放在个人仓库下，后续联系公司，希望能够加入公司的开源仓库，就叫TPC（Text Pdf Convertor）吧。公司最近也有一个编程活动，也可以报名，在活动上逐步完善它。
但是项目上也是需要这个工具，所以A把TPC直接发布到了公共包管理平台。在项目里，使用install TPC命令安装并继续使用。

---

对于这件事我的反思是：

甲方

我付钱买了10人8小时/天的工作量，现在项目依赖于开源的TPC。那就是说，在8小时的时间里，我的外包团队没有能力思考并产出TPC的逻辑和代码，除非我答应TPC需要开源。如果在项目中使用TPC发现了问题，团队是在8小时内维护TPC呢，还是在8小时之外才能维护TPC发布新的版本呢？那我的项目现在是在给TPC做测试？你说你可以在7*24在线维护TPC， 那在外包结束之后呢？我的需求永远都会在TPC最高优先级吗？我的特殊需求与TPC的蓝图冲突的时候呢？

风险

添加开源软件进入项目，未得到客户甲的书面确认。
直接依赖了公共包管理平台的工具而没有从源代码构建，项目直接依赖于个人对TPC的升级和维护。
TPC加入乙官方开源仓库，仍未有进展，但是使用了公司电脑进行开发，版权是属于乙方，从个人仓库发布至公共包管理平台是未授权操作。
从乙方到团队，处在丢失甲方信任的风险之中。

更好的开源库

开源本身没有问题，没必要重复造轮子，但是应该有更好的打开方式。

企业级开源消费者的角度

1. 所依赖的开源库使用的协议，必须有可商用且修改发布的授权。
2. 自行搭建流水线构建开源库，有必要时安排内部团队进行维护。
3. 尽量选择成熟用户多的开源库，成熟度高，缺陷相对少。
4. 开源库使用情况申请/走查制度，保护自己。

外包乙方的角度

1. 作为提供专业服务的乙方，应该帮甲方做到上面的4点。
2. 在合作初期与甲方确认软件版权相关的法务问题，明确合作方式。
3. 确保信息安全相关培训切实有效地完成。
4. 给予团队切实准确的关于官方开源仓库的指导。

开源开发者的角度

1. 确保开源代码的版权归属，确保使用正确的设备和时间进行开发维护。
2. 开源只能代表自己的意愿，请考虑团队和组织利益。