我們有一個非常酷的小型web框架，我們已經成功地使用了數十個客戶端項目。我們計劃將此軟件發佈給社區。然而，我正在絞盡腦汁想知道應該/不應該在新的開源軟件項目頁面上發佈什麼。網站必須具備哪些內容？文檔？維基？一個鏈接下載？還有什麼？發佈開源項目的最佳實踐是什麼？
而且，一個相關但可能不同的問題是我們如何開始標記版本號。我們在內部使用的是SVN郵票。是否有一種很好的方法來確定何時開始調用0.9版本與1.0版本和1.1版本等等？
你可以得到所需條件由什麼開源項目託管網站的想法提供：
至於版本號...我不認爲任何人的制定了這樣做，但:)隨着思想的最低限度的最好方式，我會考慮：
0.9/1.0/1.1/1.0.1/...版本標籤僅用於市場營銷目的（就其良好意義而言）。這可以讓您的用戶/客戶識別發佈版本是主要的，次要的還是錯誤修復的，以及您是否認爲它已經成熟或尚未成熟。
交付的最小數量是來源。其他交付物取決於您願意如何幫助您的用戶併爲他們提供支持。
看看GitHub或谷歌代碼。它們爲自己的開源項目提供了一個非常好的起點。您可以描述您的項目，在wiki中記錄文檔，使用git或svn作爲您的存儲庫，並提供下載以及問題跟蹤和多開發人員管理。開箱即可學習和使用它們的好環境。
對於發佈版本號：我不推薦0.9或類似的東西用於預發佈。原因？那麼版本1.9呢？它是主要發行版本1的第9次發行還是發行版本2的最後發行版？我的發佈標準在此描述：http://code.google.com/p/tideland-eas/wiki/ReleaseStandard。我正在使用三位數計劃，主要，次要和修復，以及狀態代碼，alpha，beta，gamma和發佈日期。所以我能夠輕鬆地並行處理多個版本。
希望這會有所幫助。
MUE
選擇一個網站主辦第一源（SourceForge上，例如）。使用匿名結賬在版本控制系統上獲取源代碼。在那裏獲取一個電子郵件地址供人們與您聯繫。
稱此第一個版本0.1。這是因爲您還沒有文檔來支持該項目。
然後呼吸。
然後開始查看文檔，如維基。一旦你掌握了所有的細節，並且你認爲這個版本已經準備好了一些黃金時間，然後轉向1.0，並開始提供二進制下載。
確保您考慮源代碼的許可證。
當我看到一個開源項目時，我檢查的第一件事就是許可證。如果許可證不是GPL2/GPL3/BSD風格或類似的，那對我來說就是一個激勵人心的問題。
許可證意味着人們將如何使用它，如何發展，以及發佈它的公司擁有多少。通過選擇開源，我儘量不依賴公司（依靠他們的股東），我真的選擇使用真正免費的軟件。
由於開源社區對企業權力非常敏感（谷歌目前似乎有點不受此限制），因此您必須確保在您的網站和其他材料上傳送真正免費的信息你發佈有關該軟件。
查看更多有關FSF的free software和open source的定義。
在版本控制上，我認爲從絕對最好的地方開始是Semantic Versioning。