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" href="http://zackbloom.com/history.html">
<link rel="past-url" href="http://zack.is/history.html">

查询参数

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平台的实质性改进中。

「链接」