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 但我不知道这信最后发出去了没有。
