Readify
下载 App

Linux与组织问题

群体的智慧

这条故事线追踪一个开源项目，展示分散式贡献如何带来多样性，以及集中审查如何提供筛选机制。

increasingupBearing stren­gth in each eventdowndecreasing
Linux 与组织问题Linux 与组织问题，《群体的智慧》中的场景。贡献邀请 首次发布 林纳斯·托瓦兹创建了一个Unix版本，并公开发布其源代码。他邀请能够改进它的人将自己的成果寄回，以供考虑纳入其中。 这项邀请将一个个人项目变成了开放式协作。在最初十次下载中，就有几位程序员寄回了修复、改进或新功能。
贡献邀请 首次发布 林纳斯·托瓦兹创建了一个Unix版本，并公开发布其源代码。他邀请能够改进它的人将自己的成果寄回，以供考虑纳入其中。 这项邀请将一个个人项目变成了开放式协作。在最初十次下载中，就有几位程序员寄回了修复、改进或新功能。 一种新型资源 项目没有雇用每一位贡献者，也没有给每个人分派工作，而是汇集那些主动选择感兴趣问题的人所付出的努力。 这一开端提出了本章的组织问题：没有传统的命令与控制，志愿者参与的分散式工作能否打造出可靠的系统？
贡献者追随兴趣贡献者追随兴趣，《群体的智慧》中的场景。没有组织架构图的工作 自选任务 Linux贡献者来自不同地方，处理自己选择的问题。没有正式经理命令他们逐一修复每个错误，也没有员工名册界定项目的全部能力。 这种安排开辟了一个可能解决方案的领域，其规模远超任何一家公司的人员配置能力。贡献者可以根据自己的兴趣和技能投入精力。
没有组织架构图的工作 自选任务 Linux贡献者来自不同地方，处理自己选择的问题。没有正式经理命令他们逐一修复每个错误，也没有员工名册界定项目的全部能力。 这种安排开辟了一个可能解决方案的领域，其规模远超任何一家公司的人员配置能力。贡献者可以根据自己的兴趣和技能投入精力。 大规模多样性 项目的优势部分来自能够检查代码的人数众多、背景多样。一名程序员忽略的错误，另一位经验不同的程序员或许一眼就能看出来。 若以保证每个小时都富有成效这一狭义标准衡量，这套系统并不高效。表面上的浪费反而增加了有用解决方案涌现的机会。
审查瓶颈审查瓶颈，《群体的智慧》中的场景。谁来选择代码 分权需要筛选 世界各地的程序员都可以提出修改建议，但操作系统仍需要一种方式，决定哪些贡献能够进入源代码。 林纳斯·托瓦兹和一小群程序员负责审查提交的修改。因此，最终决策仍比寻找可能的修复方案更加集中。 汇总判断，而非取消权威 这一安排表明，仅有分权并不能保证结果明智。
谁来选择代码 分权需要筛选 世界各地的程序员都可以提出修改建议，但操作系统仍需要一种方式，决定哪些贡献能够进入源代码。 林纳斯·托瓦兹和一小群程序员负责审查提交的修改。因此，最终决策仍比寻找可能的修复方案更加集中。 汇总判断，而非取消权威 这一安排表明，仅有分权并不能保证结果明智。系统需要评估各项贡献，并将本地的努力与共同产品连接起来。 该项目的结构将分散式探索与范围较窄的评估流程结合起来，而不是把完全控制或完全自主中的任何一方视为充分条件。
Linux与组织问题Linux与组织问题，《群体的智慧》中的场景。通过检查提高可靠性 广泛搜寻错误 数千名程序员可以检查Linux并提交修正。因此，该项目拥有异常庞大的人力储备，能够发现弱点并提出修复方案。 埃里克·雷蒙德用一句话概括了这种吸引力：只要有足够多的眼睛，所有错误都浅显易见。这一说法强调检查范围广泛，并非认为任何贡献者都不会出错。
通过检查提高可靠性 广泛搜寻错误 数千名程序员可以检查Linux并提交修正。因此，该项目拥有异常庞大的人力储备，能够发现弱点并提出修复方案。 埃里克·雷蒙德用一句话概括了这种吸引力：只要有足够多的眼睛，所有错误都浅显易见。这一说法强调检查范围广泛，并非认为任何贡献者都不会出错。 协调仍然重要 大量提交的修改也可能造成混乱或不一致。要在利用分散力量的同时维持系统的一致性，就必须进行审核与整合。 探索与一致性之间的张力，是这条故事线的核心冲突：更多贡献者能扩大错误发现的范围，但共同标准和采纳决定才能让成果保持可用。
Linux与组织问题Linux与组织问题，《群体的智慧》中的场景。分散协作，共享成果 微软的替代方案 尽管缺乏大型软件公司通常具备的所有权和雇佣结构，Linux仍成为微软的重要挑战者。 贡献者不必在每项任务上达成一致，也不必在同一位主管手下工作。他们需要的是提交工作的途径，以及一套能够判断哪些内容应纳入系统的流程。 案例的平衡之处 这个例子支持分权，但并不意味着分权是普遍适用的良方。
分散协作，共享成果 微软的替代方案 尽管缺乏大型软件公司通常具备的所有权和雇佣结构，Linux仍成为微软的重要挑战者。 贡献者不必在每项任务上达成一致，也不必在同一位主管手下工作。他们需要的是提交工作的途径，以及一套能够判断哪些内容应纳入系统的流程。 案例的平衡之处 这个例子支持分权，但并不意味着分权是普遍适用的良方。项目之所以成功，取决于广泛参与与汇总、审核贡献的机制相结合。 故事的解决方式侧重制度，而非个人：只要社群拥有一条可信的路径，能将本地问题的解决汇聚成连贯的整体，开放协作就能取得成功。
1991年
Linux的早期开发
随着 Linux 日趋成熟
Linux的贡献流程成形之后
本书第四章的结论