热榜看到的来挖个坟
#19 提到的社区问题，我本来想说的是个人开源社区相对会比较乱，相比来说大公司开源社区至少表面上会更和谐——成员部分代表公司形象，真闹出事情是可能要出 PR 问题的。点进去看了一点发现这个角度根本不适用，因为这个例子就是正常任何开源项目都有的日常扯皮——或者说是任何社会都有的日常扯皮。
当然我只看了几楼，因为 #19 所说的“PR 原作者” dissent1@GitHub 在 issue 里只是在开头发了有限的几个回复就脱离了，后面都是其他的调试过程。dissent1 基本上只是表达了“WAR over WAR”的观点，以及提供了一些 fix 问题的附加信息。并没有感觉到 dissent1 的态度比 #19 要差，也没有出现 #19 回复中“你干嘛碰我代码?”和感叹号这种强烈的情绪表达。但是看得出来双方都跟社区主流开发者不太合拍。
整个 thread 中的感叹号只会出现在两种场景："Thanks!" 和 shebang 。总体氛围还是非常亲切友好的。
解释一下这个"WAR over WAR"：“WAR”似乎是某种黑话，是 Workaround 的意思。这黑话可能是 OpenWrt 社区专属的，但我觉得更像是 dissent1 个人的，从没在其他地方见过。不过英语 native 普遍喜欢 TLA (Three-Letter Acronym) 是真的，我在单位的 acronym 数据库里面真找到了这个用法 ... 虽然真没见有人用过。
情况大概是 dissent1 原本的 patch 是有问题的——没有解决任何问题反而引入了新的问题（这个 patch 本身似乎是以一种“WAR”的方式试图解决问题，但是这个 WAR 本身又没做对）。#19 希望将其 revert （"WAR over WAR"）。而包括 dissent1 在内的社区开发者则认为不着急 revert ，而应该以“proper”的方式来 fix 。（另外这种和硬件（或其他具体环境）相关的项目的一个现实问题是经常出现开发者不具备特定的条件所以测试比较麻烦的情况）
社区的理由是原 patch 已经进了 release 很长时间，而在一个没人会日常用的允许不稳定的 dev 分支里，相对于直接 revert ，不如去“proper”地 fix——除非在下一次大版本发布之前找不到一个“proper”的方法。社区开发者 981213 和 ynezz ，在要求 #19 提供规定所需的签名后，主动把 Revert 加到了 OpenWrt 18.06.3 的小版本更新分支里面了（上一个版本 OpenWrt 18.06.2 是 1 月发布的，18.06.3 是 7 月发布的，楼主的 PR 是 5 月提的，revert 进分支是 6 月的事）。
然后 TA 们试了半天似乎找不出个“proper”的方法，所以暂时只能 revert 。（很长时间后似乎有人解决了个相关的问题，是不是彻底把问题解决了就不清楚了）
从我个人的角度我认为双方都是有一定道理的。有些项目确实 patch 出问题就要直接 revert ，部分是因为开发工作严重依赖全自动的测试，然后就有测试结果全 clean 的追求，只要 break 了测试的 patch ，哪怕是在 dev 分支，也会给别人造成麻烦。但是如果社区认为问题不对开发工作造成障碍的话，跳过 revert 而优先寻找解决方案也是可以理解的。
我觉得这个事情就是不同的社区的规矩和习惯不一样而已。倒是 #19 难以接受其他人与其观点不同，先是在 forum 里，又在 V 站阴阳怪气人家，真心显得有点小家子气。
至少从这个 issue 而言整体还是比较平等的，用户不熟悉规矩，开发者会耐心地解释（开发者的长度基本都和 #19 类似或更长，甚至有个别长篇大论），用户也会帮助开发者测试。要真说成熟的多方平等合作的开源社区有啥问题的话，大概就是没有一言堂，没人说了算（甚至这种项目会出现开发者求用户帮着测试的情况），没有领导按着你头说必须怎么干，所以大家都不知道该怎么干，扯皮出的解决方案总免不了有人看着有问题，然后自己又没能力改变，还不能给自己一个“老板已经拍板了”的接口当安慰剂。
当然这仅限于“多方平等合作”的项目，开源项目的开发工作本质上是垄断的——垄断成本很低，你自己 fork 一个就是（有没有人用两说了）。我开始说大公司至少表面上会比较友好，另一面嘛 ... 举个例子，我前两天说过的 ROCm ，
https://github.com/RadeonOpenCompute/ROCm/issues/887 这个 issue 里面 Rmalavally 代表官方给出了最“友好”的回复，大家的反应友不友好就不好说了。