History of Apache Storm and lessons learned
——專案建立者 Nathan Marz
Apache Storm 最近成為了ASF的頂級專案，這對於該專案和我個人而言是一個重大的里程碑。很難想像4年前Storm只是我腦海中的一個想法，但現在卻成為了一個有著大社群支援並被無數企業使用的繁榮專案。在此我將在本文中回首Storm的成長曆程及其經驗教訓。
我會根據我當初必須要克服的主要挑戰來涵蓋Storm歷史的相關主題。本文前25%是關於Storm是如何構思並初創的， 所以主要討論促使我開發這個專案的技術問題。其餘部分是關於Storm的釋出並由活躍使用者和開發者社群將其發展成一個廣泛使用的專案的發展過程。本文主要討論了Storm的營銷，傳播和社群的發展。
任何成功的專案都要滿足兩個條件:
1. 它解決了一個實用的問題
2. 你有足夠的能力說服很多人使他們相信你的專案是解決他們問題的最佳方案。
我認為很多開發者難以理解的是實現第二個條件與構建專案本身一樣困難和有趣。我希望在閱讀Storm的歷史時能給你一些啟發。
Storm來源
Storm來自於我在BackType的工作. 在BackType我們的工作是產品分析以幫助使用者實時的瞭解他們的產品對社交媒體的影響,當然也能查詢到歷史記錄. 在Storm之前,實時部分的實現用的是標準的佇列和worker的方法. 比如, 我們向一個佇列集合裡面寫入Twitter firehose, 再用Python worker從這個佇列集合讀取tweets並處理他們. 通常情況下這些worker需要通過另一個佇列集合向另一個worker集合傳送訊息來進一步處理這些tweets.
我們非常不滿意這種處理方式. 這種方法不穩定——我們必須要保證所有的佇列和worker一直處於工作狀態——並且在構建apps它也顯得很笨重. 我們寫的大部分邏輯都集中在從哪傳送/獲取資訊和怎樣序列化/反序列化這些訊息等等. 但是在實際的業務邏輯裡面它只是程式碼庫的一小部分.再加上一個應用的正確邏輯應該是可以跨多個worker,並且這些worker之間是可以獨立部署的. 一個應用的邏輯也應該是自我約束的.
初探
在2010年12月，我完成了第一個重大實現。也就是在那時我想出了將"stream"作為分散式抽象的想法。stream會被並行地產生和處理，但它們可以在一個程式中被表示為一個單獨的抽象。這使我產生了"spout"和"bolt"的想法——spout生產全新的stream, 而bolt將產生的stream作為輸入併產出stream。這就是spout和bolt的並行本質， 它與hadoop中mapper和reducer的並行原理相似。bolt只需簡單地對其要進行處理的stream進行註冊，並指出接入的stream在 bolt中的劃分方式。最後，我所想到的頂級抽象就是"topology"——由spout和bolt組成的網路。
我在BackType測試了這些抽象的用例，並且它們之間契合地非常好。我對於它的結果非常滿意：我們之前需要處理的繁重工作——傳送／接收訊息，序列化，部署等都能通過這些新的抽象實現自動化。
在開始構建Storm之前，我想用更廣泛的用例集來驗證我的想法。所以我發了這條微博:
我正在研究一個全新的流處理系統。如果你對這個感興趣請聯絡我，我需要你的用例。
——Nathan Marz (@nathanmarz) December 14, 2010
有一群人迴應了我，並且我們通過郵件來相互交流。很明顯，我的抽象非常非常合理。
然後我開始了Storm的設計。在我嘗試找出spout和bolt間傳遞訊息的方式時我很快就被卡住了。我最初的想法是模仿我們之前採用的佇列和工人方法並使用一個像 RabbitMQ 的訊息代理來傳遞中間訊息。我實際花費了大量時間來研究RabbitMQ用於此目的的方案和操作上的影響。但是，為中間訊息使用訊息代理的想法似乎並不好，於是我決定暫時擱置Storm直到我能想到更好的方法。
再探
我認為需要那些中間訊息代理的原因是為資料的處理提供保障。如果一個bolt處理訊息時失敗了，它可以從取得該訊息的代理中重試。但是對於中間訊息代理，有很多問題困擾著我：
-
它們是部署於Storm之外的巨大，複雜的可移動部分
-
它們建立了不合適的環境，例如當重新部署topology時該如何處置. 這些代理中很可能還有與新版本topology不相容的中間訊息。所以這些訊息需要以某種方式清理或忽略掉。
-
它們複雜化了容錯性。不僅要指出當Storm worker崩潰時的處理方式，我也要指出在某一代理崩潰時該如何做。
-
它們很慢. 訊息不是直接在spout和bolt間傳遞的，而是經過了第三方的代理，此外訊息還要儲存到磁碟上。
直覺告訴我，還有一種不使用中間訊息代理也能實現訊息處理保障的方式。所以我花費了很長時間思考在spout和bolt間直接傳遞訊息時該如何保障訊息的處理。不便用中間訊息持久化，這意味著需要從訊息來源(spout)中進行重試。棘手的是失敗可能發生在spout下游的任何地方或另一臺伺服器上，並且這些失敗需要精準檢測到。
在苦思冥想了幾周後我突然靈光一現。我開發了一個基於隨機數和異或運算的演算法，它只需大約20位元組就可以跟蹤每個spout tuple, 不論下游觸發了多少處理過程。它是我研究出的最優演算法之一，它也是在我生涯中有限的幾次，可以說如果沒有接受良好的電腦科學教育我是不會想出的演算法。
在想出這個演算法之後，我知道我已經取得了重大突破。因為避免了上面提及的所有問題，所以它大大簡化了storm系統的設計，並提供了一種更加高效的方式。(有趣的是，在我想出這個演算法的當天，我還有一個跟最近認識的女孩的約會。但我對該發現是如此激動以致於在整個約會期間我都心不在焉。不用說，我對不住那女孩.)
構建第一個版本
在下面的5個月裡，我構建了Storm的第一個版本。從一開始我就知道我會開源，因此一開始我在心裡就做了一些關鍵的決定。首先，我用Java實現了Storm的所有API，但用Clojure來實現Storm。通過將Storm的API 100%的Java實現，以確保它有一個非常大的潛在使用者群體。而使用Clojure來實現，我能夠更高效以使專案進展地更快。
一開始時我也計劃在非JVM的語言中使用Storm。拓撲被定義為Thrift的資料結構並提交了一個Thrift的API。除此之外，我設計了一個協議使得spouts和bolts可以在任何語言中的實現。Storm可以應用在其他語言讓更多的人使用了專案。它讓人們遷移到Storm中更容易，因為他們不必用 JAVA 重寫現有的實時處理器。相反，他們可以遷移現有的程式碼執行在Storm的多語言的API上。
我是Hadoop的長期使用者，用我已有的Hadoop經驗來設計Storm使得Storm會更好.比如, 在Hadoop的workers不關閉，所有的程式不做任何操作的情況下。這些”僵死程式“積累到一定程度用盡了所有的資源，最終會導致這個叢集停止不能運作——Hadoop最嚴重的問題之一. 這個問題的關鍵在於Hadoop中關閉worker的工作是由它自身負責。但是有時會因為其他很多原因導致worker自我關閉失敗. 所以在Storm的設計裡面，我把關閉worker的任務交給第一次啟動這個worker的daemon負責.最後也證明Storm的這種設計比 Hadoop更魯棒,也不存在”殭屍程式”的問題.
我在Hadoop中遇到的另一個問題就是如果JobTracker因為某種原因停掉,那麼在這個JobTracker跑的所有的任務都會終止.真正讓人著急的是已經跑了幾天的任務就這樣被停止了.在Storm裡面不會存在單個節點失敗的問題，因為“topologies"是一旦開始就不會停止的。因為設計 Storm時就加入了”程式容錯“機制：一個Storm daemon的停止和重啟對一個正在執行的topologies絕對不會有影響. 當然這種考量會使設計面臨更多的挑戰，因為你必須要考慮到程式可能在任何時候用kill -9強行停止和重啟的情況,但是這樣也使它更健壯。
在開發階段的早期我做的一個很關鍵性的決定就是讓我們的一個實習生--Jason Jackson-- 在AWS上做一個Storm的自動部署工具.這個工具在很大程度加快了Storm的開發，因為它能夠讓我很容易的測試不同大小的叢集和配置， 並且迭代更快.
被Twitter收購
2011年5月,BackType與Twitter談收購問題. 從各方面來講，這次收購對我們來講非常的重要.另外, 對我個人而言也很具有吸引力,因為Twitter品牌效應的作用，由Twitter來發布Storm比由BackType釋出更能讓Storm有所作為.
在收購談判期間,我在BackType's的科技板塊釋出了一篇部落格向世界宣佈了Storm的存在. 這篇部落格的真正目的僅僅是為了在與Twitter的談判中增加我們的談判籌碼.它確實起到了作用：Twitter對這項技術特別感興趣，在做技能評測的時候，整個評測就演變成了一次大型的Storm演示.
這引發了其他令人驚訝的影響。在那篇部落格上我不經意的提及Storm作為 “實時的Hadoop” ，這句話就這樣流行起來。直到現在人們還在使用它，甚至被許多人簡潔地稱為 “實時Hadoop” 。這個意外的品牌是非常強有力的，也有利於推廣。
開源的Storm
我們在官方上加入Twitter是在2011年七月，之後我立即開始計劃Storm的釋出。
有兩種方式你可以取得釋出版的開源軟體。第一種是“使之變大”，為專案做許多宣傳，儘可能多地在釋出的時候增加曝光率。這條途徑會有風險（如果軟體質量有缺陷或者你陷入困境，專案的人氣就會與日遞減）。那樣就會殺死任何有可能成功的專案。
第二條途徑是安靜地釋出程式碼並且讓軟體緩慢地獲得認可。這避免了第一種途徑的風險，（因為）它所擁有的風險與人們檢視工程是無關緊要的，可以忽略。
我決定採用第一種方式。 我知道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 討論組 http://t.co/S7TJlCB。 — 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，允許使用者徹底地收藏定製的、任意度量，併傳送給任何控制系統。
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以及那些曾為專案貢獻過補丁、部署過生產環境，寫使用經歷或推介過它的人。