如何看待 swoole 作者最近修改開源協議？

01-16

swoole 作者的微博：
http://weibo.com/u/1072494141
zan 作者微博：
http://weibo.com/u/2013413444
搜索「協議」兩個字就可以大概知道來龍去脈了。
swoole 作者韓天峰在國內是僅次於鳥哥的 php 大佬了，有贊基於 swoole1.8 的 fork 開發了新的 zan 擴展，由於一些不愉快的細節導致 swoole 作者不滿，swoole 作者最後決定修改 swoole2.x 的協議甚至用 GPL 協議的 PHP-X 重寫 swoole1.x
就我個人來說非常樂意見到一個 swoole 的 fork 出來挑戰 swoole，也不想看到作為 pecl 擴展一員的 swoole 採用更嚴厲的協議甚至禁止後來者再基於 swoole 的 fork 開發新的擴展，不知道大家怎麼看？

swoole： https://github.com/swoole/swoole-src
zan： https://github.com/youzan/zan

這事都驚動 @vczh 大神了，我得回答一下。首先說一下swoole的歷史，我從2010年開始就一直嘗試用php寫server了，早期swoole是用php代碼基於php的stream pcntl socket libevent 實現，php的版本後來在2012年使用c進行了重構，一直開發維護到現在。一個通信引擎看似簡單實際非常複雜，最艱難還是多線程並發性問題，無數日夜苦思冥想，才得以解決。2010年我23歲，現在30歲。能堅持這麼久，最關鍵的是對技術的興趣和熱情。這個項目有很多貢獻者，有中國人也有外國人。從默默無聞到PHP之父Rasmus也為之點贊。實屬不易。

這個項目的主力開發就是我了，付出了很多心血和精力。因為我還在公司任職，所以基本上是抽空開發，只有周末有整天連續的開發時間。所以swoole在測試用例、代碼評審、文檔編寫方面並不完善，包括官網都很醜，我很希望看到有公司力量加入，幫助完善swoole。而且我也願意讓出項目控制權，其實現在swoole group的owner已經有三位了，除了我之外騰訊的兩位成員司超和朱新宇也是owner。

有兩家公司對swoole表示出了興趣，這就是騰訊和某贊，兩家公司都邀請我做過技術分享，為他們的技術團隊講解swoole，而且事後都建了QQ群，方便大家交流。有很多次對方諮詢我swoole的細節問題，我也會抽空解答。但最終結局完全是不同的。騰訊團隊貢獻出了 Swoole2.0 協程，某贊默默地拉了個分支。

我曾多次向某贊的開發者說你們可以向swoole貢獻代碼啊，大家一起共建，這樣才能發展的更好。但最終結果大家都看到了。矛盾激化是在他們即將發布前幾個月，他們宣稱自己的分支實現了更高效的時間輪演算法，我就直接指責你為什麼就不願意貢獻給swoole呢，對方的回復是「想要等我們開源出來自己拿去，我們可沒空給你送上門」。你們用了swoole的代碼，卻沒有給swoole貢獻過任何東西，現在還到處抹黑swoole抬高自己，其中某人還來攻擊我。

我如果沒情緒就是聖人了，在微博上說的要改協議禁止拉分支與swoole競爭也都是一時氣話。最終因為很多人轉發我也刪除了。經過長期的考慮最後決定使用PHP協議，這個協議其實非常寬鬆，接近bsd了，只禁止這些商業公司的fork分支拿swoole來做宣傳。改授權協議是為了swoole項目的長遠發展，PHP協議可以保護開源社區不被商業公司利用。其實當初選Apache協議主要是@Laruence提出PECL更喜歡BSD、Apache、PHP協議，沒想到那麼多選了最簡單的Apache協議，現在來看PHP協議是最合適的。

開源世界有兩條線，高標準是尊重原作者貢獻代碼等等，底線遵守 license就可以了，尊不尊重原作者無所謂，貢獻不貢獻代碼也無所謂。他們只是選擇了後者而已，並沒有錯。如果是越過底線我肯定直接請GitHub官方刪除其項目了。都是吃瓜群眾拱火導致的，非要引起爭論，還引來好多大V關注。我其實不太願意回答這些問題。也不願意和某贊發生爭吵。我一直在說做好自己的事情就可以了。

他們這樣做的目的再明顯不過了，擴大技術影響力，提升公司的品牌形象。只是吃相太難看了點。我相信被盯上的開源項目也肯定不只swoole一個。

如今我已經意識到了一個開源項目如果要更進一步，確實需要商業化，需要組建一支裝備精良的研發團隊，需要開發流程規範化，需要設計師為swoole設計logo和頁面。還需要編輯和翻譯完善文檔，更需要測試人員把控質量。我和我的夥伴們已經開始做了。

作為原生的團隊我們怎麼可能懼怕技術競爭呢，沒有人比我更熟悉swoole了。

swoole這個問題一般的協議是解決不了的。像我的做法是這樣的：我不管你拿我的代碼幹什麼（Apache 2.0），但是只要你改了文件（添加我不管），就一定要向我開源。如果你發布了不管有沒有修改的代碼，我的庫的部分「向我開源」這條規則不能變，要繼續傳下去（逃

這就是傳說中的跟GPL相反的做法，從感染+向用戶開源，變成不感染+向原作者開源。雖然估計不會有人來fork什麼GacUI。如果你只是只讀地使用，那基本上不會受到任何限制。

6月23日更新：

我就補副圖，各位看官自己評價

說真的，我們內部也討論過了，確實是Rango有些激動，不過我們還是打算更換到PHP開源協議，至於有的人說換協議就是不尊重開源精神，我只能報以呵呵，開源協議換到另外一個開源協議就不叫開源這個道理恕我不能理解。何況Rango也沒有說過什麼不允許再次發布，我們只是不想有人拿我們辛苦開發的成果反過來攻擊我們。

此事也就就此揭過，Swoole團隊會遵循協議規定做該做的事情，至於有的人嘛，他跳任他跳，清風拂山崗~

以上。

======== 以下為原回答 ==================

利益相關：Swoole開發組成員之一

作為Swoole開發組的成員來回答一下這個問題。

首先說一下背景，起因很簡單，代維（大門）帶領的Zan團隊最初基於Swoole 1.8.5版本開發了ZanPHP框架，但是由於1.8.6版本升級改動了某些API，代維極為不爽並在Swoole群里向Rango韓天峰開火，隨後表示Zan團隊將開發一個自己的版本。Rango就此事也表示沒有異議，並且還在一定程度上指導過Zan團隊的相關改造。

但是隨後的事情就很無賴了，Zan團隊修改的Swoole雖然號稱基於1.8.5版本，但是Swoole版本後續的BUG修復merge以及一些新特性的提交也都被合併了過去，並且Zan團隊是直接將最後的成果提交在Github上，隱藏了所有的提交記錄。

其實到這裡都無所謂，你一個公司開發一個私有版本無可厚非，但是隨後代維宣布將開源他們的開發版本，這對於Rango來說，完全就是有人偷了自己的東西還要來跟自己打擂台，因此Rango非常氣憤的在開發組內部群里說到了此事，並跟代維爆發了第一次爭執，隨後宣布Swoole擴展將修改開源協議，只是當時並未確定。

後來就是今年的開發者大會前夕了，Zan團隊高調發布zan-extension，並加上了諸如「修改大量BUG」、「完全遵循Apache協議（諷刺Rango修改協議一事）」等話語，並且在發布的Github版本中並沒有正確標註Copyright，僅在一個聲明文件中標註了一句（隨後在Rango的堅持下，Zan團隊加上了Copyright）。在這之後，Rango宣布Swoole將修改為使用PHP開源協議。

以上就是此事的大概經過，我認為Rango作為Swoole創作者，看到自己的勞動成果被人拿來跟自己抗爭，並且抹黑自己的作品，生氣是一定的，而且Rango作為作者，本身就擁有修改開源協議的權利，這一點我們開發組全體成員都是支持Rango的行為的。通過修改協議來保障開源作者本身的利益，這一點沒有任何人可以指摘。

反觀代維，我就截幾張圖

我也沒什麼好說的，我還真不知道Swoole能從zan那邊拿什麼代碼，連接池是從1.8版本前就有，時間輪Rango用了一天就自己開發完了。

對，開源人，勿忘初心，要是開源人都跟你這樣我估計開源也進行不下去的。我們從來不怕別人做出更好的東西幹掉我們，我們只是怕宵小肆意剽竊我們的勞動成果還反黑我們。

這次我就只上圖了，仁者見仁，智者見智。

Swoole從Apache License改為使用PHP License,有什麼問題么?人家峰哥是項目的創造者(Creator),人家有權切換授權協議.

而且PHP License挺好呀,BSD風格,挺寬鬆的呀,只不過其中一些限制條款,比如不能拿原有項目的名稱用作自己衍生產品的商業宣傳,這有利於項目發起者,又不影響項目使用者,只不過讓那些想把Swoole拿過來改改就據為己有的個人或組織不爽而已.

http://php.net/license/

其實就算Swoole改成最嚴格的AGPL協議,我也不會反對.比如MongoDB就是AGPL授權的軟體,影響大夥使用了么?

說實話呢，拿了swoole的代碼，還說要超越swoole也不是不可以的，協議上是沒有問題的，作者都說了之前的代碼你拿去就好了，自立門戶我也不管。但是後面的代碼你還來抄我的，說成是自己的代碼這就不對了。

可以看懂代碼，但是要寫出和原來一樣水平高的框架需要的知識深度是不同的。60分和99分的區別

我成立了一個外包公司，雖然只有我一個人，但是誰不是一個人走來的。之前接過一些項目，但也就賺幾個小錢，大富大貴還離我很遠啊。由於之前從事QT客戶端工作，但是那些客戶啊都說我們技術深度不夠，用別人的框架，小修小補，誰不會啊，壓低價格。於是我重新選擇了gay UI作為我的開發框架。

我花幾天看了 @vczh 的gay UI感覺真簡單，不就是調調API嘛，於是用gay UI做了幾個demo。發現也用不好，於是我加入了輪子哥的telegram交流群（一種類似QQ群的東西），在得到輪子哥的親自傳教之後我很快就會用gay ui了。

再看看源代碼，我也能寫個gay UI啊（自大說的就是我），我還感覺gay UI好多地方寫的不好啊，好多功能都沒有，我能做的更好啊。

其實我想重新寫一個。唉，重新寫一個太麻煩了（懶癌發作），就把源碼copy上傳到github上面開源了，起了個很酷炫的名字lesbian UI，還封裝了若干組件。其實就是瞎幾把改，增加bug，反正你們你們又不會用；輪子哥還在美帝呢，難道你坐飛機過來打我？我又不犯法，打傷我可是要負法律責任的。於是我擁有了第一個開源項目。

你以為我都目的就是上傳個開源項目這麼簡單？不不不，我可是個要成為海賊王的男人。

憑著我這個lesbian UI開源項目展現出來強大技術能力和我的吹水能力（腳踩QT，拳打gay UI），終於搞到了幾個政府項目。

我雖然copy了輪子哥的項目，但是我沒能力改底層代碼啊。輪子哥都更新gay UI好多輪了，看看更新日誌。厲害了我的哥，還增加了很多6666的特性，改了這麼多bug。我怎麼能讓我的lesbian UI落後，我果斷把更新扒下，用我的賬號更新到我的lesbian UI上。

終於，還是有些人發現了我的做為。說的我這個lesbian UI項目抄的啦，巴拉巴拉一堆沒完。我說輪子哥的gay UI好多地方單詞都拼錯了，比如for都寫成fot，這個錯誤還好幾個版本都沒改，這個我都是看在眼裡的，這麼簡單的錯誤還犯，你能說你代碼比我好？我更新上去了輪子哥你可別來抄。最終我還是忍著沒說，畢竟悶聲發大財就好了。

輪子哥知道這件事後還在美帝呢，他也不跟我計較這些。因為我還是有點良心的，沒有跑去全世界說lesbian UI腳踩QT，拳打gay UI。我就自個high而已。

突然的哄堂大笑把我吵醒了，睜開惺忪睡眼。

有的叫道，「孔乙己，你臉上又添上新傷疤了！」

他不回答，對櫃里說，「溫兩碗酒，要一碟茴香豆。」便排出九文大錢。

他們又故意的高聲嚷道，「你一定又偷了人家的東西了！」

孔乙己睜大眼睛說，「你怎麼這樣憑空污人清白……」

「什麼清白？我前天親眼見你偷了何家的書，吊著打。」

孔乙己便漲紅了臉，額上的青筋條條綻出，爭辯道，「竊書不能算偷……竊書！……讀書人的事，能算偷么？」

接連便是難懂的話，什麼「君子固窮」，什麼「者乎」之類，引得眾人都鬨笑起來：

店內外充滿了快活的空氣。

我在v2ex也提了一個相同的問題：https://www.v2ex.com/t/370392 ，那邊有人支持swoole作者也有人支持youzan，討論基本上把問題實質講清楚了；然而逼乎的回答幾乎都是一邊倒向swoole作者，基本沒有觸及問題實質的東西，倒是一堆道德綁架煽情的，逼乎的姿勢水平有待提高啊。

懶得去讀v2ex討論細節的逼乎er，這裡還是給看熱鬧的你們總結一下。

結論：我支持有贊

理由：

1，swoole作者企圖禁止別人在swoole基礎上做derivative work，這是Apache 2.0協議也好GPL協議也好PHP協議也好等開源協議所不允許的，這是原則性的問題，任何對開源有一定認識的人應該很敏感的指出這一點

2，swoole要把swoole2.x協議從Apache 2.0改成PHP協議也好，swoole1.x用GPL協議的PHP-X重寫也好，需要得到所有contributor的同意，不是說作者想改就能改的；況且換成PHP協議並不能達到禁止derivative work的目的，情緒化的換協議會讓swoole的用戶感到困惑

3，swoole的開發者做出了非常漂亮的工作，奠定了swoole生態的基礎，對於有贊的derivative work的挑戰感到壓力，並且由此導致了一系列的互恁。我認為swoole作者應該擺正心態。

4，從社區發展上，zan作為swoole的derivative work出來和swoole競爭，對社區的進步是有利的，derivative work是應該鼓勵的。實際上swoole團隊最近的一些傾向恰恰說明了它需要一些競爭，比如swoole作者開php-x的坑（業界已經有php-cpp這樣的很優秀的工作了），比如開商用化的swoole compiler（類似於zend guard），實際上有贊的工作也促使swoole作者微博上宣布組建團隊專門維護swoole

5，有贊的zan把swoole的commit合併過來也好，swoole把zan的commit合併過來也好，都是沒有問題的，是值得鼓勵的，開源業界也都是這樣做的

6，有贊的zan把swoole原來的commit記錄去掉從0開始雖然不太優雅，但是並不違背Apache2.0開源協議

從個人情感上來說，我是個比較叛逆的人，看到有贊在github在QQ群在微博上恁swoole作者，我覺得很這種you can you up的風格很帥氣。我覺得你工作做的不好，但我就不想給你提pr提issue我就要自己干，我改進的地方你想要可以啊自己來merge啊。

此外有贊團隊剛在phpconf2017上海分享的zanphp微服務方案很完整很領先的，我很敬佩這支技術團隊。另外峰哥我其實也很敬佩，很早就微博關注了他，峰哥對php社區的熱愛和投入可以在微博上強烈感受到，不過這次我要站有贊一邊了。

作為一個phper我覺得有贊的工作和swoole的工作都做得很漂亮，2個團隊都是非常值得敬佩的。我推薦大家關注有贊的大門的微博和swoole的峰哥的微博，看他們互恁非常歡樂。

我支持韓老師修改協議，因為我是BSD粉絲，哈哈…

Apache和PHP的License都跟BSD差不多。Apache偏向於你必須包含我Apache信息幫我宣傳…

PHP偏向於你不能包含我PHP名字來幫你宣傳，只能說你是工作在我PHP下（xxx for PHP，not xxxPHP）。相對而言PHP的License更接近BSD 3clause…

個人感覺韓老師以前更多的是藉助swoole推廣自己網站其他產品，導致新菜鳥用戶經常跑他網站不知道下哪個東西，以前看了記得還重名的一堆東西，如果swoole獨立發展，發展肯定不止現在這個局面，當然這沒錯，人家奉獻了那麼多精力…

作為PHP擴展改到PHP協議總歸是好的，希望韓老師以後更多的是打造一個聞名世界的好擴展，把手冊和網站都搞得獨立專業點，這樣老外也會用的多…

另外韓老師有可以合併到PHP源碼的好想法，也可以學習鳥哥方式奉獻點，這樣PHP才會慢慢有質的突破，如果沒有鳥哥這種奉獻，PHP7也不會這麼NB…

要努力學習C，希望有一天能幫上諸位大神什麼忙…

如要用我是只會用韓老師的，不會用那個zan的，個人喜好…

btw：

今天發現被輪子哥拉黑了，不知道因為啥回復拉黑的，看來輪子哥很玻璃心啊，不允許跟他不同意見… (-.-;)

真有能力的話，從零挖個坑，別說些什麼『修改大量bug』，『進行大量優化』的勞什子。

swoole即使有bug，優化不夠極致又如何，swoole是第一個開源的工業級非同步拓展庫，swoole就是牛x。

國內一些互聯網創業公司的技術leader真是想出名想瘋了，吃相真是讓人不舒服。

不過，不管怎麼樣，都是zan團隊的勝利，畢竟出罵名也算出名了，不是嗎？

1. 與 swoole 項目沒有重大分歧，選擇另開分支（而不是把代碼貢獻給主分支）。

OK，沒關係。也許人家後續有大動作呢。開源力量是分散了點，但「有望」看到更牛逼的框架，也算好事一件。（暫時先把「集中力量干大事」放一邊，假設所有人的初衷都是 make the world better。

2. 對外宣稱：我們的項目基於大名鼎鼎的 swoole 哦，增加了一些新特性和擴展。我們的目標是更快更高更強！（有望最終取代 swoole 項目哦）

無可厚非。忽悠人來使用，忽悠碼農貢獻代碼，這是每個開發者必備技能。

至於原 swoole 的一群人 …… 任何人聽到別人要取代自己，多少會有點不爽吧。但你不爽歸不爽，我們吃瓜群眾只管看戲，哪個框架好用就用哪個咯。

3. 哎呀，好像沒忽悠來多少用戶和開發者呀。看看隔壁 swoole 又增加了一些新特性，看著就眼饞。這批孫子怎麼不想著給我來提交 PR？！先不管，我自己手動把代碼合併過來再說。至於原提交者姓誰名誰…… 就你那點代碼提交量，好意思讓我提你名字？

至於參與者人數過少的問題，肯定是我宣傳力度不夠。得多吆喝吆喝：我們基於大名鼎鼎的 swoole 哦，「而且它 1.8.5 版之後增加的新特性，我們也同樣有哦」。而且還增加了一些新擴展哦。比 swoole 更好用哦。

有沒有想過：你整個項目核心代碼其實是基於 swoole？你提交的那些新特性、擴展是否與 swoole 是同一重量級？或者重寫了其底層代碼是 swoole 短期內無法提供的？新項目肯定是要比 swoole 好用那麼一些，但是這些優勢是否足夠吸引大家克服重重阻力轉移到新框架上？關於這些，吃瓜群眾自有內心的判斷和選擇。

宣傳過程中與 swoole 項目的好處比較，以及有意無意的貶低，對 swoole 本身也是一種極大的傷害。等於是一邊利用 swoole 的代碼和名聲宣傳自個的「新項目」，一邊砸著 swoole 的招牌。

4. swoole 原班人馬對你「拿來主義」的作法頗有微詞，這下你可得著說辭了：你們把 swoole 當作自個孩子護著！決不允許有別的競爭者出現！你們這樣干就是為了利益和名聲！你們不是真正的開源精神！

合著別人開源就應該只給你的 repo 提交 PR，對吧？別人不給你提的話，你就自己動手拿，對吧？光拿還不行，還要說 swoole 項目不行遲早藥丸，代碼不行，人品更是不行，對吧？

5. 這下人家修改項目協議，說你別拿 swoole 名聲往自個臉上貼金了，你要牛逼自個全新開發個新項目去，別再「基於 swoole 開發」行不？你要不滿意，1.8.5 版之前的代碼就當送你了，只是求求你別在 README 以及宣傳文案里提及「swoole」字眼了，好吧？這要求不過分吧？！

本來另行開分支呢，多少應該對原 repo 保留點敬意吧，然後各靠特性和能力吸引更多貢獻者，對吧。然而直接把人家 repo 上新 commit 的代碼拿來，還去掉貢獻者信息。這事兒乾的也是驚天地，泣鬼神。

總有個別傻逼，覺得看懂了別人的代碼，就能「創造」出一個「全新」的項目。比如 swoole 和 zan，比如 android 和 smart.. OS，比如 linux 和各種國產操作系統。

有贊這個團隊拿了別人的東西還要黑別人，簡直垃圾。

這個團隊一點開源精神都沒有，微信當初封了他們，現在想來也是有跡可循。

這件事最好的方法就是不要關注有贊的任何事情，因為即使你罵他們，還會讓更多人知道，毫無廉恥之心的人最好做法就是忽視，這種吃相真難看。

對某些號稱是「專業」的人無奈之舉，但怎麼改都是人家team的權利，那些號稱「專業」的要有「神力」就自己造一個出來唄，別吃了人家的飯還叨叨別人做的不好，人品啊

附一張

為啥是一面倒的批判？

有見過mysql 去告 Percona 或者 MariaDB 么 ?

據我所知，韓天峰確實是創建了swoole,一直開源奉獻. 當時各種bug層出，也是不可否認的，當然，韓老師收到提交issue後會很快修復 . 但是做一個成熟的產品來說這種管控實在太差勁了.

雖然不清楚大門跟韓老師之間的私人恩怨，但是如果以apache協議開源，別人可以修改發布. Copyright爭議貌似也是醉了. swoole 原本代碼自己沒註明，zan 也遵循了 swoole 的要求各種配合各種協調，但是韓老師還是一直喋喋不休，說白點，就有點小雞肚腸跟怨婦的味道了.

不敢說swoole 和 zan 哪個更好。目前來看，zan 可以提供一整套的解決方案，而swoole還是停留在底層，相對來說，zan確實更像一個成熟軟體.

最終: 當然，swoole中途肯定是可以更換協議的.

為什麼題主非常願意看到swoole的folk出來挑戰swoole呢？swoole一直積極進取，現在分裂社區對開源有何好處？也沒看出zan有啥獨特的發展方向，與swoole2有何重大方向分歧。自述做的一些事也未必不是swoole所需。為何不做貢獻而要另立門戶呢？zan的做法實在令人疑惑。

我覺得題主想對swoole提出道德質疑，不如先解決吃瓜群眾對zan的道德質疑。

作者改自己作品協議，情理之中的事，都不懂有啥好吵的。

我也來回答一波吧。一個菜鳥級的php程序員。不是很懂c/c++。很早就關注了swoole，但是一直沒怎麼用。到是研究過wokerman的源碼。一個純php寫的類似於swoole的東西（不是為了給他宣傳啊，說來我跟他還有點過節，來源這種東西，一遇到利益，啥都變味了）。很喜歡網路編程，自己還在研究中。

首先很支持 rango去換協議，他是作者，這個無可厚非。不過，我也想勸韓老師，沒必要在微博上做這個解釋，那個解釋。這樣會顯的你心虛。這不正中了別人的圈套嗎？

zan項目，剛大致看了一眼。沒細看啊。不過，我感覺如果去應用的話，應該還行吧。不過，我也嚴重反對他這種fork別人代碼當自己的，這行行為。

再回來說，我為什麼覺得zan項目還行。拿yaf和phalcon來說吧，作為一個菜鳥的我，會選擇phalcon，不為別的，就為他的功能齊全。因為擼業務和水平的限制，真的不想用yaf來折騰。再比如，我要做一個長連接的應用。我會用基於wokerman的gatewayworker（不是為了給他做廣告，這個性能不如swoole），僅僅還是像之前那樣，我熟悉gatewayworker，以及他的文檔寫的還可以，源碼是php的，我可以去修改，調試。最主要的，功能齊全。不要我去寫。就好比，你去參加賽車比賽，有人給你一個F1賽車，什麼都沒告訴你，而有人給你一輛全自動駕駛的比亞迪，你會選哪個。我想等你能操控F1賽車，別人駕著比亞迪都到終點喝了幾杯咖啡了。

所以，我真心希望swoole的文檔能做的更加完善一點，自己出一些更加易用的全套解決方案框架。

最後。祝swoole越來越好！

很多作者選協議的時候都沒有考慮那麼多，都是大家禮尚往來，互相交流，協議差不多選一個就好了。

但是協議不是選著玩的，也不是「底線」，協議就是你的態度。如果你對別人有期許，請一開始就在協議中體現出來，協議說允許，就是選擇協議的你說允許。

開源協議是一件認真的事情，所以自由軟體和開源軟體之間才會因彼此的分歧有這麼大的爭論。而從程序員的角度來說，用一份統一的信息將所有事情說清楚，而不是去依賴顯式表明的信息外人與人之間的約定俗成，也是對計算機更友好，對信息化更友好的舉措。

Neovim is a project that seeks to aggressively refactor Vim in order to:

Simplify maintenance and encourage contributions
Split the work between multiple developers
Enable advanced UIs without modifications to the core
Maximize extensibility

我不覺得這麼干有啥問題啊. 反而覺得這種競爭促進了進步. 你看有了neovim之後, vim最近幾次更新比以前有誠意多了...

以及, 想要自己來拿, 這句話沒有任何問題啊... 代碼放在這裡, 你喜歡就merge回去...

抹去 commit 信息這種行為太讓人討厭了。commit 歷史代表思路，和現有代碼一樣珍貴。

最近訂閱了邏輯思維里的薛兆豐的北大經濟學課，忽然想到這個問題可以用經濟學的原理來分析。經濟學裡有一個科斯定理，大概意思是說，當交易費用為0時，一個東西（物品也好，權利也罷）無論最開始的時候產權是歸誰的，最終都會分配到能最有效使用他的人手裡。具體的證明過程我就不說了，有興趣的可以自行百度。那放到這件事情上該怎麼分析呢？zan團隊和韓老師，他們誰才是能把swoole經營的更好的人呢？我覺得他們都不是。在這裡，能達到配置最優解的情況是所有的開發者維護同一個項目，在這種情況下項目的迭代速度和效率是最高的。如果你不服，可以往反方向延伸一下，如果很多團隊fork了swoole項目並開發自己的分支，同時merge其他所有分支的更新（同時抹掉別人的commit記錄也是工作量哦），那造成的效率上的浪費將是驚人的。。。另外，大家傷了和氣，情緒上的影響也是浪費的成本嘛。所以，怎麼樣才是make a better world 呢？如果未來有1w個swoole的版本，都說自己更牛逼，我覺得那種情況挺not better的。

所以我是支持韓老師剛開始的態度的，但是修改協議什麼應該是沒必要吧，如果經濟學的原理有效的話，有理由相信，即使還有10個分支版本，最終也會變成一個，修改協議只能顯得韓老師對自己的項目不夠有信心呀。

國外不了解，但在天朝，做開源真的不易，之前我們也遇到過類似的狀況，

開源的底線是尊重，尊重他人也就是尊重自己。開源之路還很漫長也很艱辛，且行且珍惜。

傳送門：尊重開源，且用且珍惜 - 開源中國社區