本文中的連結多指向目前“内測”階段的weex github倉庫 ，如通路時頁面出現404提示，歡迎到http://alibaba.github.io/weex/送出内測申請。
weex于 2016年4月21日在北京qcon大會上宣布開源并同時上線開源站點(http://alibaba.github.io/weex/) 已近一月。對于技術同學來說,”開源”一詞肯定經常聽聞，不少同學還是知名或低調的開源項目的參與者或建立者。 但這次“weex開源”第一次讓我們一個技術團隊集體參與到開源項目中來, 其中經曆，心得和收獲我想無論是對于參與其中的同學，兄弟技術團隊乃至業界都是有價值的。 希望本次和其後的記錄能給大家帶來幫助。
“内測”與邀請
看多了不少“曬代碼後撂下不管”式的開源項目 , 也觀摩了很多代碼品質，開發過程，社群活躍情況皆優的開源項目。同時，weex又已經在阿裡内部開發了近一年時間，并已運用于多個關鍵阿裡産品裡。 出于對“開源”和“資料安全”的敬畏, 我們決定采用以下三步走的政策來推進開源過程。
建立github私有倉庫，待通過專利，安全，集團開源委員會稽核後把代碼push到github私有倉庫，同時遷移開發過程到github。
逐漸分批邀請項目組之外的同學以 “collaborator”的身份獲得weex github倉庫通路權限，在明确告知現狀和規則後，邀請參與weex開發。
完全開放github倉庫通路權限。
我們目前處于第二階段 , 對weex感興趣的同學請通路 http://alibaba.github.io/weex/ 送出你的個人郵箱和github id, weex項目組期待與你在github相會。
社群活躍情況
開源首月，截至至2016/05/12, 一共有3414位使用者向我們送出了内測申請， 我們分11批邀請了其中資訊較為完整 (有工作/組織資訊，有githubid ,githubid有活躍記錄) 的1962位使用者成為我們的github “collaborator”， 月内，這些最早的weex外部種子使用者一共給我們送出了130項github issue 。某種程度上，這些issue可以看做業界對weex的第一印象，項目組同學們對此非常重視，在每一項issue下面熱情的為提出issue的同學答疑解惑， 目前已有92項issue得到了解決。
github issue 除了作為“技術支援”的管道， 同時也是借助社群力量幫助weex完善的平台。
通過這些issue，有同學指出我們文檔中的typo ; 有同學給我們提了元件完善建議(https://github.com/alibaba/weex/issues/63)；有同學甚至研究了我們的底層渲染政策後給出了可行的改進建議(https://github.com/alibaba/weex/issues/176); 有同學通過issue宣傳自己的weex技術交流qq群(https://github.com/alibaba/weex/issues/220) ; 當然，也有[這樣](https://github.com/alibaba/weex/issues/148)讓清單氣氛歡樂起來，最後不得不鎖帖的issue。
在自身的改進之外，作為一款ui架構，我們最期待使用者能通過weex做出新的，超出我們預計的app或demo , 首月内，我們看到了内測參與同學的回應(https://github.com/alibaba/weex/issues/222) ， 雖然略顯簡單，但weex項目組同學非常珍視，因為這令我們想起了改變世界的web最初的時候，質樸中蘊含着無限的可能。
月内改進
可視化直覺呈現開發過程資料是github吸引開發者的一大特性, 通過下面的圖表可以直覺的看出在weex開源首月，一共有25位同學在weex github倉庫進行了401次送出和98次分枝間的pull request。
具體的變更記錄可以在這裡(https://github.com/alibaba/weex/pulse/monthly)檢視， 為了保證工程品質，同時讓新開發者參與weex項目更容易，我們參考了多個開源項目後制定了關于 commit log 和 branch name的格式規範(https://github.com/alibaba/weex/blob/dev/contributing.md). 每個内測期受邀的使用者，都會在代碼庫賦權通知郵件中被強調在開始參與weex前需要學習并遵守這些規範。
本月之内的工作多是完善，改進和優化。 内置元件中新增了移動應用中常見的navigation bar和tab bar ， list元件也添加了很多同學期待已久的"pull to refresh"特性。weexdsl文法也有所增強, 馬上同學們就能使用起 require/ inline event / require / compute等讓你寫we時更趁手一些的新文法。
完整的change log, 我們會在随後兩天内和weex 0.5版一起在github(https://github.com/alibaba/weex)上釋出。
經驗教訓
weex的代碼組織結構在開源前發生了一次較大的變化， 在github送出前，我們把内部的10多個倉庫中的内容合并到一個主倉庫中. 這樣做的好處是可以友善外部使用者更快上手同時彙聚社群關注. 但為項目組也帶來了不小的工程負擔, 原來可以在不同倉庫中分而治之的android ,ios, javascript團隊現在需要在一個倉庫中協作. 每個部分都有獨立的建構過程，同時又需要協調一緻。
我們初步的解決思路是讓不同的功能團隊在不同的分枝中進行開發,功能完成後再合并到主分枝。
雖然在同一個庫中，weex不同部分依賴形式各不相同，有基于代碼的依賴，有基于建構産出的依賴。 為了修複問題，某個分枝會産生緊急變更，獨立建構版本提供給weex使用者. 面對這樣的情況， 我們最初較為簡單的分枝政策經曆幾次疊代就顯現出局限性了，功能分枝合并時都每每遇到各種問題。
為了應對這種情況，我們把分枝政策進行了更新。 最新的政策(https://github.com/alibaba/weex/releases)如下圖所示：
我們希望通過多層次的分枝結合ci ， 能應付後續更複雜的代碼管理情景。
近期規劃
weex目前隻開源了android部分, 我們知道對于想嘗試基于weex跨終端開發的同學這是倉促不周的，目前，weex 開源團隊正在全力準備. 預計到6月初ios渲染器就會和html5渲染器，功能更豐富的指令行工具一起“準備好行頭"來到github和大家相見。
後續，我們會根據大家在github issue 清單(https://github.com/alibaba/weex/issues)裡的讨論，把一些有共性的問題彙總,通過文檔或blog做答。也歡迎大家嘗試把自己的weex使用體驗，對weex的所思所想記錄成文投遞給我們, 讓這裡的文章更加豐富，讓其他使用者學到新知識, 讓weex開源社群成為一個更好的地方。