报告核心观点 - 开源在减少技术债务方面有重要作用，使开发工作与上游开源项目保持一致可直接减少组织承担的技术债务，虽短期内技术债务难以避免，但长期应尽量消除，通过适当政策、流程、培训和工具可降低技术债务 [62] 技术债务相关内容 定义 - 软件开发中技术债务指因偏离联合开发主分支而产生的维护源代码成本，专有代码本身也可构成技术债务，上游代码在缺乏维护资源时也存在技术债务 [8] 症状 - 代码由单一组织开发和维护，依赖合作伙伴维护；发布节奏变慢；新开发者入职时间增加，留用和招聘困难；安全问题增多；代码维护工作量增加；与上游开发周期不一致 [11] 类型 - 临时技术债务：为加速产品开发，在开发和集成过程中临时产生，最终目的是与上游分支合并 [12] - 未知技术债务：因不良工程实践无意识产生，如编写质量差且无法被上游接受和复用的代码 [13] - 故意创建的技术债务：组织为保留专属功能而创建独立分支，随时间推移导致技术债务增加和维护成本上升 [14] - 过时技术债务：因“非此处发明”综合征或孤立开发，导致开发成果与行业标准不兼容而产生 [15] - 组织技术债务：代码开发位置与应开发位置不匹配，开发者无法正确编写或贡献代码，产生不必要的代码 [16] 原因 - 低质量代码无法上游化；自利代码对社区用处不大；组织缺乏技术领导力和对上游技术方向的了解 [18][19] 后果 - 开发碎片化，导致重复工作和竞争实现；缺乏将代码推向上游的努力；代码具有侵入性，需跨组件协调；代码被上游接受时间长，产生临时技术债务；缺乏测试和文档；技术领导力差，与技术社区互动不足；内部需求不断变化；技术不标准或与标准不一致；代码维护成本高；创新和开发周期变慢；需支付技术债务利息；可能错过主分支新功能或需回移植开发；与主分支重复工作 [20][21] 积累方式 - 以开发周期无上游集成的示例说明技术债务的产生和延续 [22][23] 应对方法 识别 - 通过思考团队工作内容、软件栈相关问题等帮助识别技术债务 [25][29] 最小化 - 选择高级编程语言，便于招聘开发者、第三方解决问题、代码移植和维护，且容错性高 [27][29] - 选择与自身目标一致的生态系统，评估和选择合适的依赖项并为重要依赖项做贡献，且持续评估依赖项 [31][32] 示例相关内容 自定义构建系统的作用 - 维护操作系统需确保其可靠安全运行、组件可重现构建、正确评估测试、遵守许可和有更新机制；选择ARM服务器发行版可减少维护自定义操作系统的需求，便于开发者转移知识和招聘人员，未来嵌入式设备开发可选择有长期支持的标准Linux发行版 [34][36] 用户界面框架 - 编写和维护UI框架是长期任务，选择UI框架意味着选择社区，需依靠社区承担技术债务并必要时提供帮助；注意许可证和知识产权归属，参与上游依赖项开发以满足自身需求 [38][39] 上游开发相关内容 作用 - 以开发周期有上游集成的示例说明，遵循持续集成和交付、尽早频繁发布、同行评审、持续测试等实践，可使功能更快可用、代码质量更高、便于理解调试和成熟化、建立信任等 [41][43] 统一努力 - 与上游保持一致开发可减少技术债务，但需参与和贡献上游开源项目，可通过贡献影响上游方向 [47] 大规模解决技术债务相关内容 政策和流程层面 - 为开源开发者提供全面贡献批准；设置快速批准路径；提供灵活IT支持；构建奖励减少技术债务开发者的绩效评估体系；保证开发者与上游项目合作时间 [53] 开发层面 - 向工程师解释业务目标；确保开发者了解技术债务；对合并贡献有合理预期；接受审查反馈；参与对上游有益的任务；鼓励开发者在添加技术债务时注释；短期工作与长期规划结合 [54] 已有技术债务的解决方法 - 选择需保留的功能；识别有用代码；移除不再维护的代码；减少分支需求；重构、清理和上游化可上游化的代码；考虑迁移到能提供所需功能的开源项目；放弃技术债务并弃用代码 [58][56][57] 推荐实践 - 采用上游优先理念；谨慎评估不向上游提交的自定义代码；计划与主分支合并；使内部开发与上游发布节奏一致；快速批准上游贡献；更新绩效指标纳入技术债务相关内容；培训开发者和管理者识别和减轻技术债务；要求代码正确文档化；遵循尽早频繁发布实践；跟踪不向上游提交的代码并重新评估 [60][61]