我不认为这是一个特定于 R 的问题。真正的问题是：你能相信别人的代码吗？或者，换个角度看：你认为你可以做得更好吗？（在您愿意/能够花费的时间）

软件是开源的还是闭源的，并不重要。与商业软件相比，开源软件的可信度是一个备受争议的话题。存在有利于讨论的任何一方的论点。没有人可以反驳说两者都可以（并且确实）包含各种性质的错误，其中一些比其他的更阴险。

TL; DR：在我看来：是的，如果它们满足您的需求，可以使用现有的包。

一般来说，我的座右铭是如果以下各种情况属实，则尝试自己实现一些东西：

1. 我确切地知道我想要什么以及如何去做（这对于许多实用模型来说远非微不足道）。
2. 与已经存在的代码相比，实现和测试我自己的代码所需的时间是值得的。换句话说：我会经常使用它还是只使用一次？
3. 已经存在的并不能提供我需要的所有功能。
4. 我有充分的理由不信任现有的实现（例如使用它时的意外行为）。

就个人而言，我喜欢、使用和开发很多开源，因为我认为这很重要，尤其是在学术环境中。在实践中，许多人只考虑在实现可用的情况下使用给定的算法。没有人会从同一事物的大量实现中受益。处理给定方法的一种有效的、经过彻底测试和验证的实现要好得多。

人们喜欢相信，如果我自己做，我就知道做的很好。实践经常与此相矛盾。

并非每个 R 包都是在学术环境中创建的

我不知道您为什么觉得学者创建的软件包更优越。当然，该方法本身可能更复杂/新颖，但所有关于实施的赌注都没有。研究人员不一定是最好的程序员（事实上，鉴于这通常不是他们的专长，我会说相反的可能性更大）。

在实践中，研究人员经常将解决方案组合在一起，有时没有进行彻底的测试。自然，这会导致各种糟糕的结果（最明显的是静默失败）。就个人而言，我认为这种行为的原因之一是软件输出在研究环境中被低估了。一些研究人员只是急于下一个出版物。结果的发布很重要，用于获取结果的软件并不重要。当人们重新发明轮子以供一次性使用时，这会导致软件没有经过正确测试。

我们如何使用开源而不冒结果失败的风险？

你不能。这也适用于商业软件和您自己编写的软件。如果您碰巧找到了确保软件没有错误或警告的方法，您应该立即与比尔盖茨预约（或者更好的是，告诉我）。

唯一的解决方案是对每一步的结果进行批判性评估。永远不要无条件地信任软件，不管它是什么软件。

一般包装和 R 是否有某些质量指标？

通常，公开可用的软件包（例如在 CRAN 上）已经过严格的测试，尤其是那些经常使用的软件包。当他们的可信度受到威胁时，人们会在公开未经测试的垃圾之前三思而后行。除了活跃的发展社区之外，引用次数也可以被视为质量指标。