如何做乙個真正牛X 的開源專案

2021-06-16 23:19:09 字數 2366 閱讀 2904

如何做乙個真正牛x 的開源專案

近年來,越來越多的開發者選擇將自己的產品以開源形式發布,有時的結果是——你滿懷誠意地開源,卻無人問津。儘管你的產品做得相當好,但是僅把產品的源**公布出來,這還不算開源,因為其他使用者可能無從下手。沒有使用者,久而久之,你的滿腔熱情就會熄滅。

那麼如何才能讓開源專案為更多人所知,成為乙個真正牛x的開源專案呢?除了專案自身優秀外,你還需要注意以下事項。

一、有乙個真正有用的readme

1. 依賴、安裝資訊

盡可能寫清楚依賴、安裝資訊,最好能夠讓使用者通過複製貼上相關**來新增依賴。比如這樣。

2. 專案成熟度狀態

不至於讓使用者在生產環境中用了幾個月後才發現你的專案才處於alpha階段。

3. 詳細說明專案支援的語言、執行環境和工具的版本

不至於讓使用者花費大量的時間去摸索你的專案的相容性。

4. 明確所使用的許可證

這個許可證需要是流行的、使用者都知道的,如果你自己創造乙個或使用乙個陌生的(比如wtfpl),那麼沒有使用者敢於在自己的產品中使用你的開源專案的。你可以選擇比較友好的

apache public license 2.0或eclipse public license等。需要注意的是一些許可證(比如mit)也是比較流行的,但是沒有提供任何專利保護。你也可以採用apl2/gplv2雙許可,讓使用者挑選適合他們的。

二、為你的專案寫乙個文件

寫文件並不容易,且比較費時,但是對於使用者來說,文件是了解乙個專案最便捷、最省時的方式,還可以讓使用者相信你不會輕易放棄這個專案。

在文件中,把你的專案可以幫助使用者完成的事情放在首位,這是使用者決定是否使用這個專案的關鍵。此外,你要讓使用者相信做這個專案的是個人,而不是乙個會產生**的機械人。

關於開源專案文件,建議你閱讀:

開源專案文件應規避的13處「硬傷」

三、專案可以很容易地公升級

隨著專案中bug的修復和一些功能的改進,你需要發布另乙個版本。需要注意的是:

1. 向後相容

不要因為不向後相容,而讓使用者重寫大量**。這樣會讓使用者憤怒,繼而拋棄你的專案。當然,你也不必像openjdk那樣相容15年前的產品。

2. 更新日誌

有乙個清晰明確的更新日誌,需要包含:該版本發生了什麼變化?會破壞使用者現有專案的**嗎?等等。比如twitter的做法:

?每修復乙個bug,就在更新日誌中寫上乙個簡短的條目

?每新增乙個功能,就簡要描述一下並附上一些示例**

?每改變乙個api,就需要在日誌中用粗體明確指出

3. 版本標籤

為你的專案的每乙個版本打上乙個標籤,比如v1.0.0-alpha1、v1.0.0、v1.1.2,可以讓你的使用者很清晰地分辨出專案的版本。

4. 發布公告

專案發布後,接下來就需要為這個事件寫一篇博文,或直接將公告發布到專案的郵件列表中。

在公告中需要說明這個專案有什麼用,是否向後相容,並給出更新日誌的鏈結。

5. 專案狀態標籤

有些專案很長時間一直使用相同的版本號,比如1.1.0,而專案一直在改進。如果這是乙個開發版本,你也需要通過標籤來說明專案所處的開發階段。比如:

?1.1.0.pre1

?1.1.0-alpha1

?1.1.0-snapshot

總之,你要確保專案有乙個嚴格的版本命名規劃。

四、使用github

在github上,你可以很容易地做下面的事情:

?發布你的專案

?瀏覽和搜尋**

?專注於專案issues

?參與貢獻,合併使用者的貢獻

五、確保有乙個為使用者提供支援的地方

六、專案傳遞

不排除這種情況——你可能會對專案維護失去興趣,或者你換了乙個新工作不再使用當前的專案了。你可以在郵件列表上公布,讓其他開發者接管你的專案。在github上專案所有權轉移會更容易,尤其是在別人為你的專案引入了新功能後。

無論如何,不要讓專案死掉。

七、總結

總之,在你打算發布開源產品時,請確保它有:

?清晰的依賴/安裝說明

?至少有乙個簡短的文件/指南

?庫中包含更改日誌和相關標籤

?一些關於支援語言、執行環境、工具版本、專案成熟度的資訊

?郵件列表,供使用者提問、相互幫助

八、最後

總之,要想讓你的開源專案「發揚光大」,首先應該讓它對使用者更友好。除了專案文件外,其他事情花費不了多長時間。

另外,將專案開源出來容易,長時間維護就難了,因此,你還需要具備堅毅的精神和打持久戰的準備。當然,如果你只希望將專案開源出來,而不指望它能夠發展得多好,那麼你完全可以忽略以上的所有內容。

英文原文:how to make your open source project really awesome

如何做乙個真正牛X 的開源專案

近年來,越來越多的開發者選擇將自己的產品以開源形式發布,有時的結果是 你滿懷誠意地開源,卻無人問津。儘管你的產品做得相當好,但是僅把產品的源 公布出來,這還不算開源,因為其他使用者可能無從下手。沒有使用者,久而久之,你的滿腔熱情就會熄滅。那麼如何才能讓開源專案為更多人所知,成為乙個真正牛x的開源專案...

如何做乙個真正牛X的開源專案

近年來,越來越多的開發者選擇將自己的產品以開源形式發布,有時的結果是 你滿懷誠意地開源,卻無人問津。儘管你的產品做得相當好,但是僅把產品的源 公布出來,這還不算開源,因為其他使用者可能無從下手。沒有使用者,久而久之,你的滿腔熱情就會熄滅。那麼如何才能讓開源專案為更多人所知,成為乙個真正牛x的開源專案...

如何做乙個真正牛X 的開源專案

近年來,越來越多的開發者選擇將自己的產品以開源形式發布,有時的結果是 你滿懷誠意地開源,卻無人問津。儘管你的產品做得相當好,但是僅把產品的源 公布出來,這還不算開源,因為其他使用者可能無從下手。沒有使用者,久而久之,你的滿腔熱情就會熄滅。那麼如何才能讓開源專案為更多人所知,成為乙個真正牛x的開源專案...