从一个 GitHub 上的 Issue 想到的
最近更新了一下一键脚本,把切换到 Vmess 协议的功能加上了。想出来了一个几乎不影响原有使用体验,脚本结构足够简单,后续维护和解释的工作量比较小的方案。欢迎有 Vmess 协议需求的来试用。 bash <(curl -L https://github.com/crazypeace/v2ray_wss/raw/main/install.sh) 我在这里想扯一点别的,关于一个 Issue https://github.com/crazypeace/v2ray_wss/issues/7 这个 Issue 的原作者向我提了几个问题,一个是怎么在 VPS 上搭建 Subconverter,一个是希望我的脚本支持搭建 Vmess 协议。我印象中 TA 的语气还是很客气的。 我回复的内容基本上是拒绝了他,当然我还是解释了几句,表达了我自己对这些需求的想法。 过了几天时间,这个 Issue 的作者把 Issue 清空了,标题和内容都改成了 “算了”。 我想关于这个清空和 “算了” 说几句。 首先,我很感谢他给我回应。像这样的 “小品” 工具,有一些 bug,或者改进的缺点,或者新功能的需求,或者实现方案的思路,是需要广大的使用者反馈的。光作者一个人使用常常是遇不到大家这么多种实际使用情况的。闭门造车的效果也很差。我以前只是在博客简单写写,没有在 Telegram 上大量加入群组,没有把自己作品使劲推广给大家的时候,我是收不到什么反馈的。我也一直自我感觉良好。直到把作品推给大家,为了解释和辅助去写详细的教程,去接触其它人的作品,学习大家的优点,找准自己的定位…… 在这样的过程中,我才觉得很快就有了很多收获。 其次,我想说,在开源的世界里,开发者是有极大的权利的。在这个世界里,就是很直接的靠能力说话,你行你上,摆事实讲道理说明你的观点。如果作者不同意你的想法,你就 fork 一份,让大家都来喜欢用你的 fork, 用事实证明你是对的。 最后,我觉得,当你提出一份 Issue 时,你是这份 Issue 的作者。 我印象中当时 TA 的描述还是比较好的,语气也很客气。我当时回复 TA 时,我只是考虑到自己开发和维护的工作量而拒绝了他。这确实是我的想法,很长一段时间我觉得如果想用 Vmess 的话,有 八合一 等脚本可以搭出来,那就不用我的 VLESS 脚本。我希望我的脚本足够简单,能成为一个大家学习自己写脚本的原料。我觉得 TA 在那份 Issue 中的表达确实是有其自...