參與開源專案，可以快速提高自己的技術水平，學到很多學校中學不到但在工作中會非常有幫助的技巧。乙份參與過開源專案的履歷，也越來越受到用人單位 的重視。所以最近幾年，我們技術愛好者對開源專案投入的關注是越來越多了。可仍會看到很多對開源專案充滿興趣和熱情的同學，用了錯誤的方式方法以至於不得 其門而入。這段時間我特意將自己的心得整理了一下，供愛好者參考。
絕大部分面向公眾開放的開源專案都有issue區或者bug tracker。所謂issue區，也就是問題彙總。對專案有興趣的愛好者，與其漫無目的開始，不如在issue/bug中先找到乙個自己感興趣的小問題，作為第乙個目標並嘗試解決它。
patch又叫做補丁。是用來修補**的文字檔案。乙個典型的patch檔案例如:
--- clinkcc.orig/configure.in 2005-11-14 18:08:07.000000000 +0100
+++ clinkcc/configure.in 2005-11-14 18:08:13.000000000 +0100
@@ -150,6 +150,7 @@
ac_check_funcs([iconv])
+am_iconv
diff -u oldfile newfile > mods.diff
通過小巧的patch，專案管理者可以快速的看到修訂內容並進行評估。如果沒有patch，專案管理者就很難對修改做出是否可用的判斷。所以為了不浪費雙方的時間，掌握製作patch的專業技巧也是必須的。
開源專案中使用的版本管理系統的種類越來越多。除了被淘汰的cvs、傳統主流的svn，新的版本管理體系例如git和mercutial(hg)越 來越流行。系統越來越多，確實增加了開發者的學習成本。但也只有掌握版本管理系統，才有可能和其他專案開發者並行開發並進行友好的協作。因此在完成第乙個 issue的階段，也是摸熟版本管理工具的好時機，要好好把握。
現代的各大開源專案對**規範的要求越來越嚴格。在幾十人以上和近百萬行**的專案中，必須依賴**規範來保證**的可讀性。所以在撰寫**時，一定要注意是否符合該專案中對**規範的要求，以免被退票。
當有一些可能帶來重大改變的想法時，務必要先和專案管理者保持良好的溝通。通過email或郵件列表或irc將你的想法描述清楚。獲得專案管理者和 專案中其他開發者的認同和幫助是乙個關鍵。附帶提一句，初次聯絡時，務必不要忘記自我介紹，這並不僅僅是禮貌，更是建立信任的主要基礎。
通過積累patch和建立信任的階段之後，通常管理者都會主動邀請你成為固定的開發成員。對於這個問題，我的建議是保持良好的心態，該來的自然會來。
fork是我認為很難翻譯的詞。fork的原意就是餐具中的叉子，沒有任何褒貶的傾向。在開發者的世界，可以將它理解為師出同源的幾個叉子尖。當你 對專案有乙個「狂野」的想法時，專案管理者可能並不願意在專案中看到這樣的實驗性分支。這時就可以fork乙個分支專案，來實現自己的想法。尤其是git 和hg大流行的背景下，fork後再merge back變得很容易，所以fork對專案的維護負擔也減小變得更容易被接受。
絕大部分參與開源專案的開發者都是利用業餘時間來撰寫**的。所以良好的時間管理，才能幫助你有效的達成目標。近年來開源專案的技術規格越來越高， 有乙個預先制定的時間表，更能幫助你準備好乙個良好的心態而不至半途而廢。只要用心和持之以恆，你就會受到關注和尊重，甚至是雇主的重新評估乃至嘉許。
如何加入開源專案的小手冊
參與開源專案，可以快速提高自己的技術水平，學到很多學校中學不到但在工作中會非常有幫助的技巧。乙份參與過開源專案的履歷，也越來越受到用人單位的重視。所以最近幾年，我們技術愛好者對開源專案投入的關注是越來越多了。可仍會看到很多對開源專案充滿興趣和熱情的同學，用了錯誤的方式方法以至於不得其門而入。這段時間...
開源專案的質量警鐘
開源專案越來越多的進入我們的視線，然而，關於開源專案的質量問題卻無人問津。前一陣子，我和一位同時討論關於開源專案質量安全的問題。他支援使用開源專案的原因很簡單，開源專案的參與者都是 高手 在他心目中何所謂高手，我無從可知，但是這種觀點的支持者卻大有人在。在google上以 開源專案 和 質量保障 為...
optee開源專案的學習
因為研究生階段選的是trustzone的研究方向，所以最近在一直看這方面的東西。前不久在github上找到這個optee的開源專案，於是fork來學習一下。發現optee有4個專案 optee os 包含了tee作業系統本身的源 提供了tee的內部介面。optee client 包含了tee客戶端庫...