1992年，Tim Berners-Lee（TBL）發明了三個東西：HTTP協議、HTML，以及URL，它們塑造出今天我們所熟悉的互聯網。天天上網的你，知道URL的發展史是怎樣的嗎？

URL從沒打算過實現現在的這種用途：讓用戶以一種近乎神秘的方式確認網站身份。然而我們沒能讓URN成為標準，也就沒法使用這種更實用的命名系統。認為目前的URL系統已經夠用了，這種想法就類似于贊美DOS命令行，并認為大部分人都需要學習命令行語法。

我們使用窗口化系統的原因在于想要讓計算機更易用，被更廣泛的用戶接受。出于類似原因，也許需要用一種更完善的方式定位網絡上的網站。

— Dale Dougherty，1996年

“互聯網”可以通過多種方式來理解。方式之一將其想象成通過網絡連接在一起的計算機所組成的系統。對于互聯網的這種認識早在1969年創建ARPANET時就已存在。其實在HTTP、HTML，或“網頁瀏覽器”誕生前，人們已經可以通過網絡進行郵件、文件、聊天等活動了。

1992年，Tim Berners-Lee（TBL）發明了三個東西：HTTP協議、HTML，以及URL，它們塑造出今天我們所熟悉的互聯網。他的目標是讓“超文本”（Hypertext）更為實用。簡單理解的話，超文本實際上是一種在不同文檔之間相互建立連接的技術。當時這種技術看起來更像是科幻小說里的萬靈藥，并催生出了超媒體（Hypermedia）以及其他很多以“超（Hyper）”打頭的詞匯。

超文本的核心要求在于要能在不同文檔之間相互連接。TBL當時認為，這些文檔可以用多種格式承載，可通過諸如Gopher以及FTP等協議訪問。但他希望能通過一種一致的方式引用使用各種協議編碼，托管在互聯網上，存在于某臺主機里的文件。

在1992年3月舉行的首屆萬維網發布會上，TBL將這種技術稱之為“通用文檔標識符（UDI，Universal Document Identifier）”。當時為這種標識符考慮過很多不同格式：

protocol: aftp host: xxx.yyy.edu path: /pub/doc/README
PR=aftp; H=xx.yy.edu; PA=/pub/doc/README;
PR:aftp/xx.yy.edu/pub/doc/README
/aftp/xx.yy.edu/pub/doc/README)

這篇文檔也解釋了為什么要對URL中的空格進行編碼（%20）：

UDI中應避免使用空白字符（White space character）：空格不是合法字符。這樣做是因為頻繁使用無關的空白字符會導致郵件等系統需要折行，或不可避免地縮短列寬，此外還要在轉換字符編碼方式的過程中，以及在應用程序之間傳輸文本的過程中對不同形式的空白字符互相轉換。

更重要的是，從本質上來說，URL只是一種對結構（Scheme）、域名、端口、憑據，以及路徑等內容組合產物進行縮略的方法，而以往在不同通信系統中需要結合上下文情境加以理解。

URL最初于1994年通過RFC正式確立。

scheme:[//[user:password@]host[:port]][/]path[?query][#fragment]

這種系統使得我們能夠在超文本中引用不同的系統，但發展到今天，幾乎所有內容都是通過HTTP方式提供的，因此可能已經不再那么重要。早在1996年，瀏覽器就已經可以幫助用戶自動插入 http:// 和 www. （這也讓當時在廣告中的網址里依然包含這些字段的做法顯得十分愚蠢）。

路徑

我覺得問題并不在于人們能否了解URL的含意，我只是認為迫使爺爺奶奶輩的用戶必須理解UNIX文件系統的各種約定到底是什么，在道義上這是一種很可惡的做法。

— Israel del Rio，1996年

過去50年里用過任何類型計算機的任何用戶，對于用來分隔URL中路徑部分的斜杠應該已經很熟悉了。這種具備層次結構的文件系統是由MULTICS系統發明的，該系統的創造者將這種做法歸功于他在1952年與愛因斯坦進行過一次兩小時談話的結果。

MULTICS使用大于號（>）分隔文件路徑的不同組件，例如：

>usr>bin>local>awk

這種做法在邏輯上很完美，但不幸的是發明Unix的那幫人決定使用 > 代表重定向，并使用正斜杠（/）分隔路徑。

最高法院，閱后即焚

錯了。現在我覺得你我之間存在明顯的分歧。 ...

作為個體，我保留為不同用途使用不同標準的權力。我希望這些名稱能夠更通用，可用于任何具體的解釋，也可用于任何具體版本。我希望實現比你的提議更加豐富多彩的世界。我不想受到你那種由“文檔”和“變體”組成的兩級系統的束縛。

— Tim Berners-Lee，1993年

美國最高法院意見里使用URL指向的頁面中，一半頁面已經不復存在。如果你在2011年閱讀一篇2001年寫就的學術論文，你肯定會發現很多已經失效了的URL。

1993年，很多人認為URL會消失，人們會轉為使用“URN”。統一資源名稱（Uniform Resource Name）是對特定內容的一種永久引用，與URL不同，URN永遠不會改動或失效。Tim Berners-Lee早在1991年就首先評論了這一“迫切需求”。

創建URN最簡單的辦法可能是對頁面內容使用算法創建哈希，例如urn:791f0de3cfffc6ec7a0aacda2b147839。但這種方法無法滿足網絡社區的某些要求，因為無法真正確定向誰提出申請才能將這串哈希轉換為實際內容。此外這種方式也沒能充分考慮文件經常可能進行的格式變化（例如壓縮和解壓縮），盡管格式再怎么變內容都是一樣的。

1996年，Keith Shafer和其他幾人針對URL失效問題提議了一個解決方案，介紹該解決方案的鏈接現已失效。Roy Fielding于1995年7月公布了一套實施建議，該鏈接也已失效。

不過我們可以通過谷歌找到這些頁面，而谷歌在這其中的作用已經類似于今天的URN。URN格式最終于1997年正式確定，但在那之后基本沒人使用。這種格式本身的實現也很有趣。每個URN包含兩個組件：負責對特定類型URN進行解析的authority，以及authority可以理解的，任何格式文檔的ID。例如urn:isbn:0131103628代表一本書，本地isbn解析程序（有可能）可從中提取出代表圖書URL的永久鏈接。

考慮到搜索引擎的強大威力，目前最好用的URN格式也許就是直接以文件形式指向早前的URL。我們可以讓搜索引擎索引這些信息，然后提供相應的鏈接：

<!-- On http://zack.is/history -->
<link rel="past-url" >
<link rel="past-url" >

查詢參數

application/x-www-form-urlencoded格式在很多方面都是一種反常的畸形，多年來在實施過程中遇到的意外和妥協產生了對互操作性的一系列必備要求，但這些要求無論如何也不能代表好的設計實踐。

— WhatWG URL規范

如果對網絡有所了解，你肯定已經熟悉查詢參數了。這些參數會顯示在URL中路徑組件之后，并包含了類似?name=zack&state=mi這樣的選項。你可能會覺得奇怪查詢為什么要像HTML對特殊字符進行編碼那樣使用連接符號（&）。實際上如果熟悉HTML，你可能曾對URL中的連接符號進行編碼，將 http://host/?x=1&y=2 變成 http://host/?x=1&y=2 或 http://host?x=1&y=2 （這種特殊的混用情況始終存在）。

你可能還注意到Cookie使用了類似但略有不同的格式：x=1;y=2，但這種格式與HTML的字符編碼完全不會沖突。這種做法并非W3C疏忽所致，他們其實早在1995年就鼓勵大家在查詢參數中支持使用;和&。

最初URL的這部分內容被限制只能用于搜索“索引”。最早發明互聯網是為了向高能物理學家提供一種協作方法（也正是出于這一目的才能獲得最初的資金）。這并不是說Tim Berners-Lee不知道自己實際上將發明出一種常規用途的通信工具。多年來他一直沒有支持在網頁中使用表格，盡管物理學家有這樣的需求。

總之這些“物理學家們”需要通過某種方式對信息進行編碼和鏈接，并通過某種方式搜索這些信息。為了實現這些目標，Tim Berners-Lee發明了標簽。如果某個頁面出現<ISINDEX>，瀏覽器就會知道這個頁面是可以搜索的。瀏覽器將顯示搜索字段，允許用戶向服務器發送查詢。

這種查詢使用了用加號（+）分隔的多個關鍵字這種格式：

http://cernvm/FIND/?sgml+cms

隨著互聯網逐漸流行，這個標簽很快被濫用來做各種事，例如對輸入的數值計算平方根。當時很快有人提議也許這種做法過于具體了，我們真的需要一種通用用途的<input>標簽。

該提議最終開始使用加號分隔不同組件，使其看起來更像是一種現代化的GET查詢：

http://somehost.somewhere/some/path?x=xxxx+y=yyyy+z=zzzz

這個提議遠遠超出了“廣受歡迎”的程度。有人認為我們需要通過某種方式宣告鏈接另一端的內容是可以搜索的：

<a HREF="wais://quake.think.com/INFO" INDEX=1>search</a>

Tim Berners-Lee認為我們應該通過某種方式定義強類型查詢：

<ISINDEX TYPE="iana:/www/classes/query/personalinfo">

我可以有些自信地說：現在回想起來，幸虧當時那種更為通用的解決方案未被采用。

基于古老的SGML類型開始實現<INPUT>的工作始于1993年1月。當時他們（也許有些遺憾地）決定<SELECT>輸入需要獨立的，更豐富的結構：

<select name=FIELDNAME type=CHOICETYPE [value=VALUE] [help=HELPUDI]>
<choice>item 1
<choice>item 2
<choice>item 3
</select>

也許你會好奇，繼續使用<li>而非引入全新的<option>元素這種做法是否是慎重考慮后的決定。當然當時這個提議還有很多備選方案。其中之一提出了一種變量置換方式，其作用有些類似于今天的Angular：

<ENTRYBLANK TYPE=int LENGTH=length DEFAULT=default VAR=lval>
Prompt </ENTRYBLANK>
<QUESTION TYPE=float DEFAULT=default VAR=lval> Prompt </QUESTION>
<CHOICE DEFAULT=default VAR=lval>
<ALTERNATIVE VAL=value1> Prompt1
...
<ALTERNATIVE VAL=valuen> Promptn
</CHOICE>

在這個例子中將根據type定義的類型對輸入內容進行檢查，并將頁面中的VAR值用于URL中的字符串置換，類似這樣：

http://eager.io/apps/$appId

還有別的提議使用@而非=分隔查詢組件：

name@value+name@(value&value)

最后Marc Andreessen根據Mosaic中的實現情況提出了我們目前使用的方法：

name=value&name=value&name=value

兩個月后Mosaic開始支持method=POST表單，“現代化”的HTML表單就此誕生。

當然，最終也是Marc Andreessen的公司Netscape發明了Cookie格式（并使用了不同的分隔號）。令人痛心的是他們的提議眼光太短淺，這也使得Set-Cookie2的引入變得更為困難，并導致產生了一些目前依然揮之不去的基本結構問題。

片段

URL中“#”之后的內容也叫做片段（Fragment）。在最初的規范中URL就已包含片段了，主要可用于鏈接到所加載頁面中的指定位置。舉例來說，如果我的網頁上有個錨點：

<a name="bio"></a>

就可以鏈接到這個錨點：

http://zack.is/#bio

這一概念逐漸擴展到每個元素（不僅僅是錨點），并可應用于id屬性，而非name：

<h1 id="bio">Bio</h1>

Tim Berners-Lee決定使用這種類似于美國郵寄地址的方式實現基于字符的鏈接（盡管他生在英國）。他的原話是：

至少在美國的傳統郵件地址中，使用數字符號（#）代表部門編號或大樓里的房間號是一種很普遍的做法。因此“12 Acacia Av #12”實際上是指“金合歡樹大街12號的大樓里，編號為12號的那個房間”。這種用途使用這個符號看起來是非常合乎常理的。那么http://www.example.com/foo#bar實際上就是指“http://www.example.com/foo這個資源中，名為bar的特定視圖”。

其實Douglas Englebart發明的最早的超文本系統也會出于相同目的使用“#”字符。這也許是巧合，或者也可能是偶然的“創意借鑒”。

片段是明確不能包含在HTTP請求中的，這意味著只能在瀏覽器內使用。這一概念在（引入pushState之前）實施客戶端導航的過程中體現出巨大的價值。如果要在不實際發送給服務器的情況下將狀態信息存儲在URL中，片段功能也會顯得極為有用。什么意思？一起看看：

小丘和大山，小題和大做

在電子數據交換[原文如此]方面有一種標準就像SGML那樣讓人不爽，我是指表單和表單的提交。我了解到的就是這些，除了它看起來很像Fortran，只不過沒有空格。

— Tim Berners-Lee，1993年

有一種很流行的看法認為，2002年時，互聯網標準的主體對于HTTP 1.1和HTML 4.01的最終定案沒起到太大幫助，而緊接著HTML 5誕生了。我把這段時期稱作XHTML的黑暗時代。然而事實是負責標準化的那幫人其實難以置信得忙，但他們只會做一些無法給人們帶來任何價值的工作。

語義網（Semantic Web）就是一個例子。這個計劃的設想是創建一種資源描述框架（作者備注：盡量遠離一切嘴里喊著要創造某種框架的人），這樣就可以用統一的方式表示有關內容的元數據。舉例來說，不要為雪佛蘭Stingray創建美觀漂亮的網頁，創建一份描述這款車尺寸、顏色，以及駕駛過程中因為超速接到罰單數量的RDF文檔就行了。

當然這本身不是什么糟糕的想法。但因為這種格式是基于XML的，讓整個世界實現文檔化，或者讓瀏覽器使用這些文檔呈現出有意義的信息，這里面又產生了一個先有雞還是先有蛋的問題。

這種想法也為哲學辯論提供了一個遼闊的舞臺。其中最厲害的一場爭論持續了至少10年，人們甚至給這個爭論起了一個著名的代號：“httpRange-14”。

httpRange-14意在回答“URL到底是什么”這個基礎問題。URL是否總是指向文檔，或者可以指向其他任何東西？我能讓URL指向我的汽車嗎？

他們對于這個問題的回答并不能讓人滿意。但他們反而開始專注于如何以及何時才能使用303重定向將用戶從非文檔鏈接指向文檔鏈接，以及什么時候可以使用URL片段（“#”后面的內容）將用戶指向鏈接的數據。

按照今天這種務實的想法來看，這似乎是一種挺蠢的問題。對我們大部分人來說，你可以將URL用于任何用途，人們愿不愿用是自己的事。但語義網除了語義本身不關注其他任何東西，所以也就那么回事了。

具體到這個話題，也曾在2002年7月1日、2002年7月15日、2002年7月22日、2002年7月29日、2002年9月16日，以及直到2005年的其他至少20個其他場合展開過討論。最終2005年頒布的“httpRange-14決議”解決了這一爭議，后又在2007年和2011年因為有人申訴而重新打開，最后有人在2012年呼吁開發一種新的解決方案。學院派的Web工作組對這個問題進行過深入的探討，但也僅僅是探討罷了。唯有一件事始終沒有實現：把大量語義數據放在網上并通過各種類型的URL提供給用戶。

身份驗證

你可能已經知道，URL中可以包含用戶名和密碼：

http://zack:shhhhhh@zack.is

瀏覽器會用Base64對這些身份驗證數據進行編碼，并作為頁頭發送出去：

Authentication: Basic emFjazpzaGhoaGho

使用Base64進行編碼的唯一原因在于，這樣編碼后就可以使用頁頭本不支持的字符，但這種方式對于用戶名和密碼信息無法提供任何保護。

尤其是在SSL大規模應用之前的互聯網時代，這種做法很成問題。任何可以嗅探網絡的人都將能輕松地看到你的密碼。對此很多人提出了各種備選方案，包括現在和當時都被廣泛用作安全協議的Kerberos。

盡管有這么多類似的例子，對瀏覽器開發商（Mosaic）來說，實施難度最低的依然是基本身份驗證這一提議。在開發者獲得自行構建身份驗證系統所需的工具前，這也使得這種方法成為首個，也是最終唯一的一個解決方案。

Web應用程序

在Web應用程序的世界里，“超鏈接是網絡的基礎”這種想法聽起來可能有些奇怪。這只是一種將不同文檔連接在一起的方法，只不過在樣式、代碼執行、會話、身份驗證等方面逐漸得到了增強，最后造就出七十年代那么多研究人員試圖打造（但沒成功）的全社會共享的計算體驗。

而從中得到的結論同樣適用于當今的任何項目或初創公司：接受度永遠是最該關心的問題。如果能讓大家都使用，哪怕你的作品并不完善，用戶也會幫你將作品塑造成他們需要的樣子。最終結論在于：如果完全沒人用，那么你的作品無論在技術上多么正確也沒啥用。很多人投入數以百萬計工時開發的大量工具今天不也是一個用戶都沒？

• 本文翻譯已獲授權，原文鏈接：

• https://eager.io/blog/the-history-of-the-url-path-fragment-query-auth/?h

• 本文譯者：大愚若智

▽

一場為你量身定做的容器技術大會！

這一次，我們的議題更加豐富，這一次，我們的講師更加專業，這一次，我們的內容把關將更加嚴格，主編、智囊團、用戶層層過濾，最好的內容，最棒的講師。CNUTCon2016全球容器技術大會將為您帶來一場技術盛宴，意在促進容器技術的發展與應用，現在8折期優惠，5人團更便宜，詳情請戳閱讀原文！

喜歡我們的會點贊，愛我們的會分享！

何提高產品價值，提高產品競爭力？關鍵是創新。

在20世紀，一家美國500強公司一般能存活67年之久。而如今，巨頭公司們只有15年左右的壽命。我們看了太多巨星的隕落——雅虎、諾基亞、甲骨文。激烈的競爭促使公司的產品需要不斷創新，提高產品價值，獲取更多利潤。

對于我們來說，如何才能保持產品的競爭力？

歸根結底兩個字：創新，產品人需要學會創新。

一、嬰兒恒溫箱的創新讓數萬嬰兒得以存活

二戰后，嬰兒恒溫箱的廣泛使用大大提高了歐美新生兒的存活率。但是，在一些發展中國家——比如利比亞和埃塞俄比亞，初生兒死亡率依然很高。復雜的設備一旦出現故障，需要專業的維修人員來處理。而缺乏的人力物力導致很多醫院的工作人員只能看著新生兒死去。

2008年末，普萊斯洛教授心起動念，建立DTM（Design That Matters）非營利組織，要為發展中國家研發一種新的嬰兒恒溫箱，要求維修簡單，并且容易找到替換的零部件。

最后，他們改進的嬰兒恒溫箱外觀和現代的嬰兒恒溫箱一樣，但是內部都是用汽車部件來拼接完成的：

1. 舊車的頭燈、前聚光燈提供主要的供暖。
2. 汽車儀表盤的風扇，用來保持空氣流通。
3. 車門蜂鳴器做報警系統，在供暖設備出問題時，蜂鳴器會叫，提醒護理人員。
4. 摩托車電瓶，或改良雪茄打火機，用來提供動力。

這樣的育嬰器不僅可以直接利用當地供貨充足的汽車零件。同時，只要是汽車維修人員，就可以修理這個育嬰器。普萊斯洛教授的汽車配件育嬰器，造福了無數的孩子與家庭[1]。

這就是開放型創新（open innovation），也被稱為合作創新。

開放創新的特點是：研究問題可以被清晰定義，所屬的領域往往可以與其他領域進行交叉，利用其他領域的解決方案來解決現有問題，衍生出創新產品。

Henry Chesbrough，開放創新之父，他對開放創新的定義是：開放創新能夠使用內部、外部有目的性的知識去加速內部創新，擴張市場。Open innovation is the use of purposive inflows and outflows of knowledge to accelerate internal innovation and expand the markets.

所以，如果你想做開放創新，需要清晰的定義產品現有的問題，并從其他行業的解決方案中尋找辦法。

比如：

1. 從各個行業的專利/文獻/數據庫中獲取靈感。
2. 連接你的客戶，專業人士，或其他領域的一些人進行合作，交流想法。

二、Nike建立GreenXchange，共享創新

2010年，Nike，Best Buy，雅虎等公司建立了GreenXchange，一個能夠分享專利和想法的組織。

GreenXchange里面的專利和想法均基于CC協議（Creative Commons）來管理共享的權限，比如：可以免費使用到商業行為中，或只能使用但是不能傳播等。目前很多文獻數據也是基于CC協議可以免費下載和傳播（比如：Arxiv, Spring Open, NCBI等數據庫）。

GreenXchange里的專利技術往往能夠節能減排，降低污染。每家公司都會在現有專利技術的基礎上再次創新、共享。

Nike的管理員說：“Nike有大量的專利和技術放在架子上從未被使用，為何不讓其他人使用進行創新”

當年Nike研發出了一款綠色橡膠（green rubber）材料，能夠降低生產成本，并且降低96%有害物質的排放。Nike隨后把這款技術分享給了一家加拿大的公司，Mountain Equipment Co-op，并授權此項技術可以應用到他們的產品中進一步創新。

三、VMWare的5E原則

VMWare，著名的云計算和硬件虛擬化軟件服務公司，內部有著自己的創新原則。

1. Exchange：交換想法。
2. Experimentation：允許員工對新想法進行實驗，允許失敗。
3. Enablement：提供培訓和工具讓你創新。
4. Enpowerment：授權，讓你自主創新。
5. Encouragement：鼓勵實現創新。

VMWare公司有個黑客馬拉松項目叫做Borathon ，在這個項目里面，VMWare的員工團隊合作，實現創新。并且從2004年開始VMWare每周都會有個一個技術討論會，大家聚在一起碰撞想法，分享建議。

四、 技術創新還是商業創新

19世紀中葉意式咖啡機就誕生了，設計者希望能在一小時內盡可能做出更多的濃縮咖啡，所以將目光聚焦在咖啡機的便捷性上，而非口味上。

1934年，Illy創始人Francesco Illy首次提出惰性氣體罐裝咖啡豆的技術，以達到長久保存咖啡新鮮度的目的，和現在的咖啡膠囊很類似。1974年Illy發布了簡易濃縮咖啡機成為了膠囊咖啡的先驅[2]。

但是，在這么多年里，咖啡機從未盈利。

而如今這款技術依然存在，卻深受用戶喜愛。技術本身沒有太大變化，但是市場卻有了如此翻天覆地的改變，這是為什么？

1990年后，Espresso公司意識到咖啡機不好賣的原因不是因為技術問題，而是商業模式問題。他們改變了銷售模式，不再售賣咖啡機，而是開始賣咖啡膠囊。相比機器，人們更加喜歡不同口味的咖啡膠囊，和制作出來的高質量咖啡。所以Espresso公司的銷售額一下子提升，并遠超其他競爭對手。

所以，商業模式創新的優勢更加明顯，并且商業模式創新還能為技術帶來許多益處：

1. 擴張現有技術規模
2. 獲取更優的新技術能力來創新產品

五、顛覆式創新

在古代，如果我們一直在使用馬車且不知道外界發生了什么。那么，我們對馬車的持續創新是不是給馬套一個鋼鐵俠的裝備？而現在，高鐵、飛機改變了我們的出行方式，每次出行再也不會有人叫一聲“駕～～”了吧。

大家還記得諾基亞和黑莓手機么？如果沒有蘋果，諾基亞一直持續創新下去會是什么樣子，黑莓手機呢？會不會變成一個鍵盤式電話？

我們的生活也接受著各種顛覆式創新的影響，比如：柯達公司在2012年提交了破產申請，如今我們也很少打印照片，而是使用各種電子化的存儲。外賣改變了我們的生活，降低了方便面的銷售額。線下零售也逐漸被線上零售占據了不少市場份額。

這就是顛覆式創新。

顛覆式創新會導致一些公司不可避免的失敗，比如：諾基亞，黑莓，柯達，Sears Roebuck等。而這些公司往往最關注用戶的聲音，傾聽用戶的需求，努力把體驗做到極致。而這些“好的特質”，卻是最致命的。

假設現在是上世紀70年代，你是硬盤制造業界排名第1的S公司高管，公司主打一款8寸硬盤，產品利潤率高，不愁銷路，下游客戶都是數一數二的業界巨頭，比如生產微型計算機的DEC公司。

S公司科研能力強，人力資源充沛，也愿意投資于創新。這個時候，你手下市場主管和工程主管分別來見你，向你提交了兩種截然不同的新產品提案。市場主管提議開發一種容量更大、速度更快的8寸硬盤，他的理由是現有的大客戶越來越喜歡大容量的8寸硬盤，新產品可以用技術優勢侵蝕競爭對手的份額，而且利潤率高達40%。

工程主管提議推出一種新產品——5寸硬盤，體積更小，但是存儲量小、速度慢、總體價格低，用戶定位也不明確，銷量、盈利前景均不明確，利潤率最多25%。

大部分參加測試的人都會認為：無論從滿足客戶角度，還是從公司利益角度，你都應該接受接受市場主管的提案，公司集中力量開發更強大的8寸硬盤，放棄工程主管提出的那個前景不明、低利潤率5寸硬盤方案。

結局呢？

進入80年代后，硬盤業界已經進入5寸時代，8寸產品無影無蹤，S公司這個字號也消失了。而你，那個曾經的高管，也加入了求職者的行列。你百思不得其解，無論從哪個方面看，你都作出了正確的選擇，可為什么市場卻給出了相反的結果呢？

在硬盤驅動器行業，最里程碑的顛覆式創新是縮小硬盤驅動器尺寸——這些創新技術將硬盤驅動器直徑從14英寸縮小到8英寸、5.25英寸、3.5英寸、2.5英寸，最后又縮小到1.8英寸。

在這“濃縮”過程中，實際是服務的市場從微型計算機到臺式計算機，最后到便攜式計算機行業的轉變，成熟企業只看重主流市場帶來的穩定增長，完全沒有預見和重視即將到來的個人電腦時代。一次次忽略市場的創新，最終被清理出局 [3]。

這就是領頭羊的“詛咒”。

圖片來源于網絡

六、 總結

看了以上這些創新的故事，對我們來說，開放創新是最容易實現的。

作為產品的領頭人，我們需要：

1. 定義正確的商業模式來獲取價值。
2. 構建合作網絡來傳遞價值（第三方、用戶、專家等）。
3. 策略化思考保護價值。
4. 犧牲部分短期利益來確保長期利益。
5. 全球化視野，實時監控顛覆式創新，關注時代整體變化。

參考資料

[1] 梁寧產品30講

[2] http://jandan.net/2014/02/11/nespresso-history.html

[3]《創新者的窘境》

作者：張圈圈，微信公眾號：lovepm

本文由 @張圈圈 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議

TML的發展歷史

HTML的歷史可以追溯到很久以前。1993年，HTML首次以互聯網草案的形式發布。20世紀90年代的人見證了HTML的高速發展，從2.0版，到3.2版和4.0版，再到1999年的4.01版。隨著HTML的發展，W3C（萬維網聯盟）掌握了對HTML規范的控制權。

然而，在快速發布了這4個版本之后，業界普遍認為HTML已經“無路可走”了，對Web標準的焦點也開始轉移到了XML和XHTML上，HTML則被放在了次要位置。

不過在此期間，HTML體現了頑強的生命力，主要的網站內容還是基于HTML的。為能支持新的Web應用，同時克服現有的缺點，HTML迫切需要添加新功能，制定新規范。

致力于將Web平臺提升到一個新的高度，一小組人在2004年成立了WHATWG（Web Hypertext Application Technology Working Group, Web超文本應用技術工作組）。他們創立了HTML5規范，同時開始專門針對Web應用開發新功能———這被WHATWG認為是HTML中最薄弱的環節

Web2.0這個新詞也就是在那個時候被發明的。Web2.0實至名歸，開創了Web的第二個時代，舊的靜態網站逐漸讓位于需要更多特性的動態網站和社交網站——這其中的新功能真的是數不勝數。

2006年，W3C又重新介入HTML，并于2008年發布了HTML5的工作草案。2009年，XHTML2工作組停止工作。因為HTML5能解決非常實際的問題，所以在規范還沒有具體定下來的情況下，各大瀏覽器廠家就已經按捺不住了，開始對旗下產品進行升級以支持HTML5的新功能。

這樣，得益于瀏覽器的實驗性反饋，HTML5規范也得到了持續地完善，HTML5以這種方式迅速融入到了對Web平臺的實質性改進中。

「鏈接」