用求全责备来形容可能比较贴切。有点小瑕疵总比没有好，所以对 R 包的作者应当有一定的包容可能更好点，毕竟人家辛辛苦苦开发出来免费分享给大家使用，太苛责就显得没良心了。当然，对于代码本身而言，严格一点也许是对的，我们都希望运行一个没有 bug 的程序，毕竟一个小小瑕疵如果放大成千上万倍（n 个用户每天运行 n 遍）就是大问题了，尤其是生产环境。

    yihui 原来R的稳定，和对作者的苛责也是有一定关系的，的确是很难去评判的事情啊。

      JinLi 下面是三张图是基于全部的日志数据，1997 年至今，约 25 年的原始代码提交日志数据

      近些年，瑞普利大人代码提交量不那么多了，毕竟 70+ 了。

      但论占比，还是最多的，不知后继何人？


      注：提交量很小的合并成 Others 了

        yihui 感觉益辉兄可以写本回忆录啥的，一定超级精彩。很多视角外人简直难以想象。

            说起来挺矛盾的：CRAN 上的包，一方面，我希望开发者能坚持长期维护，方便使用；另一方面，自己那几个不痛不痒的包却懒得维护，眼睁睁看他们逐个下架，随他去吧……

              对用户来说，现在接近 2 W 的 R 包如果能以砍掉一半的代价换来一倍的提升应该是好事。

                yihui
                你这长长的发言似乎搞混了两件事。一件事是手握权柄之人制定江湖规则应参照什么标准，或者往哪个方向倾斜，或行使何种威权。另一件事是有权之人做出了极大的贡献。

                    chuxinyuan 对于代码本身而言，严格一点也许是对的，我们都希望运行一个没有 bug 的程序

                    这话是对的，如果 CRAN 维护者也这样想的话，那就天下太平了。问题就在于，他们苛责的瑕疵很多真的就只是瑕疵，并非代码缺陷，完全不影响代码的正确性。举个简单并且困扰很多作者的例子：向 CRAN 提交包的时候它会检查包里面的所有超级链接，看看有没有死链接。这本来是一件极好极贴心的事情，可以让包的用户尽量少遇到死链接。然而，CRAN 把这件正确的事情做过了头，检查过于细致，对一些并非死链接的链接也报警，比如它不允许包里出现 301 重定向的链接。重定向是非常有用的技术，CRAN 自己也知道它很有用，并且它自己也用，比如 https://cran.r-project.org/package=markdown 这种 CRAN 称为“正统链接”（canonical link）就用了重定向。它可以用重定向，却不允许别人用重定向。说到这里，还有个相关的另一则令人哭笑不得的规定，就是如果你的包中出现了形如 https://cran.r-project.org/web/packages/markdown/index.html 的链接，那么检查的时候会报出警示，说这种链接应该用正统链接 https://cran.r-project.org/package=markdown。都特么是好好的可访问的链接，它非要巷子里赶猪一样，一会儿把你往这边赶，一会儿把你往那边赶。你说这么一点小破事，弄得大家鸡飞狗跳做啥。

                    这种鸡飞狗跳的事情每隔一阵就来一波，比如上个月它又开始苛责 C 函数的定义，强制要求没有参数的 C 函数需要加上 void 关键字。这种问题估计我们有生之年都不会真的见到它真正出问题。

                    罪与罚不成比例，是 CRAN 最大的问题。很多“罪”根本就不是罪，但罚是一定要罚的（下架）。上面 dapengde 和 Cloud2016 说的也有一定合理之处，那就是 CRAN 的包太多了，良莠不齐，CRAN 用这种苛责的方式可以砍掉那些质量不高、作者又没有精力维护的包。这应该算是件好事。能活下来的都是真爱。但有些真爱实在是受不了这种苛责，也一并被砍掉了，比如楼主提到的例子。还有些真爱，投入了很多时间写代码，但没有时间去打理那些鸡毛蒜皮的小问题，也被砍掉了。这些都是很可惜的。我个人比多数作者都幸运，因为我是全职做这事，不用担心时间不够，而且战斗经验也充足，所以只需要过滤掉情绪，就可以在 CRAN 上活得很好。那些业余时间写包的人就没这么幸运了。

                    yuanfan 嗯，是有点难扯开。一方面，有权之人做出了极大贡献，我们尊敬这贡献。另一方面，有权之人行使威权不当，我们觉得不对，希望可以商谈，但商谈的门太难打开。既然攻不进，只能先退一步求相互理解，还能咋办呢。我知道他们肯定也是受过无数次强攻，所以有点条件反射把门越关越紧，只能说这是正常人的正常反应。

                    其实还有一个办法，就是成立一个 CRAN 受伤者互助协会，大家暗地里吐槽，然后分享糊弄 CRAN 的技能，这样肯定可以让更多的包存活下来。写到这里，突然有种徐阶隐忍多年斗严嵩的感觉……

                    flujoo 哈哈，没这个胆。确切说也不是没这个胆，是要顾全大局。有些仗如果真打是可以打赢的，但赢了之后的结局马上就会是两败俱伤。单方面的（公开）说辞容易伤人，让事情更棘手。

                    其实两年前有一众作者起草了一封给 CRAN 的信呼吁改革： https://github.com/cranchange/cran_change.org/blob/main/letter.md 但我不知道这信最后发出去了没有。

                                yihui

                                其实还有一个办法，就是成立一个 CRAN 受伤者互助协会，大家暗地里吐槽，然后分享糊弄 CRAN 的技能，这样肯定可以让更多的包存活下来。写到这里，突然有种徐阶隐忍多年斗严嵩的感觉……

                                扯乎网，办起来。

                                  yihui
                                  这 R 江湖里面的事好适合当小说素材啊，人物都很有特点。

                                  容本新手问一句，是所有语言江湖的顶端管理者都像那位七十多岁老大爷一样顽固不化呢，还是只有 R 江湖一枝独秀？应该也还是有民主一点的社区存在吧。还好本新手只是新手，不会写 R 包，不然就算写了的话也多半要弃坑跑路。再不然的话就要跟益辉大神一样，被虐出双重思想来，心理上要不断地合理化极权者的种种行为，心态上要不断调整从难以忍受变成容易忍受，最终连忍都不算忍，于是达到共存共生的结果。

                                    R Core Team 对 GNU R 的修改和对 CRAN 政策的制定是很不容易的，必定是有一个基本原则在驱动。我主观上不太认同是某个人凌驾于制度之上，而有可能是制度本身赋予他极大的权利。那么，现在的问题是 20 年过去了，有不少开发者觉得制度对他们的时间和精力造成了伤害，希望制度做一些调整，这个沟通的渠道是否有？沟通机制是否平等？制度也是有生命的，我主观上相信 R Core Team 是愿意让制度越来越完善的。