导言
先说结论，我对国内开源环境持悲观态度。
起因来自于 V2EX 上的一帖：【国内开源环境】- V2EX，顺便也谈谈自己对开源项目的一些看法。
什么是开源？
开源最早起源于free software movement，注意这里的 free 并非是免费的意思，而是指的自由。自由软件是指对软件的运行、研究、修改、共享（分发副本无论修改与否）。
开源是指一种计算机程序，其中源代码可供公众使用或对其原始设计进行修改。代码是根据软件许可条款发布的。根据许可条款，其他人可以下载、修改并将其版本（分叉）发布回社区1。
好哒，现在我们来看一下国内 “最大” 的 “开源社区” Gitee 是什么情况的呢？
【如何看待 5 月 18 日 Gitee 仓库开源须审核，已开源部分仓库暂时关闭，审核通过后再次公开？ - 知乎】(https://www.zhihu.com/question/533388365)
当然，我很早就注册过 Gitee，不使用不代表不好用，毕竟速度这块肯定是在国内要比 GitHub 强一些，但大多是带有我个人一些偏见。主要是项目太少，质量太差，当时的功能一般，当时并没有像 GitHub Pages 这样的功能，同时永远永远会慢 GitHub 很多步。另外一点便是对仓库的各种限制，比如容量一类。我也知道 Gitee 官方也回答了这个问题，说此举出于无奈2。既然已经从政策上禁止了，那么所谓的 “自由软件” 也便不复存在了。
国内的开源项目
首先，先说说我对 开源项目 这一个词的理解吧，我认为开源项目最首先要具备的就是 README 和 LICENSE，这两个文件是开源项目的基础，直接说明了你这个开源项目的使用和分发方法。同时，Awesome-List 并不应该在开源项目的范畴之内，顶多算是开源文档一类的。而一个完整的开源项目，应该具有比较完整的 workflow 和规范的贡献方式，比如 CONTRIBUTION.md 告诉社区如何贡献和提交代码，以及基础的代码规范。最重要的是有一个完整的文档和版本号，更好的便是 milestone 或者 roadmap，这样才能让社区更好的参与进来，看到开源项目未来的发展规划。当然还要有人去解决 issues 和 Discussion 中的问题。同时，还应该有一些基础的测试用例，以及 CI/CD 的配置，这样才能保证项目的质量。
不得不说，国内其实有非常多的优秀开源项目，有许多开源项目都被 Apache 基金会孵化。
但你观察就会发现，这些优秀的开源项目，几乎都是由企业承担，而个人开发者的优秀项目则是少而又少。
国内的开源是企业的，没有个人开发者，有开源软件，没有开源社区。
个人开发者环境
在国内，一个开源项目的归宿有两个，一个是被企业收购（我认为是一个开源项目最好的归宿），另一个是自己成立公司。
我们先说第一点，当然这其实大多数企业是不愿意做的，毕竟这也是一笔不小的开支，而给企业带来的收益呢？既然是开源，本来就能用，那么…收购和不收购的区别也就是让 roadmap 更符合自己项目的需求吧。而且，在现在国内的疫情环境下，裁员毕业这种事已经成了常态了，原先分给企业内部开源部门的经费和人员大多也都分到了业务部门，所以收购更是不太可能了。
那第一点走不通，第二点呢？这个的难度不言而喻，怎么实现盈利呢？那自然是 2B，和企业 API 对接。那其实和第一点就差不多了，至于如何 2B，难度就是在这里了。那么你要做的就是拿开源项目做自己的名片，展示给公司，才能进行合作。但是你作为一个开源项目，想维护好这张名片，想要他长久的生存，那必然还得 2C。
只做 2C 有没有其他的道路呢？有，Sponsor。哦，对了，忘了说，中国大陆开发者，在 GitHub 是没法注册 Sponsor 的，也就是，你只能通过放置自己的二维码来实现 Sponsor，而很多 GitHub Sponsor 的功能，你也就无法使用了。Gitee 好像是没有 Sponsor 制度的，这块国内的审查明显要过段时间，毕竟涉及到税收问题。但 Sponsor 还是能收到一些帮助的，但其实无论是国内还是国外，结果也都差不多，真正的方式应该是用 Pro 来提现差异化，引导用户付费。我觉得这条路是个人开发者自己搞能走的最好的路。
不知道有多少人还记得之前 colors.js 的事件3，作者选择了 MIT Licence，希望能够得到 Sponsor 盈利或工作机会，然而结果就是企业都在用，却没有任何人买单，最终作者设置加入恶意代码，导致非常多的项目运行出现问题，甚至作者 GitHub 账号一度被封禁。从一个开发者的角度我很容易去理解作者的心情，但又很不理解的是他最初选择的开源协议，既然想一次盈利，要么做出差异化，要么干脆不要使用这么无限制的开源协议。hcaptcha-challenger 这个项目亦是如此，不少人使用它去爬 Discord Token 或是做一些灰产内容实现盈利，但是没有人愿意开源，没有人愿意遵守项目给出的 GPLv3.0 Licence。
国内在开源协议这块也在慢慢健全法律法规，有很多由开源协议引发的法律纠纷得到判决，说明开源协议在我国法律中的有效性，希望类似由开源协议引发的事件在国内开源项目能够得到很好的解决。
使用者环境
一个很简单的问题，如果不是高强度的 GitHub 使用者（比如我这个刷 GitHub 比刷空间+朋友圈都多的人…），上 GitHub 大多是具有目的性的，比如上来找找实验代码，找找有没有现成的项目拿来用用。能顺利使用的小白就不多（毕竟需要科学上网才能下载 release 和显示出来 README 中的图片），更别说让他去遵守开源协议了，可能连开源协议都不知道是啥。当然有些小白不仅啥也不知道，代码不愿看，甚至直接就来开 issue 提问，Wiki 也不看，态度还贼差，好像开源开发者就是为他服务的一样。
从 hcaptcha-challenger 这个项目就能看出来，我和另一个开发者还经常收到邮件“问候”，项目无关的问题我为什么要去帮你解决？就比如我收到过让我帮他去解决某网站的验证码的邮件。先不说这个项目的初衷是对抗 hCaptcha，而不是针对他的“某网站”，代码都是开源的，自己甚至不愿意去了解项目结构，纯结果性的寻找答案。反正这种人我是不会帮助的，我不太相信就他这种发邮件“问候”都要用翻译软件回复的人后续能带来什么收益，本身就是灰色产业，我也不愿意染指。
当然，这块并不是国内环境，稍微有点跑题，但是国内很多用户也是一样的态度，比如 YOLOv7 的骂战，看得我都觉得丢人（现在好像找不到了，直接当时有人用中文说以辱骂的语气声讨原先的 YOLOv7 项目的命名问题）。所以我也奉劝各位在 GitHub 交流尽量使用英文，不要使用网页翻译插件以后回复，提问请友好交流多用敬语，尊重开发者的工作，开发者不是你的员工！！！
结语
以上大概就是这篇文章的全部内容了，非常希望国内能够建设好开源社区，最起码是不要影响产品和项目迭代，不要让审核成为开发者的累赘而限制了开源项目的发展。另外就是希望能够建立良好的 Sponsor 制度，让优秀的个人开发者能够做自己感兴趣的事情，维护好自己的开源社区还能养活自己。
