Storm另一个大的技术跳跃是发展中的Trident，一个Storm之上微混合的API，其提供了精准的一次性处理语义。这使Storm可以被应用到许多新的使用案例。
除了所有这些重大的改进之外，这个改进中还有许多生态的改善和大量的性能提升。我们所做的所有工作让我们能够发布许多版本的Storm–那之后的一年中我们平均一个月发布至少一个版本。频繁的版本发布在项目的成长的初期是非常重要的，因为每个发布都会在人们谈论它时提高知名度。它也向人们展示了项目在不断发展，而且如果他们遇到了问题，项目也将迅速响应他们。
构建开发者社区版创建开源项目最艰难的部分是构建开发者社区版以促进项目发展。这绝对是让我吃力的部分。
在发布后起初的一年半里，我驱动整个Storm的开发。所有的变更都要经过我。以我为中心的发展有优点也有缺点。
通过控制项目的每个细节，我可以保证项目有很高的质量。因为我了解项目的各个环节，我可以预料任何变更对整个项目的影响。因为我有一个项目发展的愿景，我可以防止任何会改变该愿景（或一致的修改）的变更。我可以确保项目始终有一致的设计及体验。
不幸的是，“愿景驱动开发”有一个主要的缺点：这种项目建立一个积极热闹的开发社区非常困难。首先，其他人加入进来并作出贡献很难，因为我控制一切。第二，我是所有开发的一大瓶颈。当达到一定规模是跟上的请求进来的速度（别忘了，与此同时我还在Twitter组件了一个全新的基础设施团队）太困难了。所以当反馈/合并周期延长时有些人感到气馁了。
围绕自己开发的另一个缺点是，人们视我为一个项目失败的单点。不断有人提醒我如果我被车撞了会发生什么。这个问题确实限制了项目，超出了你的预想，像Storm，已被许多大公司所采用，但却以我为开发中心，它们包括Yahoo!、Groupon、天气频道，WebMD、Cerner、百度，阿里巴巴、淘宝以及许多其他公司。
最后，以自己为开发中心最糟糕的情况是我个人觉得负担很大。确实有巨大的压力，休息都很困难。然而，我依然很犹豫是否扩大项目开发控制给别人，因为我担心项目质量。没有其他人会像我一样对整个代码库有深入的了解，而且不可避免的，一下改变会带来意外后果。然而，我开始意识到这是扩展开发者社区时你要必须面对的。但我意识到这并不想我担心的那样是个大问题。
离开Twitter当我在2013年三月离开Twitter去追求我的新起点时，我仍然身处Storm开发的中心。几个月后，这成为一个需要优先删除的项目瓶颈。我觉得在共识驱动的发展模式下，Storm会更好发展。
我认为当项目还没有得到充分的探讨解空间“愿景驱动开发”是最好的。因此 Storm 包含我所有的决定，我们构建的多用户、自定义的度量、Trident以及主要性能重构都是好事。主要的设计问题只能由对整个项目有深入了解的人解决。
我离开Twitter的时候，我们已经绘制了Storm所能解决问题的模型。这并不是说没有更多创新的可能–Storm自那之后有了很多提升–但这些创新的改进并不一定是令人惊讶的。许多工作，自从我离开Twitter后Storm从ZeroMQ转为Netty，实现了安全/认证，提高了性能/可扩展性，提升了拓扑的可视化，等等。这些都是可怕的改进，但都是2013年三月时预期的改进方向。换句话说，我认为当问题解决空间仍具有很大不确定性时“愿景驱动开发”是必要的。当问题解决空间比较好理解时，“愿景驱动开发“的价值显著减少。然后会出现个人成为瓶颈而严重抑制项目的成长。
大约离开Twitter四个月的时候，Yahoo!的Andy Feng强烈建议我将Storm提交到Apache。那时我刚刚开始思考如何确保Storm的未来，Apache似乎是个有趣的想法。我会见了Hadoop的创造者Doug Cutting，获取他对Apache的看法以及Storm转移到Apache的潜在风险。Doug给我说了Apache如何工作的概述，坦诚地谈了Apache的利弊。他告诉我说，孵化器有些混乱，这最可能是过程中最痛苦的（但在实际中，过程却令人难以置信的平滑）。Doug的意见是非常宝贵，他真实帮我了解了共识驱动的开发模型。
在共识驱动开发中，至少包括其如何为许多Apache项目使用的，变更需要项目组“提交人员”的投票。通常一个变更需要至少两个+1同意并且没有-1反对票。这就意味着每个提交人员都有否决权。在一个共识驱动的项目中，不是每个人都会对代码有全面的了解。许多开发者会专注于代码的不同部分。随着时间的推移，一些参与者将学习到更多部分的代码并更深入的了解一切是如何配合的。
当Storm首先转移到共识驱动模型时，大多数的参与者对代码的理解不成整体比较有限，有的是不同专注领域的理解。这完全是因为我一直占主导开发地位的原因–没有人曾经被赋予他们需要学习更多以做出正确决定的责任。通过给其他人更多的权力和并退后一步，我希望别人能填补这一空白。这就是确切发生的。
当转移到共识驱动开发时我的一个担忧是开发质量会下降。而事实上，我们的转换中的一些变化导入了bug。但这没什么大不了的。因为你会得到错误报告，并在下个版本中解决这个问题。如果问题真的是很大，你可以放出一个紧急版本供他人使用。当我独自一人做所有开发决定时，我会自己彻底测试，并利用我对整个代码库的了解去释放高质量的代码。但即使这样，我的代码有时仍有bug，我们要在下个发布时解决它们。所以共识驱动开发也没有什么不同，除了变更的问题可能需要更多的迭代来解决这个不同。没有软件是完美的–重要的是，要有一个积极负责的开发社区，去迭代和解决出现的问题。
提交到Apache回到Storm的历史，离开Twitter几个月后我决定将Storm转换为共识驱动开发模式。我很专注于我的新起点，我也希望Storm有长期的住所会给用户的信心：Storm会有兴起的日子。我考虑所有的选项时，提交Storm到Apache似乎是最好的选择。Apache会给Storm带来强大的品牌，强大的法律基础以及我希望项目拥有的完全的共识驱动模型。
通过运用我从Doug Cutting的所学，我小心翼翼地将Storm往Apache转移：着手之前事先甄别孵化过程中可能引起的任何法律问题。Storm使用ZeroMQ库用于内部进程间通信，但不幸的是，ZeroMQ许可与Apache基金会的政策不相容。Yahoo!的一些开发者（他们后来成为Storm的提交者）推进并基于Netty创建了一个替代。
在形成Storm的初始提交者名单时，我选择了不同公司并对项目有较大贡献的开发者。一个人我超级高兴能够邀请到的是者是Taylor Goetz，他当时在健康科学市场（Health Market Science ）工作。我犹豫是否邀请他是因为他那时他还没有贡献代码。然而，他在社区和邮件列表上非常活跃，所以我决定在他身上试一下。成为体检者后，Taylor采取了大量的行动，分担了许多项目的管理负担。孵化期间他处理大部分细节的东西（比如顾及某些法律的事情，弄清楚如何将网站迁移到Apache，如何进行提交者的权限管理，管理发布，呼吁投票，等）。Taylor后来去了Hortonworks为Storm全职工作，他做了出色的工作来帮助Storm通过孵化器，他现在是该项目的PMC。
2013年九月，在Yahoo! Andy Feng的帮助下，我正式宣布Storm在Apache孵化。因为我们预先准备好了，建议中只有一些小的修改需要。
Apache孵化孵化过程中，我们必须证明我们能够保证发布，发展用户社区，并扩大项目的提交者。完成这所有内容我们没有遇到任何问题。一旦Storm孵化成功，我不再是瓶颈，开发迅速加速。提交补丁的迅速反馈促使了更多的贡献。我们鉴定大家贡献的重要性并邀请他们成为提交者。
因为孵化后我像其他提交人员一样只是提交者，投票的比重也是一样的。我集中精力关注影响Storm核心的任何问题，或那些有困难的设计决策。这样更有效地利用我的时间，能够审查每个小小的变化也是项巨大的安慰。
Storm在2014年9月17日正式步入顶级项目的行列，在开源后短短的三年后。
构建Storm并发展到现在是段不易的旅程。我认识到创建一个成功的项目需要的不仅仅是产生好的代码来解决重要的问题。文档，营销，以及社区的发展也同样重要。特别是在早期的时候，你必须要有创意并想出清晰的方法来起始项目。我所做的是利用Twitter的品牌，从邮件列表开始直到发布前几个月，并做一个最大限度地曝光。此外，参与建设一个成功的项目还有很多繁琐费时的工作，如写文档，回答无休止邮件列表上的问题，培训宣讲。
我看到的最惊人的事情是Storm对行业大范围的影响。在Powered By页上，有医疗保健，天气，新闻，分析，拍卖，广告，旅游，报警，金融等诸多领域的应用。阅读该页回顾大量工作我觉得对Storm的投入是值得的。
讲述这个故事的过程中我无法包括每个细节（毕竟三年是段很长的时间）。所以我想通过列出那些对Storm今日的所成重要的人物。我对所有这些人非常感激：Chris Aniszczyk, Ashley Brown, Doug Cutting, Derek Dagit, Ted Dunning, Robert Evans, Andy Feng, Taylor Goetz, Christopher Golda, Edmund Jackson, Jason Jackson, Jeff Kaditz, Jennifer Lee, Michael Montano, Michael Noll, Adrian Petrescu, Adam Schuck, James Xu以及那些曾为项目贡献过补丁、部署过生产环境，写使用经历或推介过它的人。