我决定采用第一种方式。 我知道Storm是一款高质量且实用的软件,并且因为我有发布第一个开源项目Cascalog 的经验,我对Storm能否获得认可充满信心。
开始我计划通过一篇博文来发布Storm,但后来我有个在大会上发布Storm的想法。在大会上发布可以:
1.大会能帮助做营销和推广。
2. 我可以直接面向使用Storm的潜在早期使用者群体,他们可以通过博客/微博/电子邮件更大泛围的推广Storm。
3. 我可以炒作这次会议, 建起人们对此项目的渴望,这样在发布的那一天它一定会备受关注。
所以从多个角度考滤,在大会上发布似乎更好。巧合的是,我已经计划在9月的Strange Loop上讨论一个完全不同的主题。因为我计划在那时发布Storm,我给Strange Loop的组织者,Alex发了封邮件, 将我的会议改为Storm的发布. 正如你从会议简介上看到的, 我会以Twitter的名义对Storm进行介绍。
然后,我开始炒作Storm。 在2011年8月,会议前的一个月,我在Twitter的科技博客板块发表了一篇文章,宣布我将在Strange Loop 会议上发布Storm。 在那篇文章中,我通过展示Storm 工作方式的很多细节、并给出示例证明Storm的优雅,以勾起人们对Storm 的兴趣。文章达到了我想要的效果,Storm让人们很兴奋。
第二天,我做了一些我认为比较聪明的事情。 我在Storm 邮件列表中写道:
如果你想继续了解Storm 或者对Storm 有疑问,请加入Google 讨论组 。 — Nathan Marz (@nathanmarz) 2011年5月。这就是我认为聪明的原因。 为了使项目获得认可,你必须解决的一个关键的问题是建立社会认同。 社会认同以很多形式表现: 项目的实际使用记录,Github 上关注者,邮件列表活动,邮件列表订阅者,Twitter 粉丝,项目相关的博客文章数量,等。 如果我在发布项目时就发起邮件列表活动,那么当人们查看邮件时,邮件会显示没有相关活动且关注者很少。 项目有可能会立刻变得很流行,邮件列表活动建立起了社会认同,但是对于这一点,我不敢保证。
在邮件列表发布之前,我处在被仲裁的情况。开始时人们问问题和订阅,然后我在建立社会认同感。如果什么事都没有发生,这并不重要,因为项目还没有公布。
我在最初的那些日子里犯了一个错误,从我是在Twitter上工作这是奇异的,不是为项目而注册一个Twitter账号。Twitter的一个很棒的方式让人们保持关注最新的项目以及不断的展示人们的项目(通过转发)。我没有意识到我应该有一个Twitter帐户,直到后来发布,但幸运的是它证明没有什么大不了的。如果我能再做一次我就会在我的邮件列表上一天内开始 Twitter帐户。
我写在Twitter上的科技博客和奇怪的循环的开始的时间之间,我花了我的大部分的时间为Storm编写文档。为这个项目这是我做的最重要的事情之一。我写了约12000字的仔细考虑过得文档——教程,引用,API文档等等。很多开源开发者不知道文档是多么的重要:如果人们不理解你的软件,他们就不会使用你的软件。写好的文档是痛苦的,耗时的,但绝对必要的。
项目发布在2011年9月19日进行。在发布时我感觉很高兴。 我以“我一直在争论是否开源Storm”为话题开始了我的演讲,伴随着一声巨响演讲开始,我在观众的惊叹中结束了演讲。 在演讲进行到一半时,我说我决定开源Storm来做到两全其美。 并且告诉观众,如果未来我没有开源Storm,请在网上大声地喊出来。 此时,伴随着观众的尖叫,我发布了Storm。
一切按照计划进行。 Storm获得了大量的关注,发布的第一天, Github上的粉丝就超过 1000人。 Storm立刻登上了 Hacker News 网站的头条。 演讲结束,我上网回答 Hacker News、邮件列表活动、 Twitter上人们提出的问题。
发布之后
四天之内,Storm成为了Github上最受关注的 Java, Scala与 Clojure 领域的项目。两周之内,spider.io宣布已将Storm用在了产品中。我认为那是让人难以置信的,做出高质量的项目与文档的发布承诺,。
Strom一经发布,我就开始获取用户的反馈。在第一周,我制作了三个最小化的发布,用来解决用户遇到的生命周期的质量问题。尽管他们很小,但我尽可能确保每人都有最佳体验。同时,我也在Strom中加入了大量的额外日志,使用户在邮件列表中列出问题时,能够向我提供更多遇到的信息。
我没预料到回答邮件列表里的问题会花费多少时间。 邮件列表里有很多的活动,我每天花一到两个小时回答问题。 使邮件列表这么耗时的一部分原因是大多数人的提问很糟糕。 经常有人问下面的问题: “我使用时元组报很多错误。 为什么??“ 大部分情况下,原因很简单:用户在使用 Storm时,运用了一些奇怪的配置。 但是我不得不花费大量的时间问后续的问题,以获取问题的详细信息,这样我才能帮助他们。 用户做了奇怪的操作却不告诉你,你会对这类事情发生的频率感到吃惊,比如同时运行多个版本的 Storm,手动修改本地磁盘上 Storm的守护进程,运行他们自己修改后的 Storm版本,或者为 Storm 守护进程配置共享网络驱动器。 回答邮件列表上的问题变得越来越耗时(尤其当时我正在 Twitter上建立一个全新的团队),一年多的时间里我都没有从中解脱。
在接下来的一年里,我在会议上、聚会上、公司里做了大量的Storm的演讲。 我确信我进行了超过25次演讲。 我已经达到闭上眼睛就可以介绍Storm项目的境界。 所有这些演讲使Storm越来越有名气。
营销有了回报,Storm很快获得了产品用户的支持。 我在2012年1月做了一个调查,发现Storm已有10个产品用户,另有15个用户计划将要在他们的产品中使用Storm,另有30家企业对Storm进行了试验。 在发布后的3个月内拥有那么多的产品用户,这对于一个大型的基础型项目来说是非常有意义的。
我建立了一个 Storm“技术支持”页面,以获得最后一张社会认同通行证。 用户列表中不仅仅展示公司,我请求每个人把自己加入到列表中,并附上他们如何使用 Storm的简短说明。 这可以让人们在浏览页面时了解 Storm不同的使用场景和使用力度。 对于那些想出现在用户列表的人,我提供了一个我邮箱的链接。 像我进行技术演讲一样,这个页面会一直地增长和发展。
填充一个项目的"Powered By"页面有点让人心烦,因为可能有很多人使用你的项目但你却不知道。我记得有一次我收到一封世界上最大的中国公司的邮件,要对将它加入Storm的"Powered By"页。那时他们已经用Storm超过一年,但我却全然不知道。即使现在,我不知道让别人告诉你他们正在使用你的软件的最佳途径是什么。除了对Storm"Powered By"页上我的电子邮件链接外,我用的方法是通过Twitter和邮件列表接受提交来填充"Powered By"页面。
Storm的技术演进Storm相比它刚发布时更为先进。发布时它主要是面向我们在BackType的需求,当时我们还没意识到各大公司对主要基础设施的需求。在Twitter上广泛部署经过一年半的发展后发布了它。
大公司的技术需求与初创公司的是不同的。在初创公司里,一个小团队管理着整个栈,包括所有操作与部署,而在大公司里,这些功能一般分配给多个团队。我们从Twitter中最先得知的是,人们并不想运行自己的Storm簇群,他们只想要一个由他人管理的Storm簇。
这预示着我们需要能够拥有一个巨大的、共享的簇,用来运行许多独立的应用。我们需要确保这些应用能够得到足够多的资源,确保在同一簇中一个应用出毛病时无法影响到其他的。这就是所谓的“多租户”。
我们也遭遇过进程问题.当我们扩建共享簇时,注意到相当多的人在构建拓扑时,占用了超出他们实际需要的大量资源。这导致簇的使用非常低效。问题出在没人主动优化自己的拓扑,他们只想运行自己的东西,使它们工作起来,因此在他们眼里没理由不必去占用大量的资源。
我通过开发的“分离调度器“解决了这些问题。这是一个相当简单的用于多租户的解决方案,创建了促使人们高效利用资源的激励机制,允许单簇共享产出与工作负载。
随着越来越多的Twitter用户使用Storm,我们也发现他们需要控制他们的带度量的拓扑,而不是Storm默认捕做的。这致使我们开发了Storm的优秀的度量API,允许用户彻底地收藏定制的、任意度量,并发送给任何控制系统。