| 作者：Nick Ke
| 翻譯：徐紅偉
| 編輯：舒敏
日期：2017年3月6日
我在 1990 年代開始工作于一系列 Web 應用程式，其中第一個在我當時的工作場所内部，它為衛星圖像資料的日常處理、存檔和分發提供操作員界面；第二個是現在稱為社交媒體的應用程式的前身，這也是我第一次使用 Apache 伺服器。Apache HTTPD 2.0 的釋出使我從伺服器使用者變成開發者：部分原因是我需要重新實作一些現有功能，但更令人興奮的是因為我看到伺服器本身成為應用程式的強大平台的巨大潛力。這使我開始研究核心軟體，并與 Apache 社群進行互動，同時釋出我自己的子產品和文檔。2003年，我首次在 ApacheCon 做了演講，之後的某個時間作為送出者首次被邀請進入基金會，并于2005年成為會員。從那時起，我的興趣不僅包括 Web 伺服器和相關項目，還包括 Apache 社群的發展以及其動态。我通過孵化器參與了幾個項目的指導。如果你今天要問我最想實作的一個目标，那麼它就是一個身份管理架構，它不僅在加密方面很強大，而且對于世界來說足夠友善使用，并且可以抵禦網絡釣魚等社會工程攻擊。同時，它不涉及任何動機不純的中心化權力機構（如政府）。它會終結身份欺詐和密碼管理的噩夢。
關于 Apache 之道，已經有了很多的相關文章。它通常關注社群的重要性，以及項目治理的民主化和精英化元素。關于 Apache 項目的正式管理機構，項目管理委員會（ PMC ）的作用，由社群根據貢獻記錄和建設性參與而選出的貢獻者組成。
在實踐中，PMC 的角色很大程度上是被動反應式的。諸如 “我們的項目從這裡走向何方” 這樣的有趣的大問題在公開場合進行了讨論，來自更廣泛社群的意見是非常受歡迎的。許多細節部分取決于社群的需求，通過收到和看到的回報以及個體開發者的需求來衡量。後者通常被描述為 “撓你自己的癢”。
抛開純粹的被動反應，事情的實際發展方向通常是由開發者的工作來決定，而不是由任何宏偉的計劃決定。如果你幹了具體的活，那麼實際上是你控制事情的發展方向。如果您需要某些東西，那就去實作它。這種方式偶爾用笨拙的英語-希臘語混合詞 “ do-ocracy ” （“幹活者掌權”——譯者注）來描述。我将其稱為 “ Pratocracy ”，即“創客法則”。它既适用于 Apache 核心團隊，也适用于更廣泛的社群。
那麼 Pratocratic 項目如何運作？它如何避免"通天塔"（《聖經》中的故事，世人想要建立通往天堂的高塔，上帝知道後打亂世人的語言，讓他們彼此聽不懂對方，導緻通天塔計劃失敗——譯者注）式的混亂？它如何保持凝聚力和專注力？如果一個 Apache 項目看起來是您公司所需求内容的良好基礎，那麼您如何依 Pratocracy 原則完美地實作您的目标呢？
先說第一個問題，Partocracy 是如何工作的？Eric Raymond 提出了教堂和集市的對比理論：即傳統項目的專制和自由生态的差別。集市生态本質上是達爾文進化論形式的結果，其中最強的項目能夠繁榮和發展，而長尾類型的項目則會被遺忘，因為他們的開發者會轉向新事物。
Apache 的各種流程是為了確定我們的項目能夠成為生态系統中的赢家。一個 Apache 項目是從孵化過程中畢業的項目，孵化過程要求它建立一個廣泛的開發社群，具有足夠的多樣性，以確定它不僅能夠在關鍵人員流失後繼續生存，甚至是能夠在該項目的創始團隊解散後依然繼續生存。 關鍵原則是，如果社群健康，軟體就會健康。
是以，Pratocracy 的營運環境是有選擇性的：它是 Apache 著名的精英治理（ Meritocracy ）元素。核心社群的成員是根據其已展現出的對項目的明确承諾而選出的。這意味着他們了解 Apache 工作與公司工作之間的差別，能夠自在地處理好多重效忠，并能解決或避免它們之間的潛在沖突。
是以，回到最關鍵的問題：假設我發現了一個 Apache 項目，它不能完全滿足我公司的需求，但是可以作為我們公司項目的基礎，那麼我應該如何依據 Pratocracy 原則來實作它呢？
讓我們來考慮如下可能的方法：
- 通過開發清單和問題資料庫來進行咨詢。
- 單獨聯系開發者來讨論該項目。
- 直接與公司内部的開發人員合作開幹。
這些方法中的每一種都有其自身的優點。但在許多情況下，理想的方法将涵蓋所有上述内容。在 Apache 社群中，整體大于各部分的總和。您越接近社群，您獲得的好處就越多，特别是當您發現自己項目希望與 Apache 項目更深入地內建，而不是僅僅利用公開提供的穩定的公共接口；如果你不與社群緊密合作，反而選擇自行修補核心元件，那麼你就必須承擔因而産生的維護噩夢與風險。另一方面，有一些好的和壞的方式與 Apache 社群合作：正确的方法可以使您從中獲得的好處發揮重要作用。
首先，說明你的需求非常重要。向項目清單或問題清單提出關于你需求的問題，參與讨論。或許某些人已經完成了你的需求，或是正在完成。即使你提的問題沒有答案，這也是參與社群的一個開始。
如果你想雇傭專業人士，單獨與他們聯系可能是最适合的方式。一般性的問題可能會被重定向到公共支援論壇，但是 Apache 的一些開發者也提供咨詢服務，他們或許喜歡專業的接洽。他們可以幫助您找到最佳的方法，無論是在技術層面上還是與 Apache 社群合作的層面上。但請注意潛在的利益沖突。如果您希望您的工作在 Apache 項目範疇内進行，您的顧問将希望您和您的項目确實适合 Apache，并且不會造成諸如軟體無法維護等問題。當然，任何保密協定都應該明确表明，你沒有要求獲得顧問在 Apache 正常工作成果的所有權！
如果你有内部開發人員，你隻需要讓他們進行開發即可。當你使用 Apache 項目的公共且穩定的接口就能滿足要求時，這是最簡單的方式。但是如果你想深入項目的核心，這就更難，也更容易産生混亂。當您開始這項工作時，Apache 社群是您團隊的最佳資源，是以，如果您的開發人員有以下任何的優點（不被吓得低頭不敢和外界交流），他們将在項目進行過程中與 Apache 社群進行良性互動。
現在你參與了 Pratocracy，盡管（通常）你可能暫時還是在社群的核心之外。你有能提供給 Apache 的東西，如果你把它分享給 Apache，Apache 社群的成員會檢視它，并可能會參與其中。最好的情況下，這會形成一個良性循環，在這個循環中，開發人員不僅可以從 Apache 團隊中獲益，還可以為其做出貢獻，并為自己赢得被邀請加入的資格。但這絕不是自動的：開發人員和他們的經理都需要能夠看到公司控制結構之外的東西。至關重要的是，開發人員必須能夠将他們在 Apache 的工作與他們對公司的專業忠誠度分開，這意味着管理人員必須允許這種情況發生。但不要試圖自上而下地管理這樣一個過程：這就像試圖管理一群貓一樣的困難。公司管理人員隻要從旁促進推動即可！
這意味着，在某個階段，您必須與團隊坐下來解決界限問題：哪些屬于 Apache 項目，哪些屬于您公司的操作空間。如果開發人員不是一直被監督着做事，并與模糊性作鬥争，這将極大地幫助他們樹立信心。如果您的項目不是注定要與世界公開共享，那麼建立界限可能是顯而易見的，但即使所有内容都是 Apache 許可的，這也是值得讨論的。在後一種情況下，界限定義将集中在貴公司希望在商業上出售和/或支援的産品上，并希望保持完全控制，相對于那些放棄直接控制的部分。
即使您的公司僅僅是克隆或鏡像 Apache 項目并貢獻一切，您也會希望将業務模式中的事務分開，包括面向客戶的事務和面向 Apache 的事務。
請注意，這種事情非常容易出錯。在 Apache 我們有時會看到，公司管理者告訴開發者加入 Apache 社群，但卻沒有說明具體的任務和動機。很明顯，這很痛苦，也沒有任何用途。
正确的方法是，給你的開發者們具體的任務并讓他們加入 Apache 社群 - 如果這與他們的志趣與時間投入相符合。如果與 Apache 項目的密切互動是公司的一個重要的目标，您可能希望接觸并且可能雇傭具有 Apache 或類似開源環境的良好記錄的個人開發人員。
最後，讓我們從我自己的 HTTPD（ Web 伺服器，通常被稱為 “ Apache ”）和 APR 項目的經驗中考慮一個真實的案例。SQL 資料庫內建到 Web 伺服器的曆史橫跨了 Apache 内外包括企業和社群驅動的許多項目團隊。每個開發人員或團隊都會根據各自的時間來推進項目的發展，并且（至少您或我聽說過的）在各自的領域中取得了成功。
在早期， Web 伺服器并沒有 SQL 的支援。是以當時任何需要 SQL 的應用程式必須自己來管理資料庫的連接配接。一系列的第三方子產品被開發出來，用于 SQL 身份驗證和 SQL 登入，包括 MySQL 和 PostgreSQL 等流行資料庫以及商業資料庫的商業支援産品。Web/SQL 應用程式的通用架構由 mod_perl 開創的腳本子產品提供，為開發人員提供程式語言本身的資料庫接口以及持久資料庫連接配接。
随着時間的推移，伺服器及其應用程式已經超越了這種随機方式，在伺服器中實作了多線程處理和多個應用程式。基于一系列想法，本地 SQL 資料庫連接配接架構被設計并開發出來，通過動态連接配接池和共享為應用程式提供了一些顯著的效率提升。它還促進了合理化，是以在身份驗證等領域，一大堆不同的資料庫驅動子產品可以被單個子產品替代，來完成通用 SQL 身份驗證。每個資料庫驅動程式處理不同的 SQL 資料庫，這些驅動程式為伺服器中的各種應用程式提供服務。
這項工作是在 Apache 核心團隊中進行的，并且随着腳本語言等其他語言将其作為使用者的選項納入其中而得到更廣泛的傳播。它從極簡主義開始發展，以提供開發人員 “撓癢癢” 所需的更多功能，并從各種不同來源的資料庫驅動程式的貢獻中受益。
話雖如此，上述工作的影響仍然刻意維持在小範圍裡，并不能滿足所有應用程式的需求。有些項目繼續以自己的方式使用 SQL。事實是，現在有一種正确的方式來通路 SQL ，并不意味着其他方法是錯誤的！仍然存在第三方項目，出于其自身原因，使用其他方式來通路 SQL。事實上，有人完成了工作并滿足了需求，這使他們在 Pratocratic 生态系統中獲得了完全有效的生态位。
底線？許多 Apache 使用者可以使用現成的軟體（可能在咨詢了問題的解決方案之後），其他人可能需要添加大量的功能以滿足他們的需求。如果你屬于後者，那就去做吧。你可以随時讨論或/和分享你的工作。基本的管理決策是在您的工作和社群意見之間進行權衡。與項目核心人員的互動取決于您的開發人員如何能夠最好地工作。如果僅僅訴諸于機遇還不夠——也許是因為你想要影響項目的核心軟體或引入新的 API——這時你就需要考慮你的開發人員在社群驅動的開源中的一貫表現，并確定你擁有專業能力來處理它。
譯者簡介
徐紅偉，2015年博士畢業，之後在西歐遊曆，緻力于資料加密與資料安全事業，後回國創業，樂此不疲。