100:10:1 方法 : 我是这样参与开源的

2017 年 9 月 8 日 Linux爱好者 伯乐在线

（点击上方公众号，可快速关注）

英文：Michael Fogus，翻译：伯乐在线 - 暖日生烟

如有好文章投稿，请点击 → 这里了解详情

【导读】：据本文作者 Michael Fogus 博客上的简介，他是一位 Clojure 开发者和狂热用户，并且是 Clojure 的贡献者（Clojure 本身也是一个开源项目）。平常在 Clojure 和 ClojureScript 花费时间很多。他喜欢棒球、象棋、哲学、恐怖电影、阅读和写作。出过两本书《Functional JavaScript》和《The joy of Clojure》。

许多年里我一直全心投入于开源运动，不过那时候我很少在空闲时写代码，在 Sourceforge、GoogleCode、GitHub 之类的代码托管平台，也找不到我的项目（repo）。【1】然而随着时间流逝，我逐渐意识到向全球公开代码的责任，毫不夸张的说，这吸引住了我。

除了很多“已发布”的代码是低水准的这一事实之外，无论有意与否，将代码公布于众的行为意味着与某些人签订契约【2】，这些人可以为自己的目的使用公开的代码。当然，我并不一定反对这种社会契约，相反，在发布代码的时候我最终改变了主意，以致于我在我的方法中变得更保守了。这个我现在正在使用的方法叫做“100:10:1 方法”，此术语是由开发者 Nick Bentley 创造。【3】

100:10:1 方法究竟是什么？

我会试着从我的开源软件开发方法这一背景下来概括它。

具体操作分三部分，步骤如下：

写下 100 种疯狂的想法

首先，准备一本笔记本和一支笔，为开发有意思的开源项目写下 100 种想法即可。这些有关项目的想法可以涉及各种主题，深度和质量。我想过的有，野生语言的创意、已有项目的新功能、系统设计、协议、缺损文件、有趣的 forks、代码简化、游戏、原型、论文想法的实现、第二个系统等等。

在使用 100:10:1 方法之前，我总是会用疯狂的想法填满我的笔记本。它们通常是东一点西一点，从不会聚集在一个地方。在几页纸上写下这 100个想法后，我的注意力立马集中在它们身上。这样我就可以好好筛选比较为第二步做准备。

为这 10 个想法创造最小可行性产品（MVP）

我面前的这 100 个想法，让我了解到我不止当时对追求它们充满兴趣，并且我感觉它们可以使我和他人同时获益。【4】从原始的 100 个想法里，我挑出了确定想探索和专研下去的 10 个。在这 10 个项目里，我挑不出一个更好的了，因此我想同时为它们各自编写一个最小可行“项目”。

你可能马上会想到同时开发 10 个项目这件事本身就是一个负担。这不能说是一个错误的评估。然而，我意识到对于我选择的大多数项目，要找到最可行的实现方式是非常难的，如果有也得耗费几个月甚至数年时间。你看，我曾一度认为发布开源软件是把潜在可用的工具给予他人的一种方法。很遗憾的是，随着时间推移，这个观点已经退化到能做到将代码公开就不错了。我现在的想法是，在业余时间写代码仅仅是一个探索，有没有结果也无所谓了。

同时开发 10 个项目有个好处就是，当我在一个上遇到了瓶颈可以轻易的转移到另一个更有灵感的项目去。作为一个除编程外拥有丰富爱好、社区和家庭生活的人，用一堆选择来对抗我的三分钟热度无疑是非常有用的。拥有 10 个并行的项目意味着总有一个能让我在短时间内感兴趣。我知道当所有兴趣集中在一个任务上时，工作会变的更有效率。无论怎样最后总有一个项目会见到希望【5】，当它到来时我已经准备好了进入最后一个阶段。

全力开发选中的项目，使其成为一个可以合法发布的软件

在开发 10 个项目的过程中，其中一个不可避免会成为有价值的东西。【6】万事俱备后，我会将其变为一个高质量的软件产品。【7】这意味着要完成所有内容，确保一个健壮的系统，有可靠的例子、测试、文档、稳定的API、博客文章或演讲，甚至可能有网络。【8】

在此之前为了我自己而开发的项目，可能要经历大量的工作才能使其成为值得与他人分享的东西。这当然取决于软件本身的复杂度，很可能最后一步要花最长的时间来完成。同样最后阶段也是我最容易彻底放弃的时候。因为我发现了一个大麻烦，如果我不愿为我的代码写文档、例子和测试的话，在未来的数十年想要维护它是根本不可能的。

总结

这个方法我已经用了一段时间，在此之前，使用类似的方法同样取得了不错的成果。Zeder 和 Patagonia 也是用 100:10:1 方法或类似方法进行开发的。我现在有的一个叫 Tathata 的 Clojure 库，即将进入最后阶段。或许 10 个项目【9】里会有一个成功，不过即使失败了，我还会再挑选更多的 10 个去尝试。