在今年的OSCON大会上，红帽公司的Tom Callaway作出了题为《你的失败原因：本可避免的错误在开源项目中仍一再出现》的演讲。2009年，Callaway开始加入Chromium项目的开发工作——而在此次演讲中，Callaway以轻描淡写的方式将其形容为一段并不愉快的经历。

Callaway指出，他喜欢接受挑战，但该项目却让他感到窒息，甚至最终使他选择了退出相关工作。（Callaway表示，需要提到的是Chromium的代码库并不糟糕，只不过本身工作量很大、而且谷歌在项目开发过程中并没有将其全部编写完成。）这一切让Callaway感到万分沮丧，而人们也对他的遭遇感到好奇。Callaway希望能够更为透彻地分析自己所遭遇的挫折，因此整理出了今天的这份清单——他将其称为“失败点”。

尽管Callaway并不打算通过博文博取什么关注，但人们仍然发现了他的经历并就此展开讨论。由于这份清单仅仅囊括了对他所闻所感的概括，因此多家媒体对他发出了演讲邀请，其它网站上发布与之相关的解读文章，甚至出现了开源类型下的职称图。不过在深入讨论他的失败点理论之前，Callaway希 望首先定义真正的成功。人们乐于使用开发者的软件成果是衡量成功的重要标准之一。其次（这也是我最喜爱的讨论内容），我们需要健康的社区环境来保障成功。 我们希望有更多人参与进来改进自己的产品方案、彼此帮助并定期发布更新内容。最后，我们希望自己的工作能够被“友好地分发”。一个被“友好分发”的开源项 目意味着其需要经过预打包，Callaway解释道。

大部分linux用户获取大部分软件的手段仍然是通过发行版当中的软件包集合。这是人们寻找新型软件时关注的首选平台。而在解释了成功的定义之后，Callaway给出了以下失败点的衡量标准：

1.如果你的代码库太过庞大，则会限制用户下载这些代码的意愿与能力。

2.现在是2015年，开源项目没有任何理由不提供公开源代码控制机制。这有助于人们为其作出贡献，并根据最新提交内容的日期来判断项目的当前运作状况。

3.如果你的源代码控制机制不提供Web查看器以及/或者说明文档，那么请马上想办法解决——这两项因素至关重要。

4.糟糕的代码比没有相关代码还差劲！大家需要提供说明文档，解释如何利用这些源代码构建起整个项目。

5.使用build工具。

6.采用捆绑方式并不代表着项目会失去可维护性——捆绑只代表fork能力。

7.强迫人们在特定目录之下安装软件项目。

Callaway表示一旦遇到以下情况，则意味着项目已经遭遇失败：

1.如果你的代码运行需要依赖于微软Visual之类（百分之百失败了）。

2.如果你的项目被托管在某套系统内，但却没有配合冗余，或者是直接运行在了身边的某台普通计算机当中。

3.如果不具备适当的通信工具（包括邮件列表、网站以及/或者bug追踪工具）。

4.如果你的代码属于其它项目的fork，而你的主要开发人员并没有同时参与其母项目的编程工作当中。

5.如果你的代码在进行开源之前属于专有软件（我们没有办法改变过去）。

6.如果你的代码许可缺乏一致性。

7.如果你的代码不具备任何说明文档。

8.如果大部分通过邮件列表发出的消息都没有回应、遭遇调侃甚至是侮辱。

9.如果有超过50%的项目贡献者效力于同一家企业。

10.如果你的代码不提供本地化支持。

11.如果你没有对项目加以管理，或者单纯依靠代码发布厂商进行管理。