关于开源的五个问题

（已退课）
这个作业的要求是，第一次作业 （看开源的资料，提五个问题）-CSDN社区

问题1

我读到

“TDengine 的代码质量很高，模块之间划分总体上比较清晰，文档也较全，社区相对也很活跃，遇到问题能够及时得到帮助，对于有志于学习数据库核心代码的同学来说门槛高不是一个难以攻克的问题。如果你对 C 语言并不熟悉，那我建议你也可以从学习 TDengine 生态应用软件的源代码开始，还可以通过学习 TDengine 的测试脚本来学习如何对基础软件进行测试。”

发现该项目吸引作者的一大原因是代码质量，那么在我们创建开源项目或者参与开源项目时，是不是也需要创建或遵守一定的代码规范、文档标准？有没有，类似于开源标准这样的已经创建好的规范标准？

问题2

我读到

从这里可以看出，Linux社区最稀缺的资源是两个：代码审查（Review）和测试（Testing）。我也是那个时候才知道，社区鼓励发小而美的补丁——抛出一大坨令人望而生畏的补丁集，很容易劝退查看者（至少会让人产生“等我有大块空闲时间了再来消化”的想法）。

发现即使是Linux社区（可以说是世界上最成功的开源社区之一），在代码审查、测试部分仍然存在资源不足的问题，或者说，贡献者修复bug和审查者审查相应贡献，是一个耗费精力不对等的过程，毕竟要读懂一个人的代码是很困难的，那么现在的开源项目是如何应对这个问题的？是否有一定的贡献要求以降低审查者的压力，如添加规范的注释、贡献者进行一定的测试等？

问题3

在Linux社区，质量控制的核心在于“代码合入”（Git Merge）这一动作，这是属于“看门人”的唯一权力。合入是一个重要的门槛和分水岭。在合入之前，看门人有是否接受、何时合入的决断权，以及在此基础上衍生的关于补丁实现原则/方案的建议权。此时看门人的权威一面，想必给贡献者们留下了深刻印象。可是在合入之后，强势的看门人，随即变身为苦命的维护者，这是因为开源社区有一个基本假设：在开源市集里，贡献者们进进出出，随时可能走掉，不再响应。这意味着合入代码所增加的系统复杂性，其长期维护责任，要由社区与维护者来兜底。

对于开源项目的维护者来说，其责任无疑是巨大的，那么如果某个项目出现了问题，维护者是否要承担无限责任，还是使用者也要为“开源”二字承担一定风险？

问题4

Greg Kroah-Hartman 是一名 Linux 内核主线分支的维护者，2021 年 4 月 22 日发布了一个申明，禁止一所美国大学试图以研究名义故意提交带有安全隐患和其他“实验”性质的可疑代码合并到 Linux 内核主线分支。

且不论当事人是否真的存在故意提交危险代码，对于这种故意或无意下存在安全隐患的贡献，项目维护者如何辨别呢？如果是依靠自身的技术能力，那么当项目愈发庞大后，对于审查者的能力要求也会相应提高，面对满足要求的审查者稀少的情况，又是如何解决的呢？

问题5

把这些都放在一旁，将源码开源也是个极为繁琐的事情。我先不谈清理一些让我感到尴尬的东西，下面是我想到的可能不太全面的一些点需要说明一下：
网站的主题是从WrapBootstrap 购买的，我没有权利来将它用到开源项目
富UI组件是ExtJS的商业版本。这需要被剔除，或者这个项目需要遵循GPLv3协议。
Sidekiq Pro需要被剔除掉。
用到的每一个JS库和所有的图片资源都需要检查并保证得到了授权。
涉及到客户信息的代码需要被剔除。比如我们创建了针对客户数据的组件就不能发布。这个过程意味着需要编辑检查每一个文件。
需要确保所有的接口秘钥或者密码不能在代码中出现或者配置文件中。（听起来很糟糕，但是确实有这种情况。）
服务运行中潜在的安全漏洞
移除所有的涉及钱款的代码
移除所有的邮件宣传代码
移除所有的非Web集成测试部分的代码

对于一个开源项目，其使用的组件等也应该是免费的或遵循相应的开源协议，这要求贡献者有较强的版权意识（或许是这么说），较为了解开源协议，对于MIT、BSD等常见的开源协议，它们主要涉及的是哪些领域？这些协议是否具有法律效力？开源项目拥有者的利益被侵犯（如项目被公司等申请专利），是否能从法律层面维护自身的利益？