Weex開源首月記

本文中的連接多指向目前「內測」階段的Weex Github倉庫 ，如訪問時頁面出現404提示，歡迎到http://alibaba.github.io/weex/提交內測申請。

Weex於 2016年4月21日在北京QCon大會上宣佈開源並同時上線開源站點(http://alibaba.github.io/weex/) 已近一月。對於技術同窗來講,」開源」一詞確定常常聽聞，很多同窗仍是知名或低調的開源項目的參與者或建立者。 但此次「Weex開源」第一次讓咱們一個技術團隊集體參與到開源項目中來, 其中經歷，心得和收穫我想不管是對於參與其中的同窗，兄弟技術團隊乃至業界都是有價值的。 但願本次和其後的記錄能給你們帶來幫助。

「內測」與邀請

看多了很多「曬代碼後撂下無論」式的開源項目 , 也觀摩了不少代碼質量，開發過程，社區活躍狀況皆優的開源項目。同時，Weex又已經在阿里內部開發了近一年時間，並已運用於多個關鍵阿里產品裏。 出於對「開源」和「數據安全」的敬畏, 咱們決定採用如下三步走的策略來推動開源過程。

1. 創建Github私有倉庫，待經過專利，安全，集團開源委員會審覈後把代碼push到Github私有倉庫，同時遷移開發過程到Github。

2. 逐步分批邀請項目組以外的同窗以 「Collaborator」的身份得到Weex Github倉庫訪問權限，在明確告知現狀和規則後，邀請參與Weex開發。

3. 徹底開放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開源社區成爲一個更好的地方。

阿里百川（baichuan.taobao.com）是阿里巴巴集團的無線開放平臺，經過「技術、商業及大數據」的開放，提供移動場景下的高內聚、開放式、行業領先的技術產品矩陣、成熟的商業組件和完善的服務體系，幫助移動開發者快速搭建APP、加速APP商業化進程，全方位賦能移動開發者及移動創業者。