一点小八卦——开发者和CRAN的矛盾？

JinLi 真想听吗？带着瓜子搬着板凳来，我可以给你讲三天三夜。我的第一个 CRAN 包发布于 2007 年的双十一，所以算来我是十五年的 CRAN 老油条了，早年间也被锐扑厉大人虐过若干次，导致我每次向 CRAN 提交更新时，心里都小鹿老鹿麋鹿驯鹿梅花鹿长颈鹿乱撞，生怕又犯了哪条 CRAN 王法。更可怕的是，有时候人在家中坐，祸从天上来，收到一封 CRAN 来信，说你某个包在 CRAN 上出了新问题，限期整改（目前的限期通常是两个星期之内），否则下架。说实话，这些新问题往往都是些无关痛痒、不影响功能的小问题，但 CRAN 似乎有些坚持完美主义（任何瑕疵都可能导致下架），而且一旦宣判，通常很难申辩。这些年我也学乖了，完全放弃申辩，一旦包有什么问题，二话不说立马跪着改。如果邮件是锐扑厉大人发来的，那么一定要道歉道歉再道歉（同时腹诽），要多卑微有多卑微，要多分裂有多分裂，哈哈。

算了，吐槽的话就不多说了，不然真的可以说三天三夜。锐扑厉大人是个很难评判的人，一边是巨大的贡献，一边是极难打交道的性格（主要是太苛责，说话太难听，总是让包的作者有很深的罪恶感，这种感觉真的让人太压抑了，最近我刚了解到一个相似的选手叫张婉婷，这两个人真的是让我觉得太有意思了）。经过这些年，我个人就把他视作一位病人了，这病其实是一种常见病，就是“正义的暴君”。嗨，其实又有谁不是病人呢，只不过可能每个人的病症不同、程度不同而已。我也当过正义的暴君啊。遇到锐扑厉大人这样的人，你只要把他的情绪字眼过滤掉就好了，就当他是三岁小孩、不知道他自己在讲什么吧（同样，有时候我也不知道我自己在讲什么啊，无心的话被人解读出巨大的恶意，也是有过若干次的）；对于他提出来的技术要求，能办的就办了，难办的就绕道走、糊弄一下。在糊弄 CRAN 方面，我自认为我已经成精了（坛友们要是遇到 CRAN 疑难杂症可以来咨询）。我个人感觉锐扑厉大人有某种严重的心理障碍，但我们也无能为力，况且已经是七老八十的老爷子，脾气个性来个一百八十度大转弯的可能性应该是比较小了吧（张婉婷的希望应该更大一些吧——如果吃瓜群众能把她当个病人、不急于网暴她的话）。

近几年锐扑厉大人已经比较少插手 CRAN 事务了，日常主要是 Uwe 和 Kurt 两人。CRAN 的维护确实是会消耗他们大量的精力，而且是无偿的志愿者工作，这其中的功劳、苦劳、疲劳我们都应该多多理解一下。绝大多数人都应该没有体验过管理一两万个包的日常（我猜这种经历可能容易让人偏执），所以可能也难以换位思考。据我的经历，Kurt 人挺好的，跟我沟通也还算流畅；以前我感觉 Uwe 有些苛责，但近两年似乎对我变好了，不知道为什么（是我的卑微见效了么）。总之呢，他们做的有些事情对不对呢？不对。是否不可原谅呢？也不是。他们的工作能不能改进呢？能。他们愿不愿意外界帮忙改进呢？不知道。为什么有时候我们好心好意提建议他们不搭理呢？不知道。沟通上存在大问题，但怎么解决？不知道。大家还能苟延残喘吗？似乎可以（虽然有不少作者已经弃权退场）。

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

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
这 R 江湖里面的事好适合当小说素材啊，人物都很有特点。

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

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