[知乎专栏–思考IT]Source Code + X

最近,有一位来自学术界朋友,找到了我们这个开源的圈子,因为他正在做一个课题《开源项目知识共享影响机理》,打算做一轮访谈,他所提出的大多数问题,都是围绕开源与知识共享展开的,我在经过相当长的一段时间思考之后,却打算撇开那些问题,谈谈我的一些思考。

最早的Source Code,其实是非常学术性的,那些科学家们,研究、发明并制造出了计算机,然后再编写计算机能够运行的代码。对于科学家来说:代码与论文非常类似,都是学术成果,饱含知识。他们应该、也必须被分享给学术界的其他专家。

所以,在非常早期的阶段:Source Code + 论文 = 知识分享

到 了1976年2月3日,比尔盖茨发了一封著名的《写给电脑爱好者的公开信》,高唱版权与利益。而且愤怒的将那些免费复制软件的家伙,称之为:窃贼!盖茨的 观点,可以说完全正当,甚至他的逻辑也完全成立,如果无法保护商业软件的版权,那么整个软件行业都不会出现,他们会永远停留在校园里,停留在学术阶段。

所以,在看到的软件利益之后:Source Code + 版权 = 利益

有一群黑客,他们崇尚自由,并且痛恨一切对于自由的限制,哪怕是合理的,合法的限制。伟大的Richard Stallman站了出来,在1985年发表了GNU宣言,并于1989年起草了GPL,提出了Copyleft的概念。

所以,在追求自由的黑客看来:Source Code + GPL = 自由

而在另一方面,「贪得无厌」的资本家们,觉得版权法对于他们利益的保护依然不够,他们需要借助专利的力量,不仅保证对手无法盗版他们的软件,而且连仿制都将违法。从美国的软件专利的历史来看,1992年以后,美国的软件专利保护,一直在承不断扩大的趋势。

所以,对于资本家来说:Source Code + 专利 = 受到更多保护的利益

当 然,这个世界上,中庸的人与团体,还是大多数。围绕着源代码,大家也在探索,是不是能够建立某种利益的共同体,而且这个共同体,并不会追求极端的自由,并 不是仅仅为了共享知识,交流学术,他们拿起了法律的武器,创作了很多种不同的License,用于规定参与各方的权利与义务,不但能够与版权相容,甚至与 专利都不产生矛盾。(最早的Open Source这个名词,诞生于1998年)

所以,成千上万的人们,从五湖四海走来,团结在某一个License之下:

Source Code + License = Open Source
就像我不会批评比尔盖茨一样,没有对于版权的强调,就不会有健康的软件行业。我也不会批评开源运动,没有足够好的利益协调机制,仅仅靠理想与坚持,根本不会有现在这么多开源软件。

总体而言,我的态度是:自由软件值得尊重;软件版权应该遵守;开源运动值得参与;专利说到底是个很糟糕的东西;而知识, 蕴含在任何能够被读到的源代码里。

[知乎专栏–思考IT][转载]第一份中文版自由開源授權條款「COPU 開源公共許可協議 v.1.0」草稿淺析

openfoundry.org/tw/lega

建立日期 2014-05-28 16:33 最近更新在 2014-05-29 17:59 作者是 葛冬梅 上週,中國開源軟件推進聯盟(China OSS Promotion Union, COPU,註一)發布了「COPU 開源通用許可協議 V.1.0(以下簡稱「COPU-1.0」,註二)」的草稿,整份授權條款由簡體中文撰寫而成,為全球第一份中文的自由開源授權條款,因此本期的法律專欄 將對 COPU-1.0 草稿做一個概要的介紹。不過由於中國大陸的用語跟台灣有所不同,為了避免辭彙轉換過程無法精確表達原簡體中文的詞意,因此本文在涉及說明 COPU-1.0 草稿內容時,將優先採用草稿中的用語,還請讀者自行參照本文末所附的辭彙對照表,來了解 COPU-1.0 草稿中辭彙相對於台灣的一般用詞(註三)。

【草擬背景與目的】

根據中國開源軟件推進聯盟官方的新聞稿(註四),由於中國當地社群對於既有的自由開源授權條款大多不了解,許多專案並不知道該如何選擇授權條款,而即使選 擇了,可能也不是那麼切合該專案的狀況,導致在後來的運用上產生了一些問題;此外,目前常見的自由開源授權條款均是以英文撰寫而成,這對於中國大陸的社群 成員來說並不容易了解,同時在商業運用上也發生過,因為企業審核英文授權條款的時間較長,而導致自由開源專案與企業的合作時程必須推延二個月的狀況。鑑於 這些問題,因此中國開源軟件推進聯盟與北大法學院專家合作,制訂出 COPU-1.0 的草稿,一方面協議採用中文撰寫,解決英文所造成的隔閡問題,另外一方面,目前公開草稿內容、徵求當地社群成員意見,期望透過這樣的互動,來提升中國大陸 社群對於智慧財產相關議題的關注。

由於期望這份協議未來可以被中國當地的專案加以採用,因此中國開源軟件推進聯盟之後將會發布條款的解釋文件,以輔助社群成員了解其中的內容。不過是否會發 布英文版本以及申請開放源碼促進會(Open Source Initiative,OSI,註五)的認証,官方新聞稿僅透露會加以「考慮」,因此關於這兩點還有待觀察後續的發展。

【幾近於無的 copyleft 特性】

COPU-1.0 草稿是一份具有非常低度 copyleft 特性(註六)的條款,主要是因為 COPU-1.0 允許使用者為衍生軟件選擇授權內容的自由,所以極端弱化了 copyleft 的特性。相關的規定詳細說明如下(註七):

1、使用者散布未經過修改的被許可軟件時,必須提供全部的源程序,提供的方法 COPU-1.0 規定有三種,使用者可以從其中擇一為之。

2、當被許可軟件被加以修改、增加或刪除之後,就會產生衍生軟件,不過 COPU-1.0 並沒有強制規定衍生軟件一定要繼續採用 COPU-1.0,而是將這樣的選擇權利交在使用者手上,使用者可以選擇繼續採用 COPU-1.0 散布,但是也可以自由採用其他的授權內容(註八)。不過很特別的是,依照 COPU-1.0 的規定,只要是沒有被修改、增加的部份,單獨來說都是「被許可軟件」,並不會構成衍生軟件的一部份,因此被許可軟件跟衍生軟件是兩個分開的、彼此獨立的部 份。舉例來說:最原始釋出的被許可軟件中有 A、B、C、D 四個部份,其中 A、C 被使用者修改後成為了衍生軟件,而 B、D 仍然是被許可軟件,即使 A、C 在運作上可能與 B、D 關係密切,但是 COPU-1.0 將其區分為衍生軟件跟被許可軟件,並分別適用不同的義務規定;這樣相同的修改情況,但若軟體是採用 GPL-2.0 釋出,極有可能因為 A、B、C、D 四個部份在運作上的關係密切,因此這四部份被視為一個整體看待,這一個整體是一個完整的衍生程式,無法切割,進而讓 A、B、C、D 四個部份都必須繼續採用 GPL-2.0 來授權。將被許可軟件與衍生軟件如此獨立區分,是 COPU-1.0 草稿非常特別的規定。

3、另外,COPU-1.0 明確規定兩種利用狀況不會產生衍生軟件,也因此在這兩種情況下,提供源程序的義務並不適用:

(a) 若使用者增加到軟件中的特定部份,是該使用者單獨的獨立作品,那麼這個獨立作品就不是衍生軟件,也因此,這個獨立作品完全不會受到 COPU-1.0 所拘束,使用者在散布時,並沒有提供源程序的義務;

(b) 第二種則是規定單純調用的狀況,並不會讓其他的軟件模組成為衍生程式:一個軟件模組若是為了調用被許可軟件,而包含了被許可軟件的部份調用信息時,這個軟 件模組將不會因此而成為衍生軟件;反之,若被許可軟件為了調用一個軟件模組,而包含了該軟件模組的部份調用信息,也不會讓這一個軟件模組成為衍生程式。不 過若是被許可軟件與軟件模組被編譯成為靜態調用狀態的話,這時候整個被編譯出來的程序仍然被認定為衍生軟件,未來散布的時候,使用者必須提供所有的源程序 給第三方。

上述第 1、2 與 3 (a) 點的內容與 MPL-1.1 的架構規定非常類似,但是相對來說,MPL-1.1 清楚地點出獨立性的判斷基礎在於檔案,也就是當一個檔案被增加到 MPL-1.1 程式中的時候,若是這個檔案並沒有包含任何 MPL-1.1 程式碼的話,這就是一個獨立的檔案,不會受到 MPL-1.1 所拘束,散布時可採用其他的條款授權,但是 COPU-1.0 對於何謂「獨立作品」,或其背後所蘊含的獨立性,並沒有更進一步的說明或闡釋,讓這部份規定留下疑義。另外,第 3 (b) 點的內容則與 LGPL-2.1 相近,因為 LGPL-2.1 是一份針對函式庫所制定的授權條款,因此一個程式單純連結利用 LGPL-2.1 函式庫的話,並不會讓這個程式也成為 LGPL-2.1 的衍生程式,不過若該程式與函式庫一起形成一個可執行檔的話,這整個可執行檔仍然必須受到 LGPL-2.1 所拘束,因此可以看得出來,COPU-1.0 草稿在這部份的規定是與 LGPL-1.1 非常相近(註九)。

MPL-1.1 與 LGPL-2.1 皆是 copyleft 授權條款,其所具有的 copyleft 特性雖然不如 GPL、AGPL 這些條款般強烈,但是基本上其衍生軟體都必須受到原條款所拘束,使用者無法為其自由選擇授權條款。與這兩份條款架構與內容近似的 COPU-1.0 照理也應該具有一定程度的 copyleft 特性,但是因為 COPU-1.0 允許使用者為衍生軟件自由選擇授權內容,讓 COPU-1.0 的 copyleft 特性大幅度地減弱,幾近於無 。

【其他主要內容】

除了上述極端被弱化的 copyleft 特性之外,COPU-1.0 草稿中其他主要的內容還包括了:

1、專利授權。

若是被許可軟件與衍生軟件中應用到許可人所擁有的專利技術,則此項專利技術也授權給予使用者來應用,只要依照 COPU-1.0 的規定來利用軟件,使用者就可以無償地連帶利用許可軟件中的專利技術。

2、顯名義務。

如同其他自由開源授權條款一樣,COPU-1.0 草稿也規定使用者不可刪除、修改許可軟件中的各項權利管理信息、署名信息與源程序中的注釋,除非使用者修改或刪減了源程序,為了配合這些修改、刪減,才可 以相對應地刪除或修改署名信息或相關的注釋。此外,若使用者透過網路提供許可軟件的應用服務時,其雖然不需要將源程序提供給予服務使用者,但卻有義務在提 供軟件應用服務的網站上或者是軟件的介面中,標示其使用了被許可軟件,而這項雲端應用時的標示義務,也及於衍生軟件。

3、文件與注釋保存義務。

對於被許可軟件所附隨的文件,以及在撰寫軟件過程中一併寫入源程序中的注釋,COPU-1.0 均相當重要這些文件資訊的保存。對於附隨的文件,COPU-1.0 規定使用者在散布軟件的時候,都必須要與源程序一併散布出來,不過若是在取得被許可軟件時,並沒有收到任何附隨文件的話,那麼使用者自然就沒有散布文件的 義務。而對於源程序中的注釋,如同上述第 2 點所提到過的,除非源程序經過修改或刪除,否則使用者是不得擅自修改任或刪除任何注釋的內容。

4、提供 COPU-1.0 協議內容的義務。

如同 GPL、MPL 等條款,COPU-1.0 草稿也規定使用者在提供被許可軟件的同時,也必須要提供 COPU-1.0 協議的內容,不過對於透過什麼樣的方式來提供,COPU-1.0 草稿並沒有更細部的規定,因此解釋上,使用者可以自行決定提供的方式,例如提供 COPU-1.0 協議內容所在的網頁網址,也應該是合於規定的。

5、強制散布被許可軟件的義務。

在散布「衍生軟件」的同時,使用者必須要將未經修改的「被許可軟件」的源程序、附隨文件以及 COPU-1.0 協議內容也提供給予第三方。之所有會有這項規定,是因為 COPU-1.0 草稿規定被許可軟件、衍生軟件與獨立作品是彼此獨立的三個部份,在定義上並沒有互相重疊,這樣的設計讓使用者可以選擇單獨散布衍生軟件,而不散布被許可軟 件。不過 COPU-1.0 草稿卻強制規定,無論衍生軟件採用什麼樣的授權條款,一旦使用者散布衍生軟件,同樣也必須將被許可軟件的源程序、附隨文件與 COPU-1.0 協議內容提供給予第三人,以增加被許可軟件的擴散度與能見度。

6、即時提供義務。

所有提供源程序、提供文件與提供 COPU-1.0 協議內容的義務,使用者都不得故意拖延,造成第三方無法即時獲得這些資料的狀況。

7、使用者失權不影響第三方所取得的合法授權。

使用者若是違反 COPU-1.0 規定時,所有原本所獲得的權利將會自動終止,但是第三方的權利並不會受到影響。

【草稿仍有許多待釐清或需要調整之處】

COPU-1.0 目前仍在草稿階段,有部份內容不清、需要被釐清或調整的地方。以下三點,是筆者認為幾項較為重要之處。

1、衍生軟件的定義不清。

GPL-2.0 所規定的衍生程式,是以一個整體運作的軟體為基本單位,MPL-1.1、MPL-2.0 則是以檔案為基本單位,此外,這些條款透過週邊文件的解說跟軟體專案的實務運作,讓使用者可以了解到,這些條款中的衍生程式是必須經過一定程度的修改之後 才會產生的,僅僅只是參數的調教、或少數幾行的改變,原則上並不會產生衍生程式。

但是,COPU-1.0 草稿並沒有像上述條款的闡釋或說明,目前也還沒有釋出說明文件,因此單就草稿的文字來解讀,只要排除被許可軟件與獨立作品後,其他被修改過的部份就是衍生 軟件,即使修改的幅度或品質是非常微量的。同時,對於何謂增加「部份」?何謂修改「部份」?何謂刪除「部份」?這些「部份」的基本計算單位為 何,COPU-1.0 也沒有闡釋或說明,因此這個「部份」可能是個別檔案,也可能是具有特定功效的模組,甚至也可能是一個元件,未來在實際運用上,很有可能會產生使用者各自界 定增加、修改、刪除與「部份」內涵的狀況,進而引發爭議。

此外,如同本文已經說明過的,COPU-1.0 草稿將衍生軟件與被許可軟件視為兩個分開、彼此獨立的部份來規定,這與現行一般自由開源授權條款中衍生程式的概念大不相同,由於筆者並不熟悉中國大陸相關 的法令規定,因此這個規定在其當地法規體系下的合理性與合法性有待考究,不過由於 COPU-1.0 對於如何界定增加、修改、刪除與「部份」等概念並沒有說明或闡釋,而衍生軟件與被許可軟件分別適用的義務跟權利內容差異非常大,因此這種嚴格區分的規範方 式,會讓何謂衍生軟件、何謂被許可軟件的爭議更為擴大。

2、COPU-1.0 在實質運用上的效果與 Apache-2.0 非常相近。

本文已經說明過,雖然 COPU-1.0 具有 copyleft 的形式架構,但是因為允許使用者自由為衍生軟件選擇授權內容,因此 copyleft 特性幾近於無。所以從技術上來說,只要使用者將整個被許可軟件修改過,使其整體轉變成為衍生軟件,就可以為其改用其他的條款來授權散布,甚至是不提供源碼 的條款也可以,也就是說,只要將 COPU-1.0 授權的軟件稍加修改,整個軟件就可以改用其他任何的條款授權。這樣的結果雖然一方面有利於與其他自由開源軟體相容,因為使用者可以為衍生軟件採用 GPL-3.0、MPL-1.1 等等其他的條款授權,但是另外一方面,這樣的結果卻也讓 COPU-1.0 跟 Apache-2.0 這份授權條款變得非常相近,因為 COPU-1.0 草稿的內容皆可在 Apache-2.0 中找到對應的規定,只不過 Apache-2.0 的設計架構,是讓未經修改的軟體可以採用再授權方式散布,而修改過的條款則可以在遵守簡單義務的範圍內,與 COPU-1.0 允許衍生軟件可以改採其他任何條款授權的結果是幾乎是一樣的。因此筆者相當好奇,COPU-1.0 這樣的設計與規定,是否有什麼特殊的背景原因?

3、未明示不可撤回。

經過三十多年的發展,自由開源授權條款具有不可撤回 (irrevocable) 的特性,幾乎已經是被各界所公認,因此在新近修訂的條款中,例如 GPL-3.0 與 MPL-2.0,皆會將這樣的特性在條款中加以明文規定,不過在 COPU-1.0 草稿中,並沒有看到類似的文字,稍有缺憾之感。

【結語】

COPU-1.0 草稿的部份規定,與目前常見自由開源授權條款有所不同,因此筆者相當期待可以看到官方發佈說明文件,來解釋這些文字規定背後的意涵,此外,也很期待可以在 意見徵求程序,看到中國大陸社群成員關於這些內容的討論。不過,若暫時先將草稿內容的疑義放在一邊,筆者以為,從這次 COPU-1.0 草稿的發佈可以了解到,自由開源軟體對於全球的影響之深,即使是中國大陸也因此必須要正視相關的授權議題,甚至進而積極起草制定這份 COPU-1.0 草稿,無論目前草稿內容如何,但這種正視自由開源軟體的態度是值得令人高興的。因此筆者期待中國開源軟件推進聯盟可以早日發佈說明文件,釐清 COPU-1.0 草稿中的疑義。

—-

註一:中國開源軟件推進聯盟:首页 | 中国开源软件推进联盟

註二:COPU 開源公共許可協議 v.1.0」草稿全文請見:中国通用开源许可协议V1.0 出炉,征求意见中 | CODE

註三:《COPU-1.0 草稿中文辭彙對照表》

以下辭彙依照筆劃順序排列

COPU-1.0 草稿用語 -> 台灣一般用語
(繁體中文/簡體中文)
==============================================================
信息/信息 -> 資訊
衍生軟件/衍生软件 -> 衍生軟體、衍生程式
軟件/软件 -> 軟體
許可人/许可人 -> 授權人、著作權人、權利人
被許可軟件/被许可软件 -> 本軟體、原軟體
軟件模塊/软件模块 -> 模組
程序/程序 -> 程式
源程序/源程序 -> 程式源碼、源碼、原始碼
第三方/第三方 -> 後手
署名聲明/署名信息 -> 貢獻聲明、貢獻資訊

註四:本段以下內容皆參考該篇新聞稿之內容,網頁連結如右:COPU 開源公共許可協議的官網,COPU开源公共许可协议背景资料

註五:關於 OSI 以及其所維護的開放源碼定義說明,請參閱:開放源碼定義與開放源碼促進會,開放源碼定義與開放源碼促進會

註六:關於 copyleft 概念的介紹,請參閱:什麼是”Copyleft”?,自由開源軟體概念相關類。關於常見條款所蘊含 copyleft 特性的概要介紹,請參閱:自由開源軟體授權條款的三分法,自由開源軟體授權條款的三分法

註七:本段相關的 COUP-1.0 草稿內容請參見第 2.4 條第 1 款、第 4.3.1 條 。

註八:不過若使用者採用非 COPU-1.0 授權散布衍生軟件的話,COPU-1.0 規定第 6 條的規定仍然繼續適用於衍生軟件,第 6 條主要是規定:當使用者因為違反 COPU-1.0 而喪失權利時,這並不影響使用者授予給第三方的權利。類似的規定在 GPL-2.0、MPL-1.1、MPL-2.0 中也可以見到,但是 COPU-1.0 將這樣的規定也適用在採用非 COPU-1.0 授權的衍生軟件中,則是少見的規定。

註九:本段所提及 MPL-1.1 與 LGPL-2.1 的特性,可以進一步參閱右列文章:從封閉到開放的副產品-MPL,從封閉到開放的副產品;稍稍鬆綁的堅持-LGPL,稍稍鬆綁的堅持

—-

《感謝》感謝林誠夏在本文寫作期間參與討論。

——————

感慨: 佩服对岸的开源研究者的认真和细致,大陆这边,除了冷嘲热讽,就是漠不关心…

[知乎专栏–思考IT]在GitHub,他们是怎么玩的?

Github.com,现在是全世界程序员,尤其是开源爱好者的乐园。在这个乐园里,大家玩得不亦乐乎,那么他们在玩些什么?又是怎么玩的呢?

开源项目

当然,Github首先是一个开源项目的免费托管平台,在Github上已经聚集了超过1000万个代码仓库;超过300万的注册会员(基本上都是热爱开源的程序员),而达到这一里程碑只用了不到4年的时间,这足以让人感受到开源的趋势以及GitHub的受欢迎程度。

一大批知名的开源已经迁入Github或者在Github上设立镜像仓库(例如:大量的Ruby、Rails相关项目,大量的JavaScript、NodeJS相关项目等等),较为著名的项目有:

1. bootstrap,一个twitter开源的CSS框架

2. jquery,最为著名的JavaScript框架

3. node.js,新兴的基于Google Chrome V8引擎的JavaScript语言:NodeJS

4. RubyOn Rails,最著名的Web框架之一

5. Font-Awesome,一个神奇的字体项目,以字体的方式,提供几百个实用的小图标

6. angular.js,流行的JavaScript前端MVVM框架

7. free-programming-books,汇集了全球最为流行的各种免费编程图书(后来还发展出了多种不同的语言版本)

8. …

玩玩游戏

不过,这其实并非Github最好玩的开源项目。最近有一个开源游戏,在Github已经火爆得一塌糊涂。最初,是一个叫做《Threes》的收费小游戏,然后是一个叫做《1024》的克隆版本,但是真正让一切开始爆发的,是在Github上开源的《2048》,因为他是一个开源HTML5游戏项目,因为Github上极其方便的Fork机制,派生版本开始如雨后春笋一般涌现了出来:

· 《2048朝代版

· 《2048超进化

· 《2048大型强子对撞机版

· 《2048哲学家版

· 《2048 3D版

· 《斐波那契函数版

其实还有非常多的奇葩版本,这里就不一一介绍了。
更多游戏,请访问: Web games 路 GitHub

写作

在Github上,不仅仅可以协作编程,很多软件开发类的书籍,也可以在Github上协同编写。与编程非常类似,写书的作者也是有一个“主笔”,由他来定下全书的结构与主旨,然后率先写出大纲与核心的部分。

其余的协作者,可以fork出一个自己的版本,然后修改字句、添加段落,然后以Pull Request的方式,看看主笔是否接受。

再外围一些的协作者,可以提交issue,用来做书籍的校对、勘误工作。通过迭代式的进度管理,慢慢的,一本书也就写出来了。

· 一群普林斯頓數學家,用geek最愛的開源碼託管平台GitHub寫成600頁專書! 普林斯顿大学的Andrej Bauer与另外20多位数学家,历时半年时间,完成了一本《同伦型理论:数学的单价基础》(HomotopyType Theory: Univalent Foundations of Mathematics)

· 追蹤法律修訂動向,德國社群網站助資訊公開德国的Stefan Wehrmeyer,将所有的德国联邦政府法律张贴在Github,并追踪其修订历史,甚至可以自行修改文件的内容。

· 起草并修正专利许可 Twitter 的首席律师 Benjamin Lee 通过 GitHub 为工程师们起草了一份新的专利许可协议。而不久之后,GitHub 用户们就为其修正了很多小的语法错误。再后来,Twitter 联合创始人 Evan Williams 的孵化器创业公司商业运营总监 Trishan Arul 又建议加入一些文本,Lee 表示接受。

· 分享和改进各种音乐 来自德州一家圣公会教堂的音乐总监 Adam Wood 正尝试将一份格列高利圣咏的大纲上传至 GitHub。他认为对于唱诗班总监而言,那是最好的用来分享和改进各种音乐的服务平台。

用Github Pages写博客

当然,借助Github Pages,更多的程序员开始长期“泡”在Github。他们把自己的Blog,用Jekyll、octopress或者hexo架设在Github上。

那么,为什么要在Github上写博客呢?首先当然是因为免费,我们可以申请一个包含自己用户的首页,类似于:name.github.io这样。感觉很有高端大气上档次的感觉。

其次是因为技术含量看起来很高,其实又并不是很难。借助一些开源的blog静态化工具,我们可以轻松上手,在30分钟内搞定自己的Blog site。

· 搭建一个免费的,无限流量的Blog—-githubPages和Jekyll入门

· 教程:一步步在github上建立octopress博客

· hexo你的博客

介绍一个有趣的架设在Github上的技术blog吧,岁月如歌 淘宝著名前端工程师玉伯的blog,人气极旺。

人才库

当Github汇聚了越来越多的程序员,而这些程序员在Github日夜不停的开发着各种不同的开源项目,一个全球最大的编程人才库,就此形成了。简历生成器是一个有趣的小工具,只要输入你在Github上的用户名,就能够生成一份Github版个人简历,你的开源经历,企业可以一目了然。

甚至,现在已经有了第三方网站提供基于GitHub的人才招聘服务,例如:

· GitHire:通过它,可以找出你所在地区的程序员。

· Gitalytics.com:通过它,能评估某位程序员在GitHub、LinkedIn、StackOverflow、hackernews等多个网站的影响力。

延伸阅读

这篇文章,已经附带了太多的Link,但是其实还有很多的好文章,我没有引用,下面给两个链接,推荐浏览:

· 如何高效利用GitHub 与我的这篇文章很类似,但是更加全面

· Github at 伯乐在线 伯乐在线上收集的有关的文章

[知乎专栏–思考IT]聊我所理解的敏捷(Agile)——外一篇

那些众所周知的敏捷宣言,敏捷方法,敏捷教科书,敏捷大神,我就不提了。只是聊聊,我所理解的敏捷的本质。

敏捷的本质,是承认软件开发的复杂性。而且承认,这种复杂性,达到了这样一种程度:“无法通过足够充分的前期准备,而消除后续的风险。甚至于,前期准备得越是充分,后续的风险越大。”

往往有很多人,将建造大楼与软件开发做简单的类比,以说明前期设计的重要性。但事实上,我们无法想象,一幢大楼,在接近完工的时候,有新需求出来,要求整个设计从从一幢四边形的楼,变成一幢六边形的楼。

但是,在软件开发领域,就是会出现这样的需求,而且,这种需求虽然会被所有的开发人员痛骂,但却“实际上具有其合理性”。

如何理解需求的复杂性、易变性?

软件的出现,还不到100年。建筑的历史,则至少有5~6千年了吧。人类对于建筑的需求,已经足够稳定(相对于软件而言)。另一方面,软件的可能性,又实在是太强大了,至少重力因素软件可以毫不考虑。

软件开发这个领域,还太年轻,大家都没有足够的经验。年轻到了,甚至现在去急于总结经验,都是错误的!

来源于Christopher Alexander《A Pattern Language: Towns, Buildings, Construction》曾经给予Gang of Four以巨大的启发,所以他们写出了著名的《Design Patterns: Elements of Reusable Object-Oriented Software》。

但是,现在看来,设计模式的流毒真的不少…

所谓敏捷方法,不过是一种需求发现与谈判策略

过去的思路,认为需要尽可能发现所有的需求,并且做好设计,然后再开始开发。现在大家已经意识到,一边做,一边确认,一边发现,一边纠正。从总体成本上衡量,反而会更加低。

但是,在实际施行敏捷的过程中,“一边做,一边确认,一边发现,一边纠正”,也同样可能存在巨大的浪费。而且,因为披上了敏捷的外衣,反而变得无可指责了。

本质上,这是一种对于开发方,而非需求方,更加有利的谈判策略。

总结陈词

我们现在还缺少一系列量化的手段,去衡量需求的复杂度,开发的效率以及各种流程方法的优劣。(不要跟我提Function Point Estimation,那种教授坐在书桌边发明的方法~~)

因为缺乏这种量化,所以大师满天飞,却让人无所适从。

外一篇:“设计模式的荼毒”体现在何处?

可以从两个角度来谈这个问题:

1. 建筑里的结构工程师,如何设计结构?

我们都知道,建筑设计中的结构工程师,非常重要,而且,他们必须非常深入的了解数学这门学问。

在结构设计出来之后,他们还需要做一些模拟与演算,以确保他们设计的结构,能够承载整个建筑。

再进一步,一个敢于设计结构的结构工程师,有很长的一个学习阶段,以了解前辈大师的经典结构与数学模型。

可以说,建筑结构学,是一门科学,是一门以数学模型和科学实验为基础的严谨的科学。

2. 中医如何看病

中医,也有一套理论:阴阳呀、五行呀、相生相克呀,等等等等。在这套理论的基础上,也有上千年的经验积累,什么药吃了能治什么病,大概是什么计量。

但是,说到底,这是一门「经验科学」,或者直白一点说:「这不是一门科学」。

声明一下:我不是中医黑,虽然我也不是中医粉,至少中医的确有大师,他们真的治好了很多病人,这个我绝不会否认。

毕竟:疗效的好坏,还是很难伪造的。

3. 软件架构师,如何设计架构?

架构师,看起来很像结构工程师,但是:他们没有科学基础,只有一些「设计模式」和「架构模式」。

那些「模式」的有效性与适用范围,并无严谨的证明,只有一些模模糊糊的「实践案例」。

「听说设计模式是好东西」,就像「听说人参大补元气」一样。真正的中医,尚且不敢给病人乱开人参,但是架构师,他们真敢把所有的「设计模式」都用上。

中医再怎么不靠谱,真是把病人给治死了,医生也会吃不了兜着走。但是,我们什么时候听说过一个项目的失败,是因为架构师不合格呢?

还有个更大的罪魁祸首「需求变动」顶在前面呢。

4. 总结陈词

一种「理论」却没有严谨的理论支撑,一门「手艺」却难以客观的评价手艺高低,随便看两本模式的书,就敢开整。没有流毒,就怪了。

[知乎专栏–思考IT]架构的力量

最近看了两本书,这两本书当然大有不同,一本书专注于分析软件设计,尤其是架构设计的书;而另一本则是在分析互联网领域的法律与创新的关系问题。

两本都是好书,都值得分别为他们写一篇读书心得,只是这里想谈谈的是两本书中,相通的部分——「架构的力量」。

  • 端对端原则

在《思想的未来》中,作者回顾了互联网的架构设计思想:
「这一原则是由网络设计者Jerome Saltzer、David Clark、David P.Reed在1981年首次提出的,被称为端对端(end-to-end argument, e2e),用以指导网络设计者们开发网络协议及应用程序。」
「端对端原则认为,网络的智能不应当放在网络内,而应当位于网络的端点,即网络内的计算机只是履行应用程序所需的基本功能,而一些特殊功能应由网络边缘的计算机来实现。」
「据RFC 1958所述,虽然因特网社区中许多成员会认为因特网不存在架构,但是,社区成员普遍相信,因特网的目标是连通性,工具是因特网协议,智能位于端对端而不是隐藏与网络之中。网络的任务是尽可能灵活有效地传输数据包,而其他的一切都应该靠边站。」

由这样的架构原则,作者总结出了三个要点:「应用程序在网络边缘的计算机上执行,任何种类的应用都可以立即被运行;网络没有为任何特定应用程序做优化设计,对于任何创新都是开放的;由于网络平台的中立性,网络无法做到歧视某种特定的新设计。」

在我看来:互联网最初的设计者,因为足够谦逊,所以对于「平台将会如何被使用」未做任何假设,他们的架构仅仅专注于最为简单的目标,而这也是互联网取得如今这样巨大成就的根本原因。

  • 不要尝试预测未来

在《简约之美》中,作者极力向读者阐述:架构设计简洁的价值,因为随着时间的不断增长,软件的研发成本的绝大部分,会产生于后期维护的阶段。越是简洁的架构,就越是能够为今后的维护,节约大笔费用。

另外一个值得注意的事实是:「程序员犯的最常见也是最严重的错误,就是在其实不知道未来的时候,去预测未来。」

而作者给出的策略是:「最安全的情况是,完全不尝试预测未来,所有的设计决策都应当根据当前确切知道的信息来做。」

在我看来,当年的互联网设计者,就是那种最伟大的程序员/设计师,他们未做任何假设,仅仅专注于解决信息传输的需求。

  • 一个可能的误区

不去尝试预测未来,根据当前确切知道的信息来做。这样的逻辑,可能会让人偷懒。
1. 「啊,我们这就开始干吧!」
2. 「我们不要做太多的假设!(不必想那些设计的事情)」

架构是存在的,设计是需要的,需求要尽可能的去搜集与分析。在做到这三个要点之后,才能谈及「不要假设」,「不要过度设计」。在此之前,还是不要放松为好。

架构是有力量的,简洁的架构,往往会产生的惊人的力量。当然,「无架构设计」不在其列。

[知乎专栏–思考IT]社区运营三大忌——以知乎为例

在「私吐槽」专栏,我针对这次的419事件,只写了一句话:「我一直觉得,知乎没搞好,与张亮这样的投资人,有很大关系。」

在「思考IT」这个专栏,我打算写一些更加有营养价值的内容。

前天与一个朋友聊天,我还发表过一个观点:「知乎是国内运营得最好的几个社区之一」,但是,我那天没有提到的「但是」,我想写在下面:

一忌:渐渐被遗忘的初心

周源曾经回答过这个问题:知乎团队的初心是什么?

基于这个想法,我们的初心是:

  • 每个人都是某个领域的专家,知乎能帮助每个人去展现自己亮闪闪的一面
  • 知乎将成为一个由人们的知识、经验和见解组成的 P2P 网络
  • 知乎帮助拉近人与人之间的距离
  • 知乎将持续产生高质量、可沉淀的信息,并让有价值的信息和人都关联起来

而我在另一个问题里,提到过自己的担忧:可能导致知乎走向失败的最大风险是什么?

我想,如果知乎有可能失败,最大的原因,是:“对于何为优质回答的定义发生了变化。”

知乎的运营,一直都在追求优质的回答。这是大家有目共睹的。但是,何为优质呢?
1、大家都赞同?
2、运营的员工有偏爱?
3、名人?
4、能够激发更多的讨论?
5、具备足够的深度和长度?

这些都可能不是优质的判断依据,但是也有可能被用来判断是否优秀。

我担心的最大的问题,就是知乎运营团队,在何为优秀的判断上,默默的,不自觉的,有意无意的,向KPI低头,向热闹低头,向名人和大企业低头

最终,从一个一流的问答社区,变成为一个二流的,却标榜自己是一流的问答社区。

在大约2年以后的今天,我想:「自己的那些担忧,几乎都已经成为了现实」

二忌:以人治代替法制

在一个虚拟社区,谈论法制,是不是有点大题小做呢? 之前我写过一篇给知乎的公开信:《规则与例外——写给知乎的一封信》后来,这封信还在知乎引发了一些讨论:你对《规则与例外——写给知乎的一封信》一文有什么看法呢?

但是,我在文中提到的所有问题,知乎团队一!个!都!没!有!解!决!

依然是区别对待,依然是顾此失彼,依然是各种潜规则。

这次的张公子退出,终于引起了知乎团队的重视,但是:他们的反应只会让其他知乎用户心凉!

@葛巾 算得上是知乎大神了吧?结果,照样会有没有受到重视的感觉,悠悠的叹了一句:「原来要张公子怒了,你们才会担心啊……」

而我之前的愤怒呢?我很愤怒! – 禾厶口土木曹 – 知乎专栏

我在文章里喊到:@黄继新@周源 @顾惜朝 请回答我的问题!

他们没有一个理我。我还给他们都发了私信呢!

今天,周源说:对不起,来晚了

我自然要小声的问一句:「您的私信是开放的!您的私信阅读与回复率是多少?」

你们忙,大家都理解,但是你们如果不能一视同仁,就不会得到任何理解。被你重视的,会感到失望。被你们忽视的,会更加失望!

@路小佳 明确指出:“知乎并非因为张佳玮的不满才站出来,事实上,我们在乎每一个人”,这句话,看了很不舒服,此地无银。我想,这就是大家的心声了。

三忌:指手画脚的投资人

其实,前两忌,还算是「可治之症」,这第三忌,才是「不治之症」!

大约是两年前,我曾经一口气喷了一篇文章:《要创业,就别听VC的!

其中有一句话是这么说的:「创业团队不要为了VC的建议而动摇,VC只是出钱的人,甚至不能算是业内人士,他们的建议,未必是为了你事业的长远发展,也许也许只是为了他能够更快脱手。」

但是,在知乎我们经常会看到@张亮 的身影。他的身份是创新工场的投资总监,但是却常常以知乎负责人的身份出来发表各种言论。这次张公子发怒,他居然来了一篇:知乎的耻辱 – 逆旅 – 知乎专栏

在文中,以一种居高临下的口吻说到:「刚才我已经跟周源通电话了,也跟相关产品经理沟通了,没废话,知乎会尽快改进审核相关的产品体验。别的话不说了,开始改,必须改好。」

还说:「如果你对知乎的某个用户体验不满,请留言或给我私信,谢谢!我会督促他们,没有任何借口。」

这就是一个典型的不守本分的投资人的形象!

你只是投资人,不是客服,不是公关,不是CEO,不是产品经理,不是知乎团队里的任何一员!

你只是一个投资人!但是你的手伸得太长了!不但给周源打电话,而且直接跟相关的产品经理沟通。 不但在私下插手此事,而且在知乎团队给出官方回应之前,就写什么《知乎的耻辱》!

你管得太宽了!

你管得太细了!

你管得太多了!

言尽于此吧,张亮以前的那些指手画脚的事情,我也懒得再一一去翻了,反正他没少干!

以上就是我的最后一次劝告,下不为例!

[知乎专栏–思考IT]从软件工程到研发管理(五)

五、本末之辨在我所了解的中国哲学中,有一个非常重要的命题「本末」,何者为「本」,何者为「末」,如果搞不清楚,就会舍本逐末。类似的命题还有「因果」,如果迷失于现象之中,就会「倒果为因」。

在上一篇文章里,有两张图,提及了三组关系:

研发效率→速度提升与流程优化;

研发能力→特性丰富与质量提升;

研发活力→成果重用与研发创新;

这三组关系,左边是本,右边是末;也可以说左边是因,右边是果。好的企业,会追求左边,进而得到右边的那些好处。糟糕的企业,却会盲目追求右边的那些成效,结果导致一些悲伤的结果。

这种事情,一般来说在企业里,不太会发生(不过的确是有这种企业,尤其是某些特别有「追求」的企业)。

这种情况,其实也比较罕见,我能够想到的例子,是某些声称要生产银弹的企业。

这倒是绝大多数研发企业的通病,速度快了,质量就下降。勉强把质量搞上去吧,就必须要缩减功能了。

据说,那些能够过CMM5的企业,都是具有高额利润的企业,否则根本承受不了那种流程浪费啊。

很多时候,我们都了解码农的苦,因为产品经理为了拉订单,答应了太多的功能特性。

听说,伟大的游戏总是会延期……

总之,舍本逐末的害处,实在是太多了。如何才能正确的追求研发实力的提升呢?

<未完待续>

[知乎专栏–思考IT]从软件工程到研发管理(四)

四、从项目管理铁三角到研发管理金三角

1. 眼花缭乱的铁三角

在维基百科英文版 Project management triangle 我们可以找到很多不同版本的项目管理铁三角:这些图,要细细讲解起来,每一个都可以大说一番道理。但是,若是想要究其本质,其实无非是一句话:「老板,您不能什么都想要啊!」

那么,有一个挥之不去的问题,就出现了:如果多种要素,无法全面追求,那么优秀的研发团队与低劣的研发团队,区别何在呢?项目一旦失败,因为有铁三角护身,我们就总能够抱怨:老板什么都想要,所以bla…bla…

有没有可能,通过一系列的手段与努力,提升研发团队的实力呢?有没有可能存在一个优秀的研发团队,能够在多种不同的追求方向上,都获得令人满意的结果呢?

2. 概念梳理后的金三角

为何要将这样一个图,称之为金三角呢?有几层含义:

Schedule(调度):通过提高单项工作的速度,可以提升效率,通过流程优化,进度合理安排,可以提升整体效率,因此将效率目标分解为:速度与控制力。

Requirement(需求):用户的需求有非常多,主要可以划分为特性需求与质量需求。

Profit(利润):在IT企业中,研发团队通常不是利润来源,而是成本中心,但是研发创新与研发成果重用,同样可以降低成本,甚至给企业带来利润增长。

仅仅将以上的概念归并,还不足以称之为「金三角」,再看下面这张图:

efficiency(效率):要做到足够好的调度Schedule,我们需要追求更好的「研发效率」;

ability(能力) :要满足用户的需求Requirement,我们需要追求更强的「研发能力」;

energy(活力):要追求更高的利润Profit,我们需要激发足够的「研发活力」;

而能力提升促进效率改善;效率提升增加空余时间,使得研发活力有可能增加;研发活力的提升,则能够增进研发能力;以上三种要素之间的互相促进,构成了一个「使能环」,而这样一个使能环,就是研发管理金三角的真意!

<未完待续>

[知乎专栏–思考IT]Thinking About The Internet

最近一直在思考「互联网」,比如:「互联网模式」、「互联网思维」、「互联网经济」、「互联网革命」……

一个比喻

在我看来,互联网作为一个新生事物,既不是完全的混沌,也不是完全的有序,而是某种「复杂系统」,可以打一个比方,来描述这种状况:起初是两个人玩一个游戏,道具是一个骰子。各掷骰子一次,比大小。但是,点数大的人,可以新增或者修改游戏规则。

于是,第一次的赢家,将骰子数加到了两个; 第二次的赢家,约定单数赢,双数输;第三次的赢家,邀请了一位新的比赛选手;第四次的赢家,新增的平局的规则是加划一次剪刀石头布;第五次,三个骰子;第六次,每人掷三次,取平均值;以此类推…

而对于互联网来说:

  • 最初,是将一切网络都链接起来
  • 然后,是确保在网络上能够传输各种信息
  • 然后,是将一切行业都信息化
  • 然后,是将一切行业进入互联网的门槛都越降越低
  • 然后,是将创业者通过互联网进入任何行业的门槛都越降越低

当玩家越来越多,当加入互联网领域的行业越来越多,规则就开始发生变化,然后是很多定义也开始发生变化,然后是原本天经地义的认识(三观)都开始发生变化,最后是整个生态都变得面目全非。

一条线索

值得梳理的线索有很多,在这篇文章里,就先提出一条线索,供大家参考:

首先是门槛降低,导致各种小型团队,开始创业(甚至一个人,就敢开始创业了)!随之而来的,并非全然的好消息,毕竟人力物力严重不足。于是,这个新兴的企业,只能提供非常初级、甚至劣质的产品。或者,为了保证质量,只能服务非常非常狭窄的一个细分市场。

在这种情况下,按照传统产业的规律,这种小型企业将会迅速消亡。但是在互联网时代,企业开始想出种种办法,让用户可以不太计较产品的质量;还出现了「长尾理论」。在长尾理论的指导下,即使狭窄的用户群,也能通过互联网被发现与联系上。

先不谈长尾理论所描述的另一大类现象,单单讨论一下:质量下降后的互联网产品形态。

用户当然会不满,创新的企业想出了各种办法,来降低用户对于产品质量的期待。或者称之为管理用户的预期。

  • 快速迭代,每周发布一个新版本,可以让用户觉得产品一直在进步(哪怕其实没啥进步,也能够给用户一些信心);
  • 免费, 让那些用户不好意思来骂我们;
  • 推出小范围试用版,让最早发现bug的用户,感到某种「自豪感」;
  • 排队限购,引发稀缺意识与珍惜的心态;
  • 邀请制,朋友介绍我来的,我也不太好意思骂的太狠;

在通过种种办法,降低了用户的期待之后,创新企业又进一步的切实提升了版本迭代的频率与发布版本的质量,这些快速开发的实践,又进一步引发的软件研发管理的诸多变革。一些好的敏捷实践,甚至进入了非互联网研发领域。

一种反省

最近在看朋友推荐的一本书《思想的未来 (豆瓣)》,这本书是一个美国教授写的,关于互联网创新与专利法保护的诸多思考。引用一段简介如下:

劳伦斯·莱斯格对因特网革命中为何会出现一种反革命的破坏性力量及后果做出了解释。创作之所以繁荣,是因为因特网保护了创新的公共资源。是因为因特网保护 了创新的公共资源。因特网的独特设计营造出一个中立的平台。最广大范围的作者们可在此平台上进行试验。围绕此平台的法律架构对这一自由空间给予了保护,以 使文化和信息——我们这个时代的思想能够自由流动,从而激发出了空前广泛的思想成果。但是,这种架构设计正在改变——无论是法律层面,还是技术层面。

这种改变将导致早期困持网所提供的创作及创新机遇的丧失。诸多强权力量正迅捷地以法律和技术来“驯服”因特网,使之从一个思想的开放园地沦落为一个无异于高速有线电视的东西。创新将再次受到由上而下的束缚,逐渐为网络所有者、专利大户以及版权囤积才所控制。

技术使非凡的未来成为可能,与此同时,思想的未来这门却在关闭。我们需要在进步与新黑暗时代之间做出选择。

是的,未来并非一片光明,我们也不是一直在高歌猛进,规则的不断改变,也并非越来越好,总之:未来将会如何,我们难以预料。

保存评论:

这是一个倒果为因的文章。
互联网的创新,从来都不是为了降低质量,也从来都不是为了让别人不好意思说,才去做免费的。每一个做互联网创业的人,首先想的是如何做出做好的东西来。当然也有一些人想要糊弄一下的,不过这些人已经都倒下了。各行各业可以进入互联网,可以使用互联网带来的各种各样的便利条件。但是这些行业并不能够以互联网的思维来思考问题,来判定是非。

所谓互联网思维,是互联网企业或创业者在尝试使用互联网逆袭传统行业的过程中,逐渐形成的。
传统企业占据了市场,不会主动退出来。互联网企业也不可能创建那么多的新领域,于是就会利用互联网来尝试颠覆传统行业。这是被逼无奈的。
在这个过程中,互联网思维在生根、发芽、发展壮大。

另 外一个促成互联网思维的东西,是大数据验证下的,很多传统理论的崩溃。传统科学是通过猜想和有限证明的方式来不断发展的,当数据的规模扩大之后,很多以前 证明是有效的理论,被推翻了。在这个过程中很多社会学、人文、人类行为、传播学相关的东西,都被彻底打翻了。旧的理论倒下,新的理论站起来,这些新的理 论,为互联网思维提供了理论基础。

至于粉丝文化和长尾理论,这些其实并不是互联网时代才有的,互联网只是一种工具,可以让这两种东西可以在更大范围内被验证,并最终证明,当用户、流量达到一定程度的时候,这两种东西已经发生了一些质变,变得和传统意义上不同了。

[知乎专栏–思考IT]如何定量的评价一个技术社区的优劣?

这回又是朋友约稿,出了个天大的题目,我当时脑子一热,也就答应下来了。现在想想,谈何容易啊?

这是我设想的,一个社区的良性循环模型:一个氛围良好的社区,能够不断创造优质的内容;而优质的内容通过各种渠道,吸引新人加入;而一个能够不断接纳新人,并且将其融入的社区,则能够始终保持高质量的成长。

这个循环,对于各类社区(并非局限于技术社区),应该都是适用的。

从这三个维度,我们可以找到三组指标来进行衡量:

  • 社区氛围:
    • 社区黏性指标:会员每周平均在线时间,平均每次在线停留时间,可以作为两个比较重要的指标。
    • 社 区互动性指标:首先需要定义何为互动,我发表内容,你评论,则你与我互动。我回复评论,则我与你也互动起来了。就好比一块石头投入池塘,会引发多少涟漪, 这是一个社区活力的体现。转换成定量的指标,我们可以设置两个:人均每日互动次数;一周内单篇内容引发互动总数;来作衡量。
  • 创造内容:
    • 引用性指标:一个网站的内容,被多少站外地址引用,这本来就是一个常用的质量指标,Google的Page Rank,也是这样的指标。
    • 传播性指标:在SNS网络兴起以后,一篇内容被分享出去多少次,变得非常重要。我们可以简单的用站外流量,进行衡量。
  • 招揽新人:
    • 转换率指标:一个从站外点击过来的用户,会有多少转换为社区的注册用户,这就是转化率。
    • 留存率指标:对于社区而言,新人注册之后,七日留存率;30日留存率;都是重要的参考指标。

以上讨论的三组指标,都可以是适用于任何内容型社区,而对于技术社区而言,应该需要更多的专项指标:

  • 技术日新月异,新的名词层出不穷,一个技术社区的开放程度与丰富程度,可以从社区内讨论的技术新旧程度,以及讨论技术的广度、深度来判断。(深度的确太难量化了) Webopedia: Online Computer Dictionary for Computer and Internet Terms and Definitions 这是一个很有意思的网站,他会不断的收集最新出现的计算机与网络新词汇。也许我们可以做一个词汇扫描,看看这里新出现的词汇,在多久以后,会出现在技术社区的讨论区里。
  • 技 术牛人,是一个技术社区的宝贵财富。但是这又是最难被量化的部分。如果某个技术社区,每个会员都被要求填写自己的Github帐号(甚至只能用 Github帐号登录),那么,我们可以用这个技术社区的全体会员的所有Github Repos,所获得的Stars数量与Forks数量,来做一个粗略的估计。
  • 当然,特定的技术社区,还可以有更加准确的统计:例如一个Linux内核社区,可以直接统计他们对于Linux内核每年贡献的补丁数量,诸如此类。

以上就是我的一点抛砖引玉。