當您為雇主（無論是公司還是客戶）編寫代碼時，通常都知道由誰負責。您有批準PR的團隊負責人，決定下一個版本功能的董事和產(chǎn)品經(jīng)理，以及做出重大決策的CTO和CEO。

使用開源，這些權(quán)限可能會變得更加模糊。貢獻者是志愿者，可以隨心所欲地來去。確定決策制定方式和項目進展的方式稱為治理。根據(jù)項目的不同，治理方式可能與代碼本身一樣開放，或者全部取決于單個創(chuàng)始人的領導，有時被稱為終身仁慈的獨裁者（簡稱BDFL）。一些人通過績效和社區(qū)投票任命董事會，而另一些人則由公司發(fā)起人來挑選他們的人來做出決定。

因為無論在什么時候項目的好意和隨心所欲都能大規(guī)模地取得成功，都需要做出決定并解決沖突。一個小型項目可以使用無聲的共享規(guī)則進行操作。一旦項目形成一個更大的社區(qū)，則需要寫下并明確地做出決策的過程，以便新的參與者知道如何成功參與。 “這是實現(xiàn)任何規(guī)模的基本前提，” Drupal首席技術(shù)官Tim Lehnen說。

無論采取何種形式的治理，都可以促進開源項目的進展并鼓勵做出貢獻。 Mozilla首席研究工程師，Rust核心團隊成員，編譯器和語言的共同負責人Nicholas Matsakis說：“建立既支持貢獻者又幫助確保他們看到他們的貢獻得到認可的結(jié)構(gòu)至關重要?！痹O計團隊。畢竟，OSS的主要優(yōu)勢在于它能夠吸引這么多人。當人們重視他們的努力時，他們就會堅持下去，并且會對項目產(chǎn)生影響。”

Stack Overflow自己的Sara Chipps說：“開源可能具有牛仔文化?！彼?NET Foundation董事會和OpenJS Cross Project Council的董事會成員。 “引入護欄時，您要確保每個項目都能獲得成功的安全，令人鼓舞和開放的環(huán)境?！?/span>

我與參與OSS項目的幾個人進行了交談，以了解最有效的護欄是來自BDFL，是一個擁有最終決定權(quán)的人，還是與幾個人的委員會達成共識。

BDFL風格：戴皇冠的頭部沉重

“一生的仁慈獨裁者”一詞是為Python的創(chuàng)建者Guido van Rossum創(chuàng)造的，大多是在開玩笑，但這個名字卻很固定。這個術(shù)語涵蓋了所有創(chuàng)始人領導的開源項目，包括Linux內(nèi)核，Drupal，Clojure和Ruby。有大量受歡迎的OSS項目都依靠專門的創(chuàng)始人來管理，因此必須有一些好處。

我在開源堆棧交換中向社區(qū)詢問了這一點。 “我一直認為BDFL模型介于傳統(tǒng)的開放源代碼項目結(jié)構(gòu)和傳統(tǒng)的公司項目結(jié)構(gòu)之間，”使用bta的用戶回答道。 “您擁有OSS的開放性，透明性和一般文化，但只有一個強大的項目經(jīng)理來做出高層決策并指導整體工作。”

BDFL可以表明項目具有很強的遠見，并將長期保持這一遠見。 bta繼續(xù)說道：“它使領導者能夠發(fā)展并堅持有凝聚力的長期愿景，而不是一系列短命的領導人不斷改變計劃和方向。” D. SM的另一位用戶寫道：“如果您在項目愿景方面與BDFL保持一致，那么為BDFL運行的項目做出貢獻是有意義的。”

如今，如此眾多的流行語言都在BDFL模型上運行，這絕非偶然。 Perl，Ruby，Rails，Python和Scala都是從創(chuàng)建者主導的項目開始的。甚至C ++都有一個創(chuàng)建者Bjarne Stroustrup，他一直是標準委員會的活躍成員，擔任語言擴展小組的主席已有24年。 “在語言的早期階段（“早期”是該語言的前10到20年），至關重要的一點是，要讓某人對語言有長期的了解，并在其成功上擁有既得的個人利益，這至關重要?！?Ryan Cavanaugh，Microsoft的TypeScript語言的首席工程主管。 “我認為，當今幾乎所有廣泛使用的語言都始于強大的集中式設計師，這并不是一個巧合?！?/span>

有了符合貢獻者愿景的BDFL，項目就可以遵循該愿景，并在發(fā)布方面取得實質(zhì)性進展。 “您有一小部分人正在嘗試做某事，” DevOps工程師兼Apache軟件基金會成員Rob Tomkins說。 “與一大群人，他們必須放慢腳步，他們可以更快地行動，更快地做出決定。我嘗試盡可能地保持開放的態(tài)度，因為Linus [Linux的創(chuàng)造者Torvalds]取得了巨大的成功?！?/span>

盡管Linux Foundation確實托管了許多流行的開源項目，包括jQuery，Kubernetes和具有不同治理形式的Node.js，但Linux內(nèi)核仍然具有寬松的BDFL結(jié)構(gòu)。 Linux基金會總經(jīng)理兼戰(zhàn)略計劃高級副總裁Mike Dolan表示：“ Linux內(nèi)核遵循一個模型，其中Linus負責監(jiān)督最終發(fā)布細節(jié)，但幾乎所有決定實際上都是由各自的子系統(tǒng)維護者或子系統(tǒng)組維護者做出的。所有項目都是包容性的，這意味著任何人都可以做出貢獻并參與技術(shù)社區(qū)?！?/span>

但是，隨著項目的發(fā)展，其他貢獻者可能會發(fā)現(xiàn)自己在某些領域獲得了專業(yè)知識，有時甚至是非正式的領導。 “在任何大型項目中，圍繞各個主題至少總會有一個非正式的權(quán)力所在地，” Mozilla的研究工程師，Rust Core團隊成員Manish Goregaokar說。 “ BDFL不可能始終無處不在，因此您要做的至少是將他們的角色正規(guī)化并使其易于參與。”

看來，BDFL的長期項目可以使領導者成為最終決策者，而不再是處于爭吵狀態(tài)的雜草叢生的領導者。同樣的情況也適用于Drupal的創(chuàng)始人Dries Buytaert。 Lehnen說：“ Dries在Drupal中擔任BDFL的角色使他成為涉及Drupal軟件的任何事情的最終決策者?！?“但是，Drupal項目具有比軟件變更管理更廣泛的治理框架。對Drupal項目的日常貢獻已通過同行評審過程進行了審查和接受?！?[ed。注意：您可以收聽Dries，在最近的Stack Overflow播客中討論其工作方式的詳細信息：]

在某些方面，許多BDFL風格的項目最終都將作為混合型治理運作，而BDFL擁有最終決定權(quán)，而以下團隊則負責制定細節(jié)。 Goregaokar說：“如果大多數(shù)權(quán)力都移交給其他人群，那么BDFL模型就可以發(fā)揮作用，而BDFL則可以讓這些人群做出決定?！?“這與Rust中發(fā)生的事情沒什么不同?！?/span>

當然，沒有人能獨自成功，也沒有人能完美?？ㄍ咧Z說：“實際上，我認為今天沒有語言設計師會坐在山頂上，每隔幾個月下來發(fā)表聲明，然后再回到隱居狀態(tài)。” “他們正在與尊重他們意見的人交談，尋找人們提出棘手的問題，并且可能做出比您在名稱中的'獨裁者'部分所期望的要妥協(xié)得多的事情?！?/span>

這是您依靠核心人物承擔的風險之一。該項目的成功或失敗取決于獨裁者的實力及其管理復雜技術(shù)項目的能力。 Matsakis說：“有些人具有超常的能力，既可以引導討論，暫緩所需的投入，也可以做出明智的決定?！?“其他人，沒有那么多。因此，這是您要冒的風險?！?/span>

盡管存在一些幸存者對我們認為模型成功的偏見，但我們當然不能輕視該模型的好處。 “沒有人談論過不成功的語言的BDFL，因此我們已經(jīng)在談論一個由其職位性質(zhì)證明了自己的專業(yè)知識和智慧的人們?！?Cavanaugh說。

Lehnen說：“ BDFL模型的潛在弊端很多，并且與項目創(chuàng)建者的個性不同?！庇袝r候，創(chuàng)始人的個性是問題所在。擁有強大見解，獨到見解以及雄心勃勃地推動行業(yè)重大變革的人們并不總是最樂于助人。奇普斯說：“這不是一個能很好地反映大多數(shù)人的模型。” “他們認為他們是周圍通常很難相處的人-不友善，不友好，不受歡迎。但是他們碰巧創(chuàng)造了一些很棒的東西?！?/span>

實際上，該模型的大多數(shù)問題都來自于依賴單個開發(fā)人員，而不管他們的個性如何。如果由于彩票中獎或公交車事故而消失，則該項目將陷入困境。憑借天才的技術(shù)能力善于創(chuàng)造新語言的人可能不是一個偉大的人或項目經(jīng)理，并且不管他們的編程能力或能力如何，他們只是時間和精力有限的一個人。 Matsakis說：“試圖獨自運行一個項目真的很累。” “我無法想象任何人可以獨自嘗試運行Rust項目?！?/span>

雖然開源項目與企業(yè)不同，但企業(yè)的軟件項目也不依賴一個人。奇普斯說：“即使是初創(chuàng)公司也不是那樣工作的?！?“人們?nèi)菀追稿e，因此在某些時候，人們要么精疲力盡，要么厭倦工作，要么被要求下臺。這是在項目初期的有效模型，因為它可以在擴展時迅速做出決策，并且會崩潰；人們?nèi)菀追稿e，而且會犯錯誤，而且沒有無限的時間。它確實可以防止官僚主義，但是在一定規(guī)模上，迅速拉動觸發(fā)器是不好的?！?/span>

近年來，我們已經(jīng)看到這種模式在逐漸蔓延：范·羅蘇姆（van Rossum）卸任，托瓦爾茲（Torvalds）在受到粗魯，侵略性行為的指控后休息了一段時間。他們增加了額外的決策支持和社區(qū)參與。因此，硬幣的另一面是什么樣的。讓我們看一下社區(qū)主導的項目有哪些優(yōu)點和缺點，以及如何通過基金會的參與來改善這一點。

委員會設計

在由BDFL領導的項目可以圍繞中央愿景協(xié)調(diào)貢獻者并快速做出決策的情況下，該項目尋求團體的共識，無論是被選出的委員會還是在其中投票的人，或是通過專職貢獻贏得特權(quán)投票方式的一群人，總是會減慢速度。有時，這種較慢的，可衡量的決策過程實際上可能是凈積極的。 Matsakis說：“如果做得好，開放式治理將為您提供巨大的投入，這可以更好地為您的決策提供依據(jù)。” “人們可能會貢獻出您尚未想到的想法?！?/span>

進行這些開放，較慢的對話可以幫助您實現(xiàn)想法，甚至您可能不確定的想法。有時，能夠找出錯誤答案的確定“原因”與找到新的正確答案一樣有價值。湯姆金斯（Tomkins）告訴我一個有關他何時對Apache Commons Listserv進行更改的故事。 “我討論了我們應該保留Apache Maven構(gòu)建基礎架構(gòu)還是遷移到Gradle，這是Spring Framework的用途。為了進行健康的對話，我試圖明確表示我只是在推動界限，并且我對社區(qū)所說的沒事。每個人都在想，‘不，我們不要搬到Gradle。那是負數(shù)。讓我們呆在Maven上?！耶敃r想，這很有道理?！?/span>

有了更成熟的技術(shù)，這種思想探索絕對是加分的。來自經(jīng)驗豐富且親自參與該技術(shù)成功的多個開發(fā)人員的全新思路可以使它在未來幾年保持相關性?？ㄍ咧Z說：“任何一種已經(jīng)足夠成功的語言，足以保證委員會能夠決定其方向，首先必須已經(jīng)“足夠好”以證明委員會的合理性?！?“共識委員會的慢性不會成為一個嚴重的障礙。”

Goregaokar表示：“在Rust上，正和思維的趨勢很好?！?“通常在技術(shù)決策中會涉及重大的權(quán)衡取舍，但是人們努力尋找正和答案，以表明您也可以吃蛋糕。并非總是可能的，但是如果可行，它確實可以很好地工作。”建立積極，富有成效的對話可能很困難，建立共識并不意味著每個人都參與其中。有時，委員會的決定與總體共識有所不同。 Matsakis說：“大多數(shù)時候，我們會以與RFC線程的'感覺'相一致的方式來決定事情，但并非總是如此?！?/span>

委員會的問題不僅來自試圖建立共識，還來自誰來參加這些委員會。對于創(chuàng)始人領導的項目，這個問題尚無定論。您構(gòu)建了它，然后運行了它。但是委員會通常是由現(xiàn)有成員選舉或選舉產(chǎn)生的。對于那些由公司贊助商選擇董事會成員的項目，這一決定可能會顯得格外煩惱，尤其是對于那些更加理想化的貢獻者而言。

委員會風格的治理實際上與BDFL風格存在一個問題：倦怠。如果您認為自己必須做每一個決定都很累，請嘗試與一群人一起做每一個決定。 “開放式治理可能很累人，” Goregaokar說。 “有時候人們有很強的見解，而且很難處理受到強烈見解轟炸的討論。”

BDFL治理重視決定性和遠見，而委員會治理重視耐心和同情心。湯金斯說：“人們有其細微差別。” “沒關系。您的語氣必須格外謹慎和寬容，并且要理解其他國家/地區(qū)的人們，因為他們不一定了解這種語言以及我們中某些人的細微差別。您只需要有耐心和寬容，我認為這樣可以建立一個更健康的項目?！?/span>

當出現(xiàn)多種好的解決方案時，委員會可能會陷入僵局，或者當感覺受到傷害時，委員會就會陷入戰(zhàn)斗。這就是為什么現(xiàn)在許多開源項目都屬于傘形基礎，可以解決這些元治理問題。 Mozilla，Linux，Apache甚至Java都提供了曾經(jīng)被撤職的監(jiān)督小組，以權(quán)衡這些問題。甲骨文公司Java平臺事業(yè)部軟件開發(fā)副總裁Georges Saab表示：“有一個上訴程序，因此，如果有人覺得自己做錯了事，或者沒有以合理的理由做出決定，他們就會感到不滿?！焙蚈penJDK董事會主席。 “但是我很高興地說我們不必雇用它。在過去的十年中，我們沒有發(fā)生過這樣的問題?！?/span>

可持續(xù)有機規(guī)范

當然，所有這些治理都是為了確保OSS項目在長期內(nèi)是可持續(xù)的，并且參與者可以感覺到自己正在受到重視并從中受益。為開源做貢獻有很多好處，它可以增強簡歷，使您的技能保持最新狀態(tài)并與其他開發(fā)人員建立聯(lián)系。但是事實仍然是，這主要是志愿者工作。

湯姆金斯說：“我盡力做到熱情和開放，因為真的很難找到提交者?！?“外面的每個人都超級忙。每個人都在空閑時間做這些事情。如果我能令人耳目一新地歡迎大家，從長遠來看，人們更有可能與我一起工作?！?/span>

Bootstrap，Hogan.js等的創(chuàng)建者Jacob Thornton講了一個經(jīng)典演講（警告：咸味語言）。他談到開放源代碼給人造成的損失，尤其是在該項目變得流行時。善政和行為守則可以減輕這種壓力。奇普斯說：“開放源代碼只是一個令人不快的地方，您可以在其中做出讓人喜歡的東西，然后突然有人對您大喊大叫?！?“那不是很好。開源治理允許為這些人提供支持系統(tǒng)?！?/span>

成功的項目，特別是那些使用開源代碼構(gòu)建關聯(lián)業(yè)務的項目，可以找到公司投資者。這些小組可能會提供財務或技術(shù)支持，但他們也可能開始歪曲項目的任務。 “對我們來說，一個重要的教訓是將業(yè)務和技術(shù)工作的治理分開?！?Dolan說。許多公司在其解決方案中使用OSS并產(chǎn)生實際收入。他們很快意識到需要回饋。另一種情況是，他們將花費太多金錢來維持與上游社區(qū)不同步的項目代碼庫。這就是我們許多項目找到可持續(xù)發(fā)展的周期，并希望取得長期成功的原因?！?/span>

這些管理規(guī)則不僅使貢獻者對其所做的工作感到滿意；它們還有助于確保項目朝著有益的方向發(fā)展。不管樣式如何，大多數(shù)項目都有一個提案和RFC流程，可以根據(jù)需要調(diào)整任何新功能。 “對于我們來說，重要的是，我們今天要添加的任何功能都可以滿足具體需求，而不僅僅是以推測方式添加到該語言中，” Cavanaugh說。 “一旦我們對功能建議感到滿意，最后一步就是實施它，然后我們可以嘗試一下，找出所有可能的情況，并確保我們已經(jīng)創(chuàng)建了將永遠成為一個好東西的東西。除了語言?！?/span>

Linux基礎可能是當前治理的黃金標準。他們起步很早，從根本上創(chuàng)造了現(xiàn)代開源理念。 Linux操作系統(tǒng)設想的代碼貢獻就像集市，而不是大教堂。也就是說，任何人都可以貢獻力量，而不僅僅是選民。由于他們很早就開始開源，因此隨著時間的推移，他們已經(jīng)獲得了豐富的經(jīng)驗。 Chipps說：“將Linux基金會作為父基金會是治理的一個很好的例子?！?“由于它在很多方面都失敗了，因此必須在所有工作上都變得更好。它開始是一個對抗的地方。現(xiàn)在官僚機構(gòu)太多了，這是不可能的?！?/span>

多蘭同意：好的決定來自經(jīng)驗，經(jīng)驗來自于破壞事物。 “我們當然是通過做事，破壞事情以及必須幫助解決這些問題來學習的。這不僅適用于軟件，還可以對治理本身進行建模。我們還聘請了開放源代碼專業(yè)人士，他們在進入Linux Foundation之前已經(jīng)建立并破壞了許多東西，并在我們建立新社區(qū)時將這些經(jīng)驗帶到了桌面?！?/span>

像代碼本身一樣，開源項目及其治理仍在進行中。它仍在弄清楚什么是治理模式，以及如何將所有志愿人員的捐款變成可持續(xù)的模式。但是他們已經(jīng)改變了世界，并將繼續(xù)與世界一起改變。