1998年2月23日，Netscape發表了兩個聲明。第一個聲明在CINet報道中稱：“在一種史無前例的運動中，Netscape Communications公司將會把Navigator瀏覽器拱手相讓，這證實了過去幾周內業界中的傳聞。”

而另外一條消息則是：“在將Navigator瀏覽器出讓的同時，要將下一代communicator套件的源代碼公之於衆。”

將瀏覽器出讓的決定並不令人感到奇怪，但是公佈源代碼的做法確實讓業界爲之一震。該條消息出現在世界各地的報紙上，甚至連開源軟件社團（Open Source community）爲此也感到驚訝。從來沒有一家大的軟件公司將其擁有版權的代碼公開過。Netscape的做法究竟意味着什麼？

我們已經決定轉換遊戲的領域，而且也不是第一次這樣想過。我們總是從這個領域以外得到過很多的想法，這一次Netscape爲建立一個更好的Internet環境以到達一個新的層次作出了貢獻。1994年當Netscape最初沒有限制在Internet上分發其早期的瀏覽器版本時，就有人說：“他們真是瘋了！”，而現在當Netscape提到“釋放源代碼”時，人們仍然像從前那樣評價他們。

這個問題的討論將開源公告比喻成一個正常運行的火車。在經過幾個月對於是否要將運行包免費分發的討論後，在令人難以置信的24小時裏，大家達成了一個協議，也就是將源代碼公佈於衆。

無論對於業內人士還是業外人士，這個舉動都是非常迅速而令人奇怪的，它反映了幾個不同思路的融合之處。Netscape的執行官們正在討論一份由Frank Hecker起草的白皮書，在白皮書中Frank描述了一個即將到來的前景。他提倡將Netscape的源代碼免費公佈。Frank已經完成了他的工作，引用Eric Raymond的文章——《教堂和集市》告訴人們如何將部門規劃推及到整個機構——從工程到市場再到管理，在這篇二十多頁的著作中很好的得到了全面的講述，他稱從中得到了源泉和動力：

當最初Netscape第一次將Navigator通過Internet網絡讓用戶不受限制地下載時，許多人認爲這種做法與傳統意義上的商業化軟件的贏利模式是背道而馳的。並且詢問我們如何能夠通過“將我們的軟件公佈出去”來贏利。當然，現在這個策略在Netscape的快速增長過程中，是一個關鍵性的成功因素，並且被視爲是一場成功的革新，而目前少有軟件公司以一種或多種方式來效仿我們的做法。於是隨後而來的問題是：將來是否我們要重複這種做法，僅僅是隻有這一次將源代碼公佈於衆？

在工程領域也有相似的看法。許多的Netscape僱員都有過同開放源代碼運動相互關聯的工作經驗。而且因爲Communicator的代碼同Java和HTML緊密相連，大多數人認爲有一個明顯的事實：這不是一個非常大的跳躍。Java的特性本身就引入了更開放的觀點來看待發行源代碼。因爲它是跨平臺的，在編譯成類文件之後可以成爲獨立與機器的可執行代碼，每一個可執行的二進制類都像是一臺虛擬機。這一努力的結果之一是程序員可以反編譯可執行代碼，並將它轉換回源代碼。而瀏覽器的“觀察源代碼”（view source）命令使得HTML成了一種普通的方言。許多人相信Netscape應該具備這一功能，而不是放棄它，應該鼓勵這一點，如果可能的話，甚至應該從中受益。

許多學術思想是在出人意料的瞬間合併的。在多次會議中，對這一建議的反應在幾分鐘內從發愣、震驚變成了點頭同意。大多數討論很快地從“我們是否應該”過渡到“什麼時候。”大多數關鍵人物認爲我們應該快速向前進，確定最終日期，實現目的。在元月份，Netscape向網絡界作出了承諾：Comminucator的源代碼在1998年的第一季度發佈。Netscape的這一承諾是極其嚴肅的，而且Project Source 331隨即啓動。這一切努力都是爲了讓Netscape能在1998年3月31日提供源代碼。

接着我們便開始真刀真槍地幹了起來。

生米煮成熟飯

Communicator源代碼的主體在Netscape公司被稱爲“Mozilla”。Mozilla最初是由Jamie Zawinsky和公司在開發Navigator時杜撰出來的一個詞。小組方式正在以近乎狂亂的節奏創建一個功能要比Mosaic要大得多的龐然巨獸。最後這一代碼的正式名稱稱爲Navigator。後來，這一大綠色恐龍成了公司的一個笑話，接着成了一個公司的吉祥物，最終成了一個公共的符號。現在這一名稱的用法更加通用了，用來指從Netscape Navigator衍生出來的開源web瀏覽器。說法改成了“釋放壁虎”。

在代碼第一次準備好公佈之前，要完成的工作量是驚人地巨大。由於事情已經表面化，他們將自己分成幾類，各司其職。大家都感到接下來的三個月將用於以Netscape公司都知道的那種近乎狂亂的節奏來解決問題。

最大的問題是包含在瀏覽器中的第三方模塊的處理。Communicator的源代碼中包括了不少於75個第三方提供的模塊，我們需要與所有第三方代碼的版權所有者打交道。我們安排了由工程師們組成的小組和佈道者，讓他們訪問每一家公司，並向他們推銷Netscape的開源觀念，希望他們能成爲我們的同志。他們所有的人都聽說過Netscape公司宣佈的開源決定，現在每一個公司都要作出選擇：他們的代碼可以被刪除，或者被替代，以二進制形式發佈（將它們保持在編譯過的狀態），或者以源代碼的形式與Communicator一起發行。由於情況複雜，許多第三方的承包商情況比較特殊，所以每一家公司所消耗的時間也是長短不等的。沒有一個普適的方案適用於所有的情況。

爲Project Source 331制定一個最後期限是一個基本考慮。這一最後期限需要艱難的選擇。當然第三方開發人員參加進來是可能的。規則是你要麼在2月24日前宣佈接受條件進入，要麼是從源代碼中被清除掉。當然我們一開始就設置這一最後期限是不難的，但是如果我們敲打牆壁與他們爭吵，則他們會覺得我們那樣做是讓人難以忍受的。當時間一天天過去時，一些代碼必須被清除掉。

Java是一種專有語言，所以它必須被清除出來。我們指定了三個工程做“Java切除手術”——也就是說，瀏覽器必須在沒有Java的情況下創建、編譯和運行。由於原來的整個代碼都是與Java緊密集成的，這個手術的難度是很高的。而且給他們設定的目標是在3月15日之前將源代碼搞好，以便騰出最後的兩個星期的時間用於測試。可憐的工程師們必須在極短的時間內在瀏覽器內將所有的Java代碼理清楚。

徹底清理代碼是一項巨大的工程。剛開始時，許多人感到在最後期限前要完成這一工程是不大可能的。但是在多次會議中，大家的熱情不斷高漲，並形成了戰略，車輪開始轉動起來。開發組扔掉了他們的整個工作負荷（大部分代碼是在爲下一代的瀏覽器開發的），每一個人的任務變成了外科手術。我們不僅納入了（或者刪除了）每一個要解決的第三方模塊，而且爲代碼編輯了所有的註釋行。每一個模塊的責任都分配給了小組，然後由他們去擦洗。

開始時一個偉大的革新是，我們決定使用Intranet的bug報告系統作爲任務管理員。“Bugplat”是Scopus的名稱，這是一種錯誤報告程序，它的前臺是HTML界面。這是一個極好的工作流管理系統。一旦新的任務出現，系統便開始報告，輸入是簡單的HTML表格。一旦得到bug的報告，系統立即設置優先級別，接着便決定相應的人員來解決問題，而且立即圍繞這一bug創建一個郵件列表。一旦一個任務（或者一個bug）被解決後，所有相關的郵件列表和優先級別將被停止，而且從視野中消失。工程師們可以跟蹤他們的模塊的進展，並且通過登錄到Intranet上觀察工程開展的情況。

刪除加密模塊是工程師小組的另一項艱鉅任務。不僅政府要求所有的支持加密的代碼必須清除掉，而且每一個調用它的句柄都需要編寫。小組的一項特有工作是與NSA（美國國家安全局）保持經常的聯繫，以管理合規性（compliance）之類的事情。

創建許可證

與代碼大清洗同等重要的事情是創建許可證。第一步是要解決一個大問題：現存的任何許可證是否都適合開源軟件？沒有一個人想起草一個新的許可證，但是每一個人都意識到必須有一種許可證可以適用於所有第三方的代碼，使得這一工程可以運行在企業水平上。現有的專有版權的軟件沒有一個是按照自由軟件的許可證發佈的。

一組開源軟件社團的領導，包括Linus Torvalds、Eric Raymond、Tim O’Reilly被邀請去參加Mountain View校園。他們對企業領導、律師和程序員發表了演講，他們談到了他們代表什麼，並且與一些小組談到了他們願意面臨的一些問題。他們花了大量的時間與Netscape的法律小組討論了現存的許可證——他們既談到各種不同類型許可證的力量，也談到了它們引起的問題。這些顧問還起着著名的創意班子的作用。

在得到這些顧問的意見和Netscape法律小組的指導原則後，一個小組開始深入研究現存許可證協議，試圖判斷是否有一種許可證可以Mozilla的要求。首先討論的是GNU General Public License，GNU Library General License和BSD許可證，我們花了很長時間考查並總結了這些許可證解決的問題和引起的問題。與過去應用這些許可證協議的代碼不同，Netscape現存的代碼基（Code Base）具有獨立的環境。一個最棘手的問題是，在代碼中使用了相當多的第三方元件，而這些東西受專有的許可證協議的約束。顯然，我們需要創建一種環境，在這個環境中，這些和其他一些新的商業開發人員可以貢獻他們的代碼給Mozilla，而Mozilla的許可證可以保護他們的商業利益。

BSD許可證更加寬容，它只要求版權持有人原封不動地出現在代碼中，但是這對Mozilla的開發是不充分的。它會讓開發人員承擔這樣的風險：對代碼的改進不會返回給他們或者社團的其他人。僅此一點就是一個很大的問劇，因爲它對開源開發努力長期地存在下去很關鍵。

另一方面，GPL的要求又使它在這一工程不受歡迎。GPL是“不健全的”，當把它用在一段原始的代碼中時，任何其他與原始代碼一起編譯的代碼也必須受GPL的約束。這一點對商業軟件開發人員是不可理喻的。例如，GPL可能會要求一個編譯進了屬於商品版本的Communicator第三方的元件也要按照GPL來發布，有些事情超出了Netscape的能力，因爲Netscape不能控制這些第三方開發商，並且Netscape也在自己的其他產品中使用了一部分Communicator的代碼（諸如服務器端的程序）。因爲Netscape沒有立即發佈那個代碼的計劃，所以GPL對這些產品的不健全作用將會對Netscape和其他公司構成相同的問題。GPL的一種改進，LGPL顯得更加開放或者限制更少，最接近滿足於Netscape商業開發的要求，但是它還是與GPL一樣含有太多的商業陷阱。

經過一個月的拼命研究、討論、並且與自由軟件社團的專家和辯護者開會之後，如同公衆的推測那樣，小組決定搞出一種新的許可證來解決這一特殊問題。Netscape Public License（NPL）出現了，它試圖在商業企業推廣自由軟件開發和保護自由軟件開發之間達成一種妥協。制定這一個爲下一步開源軟件許可證的過程花了一個月的時間。

還有一個非常之處就是，Netscape Public License（NPL）開始時是以由公衆可以對它進行貝塔版本測試的形式提出的。我們在netscape.public.mozilla.license這個新聞組提出了這一許可證的草稿，並請求大家進行公開評論。大家反饋的意見好壞參半。這份許可證草案的有一節像是一塊打火石，引來了最多的批評：NPL的一部分條款向Netscape提供了特別的權力，讓Netscape在它的其他產品中使用這些受NPL約束的代碼，但是那些其他產品卻不受NPL的約束。它還允許Netscape發佈NPL的修訂版本，最引起爭議的是，受NPL約束的代碼再授權給第三方時的條款與NPL是不同的。有些人提出的反饋意見說，僅憑這一點實際上就讓開源軟件社團不能接受NPL。

3月11日，jwz（Jamie Zawinsky）出現在netscape.public.moziIla.Iicense新聞組中，他寫的部分內容如下：

首先。我感謝你們提供了大量的反饋意見。這些意見對我們是極有幫助的。我們在認真聽取了大家的批評之後，提出下面的意見。

你們在下個星期將會看到第五節已經經過了大幅的修改，或許我在這裏不應該發表過多的評論（我不打算設置一個不正確的期望值），但是。你們大家都討厭的那一部分的內容現在已經很清楚。

3月21日，許可證的修訂稿發佈了，過是沒有先例的。反響巨大：“我告訴他們這是令人不快的，但是他們聽進去了！我簡直不敢相信！”大家意識到這是一個真正的開源工程，儘管開源工程並不是從這裏起源的。新聞組中的討論一直在幫忙指導這一過程，而不是對它的結果提供評論。後來持續不斷的討論語調一新，而且人氣旺盛。

對NPL貝塔版本的批評使許可證小組回到了起草委員會。他們找到了一種方案，可以讓Netscape在吸引自由源代碼開發人員的工作不偏離目標，和滿足公司的商業目的之間取得了一種平衡。結果是經過修改的NPL第二次發佈了，名稱爲Mozilla Public License（MozPL）。除了NPL包含對Netscape提供附加權力的修改內容之外，NPL和MozPL是等同的。

1998年3月31日，所有的代碼都在NPL的許可證形式下發布了，而且對代碼的改進也是在NPL許可證形式下發布的。新開發的代碼將按照MozPL的形式發佈，或者按照任何與之相兼容的許可證形式發佈。如果對源代碼中包含的文件進行改動，將被視爲是修改，將受NPL的約束。這消除了網絡界很多人的疑慮：不含任何原始代碼或者根據原始代碼修改的代碼的新文件將不被視爲修改，而且不受NPL的約束。這樣得到的代碼可以受任何相兼容的許可證的約束。GPL與NPL或者MozPL是不相兼容的。GPL在一開始就設計得與任何其他的許可證都不相兼容，因爲GPL在它的邊界上禁止增加任何限制或者更遠的許可。所有用GPL軟件開發的代碼必須回到受GPL約束的範圍內。另一個小問題是GPL堅持當你發行受GPL約束的代碼時，你發行的代碼必須是完全完整的。但是NPL沒有這一限制條件。

新聞組中的討論爲我們堅定信念，帶來了一個重要的內容：開發人員需要Netscape允許在對bug的修改代碼和新的代碼之間作出區分。顯然，如果一個人說：“我排除了一個bug，並對你的程序作了一點小的改進”，而另一個人說：“我爲你的程序增加了新的特性”，那麼你聽到這兩個人的說法後會產生不同的感覺。大多數人感到排除了一個bug不算什麼，它的價值通過貢獻出除錯代碼本身就得到了體現。但是新的代碼卻完全不同。一個完成了很多新工作的人不想看到有人會利用他的代碼去牟利。

NPL和MozPL都是設計用來鼓勵在Mozilla代碼基上進行開放的開發，但是從一開始，我們的頭腦中就有另一個目的。Netscape願意成爲第一家公開它的專有版本代碼的大公司，因爲它想吸引更多的公司在開源環境中進行開發的興趣。創造一個氣氛使得大型的贏利的組織採納這一模式並躋身於這一運動是最重要的。在大多數開源許可證中的法律基礎對於公司合作是一個大的障礙。有了Mozilla之後，許可證的問題成了它本身必須解決的問題。

通過公開今後版本的源代碼，我們希望它能鼓勵網絡上的整個團體在瀏覽器市場上產生新的革新。我們的想法就是讓全世界有才華的程序員玩味我們的代碼，用他們的創新能力不斷地爲瀏覽器奉獻新的生機，即使前途艱險，荊棘叢生，也能鼓勵每一個人勇往直前。

Mozilla.org

以前投入到開源工程的人已經意識到，必須要有一個地方來存放代碼。在Netscape宣佈釋放源代碼後的那天晚上，Jamie在InterNIC上註冊了一個新的域名，並且就如何發佈已開發項目的工作擬定了一個方案。於是，Mozilla.org就這樣誕生了。

所有成功的開源軟件工程部遵循一個模式，這並非是設計上的需要。也就是說，要有一個人或者小組做協調工作。無論什麼人對他們關心的代碼做了什麼工作，都會引起他們自己的興趣。一天下來之後，他們可能會對一些代碼作出一些小的改進。但是一個月過去之後，當軟件的新版本發佈之後會出現什麼情況呢？這時的情況可能比較複雜：他們當初的修改方案對於開放可能已經過時了，還可能需要回到原來的出發點——甚至更糟糕的是，因爲軟件本身可能也已經變了。

結果是，開發人員想將他們的補丁包含在主要的發行版本中。如果只有一堆源代碼出現變動，而且有一批人圍繞着這堆代碼工作，那麼最終會有一個人站出來說：“我想收集一批補丁的代碼，並且搞出一個發行版本來。”當第二個人問：怎樣將他的補丁加入到下一個發行版本中時，第一個人會說：“我不知道我的補丁還會有誰要，所以我會把代碼提供給那個人。我相信會對它作出改進。”隨着時間的推移，那個人會成爲維護者。

對於這個開源工程而言，馬是套在馬車的前面。mozilla.org的人從一開始就認爲並且將自己設定爲維護者的角色。因爲總是需要一某種方式產生這一角色，所以我們決定創造出一個基礎結構以成爲清算中心。

在接下來的幾個月中，rnozilla.org開始成了一個組織，並且得到了資金支持和設備，啓動了郵件列表，並且爲開始必要的工作掃清了障礙。任務只是讓組織從頭開始，並有效工作。關鍵是一旦源代碼發佈之後，在運作時應該有一箇中心的儲存點。如果我們不作準備的話，那麼六個月以後，我們得尋找其他某個人來做這件事。大家都知道Netscape不會守株待兔。

釋放了源代碼意味着Netscape將與Internet協同工作。當時需要接受一個關鍵概念：Netscape客戶產品開發小組（Netscape Client Product Development Group）和mozilla.org不是同一個組織。Mozilla.org的目的是爲全世界圍繞這一軟件的所有人充當協調人。而Netscape客戶產品開發小組的目的是發運產品——基於Moilia代碼的Netscape產品。因爲兩個基本點小組都爲同一個產品工作，所以他們的利益可以有所重疊。但是mozilla.org後面的小組知道，如果Internet上的人看到這個組織之後說：“啊，這些人心裏只有Netscape，他們只是發運Netscape產品而已”，那將是災難性的。這意味着mozilla.org沒有達到充當一個好的維護者的目的。因此必須將“Netscape客戶產品開發小組”和“mozilla.org”兩者隔開，並且讓網上的人知道這個情況。

垂簾的後面

當一個開發人員改進了代碼並且提交出來後說：“嘿，mozilla.org，請採用我的代碼吧！”會出現什麼情況呢？Mozilla.org最重要的一個角色是制定一個標準，以確定可以接受什麼樣的代碼，以及不能接受什麼代碼。我們必須將這一問題轉化爲好幾個子問題。首先而且最重要的是，代碼的優點何在，代碼真的好嗎？第二，代碼是否滿足NPL許可證的要求？我們決定，不接受不能滿足NPL許可證的貢獻者提供的代碼。如果不這樣做的話，那麼情況將會和修建萬里長城一樣，每一個人將會陷入沒完沒了的法律認可事務中，而且潛在的問題也會相當地多。

由於Mozilla採用了高度模塊化的代碼基，每一個主要的模塊，例如Image Library（圖像庫），或者XML解析器，有一個指定的“擁有者”（owner），這個人最瞭解代碼，他可以仲裁什麼東西應該進入模塊，而什麼東西不應該進入模塊。

許多模塊的擁有者是Netscape的工程師，但是也有一些來自網絡世界的五湖四海。當一個模塊的擁有者決定進行修改時（例如，向Image Library增加一個API），他的修改草案將寄往Mozilla.org，以便在發行版本中含有修改過的內容。如果在貢獻者和模塊擁有者之間出現了不同意見，那麼Mozilla.org將扮演仲裁者的角色，並作出最終的裁決——當然他總是會注意，如果他的某一種做法妨害了公平競爭，那麼他將會被大家瞧不起而被忽略掉，而且將會出現某個人替代他的職位。

Mozilla.org必須堅持讓Netscape內部的開發人員和在網絡上的人們都可以對代碼進行改進。在公司內部工作的人可以在Web上，而且可以從所有的平臺、在任何時間進行存取。這是由Bonsai和Tinderbox這些工具完成“tree control”的。

Bonsai這個工具可以讓你對一個檔案的內容進行查詢。它就像國書館的前臺，你可以對你工作過的代碼進行檢查，或者查看由其他人完成並加入了什麼代碼。在後臺，Bonsai經常地運行代碼，檢查代碼樹。如果樹折斷了的話，那麼它會發出一個紅色旗標，在問題得到明確以前，停止更多的代碼進入檔案。你可以將日誌拉出來對某個特定時間期間的問題進行踉蹤。這一工具以前只是被Netscape內部的開發入員採用，但是後來被mozilla.org拿來供全世界所有的開發人員使用，而且在任何平臺上都可以利用瀏覽器來直接使用它。

如果你的開發人數超過十人，而且沒有工具的話，那麼情況馬上會失去控制和爆炸。在Tinderbox後面有一種理論，Tinderbox是一種讓可能潛在爆炸局面得到控制的程序。Tinderbox是一種探測工具。它允許你查看在代碼樹中正在發生的事情。它顯示誰檢查了什麼（通過詢問Bonsai），什麼平臺建立成功，什麼平臺已經垮掉，並且精確地告訴你它們是怎樣垮掉的，建立成功的文件的狀態，以便你可以跟蹤並找出究竟是什麼原因導致破壞的出現。

1998年的愚人節

在1998年三月底前的一個半星期，最終期限馬上就要到了。大家都感到需要開一個慶祝會來祝賀代碼的發行，但是當時什麼也沒有做。爲了保留這一工程的其餘部分，邀請公衆進入Netscape沒有設防的世界的舉措，將是一個破天荒的事件。

在一次會議上，Jamie列出了一份計劃，準備租用舊金山的一個夜總會，邀請全球的人，並通過Internet進行廣播。“你是說邀請非公司僱員來這個慶祝會嗎？我們可是從來沒有這麼幹過啊！”爲了讓項目的其餘部分富有新意，在一陣停頓後，大家的反應是......“爲什麼不這樣做？”

慶祝會沒有被很快忘掉，Jamie租用了The Sound Factory，這是舊金山的最大夜總會之一，而且時間定在四月一日晚上。晚會的主持人（包括Apache的創始人Brian Behlendorf）在晚會上散發了幾千件恤衫，以及由NetObjects、Macromedia、Digital、Be、Wire和unAmerican Activities提供的軟件和東西。

當晚上八點“Mozilla Dot Party”開門時，門口已經排起了長隊。一個半小時後，能容納兩千人的夜總會場地被擠得爆滿，而且夜總會建築物的周圍也擠滿了人羣。在夜總會的其他一些人離開後，晚會開始在八點鐘放人進場，到晚會結束時，有3500多人進入了會場，包括一些自由軟件的大師（例如Brewster Kahle，WAIS的創始人，以及Eric Raymond）。成百上千的人將手錶調準時間，全球都爲Mozilla祝福。虛擬與會者包括雲集在荷蘭阿姆斯特丹Waag城堡的人羣，以及分佈在挪威、加拿大的蒙特利爾、賓夕拉尼亞、北卡羅萊那、威斯康星、科羅拉多和阿拉巴馬的人羣。

在會場內部，三個投影屏幕以大約每秒60行代碼的速度滾動地顯示了代碼。（按照這一速度，晚會將花至少七個小時才能顯示完Mozilla的全部一百五十萬行代碼）。晚會的第二個節目由Brown Band（Netscape的一個極具個性的工程師）和專程從費城趕來赴會的Eric Raymond主持表演。他們上臺後，分別獨奏笛子，的確讓全場觀衆大吃一驚。到晚會快結束時，一打刻錄了Mozilla源代碼的光盤和簽名版本的光盤（上面有頭天晚上Netscape Build Team和mozilla.org成員的簽名和編號）被拋向了人羣中的幸運觀衆。壁虎（lizard）被釋放了！

作者簡介

Jim Hamerly

Jim Hamerly是Netscape Communication公司客戶端產品部門的副總裁。1997年6月，Netscape公司兼併了DigitalStyle公司，當時Jim是該公司的一個創始人、總裁和CEO。

在建立DigitalStyle公司前，他是Pages軟件公司的副總裁、工程師。在該公司中，他負責管理公司的開發工作，包括桌面出版工具、WebPages和第一個所見即所得（WYSIWYG）式的Web創作工具。

Jim在同Xerox公司合作的15年中，參與了R&D和產品開發的各種活動，最近的工作是XSoft項目的執行總工程師，而該項目是Xerox公司軟件部的項目，他負責四條產品線的開發。Jim獲得過MIT、UC Berkeley和卡耐基梅隆大學的電子和計算機科學的學士、碩士和博士學位。

Tom Paquin

Tom Paquin最初加入了IBM研究部門爲有關並行處理器的項目工作，並以從事位圖圖形加速器（基於AMD 29116）而結束，而該項產品隨後被用於新型的PC上。在MIT和Brown大學完成了對X6和X9的修補工作後，他參與了卡耐基梅隆大學移植商業X11系統的部分工作。

Tom在1989年5月加入Silicon Graphics公司（SGI），在該公司他從事了並不如意的工程項目——集成GL和X。1994年4月，他加入了Jim Clark和Marc Andreesson工作的Netscape公司。他是最初的工程經理，他領導了他的小組發佈了Mozilla的1.0到2.0版本。現在作爲Netscape的一名成員，他從事的工作是mozilla.org的經理，問題仲裁者及其神祕政策的領導者。

i4CN（工業4.0中國-簡稱），是中國最系統化、最全面的工業4.0、工業互聯網、智能製造、無人工廠領域的第三方諮詢公司。公司整合華爲、博世、騰訊、美的等專家，首家提供工業4.0整合方案，包括i4技術項目、i4四大管理體系、十大思想變革的三層金字塔式諮詢架構；能夠指導企業實施專業化的工業4.0變革和無人工廠規劃建設與運營管理。助力國家實現中國製造2025的宏偉藍圖。

樑卓業 i4CN首席諮詢顧問中國工業4.0、智能製造、無人工廠、工業互聯網專家，華爲ISC、IPD體系專家華爲ISC+項目組成員，智能製造標杆車間項目經理工業4.0十大思想變革、無人工廠建設體系首創人中山大學麻省理工學院雙MBA，廣東工業大學機電學院本科歡迎需要導入華爲ISC、IPD體系，實施工業4.0無人工廠的企業與i4CN合作。

（請搜索i4CN樑卓業老師相關課程視頻並進一步瞭解）