現在算是正兒八經地參與到開源專案來了。一個多月的適應和學習，現在已經漸漸瞭解和習慣開源專案的開發模式。
在實驗室寫程式碼，是不用考慮太多的，寫出的程式碼能用，能解決問題就好。這樣做的原因很多，一是工期有限，二是知識不到位，三是沒有支援，種種的限制讓人很難寫出滿意的東西來。程式碼基本都是不能反饋給上游的。
而真正參加到專案中來，有明確的實現目標，一開始就做好設計——必須要反饋給上游，郵件列表的支援和討論也很到位，所以做起事情雖然很累，反而還覺得舒服點。
過硬的程式碼能力是基本的要求，這個自不必多講。但是編碼沒有想像中的那麼重要，反而是一些設計上的取捨要花費大量的時間討論。一段程式碼為什麼要這樣寫不那樣寫，一個功能為什麼要這樣設計不那樣設計，一個介面為什麼要接受這個引數而不接受另外一個，這些討論上花費的時間是很多的。最後編碼的時間相對來說反而佔的比例不是很高。一般來說key developer的見解都非常到位，他們可以指出程式碼和設計中的種種問題，還會考慮到相容性、擴充套件性等等問題，和他們進行一番討論會獲益良多。不得不提的是，雖然key developer的意見比較重要，但是他們也不一定都是對的。作為開發者來說，大家完全是平等的，也不需要對他們完全盲從。
要引發高質量的討論，首先要拿出來的就是patch。開源專案的geek們更喜歡用程式碼說話。連原型都沒有就空談，一般大家都不會理睬的。 Linus說過“Talk is cheap. Show me the code.”大抵就是這個意思。一個patch，可能要根據討論的結果改好多次。幸運的話，大家表示沒意見了，不想再拍磚了，就有機會進倉庫了。這個時候應該最有成就感了。
所以總結一下，開源專案的發展就是靠大量的程式碼加上大量的討論來推動的。當然，真正趟過這灘水和只看不做，感受還是有所不同的。
再來聊聊工具。
一是版本控制工具。這個是軟體開發中的必備品了。現在開源專案越來越流行分散式的版本控制工具了，像Xen就提供了Mercurial和Git的倉庫。分散式的好處不言而喻，大家都可以專心於自己的程式碼，不用受限於中心倉庫。我個人比較偏好Git，用熟悉了基本的命令就不會有什麼大問題，高階的用法可玩性也很強。
二是編輯器。這個是個人喜好的問題，搞*NIX的人，無非就是Emacs或者Vim。我個人喜歡Emacs，因為它的縮排控制更加智慧，多 buffer支援也很方便；雖然一直被詬病體積大速度慢，但是這些問題在現在的機器上都不再是問題。Vim來寫核心程式碼還是可以的，但是寫Xen的程式碼有點難受。
三是郵件客戶端。收發大量郵件的話，一個趁手的email client必不可少。Gmail的Web GUI用起來方便，但是不合適提交patch。現在我用Evolution和Mutt，其他的一些客戶端可以看看Linux核心文件的email- clients.txt。
原文：Liuw