在this question中，我提到了我的假設，即rubyforge寶石比github forks更官方，權威，更穩定。其中一位回答我的問題的人說，我的假設可能不準確。github寶石是否比rubyforge寶石更穩定？
你觀察到了什麼？人們是否經常使用github來提前發佈和發佈，只是在rubyforge上放置穩定的版本，或者其他原因（比如rubyforge更麻煩）在rubyforge上發佈的頻率較低？
更新：這個問題現在有點沒有實際意義。 Github gems are defunct和rubyforge gems將被移到rubygems.org。
據我所知，沒有區別。
來自兩個來源的寶石質量/穩定性有很大的範圍。有些是堅如磐石的，有些則是前alpha質量。
這真的取決於寶石項目本身。
儘管如此，github模型確實適用於更快速地解決問題。分叉一個項目，修復一個bug，然後將其提交回來以包含在原始源代碼中更容易。所以至少在受歡迎的項目中，bug可以更快地修復。所以也許這有助於項目更快成熟，但我不知道。
我注意到，通過GitHub發佈的GEM質量與RubyForge的GEMS的整體質量相比有所下降。
恕我直言，這是你的行爲至少有兩個主要解釋：
-
此前的GitHub Rubyist的99％，是顛覆依賴性。你可以說你想要的Subversion，但與Git相比，它確實更容易使用，並且每個人都知道trunk/tags/branches佈局。然後人們開始轉向Git。只有超過一小部分的Subversion用戶開始使用Git，其應該具備的知識水平，我注意到的是人們開始忘記標籤。
曾幾何時有標籤。在Subversion中，人們習慣於根據特定的標籤發佈新版本，這樣您就可以輕鬆檢測出您安裝的版本以及穩定的分支。
現在我看到大量的庫總是在Git master分支中開發。沒有標籤，沒有穩定的分支。通常，當通過RubyForge發佈的庫對於部署步驟有更高的關注度時。
-
GitHub上是沒有的發佈步驟更麻煩。也就是說，您可以輕鬆發佈新的GEM，只需將gemspec推入您的存儲庫。
在我看來，這種簡單性可能會導致質量下降。更多的技能較低的開發者開始分發GEMS，因爲它很容易與珠寶商（或類似的庫）生成一個新項目並推送一個git倉庫。他們對發佈管理，向後兼容，發佈顛簸，發佈維護知之甚少。
我經常遇到一個未完成的庫，打包成一個GEM，只是因爲開發人員忘記遠程.gemspec文件。每次提交都會導致創建一個新的創業板，但沒有明顯的一致性和一致性。
我絕對贊成「經常發佈」的做法，但當它是有道理的。 Git提供了出色的分支支持，您不需要用大量不相關的提交來混亂主分支，並釋放您稱爲庫的未完成的代碼片段。
-
最後但並非最不重要的，我大概最討厭的就是同一個GEM的無限重複。當RubyForge是不受質疑的創業板資源時，很容易找到並安裝一個新項目。
恕我直言，GitHub引入了一個不必要的複雜層。首先，你的GEM都可以通過rubyforge作爲mygem，並通過GitHub作爲username-mygem。你經常需要花時間去弄清楚哪一個創業板是最新的，並持有主發展。
此外，一些流行的GEM不再更新RubyForge，許多人繼續使用它們，因爲RubyGems沒有通知您有關新版本。易於理解的是，如果您安裝coolgem版本1.2.4，並且現在以superuser-coolgem（版本2.0）的形式提供相同的庫，那麼RubyGems不夠聰明，無法告訴您有新的更新可用。
-
現在該發佈免責聲明。
我並不是說GitHub用戶生產蹩腳的GEMS與RubyForge相比。我是GitHub用戶，之前我也是RubyForge用戶。成千上萬的GEMS從RubyForge成功遷移到GitHub，而不會讓最終用戶陷入「哪一個」的困境。
最好的例子Rails，但我可以提到許多其他GEM包括（但不限於）Capistrano，Hpricot，RedCloth ......所有這些庫現在都託管在GitHub上，如果仔細看看它們，您可以輕鬆識別與之前相同的質量水平。
最後但並非最不重要的是，所有這些庫繼續作爲主源碼通過RubyForge發佈，因此您不需要重新配置環境以檢測是否安裝rails-rails或rails。
此外，最終用戶不受開發決策的影響。以卡皮斯特拉諾爲例。幾個月前，Jamis宣佈終止對開發的承諾。社區負責開發工作並將主資源庫從jamis/capistrano移至capistrano/capistrano。如果創業板以jamis-capistrano的形式發行，會發生什麼？所有的用戶將不得不切換到新的創業板和新的倉庫，很多麻煩。
這種情況從來沒有出現過，因爲RubyForge是並且仍然是主要的Capistrano交付中心。
-
總之，我不幸注意到創業板的質量主要是由更多的人接近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
這不回答你的問題，但在題爲「不要忘記RubyForge的」博客文章（http://judofyr.net/posts/ dont-forget-about-rubyforge.html），作者談論瞭如何使用Rubyforge gem服務器進行常規發佈，以及關於使用github作爲gem服務器的一些麻煩。 – RFelix 2009-07-12 11:15:46