非一般的最簡單的例子, 是許多位共同維護者在一位`仁慈的獨裁者'下工作. 在共同計劃中習慣於這個模式; 我們在大計劃像Linux kernel或Emacs中看到, 及解決``由誰來決定''的問題, 這看起來不會比其它的方式來得糟糕.
典型來說, 一個仁慈的獨裁者組織由一個擁有者-維護者組織, 建立者吸引貢獻者演化而來. 即使擁有者依然在位, 它也有計劃部份的功勞由誰來獲取的爭執存在.
在這種狀況下, 習俗有義務由擁有者/獨裁者來公平地處理貢獻者的貢獻(例如透過在README或歷史檔中提及). 在Locke的產權模型術語來說, 這意味透過貢獻一個計劃來獲取部份的名望(正面或負面的).
追朔這個邏輯, 我們見到`仁慈的領導者'並非真正擁有整個計劃. 雖然他有權力做下決策, 他事實上是透過交易名望來交換其他人的工作. 這類比就像佃農耕種, 是很難抗拒的, 除了有時候當某個貢獻者不再活動, 他的名字依然繼續獲得好處.
一個仁慈的獨裁者計劃加上許多參與者, 他們傾向於發展出兩族貢獻者; 一般貢獻者及共同發展者. 一個典型的途徑, 變成共同開發者, 可獲得計劃較大部份的責任. 另一種是以`lord high fixer'的角色, 專長在修正許多臭蟲. 以這種方式或其它種類的, 共同開發者在整個計劃中, 是那些以透過投資時間並有重大貢獻的貢獻者.
次系統擁有者角色在我們的分析中特別重要並且要求更進一步的檢驗. 玩家喜歡說`權威要負責'. 接受維護責任的共同作者可獲得一個次系統的掌控權及所有相關部份的計劃, 只受到計劃領導者的修正(可說是建築師). 我們觀察到這項法則有效地圈起Locke模型的計劃產權, 並且同樣地有其它產權界線避免衝突的效用.
傳統上, `獨裁者'或計劃中的領導者及共同作者, 是預期要與共同作者在關鍵決定上做協商. 特別是該決定與共同作者所擁有的次系統有關(也就是說, 有投資時間並負責任). 一個有智慧的領導者, 認識出計劃內部產權界線的作用, 是不會輕率地影響或反轉由次系統擁有者的決定.
有些很大的計劃完全不吃`仁慈的獨裁者'這一套. 一個方法是轉共同作者成為投票委員(像Apache). 另一種為輪換獨裁者, 即控制權由一位成員輪換到另一位資深成員(為Perl組織所採用).
這樣複雜的安排通常被考慮為不太穩定及複雜. 很明顯地這些困難的認知, 為這些委員及設計者本身所瞭解; 這些問題是玩家文化中, 大家清悉地瞭解的. 不論如何, 我認為有些玩家對委員會或輪換獨裁者組織心中不舒服, 因為它與過去Locke模型的思考大不相同. 在這些複雜的組織中, 不論是做擁有權或是名望回報的計算是有問題的. 很難看出其內部界線在那裡, 除非高度的協調及信任, 否則很難避免衝突.