instagram 是近期窜红的 iPhone App 和图片分享社区。仅一周时间就积累了 10 万注册用户。但 InstaCamera 可不是新玩意，那东西以前叫“拍立得”。谁拿个 Polaroid 在手，立马文艺的牛比闪闪。著名博客评论家 Robert Scoble 近日发表了一篇博客，详细阐述了为什么 Google 不能出品类似 Instagram 的应用.

今晚我和一 Google 高管聊天，提起了近期窜红的 Instagr.am （几个星期内超过 50 万的下载量），然后就问他”为什么 Google 做不出类似的应用？“

其实我是多少知道点答案的，因为在我为微软工作的时期，很多创业公司超越了微软。（比如 Flickr，Skype，等等）。

我告诉了他一些我的看法，他也透露 Google 内部也意识到创新出了问题（看看 Google Wave 和 Buzz 就知道他们失败到何种程度了）。Google 正在内部改变公司文化，以鼓励内部员工创业性的项目。

1. Google 没有办法把团队保持到一定的小规模

Instagram 的两位创始人是在第 38 号码头的 DogPatchLabs 租了一张办公桌开始的。据此 Google 高管说，Google Wave 团队超过 30 人。他曾经创业过，所以他非常了解那个神秘的人月关系。每加一个人到团队，项目迭代的速度就会下降。他告诉我甲骨文的 Larry Ellison 是如何提高团队效率的故事。如果一个团队效率底下，他会每个星期过来说“让我来帮你一下”。他做了什么呢？他每次从团队调走一个人，直到团队停止无谓的会议，开始做出产品。

2 Google 不可能像 Instagram 那样大刀阔斧的削减需求

Instagram 的初衷其实和现在的产品很不一样（这事据说当时和他们的疯投 Andreesen 起了冲突）。起初这个不仅仅是个拍照片的软件。但几个创始人认识到他们不可能完成这个巨大的任务。他们开始削减需求。Instagram 可以做到这些。但 Google 不行。想象一下如果你对 Larry Page 说：嗯，关于我们的那个社交平台，我们去除 90% 的需求吧“。Google 要和 Facebook 正面竞争。Instagram 只需要和它自己竞争。所以 Andreesen：这也是为什么几个我喜欢的公司从来就没有去拿疯投，比如 GoPro 和 SmugMug。“着眼于本垒打”的压力其实压垮了很多公司。

3. 在 Google，如果一个产品成功了，它会获得很多很多的资源和人力

想象一下如果你在 Google 工作，然后你在你的 20% 的时间会做什么事情呢？肯定不是很乏味的项目吧。你当然想加入一个超酷的项目，比如 Instagram，一个炙手可热大家都喜欢的项目。如果 Instagram 是 Google 内部的项目，他们就要面对潮涌的 email 和一大批等候在他们办公室外面跃跃一试迫切想加入的同事们。我在微软也亲眼目睹了类似的事情。

4. Google 要求他们的员工用自己的基础设施，但问题是这些基础设施并不适合小型的社交模式的项目

在 Google，你不能用 MySQL 和 RoR。你只能用 Google 的 Big Table 来存储数据。那可不是为了小型社交类型的项目而设计的。开发者们告诉我说用 Big Table 并不是很容易，而且也比外部开发者缺乏效率。

5. Google 的服务需要支持所有的平台

在这种情况下，如果你说“我们的项目只支持 iPhone”，你肯定会被轰出会议室。而且这项目也必须支持 Google 在全球范围内的每个社区。我记得微软的团队因为要测试自己的产品在全世界的所有语言环境里都可以运行而被拖至龟速。还真让人无可奈何。Instagram 就没这样的问题。他们可以说“我们现在只支持英文，其他人我们没空管”。

6. Google 不能使用 Facebook 来整合产品

这也意味着获得新用户会有点困难。我这个星期下载了几个 iPhone app，然后登录 Facebook 后就很方便的加入了我的朋友清单。我的朋友们都在 Facebook。我在 Google 的社交圈根本没什么朋友。Instagram 可以使用任何他们喜欢的系统。Google 则要付出点“战略税”（Strategy taxes：因为战略上的原因而不得不用其他非 Facebook 的方法来实现功能。这里耗费了不必要的人力和物力）。

7. Google 没办法半公开的测试产品

几个星期前 Kevin （Instagram 的创始人）给我的 iPhone 装上了测试版的 Instagram。他叫我不要和其他人说，但也没有叫我签保密措施。其实他知道如果我泄露一点信息可能对他也有好处（不过我没有泄露）。他那时候需要的是热情的用户，那些会使用这个软件并提交测试过程中遭遇到的问题。Google 的做法是“吃自己的狗粮”。但现实是你需要公司外部的人来使用你的产品，而不是闭门造车。Google 不行，这牵涉到太多的政治斗争。Instagram 没有这种政治斗争地狱。他们毫无顾忌的给几十个人预览这个应用，从而获得很多的反馈，修复了一大堆的 bug。而且这批早期用户也非常喜欢这个产品。

8. Google 没法用 Eric Ries 的技巧

Eric 的“瘦形创业公司”方法是先搞清楚客户需要什么，然后再建设所需要的基础设施和未来的可扩张性。Google 则相反，他们需要确认这服务几亿个人使用没问题，然后再开始做产品。Google Wave 失败的一个原因就是第一批用户进来后就变得非常的慢，虽然他们有个邀请机制限制新用户数量。

那么，大公司如何创新呢？嗯，大公司可以收购小公司。或则，Google 可以去开拓一些小公司没有能力去开拓的领域。比如开发无人驾驶汽车。这就需要很多人的团队了。

还有一条路就是开源项目，这样大家都可以贡献代码，而不需要开无聊的会议。比如 Rackspace 的 OpenStack 里有一些非常不错的创新。而这些创新是来自 Rackspace 外部的人。还有硅谷目前最酷的公司，Cloudera，他们知道公司会越来越大，为了防止类似公司内部政治冲突，他们正在建立一个系统，让开发者可以无顾虑的加入新的创新。又比如非科技公司的 TEDx，他们用加盟的方式在全世界举办了几千场 TED 大会。他们给会场 TED 的冠名，而不需要经过母公司的审批。这样他们就可以一直的处于创新的地步，就算他们的内部已经停止创新。

Posterous CEO 从苹果公司学到的 8 个管理经验也或多或少验证了我的观点，特别是保持一个小的团队。

有些经验听起来莫名其妙。让团队更有效的方法是调走团队成员？但根据我多年在世界上最好的科技公司混迹的经历来说，这些事层出不穷。

所以，你觉得呢？你工作的地方有类似的问题吗？如果是我，我就会指出这个问题，并试图如何找到解决办法。

自1999年起我就开始发掘一些科技公司，并帮助它们运营。我最近的一个公司是fabulis.com。下面是从干这行中得到的57条经验。我可以列出更多，但恐怕会令你厌烦。

1.做你个人有热情的事情。你是你自己最好的民意代表。

2.用户体验很重要。大多数产品做不到这些是因为用户弄不清怎样才能从这些产品中获得好处。很多产品做不到这些是因为过于复杂。

3.要懂技术。你不必去写代码，但你必须能理解它是如何被开发出来的，如何工作的。

4.创业公司的CEO必须，必须，必须担任产品经理。他/她必须对产品拥有功能性的用户体验。

5.对功能进行主次分级。不会有两个等同的功能。你不可能把它们一次全实现。要进行兵力优化。

6.使用缺陷跟踪系统，虔诚的用它来管理你的开发活动。

7.及时发布。除非真正的用户接触到你的产品并给予反馈，你永远都不会知道你的产品是好是坏。

8.尽快发布，经常发布。不要惦记着再增加一些其它功能。只要能达到可以用来收集用户反馈的最小功能集合，那就发布它。收集反馈信息，反复这个过程，发布下一个版本、下一个版本，越快越好。如果你3个月才发布出第一版面向用户的产品，你拖延的太久了。如果3个星期才发布一次更新包，你拖延的太久了。如果不能一周几次，那每周发布一次更新。每3周发布一次重大更新。

9.唯一有意义的事是你的产品的好坏。其它的都是鸡毛蒜皮。

10.对你的产品好坏的唯一判定来自于有多少用户使用它。

11.因此(补充第9、10条):产品初期决定你将来是否能成功的关键因素是你的产品的吸附力。把你主要的时间花在如何在你早期的受众中培养吸附力。如果你能启动这个过程，雪球会越滚越大。

12.如果你最初设想的50%后来证明可行有效，那你已经相当成功了。尽可能的听取你的用户。

13.不要依赖于你的用户代表去告诉你如何发展。用户代表可以告诉你如何定位，帮助你明确潜在的需要打磨的核心内容，但你仍然需要有能力汇总消化这些信息，知道哪里去找到你的用户。

14.大多数人真正主要使用的也就是5～7种服务。如果你想做一个重要的产品，成为一个大公司，你需要能清楚如何成为这5～7种服务中的一种，这样去让用户为你着迷，俘获他们的热情和信任。你需要给你的用户一个好的能够让他们在你的服务上花时间的理由。

15.尝试追逐正在进行的潮流，开创你自己的市场。如果可以的话，捕捉刚刚出现的趋势苗头，驾驭它。

16.找个“引路人”。有些人以前做过这些 — 融资，贸易，给创业公司工作。给这个人你公司的1%～2%作为报酬换取他的时间。借助他们打开未来市场的大门。把他当作企业发展的宣传媒介。不要让委员会去做这种事情。顾问部从来就没有提供过有用的东西。找到这样的人，把他们当作你的引路人，依靠他们。

17.在你的项目上尽量找最棒的人一起工作，不管他在什么地方。

18.有可能的话最好设立分部，但这需要你穿梭在几个地区之间使他们正常运作。在线合作最少3～4周一次，这意味着你需要几乎每月都要在这几个地方旅行一次。

19.跟你喜欢相处的人一起工作。这不是说你可以跟你不喜欢的人不合。

20.要像信赖你的家人一样信赖跟你一起工作的人。

22.摆放你的办公桌，使你能看到你的同伴，他能看到你。如果你们每天都没有兴趣看到对方，那你们选错了一起工作的人。

23.使用一个类似Yammer的内部分享工具，分享你们正在开发的东西。对很多人(特别是开发人员)来说，更新状态信息要比发送邮件更容易。

24.在团队中使用一个文件共享服务系统，例如basecamp。这对所有人都很重要，它可以记录所有的文件动态并发送到你的邮箱里。basecamp使你有了历史存档，有了一个集中式数据文档库。

25.认清楚自己真正擅长的是什么，把自己的精力主要放在这些事情上。让其他的人做其他的事情。

26.让你的周围围绕着能够弥补你的缺陷的人。让他们做他们擅长的事。你不要去做他们的事。

27.跟在某些方面比你更聪明的人一起工作。

28.跟那些会和你争论，反对你的人一起工作。

29.白天地狱式的奋斗工作，晚上回到家和家人相亲相爱。

30.跟那些热衷于解决你正要解决的某些特定问题的人一起工作。光热情于发展公司业务还不够；还要热情于你的客户，热情于解决他们的问题。

31.促使你周围的人像你一样用心。

32.忠诚。培养和引导人们，而不是鼓噪他们。

33.你永远不会像你想象的那么正确。

34.每周至少去健身房或跑步4次，要想保持你的思维的体型，先保持你身体的体型。

35.不要在飞机上喝饮料，除非你的航程超过8小时。那会害了你，而且浪费你的时间。

36.你选择的投资者应该是你喜欢和他一起工作的，可以做朋友的，能够得到忠告的人。

37.不要按价值来选择投资者。淡化一些这方面的色彩，从长远看，不会有坏处，只要选对人。

38.创业初期募集资金越少越好。强迫自己进行严格的预算，认真使用每一块钱，就好象是最后一块钱。

39.一旦有了一些发展动力，募集一些多于你的需要量的资金，但你要清楚它们都将做什么。这有些技巧。不要在募捐活动上吝啬。

40.每分钱都要花的小心谨慎，就像那是你最后一分钱。

41.清楚你要做什么样的公司。像Google和Facebook这样的公司没几个。对于你的公司，也许1千万的回报额已经很好，也许2千万，也许一亿，也许什么都没有。计划好你要做什么样的工作。不要去做做不到的事情。看清楚你口袋里有多少钱，能做什么事情，两年赚取2千万期望值的20%要比5年赚取1亿期望值的3%要好。

42.跟41条有关，明白你的业务是否适合接受风险投资。风险投资一般会期望10倍的回报率。也就是说，你接受5百万，那就要提供5千万的回报。1千万的投资 = 1亿的目标。在签署接受风险资金时一定要想清楚他们在你身上期望的是什么。

43.把你的个人公司发展目标和你的投资者的目标保持一致。有目标公司才能成功。投资者没有魔力让事业成功。同样他们也没魔力让CEO用心。

44.会议一般来说都是在浪费时间。

45.微笑。大笑。穿有趣的袜子。我穿有趣的袜子，用来提醒我不要满足于平淡，要有创新。

46.做事情时，做任何事情时，都不要让你看起来像个机器人。让人们知道真实的你。

47.正视你的问题，化劣势为优势。

48.任何地方都穿着你公司的T恤衫。

49.成立自己的客户服务。

50.要会讲故事。

51.别说谎。永远不要。

52.在你周围的人身上寻找灵感。

53.每天都保持快乐。如果不高兴，那就别做。没人要你做。

54.销售中的那句话说的很对，你的成绩只跟最近的一次销售有关系。

55.犯错误，但要吸取教训。我犯了无数错误。

56.成熟，但不要长大。

57.永不放弃。

自从编程界的领袖们发表旨在通过接受需求变更，加强同用户合作，缩短软件提交周期来改善软件开发过程的敏捷软件开发宣言至今已近10年之久了。

敏捷宣言制定2001年2月，当时一群软件开发者聚集在犹他州，他们希望能找到一种可以替代那些由文档驱动的、“重型”的软件开发模式(如当时的被当作金牌标准的瀑布模型方法)的新方法。

尽管早在犹他州会议之前，敏捷开发方法就已经出现，但这次会议却被当作这种方法论推广进程中的一次分水岭事件。十年以来，敏捷开发已被众所周知，很多软件公司采纳了Scrum和XP(极限编程)等敏捷开发实施方案。尽管还存在着不可预知的问题，敏捷方法领域里的专家都认为，总的来说，敏捷方法的实施会给软件开发活动带来益处。

“我说过，我们改变了这个行业，”一位宣言的签署者、目前在Tektronix工作的Ward Cunningham这样说。由于敏捷的出现，关于计算机编程的没落和编程危机的讨论逐渐消失，他说：“我们已经再也听不到人们谈论这个话题了。”

敏捷宣言比实际预期要成功的多，IBM Rational部门的首席敏捷和Lean方法论导师Scott Ambler这样说。

“它对我们整个行业有着重大的影响，”Ambler说。“如今你已经很难找到有不想去试试敏捷方法的人了。跟传统的开发方法相比，人们希望使用敏捷开发和迭代开发来使项目获得成功的愿望要强烈的多。“

但是Kent Beck，同样也是一位宣言的签署者，并且是XP的创始人，在宣言签署的10年后，对敏捷开发所带来的好处去并不是那么认可：“对于这个问题我没有一个几句话的答案。”

“敏捷开发是让人们更加认真仔细的思考如何开发软件，”Beck说。然而，并不是每个人都在敏捷开发上走对了路，他提示说。“仍然有很多人喜欢把读来的一些建议指导应用到他们的项目上，其实那些根本不是所谓的敏捷开发，“Beck说。

敏捷开发的条件

敏捷开发很难学，Cunningham说；”在你能够使用这套方法论前你必须掌握精通各种技巧。“

敏捷开发需要你扎实的技术功底，Cunningham强调道。”有很多人闯进这个领域后发现编程枯燥乏味，不再想学。“Cunningham说:”你要有兴趣做它，想把它做好，这样才有助于你成功。“

“来自企业组织的阻碍会在敏捷方法论的实施过程中显现出来。敏捷开发鼓励更加频繁的交付软件，鼓励把事情分解成小块，而不是把整个项目看成一块。”Skip Angel — 工作于BigVisible Solutions的一位敏捷顾问这样说。”我想这些对于一些企业是个挑战，这些企业的运营方式并不能使他们可以做敏捷的交付。“

项目在一些耗时的过程中很可能会陷入泥潭，Angel补充道，开发人员应该使用持续集成来避免这种瓶颈。

敏捷开发不是银弹，Ian McLeod–做应用软件生命周期管理工具的SmartBear Software公司的执行副总裁这样说。”你需要把事情做对 … 你的敏捷开发可能做的很失败，“ 他说。

Beck回忆起1997年用敏捷开发方法成功的开发出JUnit Java单元测试工具。他们团队使用短周期迭代，大量的单元测试，紧密和客户进行沟通。

”它使我们开发的更快，使我们更好的清楚需要去做的事情，“Wade Weston — 开发标准化交流系统的AttainResponse公司的CEO 这样说。”AttainResponse每周进行开发工作的sprints。我们的sprints周期很短，我们把精力高度的集中于本周要做的工作。“Weston说。

“‘可是让每个人都能上手仍然是个问题，’我的一个兄弟经常对我这样说，他喜欢更详细明确的需求。我一直告诉他，我们之所以开发的这么快，就是因为我们没有明确的需求，”Weston说。等待核心的需求说明基本上是浪费时间。他补充道。

”有些时候，一些开发人员说他们在做敏捷开发，可事实他们根本不是，“Damon Poole — 提供敏捷开发项目管理软件的AccuRev公司的CTO 这样说。“有些开发人员2周都不能把开发的东西(或“故事”)完整的编译集成，”他说。“如果你真的是做敏捷开发，那2周的时间足够把用户故事发布了。”Poole说。

敏捷编程的多种实施方案

Scrum 和 XP 是两个最具有代表性的敏捷方法论。Beck把XP描述为更注重开发的技术方面的方法。“XP说的更多的是告诉程序员应该做什么，相对比，Scrum是一种项目管理方法论”他说。

”XP的与众不同之处在于它是一种体系，而不是一种解决方案。“Cunningham — 一位推动XP发展的贡献者这样说。”它是一种有计划的编程方式。“

Scrum专注于如何管理和交付你的产品，而XP却是考究于如何去做你的工作，Angel说。

Poole指出，”很明显Scrum和XP是目前两种主要的方法论，你经常能看到Scrum团队会采纳XP技巧，而XP团队也会使用Scrum概念。“

另外一种敏捷方法论是Kanban，它起源于制造业生产流程和Lean软件开发概念，Poole说。Kanban里的约束很少，它关注于如何使价值反馈给客户的过程，他解释说。Lean关注于组织效能优化，价值优化，降低浪费，确保正确的好的生产过程，Angel补充说。

RUP(Rational Unified Process)也被人们称作为一种敏捷方法，尽管这种说法有待商榷，McLeod说。RUP的特点是有一大堆的文档，它可能是针对敏捷方法中的各个步骤的，他解释说。RUP可以是一种敏捷方法，Ambler说：”RUP给予我们的是流程上的架构准则。它完全依赖于你是如何制定的。“

Ambler同时提到了DSDM — Dynamic Systems Development Method — 一个敏捷领域里的失败的案例。SDSM有点像RAD [rapid application development]，但在里面增加了一下额外的处理。RAD跟敏捷开发的不同之处在于它只关注开发迭代，而不考虑促进合作，他指出。

McLeod认为各种敏捷方法论和迭代开发过程很相似。”它们之间没有太多的区别，“他说。

“敏捷”这个术语，Cunnigham说，是在犹他州会议上选出的一个词，人们通常把它引用为”轻量级“的方法，他回忆到。但”轻量级“这个词从表面意思上看也承载着一些负面的含义，他说。

如果你看过之前的文章，应该对 Oracle 状告 Google 侵犯专利有所了解。上次事件之后，Google 显然没有服软，接着，Oracle 指出 Google 的 Android 平台偷窃 Java 代码，将事情推向了另一个高度。今日，JCP 重要成员Apache 基金会宣布，如果 Oracle 不给 Harmony 提供兼容性测试，将退出 JCP，并号召其它成员抵制 Java7。所有这些事件不仅是对 Google 的威胁和打击，而且直接关系到 Android 与 Java 语言的前途。

自由的语言，不自由的平台

Java 号称是跨平台的语言，简单的说，它是在不同平台之间搭建一个相同的软件运行环境。或说是 Java 虚拟机。虚拟机起到一个承上启下的作用，开发者不用考虑平台，只要保证自己的程序能够在虚拟机上运行，而实际的硬件操作由虚拟机联系操作系统完成。

Java 原本属于 Sun 公司。Sun 一直是一个在商业和开源之间走着平衡的公司。虽然，Sun 开发了大部分的 Java平台代码，但任何公司的平台，如果想要运行 Java 程序，仍就必须购买 Java 虚拟机的使用权，这涉及到安全和技术支持问题。从手机平台来说，诺基亚、RIM 等公司的手机平台都支持 Java 程序，就是因为它购买了 Java 虚拟机的使用权。

Apache 基金会的 Harmony

Apache 基金会的 Harmony 计划是试图提供一个 Java 的开源实现，就是说试图使 Java 平台脱离 Sun 的控制，获得充分的自由。这就是Harmony 计划产生的原因，对此 Sun 自然不会很高兴，一是商业原因，二是可能产生的平台分裂。因此，Sun 虽然没有起诉 Apache 基金会，却一直没有给 Harmony 提供兼容测试，同时 Sun 在 Java 平台的使用上有限制，因此 Harmony 的代码是不能使用到手机上的，当然 Apache 也没有这个计划，所以事情就搁置了下来，直到 Android 的出现。

Android 之道

Android 的 Dalvik 虚拟机运行的不是 Java 程序，可以说 Dalvik 完全可以运行其它语言开发的程序，但是 Google为了吸引 Java 程序员，允许 程序员使用 Android 的SDK 将 Java 代码转换成 Dalvik 可以运行的代码。它是如何实现的呢？Google 在开发 Android 的时候，雇佣了 Sun 的一些程序员，利用 Harmony 中的开源 Java 库来实现Java 程序的转换，避开了授权费用。这意味着开发者可以使用 Java 语言为非 Java 平台开发程序，Android 的火爆发展不能给 Sun 带来商业利益，而且可能造成平台分裂。

Java 7 的到来和 Apache 的反抗

自从 Oracle 掌权 Java 之后，JCP 便逐渐为 Oracle 所抛弃，这意味着 Oracle 要独自控制 Java 平台。做为 JCP一员的 Apache 基金会已经无法影响 Java 的方向，它的 Java 开源实现 Harmony 也被 Oracle 拒之门外，因此，Apache 基金会的存在只是一个形式而已。

Oracle 拒绝给 Harmony 提供兼容测试，这意味着 Harmony 与 Java 平台的彻底分裂，随着 Java 7 的到来，这个问题将更加严重。这是否意味着 Java 语言升级之后，Google 不得不重新编写底层代码已适应新的 Java 语言，但是 Google 这将是一项耗时费力的艰苦工作，而自己编写的实现也许会再次遭到 Oracle 的起诉，因为 Oracle 已经推出自己的开发环境 OpenJDK，获得了 IBM 和苹果的支持。

Apache 基金会目前已经正式声明，号召其他成员抵制 Java7，如果 Oracle 不提供 Harmony的兼容性测试，将退出 JCP，这意味着 JCP 内一个最大的开源势力推出 Java，下一步便是彻底的决裂，这对 Google 会产生什么影响，仍无法预料。

法律和技术的双重困境

Android 已经成为 Google 的收入生命线，Google 自然不会让步，在最近的回击中，Google 指出，即使存在侵权（或抄袭）的可能，也应该由第三方负责，因为 Google 使用的是第三方的开源实现。法律问题先放在一边，从技术上来说，Google 也面临着困境，因为 Android 的开发者使用的是 Java 语言，如果失去官方提供的支持，将是一个严重的问题。

Java 陷阱

开源领袖Ricard Stallman 早就指出Java 是“带着镣铐的自由”（Free but shackled），警告开发者谨防 Java 陷阱。此后，Sun 开源了大部分的 Java 实现代码，因此 Java 陷阱已经可以避免，但仍然要注意使用完全自由的平台，因为并非所有的平台都是自由的。

如果 Google 收购 Sun，将 Java 收归己有，或者当初与 Sun 达成协议，也许今天情形会不同。或着当初开发 Android 的时候，Google 应该培育自己的 Go 语言，而不是急于利用现有的 Java 开发者队伍。Java 关于开放的说法只是一个假象，而如今 Java 易手，一切都改变了。

很难想象 Google 会放弃 Android 系统，问题是如何发展它。Java 将逐步脱离开源社区，沦为 Oracle 的生财之道，这是一个利益当头、注重企业而不考虑个人开发者的公司，与 Java 的纠缠不清只能带来更多的麻烦。

Android 其实是在帮助 Java

现有的智能手机平台中，Java 已经不是开发者的首选，iOS，MeeGo 都有自己的开发环境，WebOS 不需要 Java实现，而 RIM 也在逐渐抛弃 Java，转向 Adobe AIR，这意味着 Java 在手机市场的空间在逐步缩小。讽刺的是，现在 Android 的飞速发展反而有利于 Java 语言在手持领域的地位。如果 Google 抛弃 Java，是否 Java 将只能在低端机之间苟延残喘，逐渐消亡呢？相信随着 Web 开发技术的进步，HTML/CSS/Javascript这样的网络开发环境将成为网络应用的首选，而底层应用开发将会是 C/C++的天下。

Oracle 的作法也许只是加速 Java 在手机领域的灭亡而已，当然是在它收完最后一笔保护费之后。

© merlin for 爱范儿: 拇指资讯小众讨论,