# 資助非編程活動 編程只是開源項目的所有工作的一部分。從項目志愿者的視角，這是最明顯和迷人的部分。很不幸，這意味著其他活動，例如文檔、正式測試等等，是可以忽略的，至少與私有軟件相比，投入了更少的精力。公司組織有時可以彌補這件事，通過投入一些他們內部軟件開發時的基礎架構到開源項目。 在公司內部過程和公共開發社區之間的轉換是成功的關鍵。不過這種轉換也不是輕而易舉的：通常二者并不是一場接近的比賽，這種區別只能通過人為干預連接起來。例如，公司會使用與公共項目不同的bug跟蹤系統。即使使用相同的跟蹤軟件，其中存放的數據也會大不相同，因為一個公司需要的bug跟蹤與自由軟件社區完全不同。位于某一跟蹤系統的信息在映射到另一個系統時，必然要刪除機密部分，從另一個方向來說，則是要添加。 本小節余下部分關于如何構建和維護這種聯系。最后的結果必定是開源軟件運行的更加平滑，社區會認可公司對于資源的投資，也不會感到公司掌控事情往自己的目標發展有什么不適合。 ### 質量保證（也成為專業測試） 在私有軟件開發中，一般都有一組人專注于質量保證：尋找bug、性能和擴展性測試、接口和文檔檢查等等。作為一般的原則，此類活動一般不會被自由軟件項目的志愿者社區積極的追求。部分原因是很難為測試之類的不起眼工作找到志愿者，也因為人們總是假定他們有一個大的用戶社區，可以給項目好的測試覆蓋，以及性能和擴展性測試，也因為志愿者經常無法使用必要的硬件資源。 有很多用戶等價于有許多測試者的假設并不成立。誠然，有時候分配測試者在普通環境中進行基本功能測試有一點用處：bug會在用戶的日常操作中迅速被發現。但是因為用戶只是期望把事情完成，他們不會有意識的開始探索程序未知的最新功能。此外，當他們在一個簡單的場景發現了一個bug，他們經常悄悄的實現這個場景，而不會去報告這個bug。大多數沒有意識到，你的客戶（驅使*你*進行軟件開發的人）對于軟件的使用模式會與普通用戶的使用模式在統計學上有顯著的不同。 專業的測試團隊可以迅速發現此類bug，和他們在私有軟件時一樣容易。真正的挑戰是將測試團隊的結果以有用的形式反饋給公眾。在內部測試部門中，通常有自己報告測試結果的方法，也需要使用公司特定的術語，或與特定客戶和他們數據集相關的專業知識。這種報告對于公共bug跟蹤并不適合，一方面是因為其格式，另一方面是因為機密性。即使你公司的內部bug跟蹤軟件與公共項目相同，仍然需要對此問題發生的公司特定的評論和元數據變更進行管理（例如，提升某個問題的內部等級，或者設定其為特定客戶進行解決）。通常情況下，這些注釋是機密的—有時候他們甚至不會展示給客戶。但是即使沒有機密，他們對于公共項目也沒有意義，因此公眾不想因此分散注意力。 核心bug報告本身對于公眾*非常*重要。實際上，來自測試團隊的bug報告會比普通用戶的報告更有價值，因為測試團隊是在為發現問題進行探測，而普通用戶不是。因為你不太可能從任何其他來源獲取這樣的bug報告，你一定希望將其保留并發布給公眾。 為此，如果他們愿意，或者可以將內部測試報告的問題轉化到公共跟蹤系統中，QA部門可以在公共問題跟蹤系統中歸檔問題。轉化僅僅意味著使用不涉及用戶特定信息（重現的處方會使用用戶數據，當然要假定用戶對此認可）的方式描述bug。 推薦讓QA部門在公共跟蹤系統直接填寫問題。這樣會讓公眾對你公司的投入更加感激：有用的bug報告和技術貢獻一樣會增加你的組織的信譽。這樣也給了開發者一個與測試團隊直接交流的渠道。例如，如果內部QA團隊監控著公共問題跟蹤系統，一個開發者可以為一個可量測bug（開發者沒有資源自己測試）提交修正，并為該問題提交一個說明詢問QA團隊查看該修正是否起到了預期的效果。也許會遇到一些開發者的抵制；最好情況下，程序員會把QA當作必要的魔鬼。通過發現顯著的bug，填寫復雜的報告，QA團隊可以輕易的達到這個目標；另一方面，如果他們的報告甚至沒有來自普通用戶社區的報告質量高，那么讓他們與開發團隊直接交流也沒有什么意義。 無論哪一種方法，一旦公共問題已經存在，原來的內部問題就應當在技術內容中引用公共問題。管理層和有薪開發者根據需要，或許可以繼續關注包含公司特定注釋的內部問題，但是使用公共問題可以讓所有人看到對應的信息。 你應當會預期有額外的成本。維護一個bug的兩個問題，將會比一個時耗費更多的工作。好處是，將有更多的程序員將會看到這個報告，并且能為這個解決方案作出貢獻。 ### 法律建議和保護 公司，無論是盈利或非贏利，恐怕是唯一在自由軟件中將精力投入到法律問題上的實體。單個開發者通常理解多種開源許可證的微妙，但他們沒有時間和資源去對版權、商標和版權法進行詳細研究。如果你的公司擁有法律部門，可以通過否決代碼的版權狀態來幫助項目，并可以幫助開發者理解可能的版權和商標問題。如何幫助的具體形式將會在[Chapter?9, *許可證，版權和專利*](# "Chapter?9.?許可證，版權和專利")討論。主要是確保法律部門和開發社區的交流，如果發生這種交流，主要是因為完全不同的雙方都有相互的渴望。在偶然情況下，這兩組人會互相討論，每一方會假定擁有另一方沒有的領域特定知識。一個好的策略是在中間設定一個聯絡，在任何需要的時候進行轉化。 ### 文檔和可用性 文檔和可用性都是開源項目著名的軟肋，盡管我認為，在文檔方面，自由和私有軟件的差距被夸大了。然而根據經驗，大多數開源軟件缺乏一流的文檔和可用性研究。 如果你的組織希望為一個項目彌補這個差距，最好雇傭一些*不屬于*項目常規開發者，但可以與開發者進行有效率交流的人。不雇傭開發者有兩個原因：首先，你不會從項目帶走開發時間；其次，距離項目過近的人通常不是編寫文檔或研究可用性的最佳人選，他們很難從外部視角觀察軟件。 然而，從事該工作的人還是有必要與開發者進行交流。找到的人需要擁有與編碼團隊交流的技能，但不必對軟件過于專業而無法移情于普通用戶。 一個中等用戶很可能是編寫好文檔的合適人選。實際上，本書發行第一版后，我收到開源開發者Dirk Reiners的一封電子郵件： ~~~ 關于金錢::文檔和可用性的一些意見：當我們要花一些錢 并決定我們最需要的是編寫初學者教程時，我們雇傭了一 個中級用戶。他剛剛經歷了系統的入門，所以能夠記住問題 ，但是因為已經通過問題，所以他知道如何描述問題。這樣 他就可以編寫一些只需由核心開發者進行少量修正的內容， 同時還是會覆蓋開發組會認為‘非常明顯的’而遺漏的內容。 他的案例甚至更好，隨著他的工作，引入了許多用戶（學 生）進入系統，所以他組合了許多人的經驗，有時候某些事 看起來只是好運當頭，恐怕不是在任何情況下都有效。 ~~~ ### 提供主機/帶寬 對于不使用包裝主機的站點（見[Chapter?3, *技術基礎設施*](# "Chapter?3.?技術基礎設施")的[the section called “包裝主機”](# "包裝主機")），提供服務器和網絡連接—以及更重要的系統管理幫助—會是重要的輔助。即使這是你的組織為項目所做的唯一工作，也是一種獲取公共關系回報的適度有效的方法，盡管，它不會帶來任何對于項目方向的影響。 你可能會在項目主頁發現一個廣告條或致謝，用以感謝提供主機的公司。如果你通過設置主機，讓項目網址位于公司域名之下，那么單純通過URL你就獲得了額外的聯系。這會導致大多數用戶認為軟件與你的公司有關，即使沒有在開發中作出任何貢獻。問題是，開發者也會意識到這種關聯的趨勢，會對項目位于你的領域感到不適，除非你能貢獻出除帶寬以外的更多資源。畢竟，現在有很多存放主機的地方。社區會最終感覺到這種隱含信用分化與主機帶來的便利并不相配，并將項目帶到別的地方。所以，如果你希望提供主機，要這樣做—不但要計劃投入更多，更要細心的考慮聲明投入多少。