# 作為一些個體出現，而不是一個整體 你的開發者必須力求在項目的公共論壇中以一個單獨的參與者出現，而不是一個單獨的公司。這不是因為作為一個公司出現本身固有的一些負面含義（好的，或許有一些，但那不是本書所討論的）。而是因為開源項目的結構配備只能處理個人實體。一個單獨的貢獻者可以討論、提交補丁、獲取信譽、表決等等。而一個公司不能。 此外，因為分布式的行為方式，你避免了對于刺激性中央集權的敵對。讓你的開發者在郵件列表中意見并不一致。鼓勵他們經常評審他人的代碼，盡可能的公開，就象他們是任何其他的人。阻止他們象一個集團一樣表決，因為如果你這樣做，其他人就會感覺到，根據一般的原理，一定有一個有組織的力量在控制他們。 實際的非中央集權和假裝的是有區別的。在特定環境下，讓你的開發者協同一致會非常有用，而且如果必要還必須在幕后進行協調。例如，當發出提議時，讓許多人盡早跳出來表示認可，得出正在達成共識的印象會有助于提議的進展。其他人會感到提議的動量，如果他們反對，他們需要阻止這個動量。因此，人們只會在有好的原因時才會提出反對。如果能夠慎重對待反對意見，這樣的精心安排也沒有錯。私下協議的公眾表現不會因為經過預先的協調而變得不夠誠實，只要他們沒有用這個方法來扼殺反對意見就不會有太多害處。他們的目的僅僅是阻止那些喜歡保持個性的人提出反對意見；更多相關內容可以看[Chapter?6, *交流*](# "Chapter?6.?交流")的[the section called “主題越軟，辯論越長”](# "主題越軟，辯論越長")。