在this question 中，我提到了我的假设，即 rubyforge gems 比 github forks 更官方、权威和稳定。一位回答我问题的人说我的假设可能不准确。
你观察到了什么？人们是使用 github 提前发布并经常发布，只将稳定版本放在 rubyforge 上，还是因为其他原因（例如 rubyforge 更麻烦）而较少在 rubyforge 上发布？
更新：这个问题现在有点没有实际意义。 Github gems are defunct 和 rubyforge gems 将被移至 rubygems.org。
【问题讨论】：
据我所知没有区别。
这两种来源的宝石质量/稳定性差异很大。有些是坚如磐石的，有些是 pre-alpha 质量。
这真的取决于 gem 项目本身。
话虽如此，但 github 模型确实有助于更快地解决问题。派生项目、修复错误并将其提交回原始源中要容易得多。因此，至少在流行的项目中，错误得到更快地修复。所以也许这有助于项目更快成熟，但我不知道。
【讨论】：
我注意到，与 RubyForge 上 GEMS 的整体质量相比，通过 GitHub 发布的 GEM 质量有所下降。
恕我直言，这种行为至少有两个主要解释：
--
在 GitHub 之前，99% 的 Rubyist 都依赖于 Subversion。你可以说出你对 Subversion 的看法，但它绝对比 Git 更容易使用，而且每个人都知道 trunk/tags/branches 布局。然后人们开始转向 Git。只有极少数的 Subversion 用户开始使用 Git，并且具备应有的知识水平，而我注意到，人们开始忘记标签。
从前有标签。在 subversion 中，人们习惯于根据特定标签发布新版本，以便您可以轻松检测您安装的版本以及哪个是稳定分支。
现在我看到大量的库总是在 Git 主分支中开发。没有标签，没有稳定的分支。通常，当通过 RubyForge 发布库时，部署步骤会受到更高级别的关注。
--
GitHub 让发布步骤不再麻烦。也就是说，您只需将 gemspec 推送到您的存储库即可轻松发布新的 GEM。
在我看来，这种简单性可能会导致质量下降。更多技能较低的开发人员开始分发 GEMS，因为它就像使用 Jeweler（或类似的库）生成新项目并推送 git 存储库一样简单。他们对版本管理、向后兼容性、版本冲突、版本维护了解不多。
我经常遇到一个未完成的库打包为 GEM，只是因为开发人员忘记远程 .gemspec 文件。每次提交都会导致构建一个新的 GEM，但没有明显的连贯性和一致性。
我绝对赞成“经常发布”的做法，但前提是它是有意义的。 Git 提供了出色的分支支持，您无需将大量不相关的提交弄乱主分支并释放您称为库的未完成代码。
--
最后但同样重要的是，我最讨厌的可能是同一个 GEM 的无限复制。当 RubyForge 是无可争议的 GEM 源时，很容易找到并安装一个新项目。
恕我直言，GitHub 引入了不必要的复杂层。首先，您可以通过 rubyforge 以mygem 和通过 GitHub 以username-mygem 获得 GEM。您经常需要花时间弄清楚哪个 GEM 是最新的并掌握了主开发。
此外，一些流行的 GEM 不再在 RubyForge 上更新，许多人继续使用它们只是因为 RubyGems 没有通知您有关新版本的信息。很容易理解，如果您安装了 coolgem 1.2.4 版并且现在可以使用相同的库作为超级用户-coolgem（2.0 版），那么 RubyGems 不够聪明，无法告诉您有新的更新可用。
--
现在是免责声明的时候了。
我并不是说 GitHub 用户与 RubyForge 相比产生了糟糕的 GEMS。我是 GitHub 用户，之前我也是 RubyForge 用户。成千上万的 GEMS 成功地从 RubyForge 迁移到 GitHub，而不会让最终用户陷入“哪一个”的困境。
最好的示例 Rails，但我可以提及许多其他 GEM，包括（但不限于）Capistrano、Hpricot、RedCloth...所有这些库现在都托管在 GitHub 上，如果您仔细查看它们，您可以轻松识别与以前相同的质量水平。
最后但同样重要的是，所有这些库继续通过 RubyForge 作为主源发布，因此您无需重新配置环境来检测是否安装 rails-rails 或 rails。
此外，最终用户不受开发决策的影响。以 Capistrano 为例。几个月前，Jamis 宣布终止对开发的承诺。社区负责开发并将主存储库从 jamis/capistrano 移动到 capistrano/capistrano。如果 GEM 以 jamis-capistrano 的形式发布会怎样？所有用户都必须切换到新的 GEM 和新的存储库，非常麻烦。
这种情况从未出现过，因为 RubyForge 曾经并将继续是 Capistrano 的主要交付中心。
--
最后，不幸的是，我注意到 GEM 质量总体下降主要是由于更多人在没有必要知识水平的情况下使用 Ruby 和 RubyGems。这同样适用于大量 Rails 插件。
GitHub 不能被标记为罪魁祸首。当复杂的事情变得更容易并且更多的人在没有基础知识的情况下接近它们时，质量会降低是正常的，因为复杂性是自然选择的过程。
无论如何，Ruby 社区的质量仍然很高。看到 Ruby 开发人员如何致力于单元测试和其他专业的编程习惯，真是令人惊讶。
【讨论】：
可能不太稳定，但稍微更新一点 :) -r
【讨论】：
最后回答您的问题：您提到的两个资源（rubyforge、github）现在都已过时，因为 gemcutter 是 rubygems 的新的和唯一的地方。
Gemcutter 是新的官方默认 RubyGem 主机： http://www.rubyinside.com/gemcutter-is-the-new-official-default-rubygem-host-2659.html
【讨论】：