思想一碰就冒火: 开源贡献须耐心, 选择框架要谨慎

引子

最近笔者学习Go语言的过程中,使用了一些不错的package.

使用过程中根据自己的理解和需求,需要对package做写修改.

这很容易, fork 一个分支自己修改就好.

但是开源的力量所在不是搞独立不兼容的分支. 而是大家共同维护一个版本, 使之丰富完善, 这样才能体现开源的力量, 才能更好的维护开源的良性生态. 然而

思想一碰就冒火

这里先贴出几个修改讨论的连接

pelletier/go-toml 的讨论遇到语言障碍

uniqush/log 的讨论还在进行

gosexy/db 的讨论比较顺利

这些讨论, 有些获得了原作者的认同, 有些原作者表示已经意识到问题, 但是需要认真考虑下. 有些因为语言障碍, 貌似让原作者纠结了.

重要的是, 这些讨论所花费的时间成本太高了. 好在这些都是独立的package, 我在应用中可以先使用自己的分支. 如果用的是框架级别的 package, 那基本上我是不敢用自己fork并修改的版本, 因为框架的复杂性, 如果原作者后续更新了新的支持, 自己fork并修改的版本不能兼容, 那就惨了.

选择框架要谨慎

对应技术讨论, 很难有一个评判标准说, 谁的方法就一定是正确的. 所以不能抱怨别人不认同自己的想法. 也许那根本就是错误的, 也许是正确的, 这很难说. 但是对使用造成的不便是客观事实. 期望原作者能够及时的提供支持是不靠谱的. 所以选择框架要谨慎. 如果不能确定所选的框架足够强大或者解耦, 并且经过时间的检验. 那最好不要用她, 采用多个独立的package组合完成任务吧.