选用开源组件，可以让小团队更快完成产品。进入真实交付之后，还需要处理升级、故障与维护交接。选型时顺手写下退出方案，有助于看清这项依赖真正带来的责任。
先列出承担不起的故障
开发一个内部数据平台，图表库、身份认证、任务调度和数据存储的风险各不相同。图表暂时不可用，可能还能导出表格；登录故障会挡住所有用户；存储损坏则需要恢复数据。选型应先按故障后果排序，再分配研究与测试时间。
对关键依赖，至少记录版本、许可证、维护者、升级方式、已知限制和替代路线。GitHub 的软件物料清单说明介绍了从依赖图导出包含版本、许可证等信息的清单。自动清单适合打底，项目仍需补上服务型依赖、人工安装组件与运维责任。
看到公开仓库后，还应核对具体许可证和使用条件。OSI 的定义明确，能够查看源码只是其中一部分。涉及交付、分发或修改时，要按实际使用方式核对条款；存在不确定性就单独处理，避免在报价阶段默认没有额外义务。
做一次小型退出演练
假设将来需要替换当前图表服务，可以先挑一张核心报表验证：是否能导出原始数据与配置？业务计算是否被写进专有表达式？替换后能否得到相同的筛选结果？需要改动几个调用点？这些问题比“支持开放格式”更接近迁移成本。
工程上可以在外部依赖与业务逻辑之间保留薄薄的一层适配接口，但不必提前实现所有供应商。先隔离最可能变化的调用，保存典型输入输出样例，记录迁移时必须满足的条件。这样既保留选择空间，也避免为了假想未来增加大量代码。
数据导出要带上字段解释、时区、编码与关联标识。只有一份能下载的文件，接手者仍可能无法还原业务含义。可以把导出与恢复各执行一次，并检查记录数量、关键关联和抽样内容；备份是否可用需要通过恢复来确认。
把维护工作放进交付说明
开源依赖会带来升级测试、漏洞处理和兼容性检查。独立交付时，应明确谁关注更新、谁决定升级、谁执行回滚，以及相关工作是否包含在维护范围内。客户需要知道后续责任，开发者也需要避免无限期的隐含承诺。
作品集可以附上一页依赖决策记录：为什么选它、验证了什么、尚有哪些风险、何时重新评估。它传达的是完整的工程判断。组件选择得再好，也需要一条清楚的接手与退出路线，才能成为稳定交付的一部分。