# 契約 在自由軟件項目中的契約需要小心處理。理想狀況下，你希望一個承包者的工作被社區接受并打包進入公共發布版本。在理論上，誰是承包者并不重要，只要他的作品足夠好并滿足項目的指導方針。理論和實踐一般也是一致的：一個通過貢獻好的補丁展示自己的完全陌生人通常能將代碼置入軟件當中。問題是，一個完全的陌生人很難為非瑣碎的改進或新的特性貢獻好的補丁；一個人必須首先和項目的其他人進行討論。討論的時間不能精確預測。如果承包者根據小時付費，你最終可能會付出超過預期的費用；如果他是通過總費用支付，那么他最終會做出超過承受能力的工作。 這里有兩種方式。較好的一個方法是根據以前的經驗，對討論過程的長度做出一個有根據的推測，并要考慮到出錯的延誤，并根據這些信息完成契約。這也有利于盡可能的將問題分離為許多小的獨立的區塊，增加每個區塊的可預測能力。另一個方法是為每一個發布的補丁單獨契約，然后將補丁的被接受當作公共項目一個獨立的事件。這樣編寫契約就可以很容易，但是只要你依賴這個軟件，或至少在這個補丁或對應功能進入主線的這些時間里，你必須承擔維護單個補丁的責任。當然，即使是你中意的方法，契約本身不能要求代碼必須可以接受補丁，因為那會包含出售一些不能銷售的東西。 （如果項目的余下成員不希望對這個特性提供支持？）然而，契約可以要求*真誠地*投入以獲得社區接受的機會，也就是在社區認可的情況下被提交到版本庫。例如，如果項目編寫了代碼變更的標準，契約可以參考這個標準并指明作品必須達標。在實踐中，這通常會超出每個人期望的方式。 最好的策略是雇傭項目的一個開發者—最好是提交者—作為承包者。這可以看作是購買影響力的一種形式。但是并不是表面上那樣的不道德。一個開發者對于項目的影響力主要取決于他的代碼質量和與其他開發者的交互。他作為承包者完成特定工作的舉動并不會提升他的狀態，當然也不會降低，盡管這樣會讓人們對他更加仔細的審視。大多數開發者不會因為返回不當或廣泛反對的新特性而讓自己的長期位置經受風險。實際上，當你雇傭一個這樣承包者時，一定程度上你會得到，或者說一定會得到一些關于哪些變更會被社區接受的忠告。項目的優先級也會得到些許轉變。因為優先級只與哪個人有時間完成哪個任務有關，當你為某人的時間支付時，會導致他們工作的優先級提前一些。這是經驗豐富的開源開發者都理解的一個事實，至少他們中的某些人會將精力投入到承包者的工作上，僅僅因為它看起來將要*完成*，所以他們希望去幫助正確完成。或許他們不會編寫任何代碼，但是他們還是會討論設計并評審代碼，這些都非常有用。出于以上原因，承包者最好是那些已經參與到項目的人。 這樣立刻凸顯了兩個問題：承包協議必須是私密的嗎？如果不是，你應當為你在社區中造成的不安而感到擔憂嗎？你為某些開發者提供了承包合同，為什么不是其他人呢？ 如果可以，最好將合同公開。否則，承包者的行為與社區中的其他人相比會看起來有些奇怪—或許他突然對一些過去從未表現出興趣的特性展示出了不可理解的高優先級。當人們詢問其原因時，他怎樣才能避免說出他是根據合同編寫代碼，同時回答的讓人信服。 與此同時，你和承包者都不應該表現的仿佛其他人應當把你的安排看得過重。我見過一些承包者招搖著進入開發列表，自認為他們的留言應該被更加鄭重的對待，僅僅因為他們是支付薪水的。那種態度也是對于項目其他人的一種信號，承包者看重合同這件事—而不是合同*導致*的代碼—本應當是重要的事情。但是從其他開發者的視角，只有代碼有意義。在任何時候，注意力應該保持在技術問題上，而不是誰給誰付薪水的細節。例如，Subversion社區的一個開發者用一種優雅的方式處理承包。當在IRC討論他的代碼變更時，他會在旁白（通常是在私有備注，一種IRC *privmsg*，發送給其他提交者）中提及他是被支付薪水完成特定bug或特性。但是他也一直表現出無論如何他都會作出那些變更的印象，并很高興金錢可以讓他完成那些工作。他可以表露客戶的身份，也可以不表露，但是無論怎樣，他沒有詳述合同。他關于此事的備注只是一個對于如何完成工作的另類技術討論的修飾。 那個例子也展示了開放承包合同帶來益處的另一個原因。會有多個組織為開源項目資助承包，如果他們都知道其他人的目標，他們可以更好的調配資源。在上面的例子中，項目最大的創建者（CollabNet）沒有以任何方式參與這種計件承包，但是當知道有人為某些bug修正提供資助時，CollabNet便將其資源轉向到了其他bug上，從整體上大大提高了項目的效率。 其他開發者會憎恨這些因為薪水而為項目工作的人嗎？通常情況下不會，這些得到支付的人都是社區值的尊敬的成員。沒有人會期待承包工作會公平的分發給所有的提交者。人們理解長期關系的重要性：從事承包的不確定性會導致一旦你發現某人值的信賴，你就不太會只是因為公平性而找其他人。可以這樣想一下：你第一次雇傭時，不會有抱怨，因為你必須*選出*某人—不能雇傭所有人不是你的錯。此后，當你第二次雇傭此人時，那只是常識：你已經了解了他，上一次是成功的，為什么要承擔不必要的風險？因此，只雇傭一個或兩個人，而不是將工作分散開，這是非常自然的。 ### 評審和接受變更 社區對于承包工作的成功也非常重要。他們為較大變更所投入的設計和評審過程不能只是事后處理。不應該把它當作工作的一個部分，并且完全交給承包者。不要把社區的仔細審查當作需要克服的障礙—而應該把它當作一個免費的設計委員會和QA部門。可以從攻擊性的追逐中獲益，而不僅僅是忍受。 ### 案例研究：CVS密碼認證協議 1995年，作為合伙人中的一個，我為CVS（并行版本系統，見[http://www.cvshome.org/](http://www.cvshome.org/)）提供支持和改進。我的搭檔Jim和我，當時在非正式的維護著CVS。但是我們沒有仔細考慮如何與已有的，主要是志愿者的CVS開發社區處理關系。我們只是假定他們會發送補丁，我們會應用補丁，那樣就會一切正常。 那時，網絡化的CVS還只能通過如`rsh`的遠程登錄程序完成。在CVS訪問時使用與登錄相同的密碼顯然存在安全風險，許多組織因此而放棄。一個主要的投資銀行雇傭我們來添加一個認證機制，這樣他們就可以使用網絡CVS安全的連接遠程辦公室。 Jim和我得到這個契約并坐下來設計新的認證系統。我們面臨的問題非常簡單（當時美國對于加密算法代碼有出口控制，所以客戶知道我們無法實現較強的加密），但是因為我們沒有設計這種協議的經驗，我們還是作出了許多對于專家來說非常明顯的錯誤。如果我們能夠花時間寫下提議并交給其他開發者評審，這些錯誤可以很容易的被發現。但是我們沒有這樣做，因為我們當時沒有把開發列表當作可以利用的資源。我們認為人們將會接受所有我們提交的東西，而且—因為我們不知道我們所不知道的—我們不愿意在眾目睽睽之下工作，例如頻繁發布補丁，在一個特殊的分支作出較小、簡單和易消化的提交等等。最后的認證協議并不是很好，當然，一旦建立起來，就很難在改進了，因為兼容性的考慮。 問題的根源是缺乏經驗，我們可以輕易的認識到我們需要的知識。問題是我們對志愿者開發社區的態度。我們將對變更的接受當成了跨越障礙，而不是變更可以被改進的一個過程。因為我們很自信我們所做的任何事情都幾乎會被接受（事實也是如此），所以放棄了讓其他人參與的努力。 很明顯，當你選了一個承包者，你一定希望他擁有此工作的正確技術技能和經驗。但是，同樣重要的是要選擇一個擁有與社區其他開發者有建設性交流歷史的人。你得到的不僅僅是一個人，也是一個代理人，他將會構建一套專業技能網絡以確保他是以健壯和可維護的方式完成的工作。