把内部工具开源之后，我不后悔的几个决定

前言

以事后回顾的方式拆解两个内部 CLI 公开发布的过程：授权条款的意外、文档欠债，以及意料之外的社区拉扯。

为什么这个问题反复出现

每一场 Share 的讨论最后都会落在同一个张力上：对团队当下舒服的选择，和项目一年后真正需要的东西。光靠辩论，哪一边都赢不了。

一种思考方式

• 默认值比意图活得久——请刻意设计它。
• 决策本身很便宜，沟通很贵——为后者留出预算。
• 分歧是数据。把「什么证据会改变你的想法」写下来。

我会怎么做

从「小到觉得没什么用」的规模开始，把理由写进 commit 或 RFC，然后在日历上定一个日期重访它，而不是凭感觉。

写在最后

Share 的品味，大多是记忆。请刻意收集属于你的那份。