En basit durum, bir projenin tek bir sahibi/lideri olduğu durumdur. Bu durumda bir çatışma olması ihtimali yoktur. Sahip, bütün kararları verir, bütün krediyi alır veya bütün suçlamaların muhatabı olur. Tek çatışma mevzuu, yerine kimin geçeceğine dair karar verilmesi esnasında olabilir -- eğer eski sahip kaybolur veya ilgisini kaybederse yerine kimin geçeceği. Topluluk, (C) problemi uyarınca, ayrıca çatallanmayı önlemek arzusundadır. Bu arzular, sahip/liderin, artık proje liderliğini yerine getiremediği durumlarda kamu önünde yerine geçecek olana bayrak teslimi yapmasına yönelik bir kültürel norm doğurur.
Bir aşama daha kompleks olan durum, tek bir ``iyiniyetli diktatör'' önderliğinde çalışan çok sayıda proje yöneticisi olmasıdır. Alışkanlıklar grup projelerinin bu şekilde organize olmasına yöneliktir; bu yapı Linux çekirdeği veya Emacs kadar büyük projeler için de kullanılmakta ve ``karar veren kim'' problemini diğer alternatiflere göre bariz bir kötülüğü olmayan bir şekilde çözümlemektedir.
Genelde, iyi niyetli diktatör yapıları tek sahipli yapılardan, kurucu lider yeni katılımcılar çektikçe doğal evrimle oluşur. İlk sahip, diktatör olarak kalsa bile projenin hangi kısımları için kime kredi verileceği konusunda yeni tartışma noktaları oluşabilir.
Bu durumda, gelenekler sahip/diktatörün katılımcılara adilane bir şekilde kredi vermesini (örneğin README dosyaları veya proje tarihçesinde) gerekli kılar. Locke mülkiyet modeline göre bu, bir projeye katkıda bulunarak o projenin şöhret getirisine (pozitif veya negatif) ortak olunma hakkının elde edilmesidir.
Bu mantığı devam ettirirsek, `iyiniyetli diktatör'ün aslında kayıtsız şartsız olarak projesinin sahibi olmadığını görürüz. Kalıcı kararlar alma hakkı olsa dahi, başkalarının katkısı karşılığında toplam şöhret getirisini katılımcıları ile paylaşmaktadır. Bir çiftlikte `yarıcı' olmak benzetmesinden neredeyse kaçınılamaz, fakat burada katılımcının ismi kredi listesinde yer almaya devam etmekte ve katılımcı artık aktif olmasa bile `getiri' sağlamaya devam etmektedir.
İyiniyetli diktatör projeleri daha fazla katılımcı eklemeye devam ettikçe iki sınıf katılımcı oluşturmaya başlarlar; normal katılımcılar ve eş-geliştiriciler. Eş-geliştirici olmaya giden tipik bir yol, projenin önemli bir alt sistemi için sorumluluğu almaktır. Bir diğeri, çok sayıda hatayı bularak ve ayıklayarak `yüksek hata ayıklayıcı' olmaktır. Bu ve benzer şekillerde oluşan eş-geliştiriciler, projeye önemli ve devamlı bir zaman yatırımında bulunan kişilerdir.
Altsistem-sahibi rolü analizimiz için önemlidir ve daha dikkatle incelenmelidir. Hackerlar, `yetki, sorumluluğu takip eder' demekten hoşlanırlar. Bir altsistemin bakım sorumluluğunu üstlenen bir eş-geliştirici, genellikle hem o altsistemin iç dizaynı ile ilgili hem de projenin geri kalan kısmı ile iletişim için kullanacağı arayüzler ile ilgili kararları, yalnızca (proje mimarı sıfatı ile) proje liderinin düzeltmelerini uygulamak ve kabul etmek koşulu ile verebilir. Bu kuralın, pratikte, bir proje içerisinde Locke modeline uygun ayrılmış mekanlar oluşturduğunu ve bütün diğer mekan sınırları ile aynı çatışma engelleyici işlevi yerine getirdiğini gözlemliyoruz.
Gelenek olarak eş-geliştiricileri olan bir `diktatör' ya da proje liderinin önemli kararlarda eş-geliştiricilerinin fikrini alması beklenir. Bu, özellikle alınacak karar bir eş-geliştiricinin `sahip' olduğu (yani zaman ayırdığı ve sorumluluk üstlendiği) bir altsistemi ilgilendiriyorsa titizlikle uygulanır. Akıllı bir lider, projenin iç mekan sınırlarının işlevini kavrar ve altsistem sahiplerinin almış olduğu kararlara çok gerekmedikçe karışmaz veya değiştirmez.
Bazı çok büyük projeler `iyi niyetli diktatör' modelini tamamen bırakırlar. Bunu uygulamanın bir yolu, eş-geliştiricileri oy hakkı bulunan bir komite haline getirmektir (Apache'de olduğu gibi). Bir başkası, kıdemli eş-geliştiriciler arasında sırayla kontrol devrinin yapıldığı dönüşümlü diktatörlüktür; Perl geliştiricileri kendilerini böyle yapılandırmışlardır.
Böyle karmaşık yapılar genel olarak dengesiz ve zor kabul edilir. Bu düşüncenin genelde bilinen `komite yolu ile dizayn' güçlüklerinden ve komitelerin kendilerinden kaynaklandığı aşikardır; bu problemler hacker kültürü tarafından yakından bilinir. Fakat, hackerların komite veya dönüşüm yapılarından duyduğu rahatsızlığın bir kısmının, hackerların daha basit yapılar üzerinde değerlendirme yaparken kullandıkları bilinç altı Locke modeline bu yapıları uydurmakta yaşadığı zorluktan kaynaklandığını düşünüyorum. Bu karmaşık yapılarda kontrol amaçlı mülkiyetin ve şöhret getirilerinin sahipliğinin muhasebesini yapmak güçtür. İç sınırların ne olduğunu görmek zordur ve dolayısıyla eğer grup normalin üzerinde bir armoni ve güven içerisinde değil ise çatışmayı engellemek zordur.