Linux 版 (精华区)

发信人: netiscpu (网中鸟~~倒计时), 信区: Linux
标  题: 开拓智域(十七)15.计划结构及拥有权
发信站: 哈工大紫丁香 (Sun May 30 20:44:52 1999), 转信

发信人: pure (青衣～悠然而虚), 信区: Linux

标  题: 开拓智域(十七) 15. 计划结构及拥有权

发信站: BBS 水木清华站 (Mon Jan 18 23:42:13 1999) WWW-POST

下一页 上一页 目录 

15. 计划结构及拥有权

一般的个案来说是一个计划有一个单一个拥有者/维护者. 在这种状况下没有可能会有

冲

突. 拥有者可做下所有的决定, 拥有所有的益处, 及受到所有的谴责. 唯一会冲突的问

题可能是继承者 -- 当旧的拥有者失去兴趣或不见了, 由谁来当新的拥有者. 该团体亦

对避免分歧很感兴趣. 这些兴趣都由文化规范所表达, 即当一个拥有者/维护者对该计

划

不再有兴趣, 应该公开地将名衔交给下一位. 

非一般的最简单的例子, 是许多位共同维护者在一位`仁慈的独裁者'下工作. 在共同计

划中习惯於这个模式; 我们在大计划像Linux kernel或Emacs中看到, 及解决``由谁来

决定''的问题, 这看起来不会比其它的方式来得糟糕. 

典型来说, 一个仁慈的独裁者组织由一个拥有者-维护者组织, 建立者吸引贡献者演化

而

来. 即使拥有者依然在位, 它也有计划部份的功劳由谁来获取的争执存在. 

在这种状况下, 习俗有义务由拥有者/独裁者来公平地处理贡献者的贡献(例如透过在

README或历史档中提及). 在Locke的产权模型术语来说, 这意味透过贡献一个计划来获

取部份的名望(正面或负面的). 

追朔这个逻辑, 我们见到`仁慈的领导者'并非真正拥有整个计划. 虽然他有权力做下决

策, 他事实上是透过交易名望来交换其他人的工作. 这类比就像佃农耕种, 是很难抗拒

的, 除了有时候当某个贡献者不再活动, 他的名字依然继续获得好处. 

一个仁慈的独裁者计划加上许多参与者, 他们倾向於发展出两族贡献者; 一般贡献者及

共同发展者. 一个典型的途径, 变成共同开发者, 可获得计划较大部份的责任. 另一种

是以`lord high fixer'的角色, 专长在修正许多臭虫. 以这种方式或其它种类的, 共

同开发者在整个计划中, 是那些以透过投资时间并有重大贡献的贡献者. 

次系统拥有者角色在我们的分析中特别重要并且要求更进一步的检验. 玩家喜欢说`权

威

要负责'. 接受维护责任的共同作者可获得一个次系统的掌控权及所有相关部份的计划

,只受到计划领导者的修正(可说是建筑师). 我们观察到这项法则有效地圈起Locke模型

的计划产权, 并且同样地有其它产权界线避免冲突的效用. 

传统上, `独裁者'或计划中的领导者及共同作者, 是预期要与共同作者在关键决定上做

协商. 特别是该决定与共同作者所拥有的次系统有关(也就是说, 有投资时间并负责

任). 一个有智慧的领导者, 认识出计划内部产权界线的作用, 是不会轻率地影响或反

转由次系统拥有者的决定. 

有些很大的计划完全不吃`仁慈的独裁者'这一套. 一个方法是转共同作者成为投票委员

(像Apache). 另一种为轮换独裁者, 即控制权由一位成员轮换到另一位资深成员(为

Perl组织所采用). 

这样复杂的安排通常被考虑为不太稳定及复杂. 很明显地这些困难的认知, 为这些委员

及设计者本身所了解; 这些问题是玩家文化中, 大家清悉地了解的.  不论如何, 我认

为有些玩家对委员会或轮换独裁者组织心中不舒服, 因为它与过去Locke模型的思考大

不相同. 在这些复杂的组织中, 不论是做拥有权或是名望回报的计算是有问题的. 很难

看出其内部界线在那里, 除非高度的协调及信任, 否则很难避免冲突. 

下一页 上一页 目录 

--

看着她笑，他忽然觉得她好寂寞好寂寞。

她静静的看了他半天，才柔柔慢慢的:「 你好像已经找到了。」

※ 来源:·BBS 水木清华站 bbs.net.tsinghua.edu.cn·[FROM: 202.99.18.67] 




--
☆ 来源:．哈工大紫丁香 bbs.hit.edu.cn．[FROM: bin@mtlab.hit.edu.cn]