<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>开放平台实验室</title>
	<atom:link href="http://oplatform.org/feed" rel="self" type="application/rss+xml" />
	<link>http://oplatform.org</link>
	<description>Open Platform Lab</description>
	<lastBuildDate>Wed, 07 Jul 2010 09:35:48 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>[节译] 关于碎片化的移动开发生态系统，你不可不知的点点滴滴</title>
		<link>http://oplatform.org/archives/171</link>
		<comments>http://oplatform.org/archives/171#comments</comments>
		<pubDate>Wed, 07 Jul 2010 09:35:48 +0000</pubDate>
		<dc:creator>刘青焱</dc:creator>
				<category><![CDATA[未分类]]></category>

		<guid isPermaLink="false">http://oplatform.org/?p=171</guid>
		<description><![CDATA[

出处：TechCrunch http://techcrunch.com/2010/07/05/mobile-developer-economics-2010/
原作：Robin Wauters
翻译：刘青焱 (qingyan123 AT gmail DOT com)

因为移动应用行业的碎片化，我们需要查看一些比较不错的研究报告来帮助我们理解这个持续增长的行业。由是，我请人检视了一下VisionMobile在这个课题上的详细报告（由  Telefónica开发者社区 资助），因为这个报告，是我迄今读过最好的之一。
这份名为 2010年开发者经济状况 的免费报告涉足了移动应用开发的方方面面，调查了全球超过400个开发者。他们主要分布在8个主要的平台上：iOS (iPhone), Android,  Symbian, BlackBerry, Java ME, Window手机, Flash/Flash Lite 以及 mobile web  (WAP/XHTML/CSS/Javascript)。
这份报告由一个三个研究员、五个采访员、八个移动应用开发者组成的团队在2010年一月到六月间完成。它提供了从平台选择到应用分发以及变现等关于移动应用开发的方方面面。

以下是一些要点：

市场渗透率（penetration）和知名度（mindshare）

-  75%以上的开发者认为市场渗透率是选择移动开发平台时首要的原因。很明显的，比较于技术层面，开发者更关注潜在市场以及变现的潜力。
-  大部分开发者在多个平台上进行开发：平均每个开发者在2.8个平台上开发。以iPhone和Android开发者为例，1/5的应用会同时出现在App  Store和Android Market上。
- 在过去两年，潮流正在变迁（见此）。开发者正在从“主流”平台上迁徙离开——我指的是Symbian,  Java  ME和Windows手机。一大批在iPhone和Android应用商店售卖他们的应用的少数派（约占20-25%）Symbian开发者说，这些新平台正在汇集大量开发者。
- Java ME“一次编写到处运行”的信仰已经逝去。更有趣的是，半数Windows手机MVP开发者（MVP的称号通常授予那些死忠开发者）都在用iPhone，而且，正在为下一次是否还要在Windows手机上投资而犹豫不决。
-  Android成为最受移动开发者欢迎的平台。调查结果显示，接近60%的移动开发者最近在Android上进行过开发。第二位的就是iOS  (iPhone)，超出了2008年的标杆Symbian和Java ME。
-  平台的特点显示出其在开发者中的知名度与其潜在市场的脱节。比如说，Symbian系统大概有3亿9千万的装机量（2010二季度数据），并号称有超过6000个应用。但是同期仅有6千万装机量的Apple  iPhone却有着30倍数量的应用。
-  证据显示，大多数开发者对他们投入大量时间的平台有着更强的粘性。在所有被调查的8类主要移动平台中，开发者总是感到他们的平台有这最高的市场渗透率，尽管实际上并不高。


&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;



市场（marketing），销售（sales）和变现（monetization）

-  时至今日，过去几年主流的市场渠道在移动应用推向市场的途径中已无足轻重。只有不到5%的移动开发者会把运营商门户或者通过OEM厂商/运营商进行预装作为首选渠道。研究发现，除了开发定制化应用的传统模式之外，开发者更多的借助于“原生”的应用商店或者从他们自己的网站上直接下载这样的方式。
- [...]]]></description>
			<content:encoded><![CDATA[<div id="WizHtmlContentId">
<p><!--WizHtmlContentBegin--></p>
<div id="WizHtmlContentId">出处：TechCrunch <a href="http://techcrunch.com/2010/07/05/mobile-developer-economics-2010/"><span style="color: #0066cc;">http://techcrunch.com/2010/07/05/mobile-developer-economics-2010/</span></a></div>
<div>原作：Robin Wauters</div>
<div>翻译：刘青焱 (qingyan123 AT gmail DOT com)</div>
<p><br class="spacer_" /></p>
<div>因为移动应用行业的碎片化，我们需要查看一些比较不错的研究报告来帮助我们理解这个持续增长的行业。由是，我请人检视了一下<a href="http://visionmobile.com/">VisionMobile</a>在这个课题上的详细<a href="http://www.visionmobile.com/blog/2010/07/mobile-developer-economics-2010-the-migration-of-developer-mindshare/">报告</a>（由  <a href="http://www.o2litmus.co.uk/tools/o2-network-enablers/communities">Telefónica开发者社区</a> <a href="http://www.o2litmus.co.uk/o2blog">资助</a>），因为这个报告，是我迄今读过最好的之一。</div>
<div>这份名为 <span style="text-decoration: underline;"><span style="color: #0000cc;">2010年</span></span><a href="http://www.visionmobile.com/research.php#devecon">开发者经济状况</a> 的免费报告涉足了移动应用开发的方方面面，调查了全球超过400个开发者。他们主要分布在8个主要的平台上：iOS (iPhone), Android,  Symbian, BlackBerry, Java ME, Window手机, Flash/Flash Lite 以及 mobile web  (WAP/XHTML/CSS/Javascript)。</div>
<div>这份报告由一个三个研究员、五个采访员、八个移动应用开发者组成的团队在2010年一月到六月间完成。它提供了从平台选择到应用分发以及变现等关于移动应用开发的方方面面。</div>
<p><br class="spacer_" /></p>
<div>以下是一些要点：</div>
<p><br class="spacer_" /></p>
<div><strong>市场渗透率（penetration）和知名度（mindshare）</strong></div>
<p><br class="spacer_" /></p>
<div>-  75%以上的开发者认为<strong>市场渗透率</strong>是选择移动开发平台时首要的原因。很明显的，比较于技术层面，开发者更关注潜在市场以及变现的潜力。</div>
<div>-  大部分开发者<strong>在多个平台上进行开发</strong>：平均每个开发者在2.8个平台上开发。以iPhone和Android开发者为例，<strong>1/5的应用会同时出现在App  Store和Android Market上</strong>。</div>
<div>- 在过去两年，<strong>潮流正在变迁</strong>（<a href="http://www.visionmobile.com/blog/2010/07/mobile-developer-economics-2010-the-migration-of-developer-mindshare/">见此</a>）。开发者正在<strong>从“主流”平台上迁徙离开</strong>——我指的是Symbian,  Java  ME和Windows手机。一大批在iPhone和Android应用商店售卖他们的应用的少数派（约占20-25%）Symbian开发者说，这些新平台正在汇集大量开发者。</div>
<div>- Java ME<strong><span style="font-family: 宋体;">“</span>一次编写到处运行”的信仰已经逝去</strong>。更有趣的是，半数Windows手机MVP开发者（MVP的称号通常授予那些死忠开发者）都在用iPhone，而且，正在为下一次是否还要在Windows手机上投资而犹豫不决。</div>
<div>-  <strong>Android成为最受移动开发者欢迎的平台</strong>。调查结果显示，接近60%的移动开发者最近在Android上进行过开发。第二位的就是iOS  (iPhone)，超出了2008年的标杆Symbian和Java ME。</div>
<div>-  平台的特点显示出其在开发者中的知名度与其潜在市场的脱节。比如说，Symbian系统大概有3亿9千万的装机量（2010二季度数据），并号称有超过6000个应用。但是同期仅有6千万装机量的Apple  <strong>iPhone却有着30倍数量的应用</strong>。</div>
<div>-  证据显示，大多数开发者<strong>对他们投入大量时间的平台有着更强的粘性</strong>。在所有被调查的8类主要移动平台中，开发者总是感到他们的平台有这最高的市场渗透率，尽管实际上并不高。</div>
<div><img class="alignnone" title="mobile apps" src="http://tctechcrunch.files.wordpress.com/2010/07/mobile-apps.png" alt="" width="1222" height="549" /></div>
<div><img src="file:///C:/Users/ehjlnox/AppData/Local/Temp/WizKnowledge/fb4237ba-9222-46ba-b124-28ee0e4f4d4c_files/mobile_apps[1].png" alt="" /></div>
<div>&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;</div>
<div><img class="alignnone" title="mobile app share" src="http://tctechcrunch.files.wordpress.com/2010/07/mobile-app-share.png" alt="mobile app share" width="630" height="392" /></div>
<div><img src="file:///C:/Users/ehjlnox/AppData/Local/Temp/WizKnowledge/fb4237ba-9222-46ba-b124-28ee0e4f4d4c_files/mobile_app_share[1].png" alt="" /></div>
<p><br class="spacer_" /></p>
<div><strong>市场（marketing），销售（sales）和变现（monetization）</strong></div>
<p><br class="spacer_" /></p>
<div>-  时至今日，过去几年主流的市场渠道在移动应用推向市场的途径中已无足轻重。只有<strong>不到5%的移动开发者</strong>会把运营商门户或者通过OEM厂商/运营商进行预装<strong>作为首选渠道</strong>。研究发现，除了开发定制化应用的传统模式之外，开发者更多的借助于“原生”的应用商店或者从他们自己的网站上直接下载这样的方式。</div>
<div>-  <strong>应用商店将应用上架的平均时间减少了2/3</strong>：从传统渠道的68天减少到22天。进一步的，应用商店<strong>将付费的平均时间减少了一半</strong>：从传统渠道的82天减少到了36天。平均看来，通过运营商渠道，55天收钱，通过终端商预装，168天收钱。</div>
<div>-  <strong>在Apple和Android平台之外，鲜有应用商店，也鲜有人用</strong>。Java中仅有5%、Windows手机中仅有略超10%的开发者使用应用商店作为首选分销渠道。</div>
<div>-  移动开发者认为最大的挑战就是<strong>缺乏有效的市场渠道</strong>来增加应用的曝光率。半数的开发者愿意付费购买其在应用商店中的展示位置。</div>
<div>-  应用认证的最大挑战就是其花费：超过30%的开发者认为，<strong>对其应用进行认证过程中所需的花费是首当其冲的挑战</strong>。经济学只适合大规模生产，不适合廉价应用。</div>
<div>-  应用淘金更像是梦一场：<strong>只有5%的开发者获得了很好的收入</strong>。接近60%的iPhone开发者没有达到他们的营收目标。</div>
<div>-  基于广告的收入模型是开发者通过应用商店和门户渠道分销应用的仅有的第二收入来源。而且是在<strong>按下载付费模式已经过实践检验</strong>之后才姗姗来迟。然而，订阅收费这一经由运营商或内容聚合门户分销的应用所广泛采取的模式，却只能在应用商店里得到极为有限的运用。</div>
<div>-  <strong>移动开发者视网络运营商为比特管道</strong>。近80%的开发者认为网络运营商的角色应该是随时随地提供数据访问能力。仅有53%的认为他们的角色是提供语音通话服务。</div>
<div><img class="alignnone" title="app store" src="http://tctechcrunch.files.wordpress.com/2010/07/app-stores.png" alt="app store" width="630" height="413" /></div>
<div><img src="file:///C:/Users/ehjlnox/AppData/Local/Temp/WizKnowledge/fb4237ba-9222-46ba-b124-28ee0e4f4d4c_files/app_stores[1].png" alt="" /></div>
<div>&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;</div>
<div><img class="alignnone" title="mobile app rev" src="http://tctechcrunch.files.wordpress.com/2010/07/mobile-app-rev.png" alt="mobile app rev" width="630" height="390" /></div>
<div><img src="file:///C:/Users/ehjlnox/AppData/Local/Temp/WizKnowledge/fb4237ba-9222-46ba-b124-28ee0e4f4d4c_files/mobile_app_rev[1].png" alt="" /></div>
<p><br class="spacer_" /></p>
<div><strong>技术方面</strong></div>
<p><br class="spacer_" /></p>
<div>-  不同的移动平台的学习曲线差异十分巨大。平均而言，学习Symbian平台需要15个月或更久的时间，而学习Android则<strong>仅需少于6个月的时间</strong>。而且，Symbian编程比iOS  (iPhone), Android或Java  ME更加困难和消耗时间。对开发九个不同类型的典型应用进行对比测试显示，<strong>一个Symbian开发者需要书写4倍于Android开发者的代码量，或者2倍于iPhone开发者的代码量</strong>。</div>
<div>-  从技术角度看来，手机模拟器和调试器最令人痛苦的莫过于<strong>蜗牛的速度和糟糕的与目标设备的一致性</strong>。开发环境（IDE）最令人痛苦的莫过于缺乏应用移植框架，以及糟糕的模拟器整合。</div>
<div>- 在调试方面，我们的测试显示，和iPhone, Symbian, Java  ME比起来，<strong>Android的调试流程是最快的</strong>。在Symbian上调试要花费3倍于在Android上调试的时间。</div>
<div>-  创建迷人的用户界面对大多数移动开发者而言仍然是镜中月、水中花。50%的Symbian、BlackBerry和Windows手机开发者尚在为如何创建出好的用户界面而困扰。</div>
<div>- 报告支持大部分的开发者——<strong>超出80%</strong><span style="font-family: 宋体;"><strong>——在开发中依赖于在线社区或者非官方论坛来获取技术支持</strong>。只有40%的开发者通过官方网站寻求支持。</span></div>
<div><span style="font-family: 宋体;"><br />
 </span></div>
<div><span style="font-family: 宋体;">-  平台商致力于控制的一点就是对未发布或未公开的设备API的使用，但是<strong>这却同时是开发者愿意为之付费的地方</strong>——事实上，这个意愿更甚于获取任何其它技术支持的意愿。因此，平台商可以通过实施分层SDK计划而获益，即使得某些私有SDK仅对某些付费的开发者可用。</span></div>
<div><span style="font-family: 宋体;"><br />
 </span></div>
<div><span style="font-family: 宋体;">-  运营商的网络API计划迄今<strong>尚未成功吸引到很多开发者</strong>。仅有5%的开发者认为网络运营商应该担任网络API提供者的角色。不过，<strong>超过半数的开发者愿意付费使用支付API，然后依次是短信API和定位API</strong>。</span></div>
<div><span style="font-family: 宋体;"><br />
 </span></div>
<div><span style="font-family: 宋体;">-  平均而言，86%的开发者使用开源软件进行开发工作。<strong>Android和iPhone开发者有着4倍于Symbian开发者的意愿去领导一个开源社区</strong>，彰显了其开发者社区从发起到发展方面的极大反差[译注：revealing  the contrasting pedigree of the developer  communities，我的理解是说，前者更多的是由这些有领导意愿的活跃开发者发起的，而后者则更多是官方性质的]。60%的开发者认为，开源的唯一关键缺点就是<strong>林林总总的开源许可证造成的混淆和困惑</strong>。</span></div>
<div><span style="font-family: 宋体;"><br />
 </span></div>
<div><span style="font-family: 宋体;">完整版本的报告可以在 <a href="http://developereconomics.com/">DeveloperEconomics.com</a> 免费获得。</span></div>
<div><span style="font-family: 宋体;"><br />
 </span></div>
<div><span style="font-family: 宋体;"><img class="alignnone" title="mobile app learning" src="http://tctechcrunch.files.wordpress.com/2010/07/mobile-apps-learning.png" alt="mobile app learning" width="630" height="355" /></span></div>
<div><span style="font-family: 宋体;"><img src="file:///C:/Users/ehjlnox/AppData/Local/Temp/WizKnowledge/fb4237ba-9222-46ba-b124-28ee0e4f4d4c_files/mobile_apps_learning[1].png" alt="" /></span></div>
<div id="WizHtmlContentId">&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;</div>
<div><img class="alignnone" title="mobile app open source" src="http://tctechcrunch.files.wordpress.com/2010/07/mobile-apps-open-source.png" alt="mobile app open source" width="630" height="398" /></div>
<div><span style="font-family: 宋体;"><img src="file:///C:/Users/ehjlnox/AppData/Local/Temp/WizKnowledge/fb4237ba-9222-46ba-b124-28ee0e4f4d4c_files/mobile_apps_open_source[1].png" alt="" /></span></div>
<div><span style="font-family: 宋体;">（全文完）</span></div>
<p><!--WizHtmlContentEnd--></p>
</div>
]]></content:encoded>
			<wfw:commentRss>http://oplatform.org/archives/171/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Big O小组活动第二周</title>
		<link>http://oplatform.org/archives/156</link>
		<comments>http://oplatform.org/archives/156#comments</comments>
		<pubDate>Sun, 11 Apr 2010 03:53:37 +0000</pubDate>
		<dc:creator>easy</dc:creator>
				<category><![CDATA[Big O]]></category>

		<guid isPermaLink="false">http://oplatform.org/?p=156</guid>
		<description><![CDATA[Big O活动简介: 技术和产品人员聚集在一起,完成一个小型的互联网应用(开发时间在6小时内).整个过程24小时,第一周讨论产品方向,第二周做产品原型,第三周开发产品,第四周总结和展示.
第二周活动概要
@龚民 同学到场,为大家解答了关于微博开放平台的申请,支付接口和分成比例等问题. 我们小组要申请的接口已经搞定, 老谭(@谭晨辉)将在周日补齐产品原型.下周开始之前讨论的应用的开发. @焕岭@西米哥@陈镇波 同学组了一个新队,下周开始做产品设计. 何直群(腾龙),张翼鹏同学进行了围观并参与了讨论.

微博开放平台的状况
通过龚民同学的介绍和现场同学的提问,我们获知了微博平台的第一手信息.
申请地址
新浪微博开放平台已经开放了对外的申请,地址是open.t.sina.com.cn;认证密码: wiki / 14001400.

现在开发者可以直接申请,申请之后可以直接使用,但是推送到微博的数据不显示来源;申请通过审核后,显示来源.

应用开发注意事项
因为目前的互联网环境,微博平台不允许应用将新浪微博的内容进行二次传播.应用可以将相关内容展示到自己网站上,但是不能再发布到第三方.
不能满足此条件的应用会被关停.
应用API里边的搜索接口即使已经成为新浪微博开放平台的合作伙伴后还需要申请一次,申请标准主要考察上述注意事项.
新浪微博将添加应用页面
添加完成后,微博将拥有应用入口和应用管理页面,具体如下

个人设置页面添加应用列表和应用授权
个人微博页面右侧添加&#8221;我的应用&#8221;模块,可收起和隐藏.
微博广场添加应用广场页面,进行应用推荐

以上功能预计五月完成.

支付和分成
微博支付接口正在开发中,稍后将提供给大家.分成比例将力争2/8(开发者8);最少不会低于3/7.
运行平台支持
通过微博平台和SAE(新浪云计算平台)的合作关系,目前申请微博应用的同学可以拿到SAE的邀请码,享受SAE的免费配额.

超出SAE免费配额的应用在达到一定的活跃人数时,可向微博和SAE申请更多资源.另外SAE将在5~6月推出资源购买功能.
应用开发讨论
以下是部分讨论内容

微博上活跃的一批应用主要是 机器人和 用户关系类应用. 如微博指数,查天气 等.
基于好友和关系的一些小测试和文字pk游戏应该也有市场.
大量推送feed的应用会被用户和用户的好友unfollow,需要注意
和sns相比微博有特有的东西: 机器人式的交互;单向关注的信息流;名人和机构资源
关于社交游戏是否能在微博流行,还很难讲,大家可以尝试

Big O 小组进度汇报
微博关键字监控的项目已经申请了搜索接口权限,应该本周能通过. 老谭同学继续做产品原型(完成后会公布出来).
@焕岭@西米哥@陈镇波 同学组了一个新队,下周开始做产品设计.

Big O 流程存在的问题
从最近两周的活动,发现原来流程存在的一些问题.

要安排一个4~5周的连续时间并不容易.时间安排需要考量.
大家很难在一个较短的时间内讨论出一个有意思的产品,有部分设计和规划考虑放到线上和活动以外.
不同的人感兴趣的项目不同,每次聚会应该召集对相同项目感兴趣的人,这需要我们有一个线上的项目展示,其他人由此考虑是否参加.
大家对6个小时开发时间能作出来的东西没有概念,需要更多的典型应用来给大家整体印象.

我们将针对以上问题进行调整,如果你有好的想法和建议欢迎在评论中留言或者发邮件给 easychen@gmail.com .
PS: 之前选定的咖啡馆的顶楼非常不错,但是没想到木有wifi,我们只好又回到了3楼.比较挤&#8230;
下周地点未定,有建议的同学欢迎推荐.


]]></description>
			<content:encoded><![CDATA[<p><span style="color: #ff6600;">Big O活动简介: 技术和产品人员聚集在一起,完成一个小型的互联网应用(开发时间在6小时内).整个过程24小时,第一周讨论产品方向,第二周做产品原型,第三周开发产品,第四周总结和展示.</span></p>
<h2>第二周活动概要</h2>
<p><a href="http://t.sina.com.cn/n/%E9%BE%9A%E6%B0%91">@龚民</a> 同学到场,为大家解答了关于微博开放平台的申请,支付接口和分成比例等问题. 我们小组要申请的接口已经搞定, 老谭(<a href="http://t.sina.com.cn/n/%E8%B0%AD%E6%99%A8%E8%BE%89">@谭晨辉</a>)将在周日补齐产品原型.下周开始之前讨论的应用的开发. <a href="http://t.sina.com.cn/n/%E7%84%95%E5%B2%AD">@焕岭</a><a href="http://t.sina.com.cn/n/%E8%A5%BF%E7%B1%B3%E5%93%A5">@西米哥</a><a href="http://t.sina.com.cn/n/%E9%99%88%E9%95%87%E6%B3%A2">@陈镇波</a> 同学组了一个新队,下周开始做产品设计. 何直群(腾龙),张翼鹏同学进行了围观并参与了讨论.</p>
<p><a href="http://oplatform.org/wp-content/uploads/2010/04/DSC01341.jpg"><img class="alignnone size-medium wp-image-157" title="DSC01341" src="http://oplatform.org/wp-content/uploads/2010/04/DSC01341-300x225.jpg" alt="" width="300" height="225" /></a></p>
<h2>微博开放平台的状况</h2>
<p>通过龚民同学的介绍和现场同学的提问,我们获知了微博平台的第一手信息.</p>
<p><strong>申请地址</strong></p>
<p>新浪微博开放平台已经开放了对外的申请,地址是<a href="http://open.t.sina.com.cn" target="_blank">open.t.sina.com.cn</a>;认证密码: wiki / 14001400.</p>
<p><a href="http://oplatform.org/wp-content/uploads/2010/04/DSC01340.jpg"><img class="alignnone size-medium wp-image-159" title="DSC01340" src="http://oplatform.org/wp-content/uploads/2010/04/DSC01340-300x225.jpg" alt="" width="300" height="225" /></a></p>
<p>现在开发者可以直接申请,申请之后可以直接使用,但是推送到微博的数据不显示来源;申请通过审核后,显示来源.</p>
<p><a href="http://oplatform.org/wp-content/uploads/2010/04/opent.png"><img class="alignnone size-medium wp-image-165" title="opent" src="http://oplatform.org/wp-content/uploads/2010/04/opent-300x212.png" alt="" width="300" height="212" /></a></p>
<p><strong>应用开发注意事项</strong></p>
<p>因为目前的互联网环境,微博平台不允许应用将新浪微博的内容进行二次传播.应用可以将相关内容展示到自己网站上,但是不能再发布到第三方.</p>
<p>不能满足此条件的应用会被关停.</p>
<p>应用API里边的搜索接口即使已经成为新浪微博开放平台的合作伙伴后还需要申请一次,申请标准主要考察上述注意事项.</p>
<p><strong>新浪微博将添加应用页面</strong></p>
<p>添加完成后,微博将拥有应用入口和应用管理页面,具体如下</p>
<ul>
<li>个人设置页面添加应用列表和应用授权</li>
<li>个人微博页面右侧添加&#8221;我的应用&#8221;模块,可收起和隐藏.</li>
<li>微博广场添加应用广场页面,进行应用推荐</li>
</ul>
<p>以上功能预计五月完成.</p>
<p><a href="http://oplatform.org/wp-content/uploads/2010/04/DSC01344.jpg"><img title="DSC01344" src="http://oplatform.org/wp-content/uploads/2010/04/DSC01344-300x225.jpg" alt="" width="300" height="225" /></a></p>
<p><strong>支付和分成</strong></p>
<p>微博支付接口正在开发中,稍后将提供给大家.分成比例将力争2/8(开发者8);最少不会低于3/7.</p>
<p><strong>运行平台支持</strong></p>
<p>通过微博平台和<a href="http://sae.sina.com.cn/" target="_blank">SAE(新浪云计算平台)</a>的合作关系,目前申请微博应用的同学可以拿到SAE的邀请码,享受SAE的免费配额.</p>
<p><a href="http://oplatform.org/wp-content/uploads/2010/04/sae.png"><img title="sae" src="http://oplatform.org/wp-content/uploads/2010/04/sae-300x176.png" alt="" width="300" height="176" /></a></p>
<p>超出SAE免费配额的应用在达到一定的活跃人数时,可向微博和SAE申请更多资源.另外SAE将在5~6月推出资源购买功能.</p>
<p><strong>应用开发讨论</strong></p>
<p><em><span style="color: #888888;">以下是部分讨论内容</span></em></p>
<ul>
<li>微博上活跃的一批应用主要是 机器人和 用户关系类应用. 如<a href="http://tttt.sinaapp.com/" target="_blank">微博指数</a>,<a href="http://t.sina.com.cn/weathers" target="_blank">查天气</a> 等.</li>
<li>基于好友和关系的一些小测试和文字pk游戏应该也有市场.</li>
<li>大量推送feed的应用会被用户和用户的好友unfollow,需要注意</li>
<li>和sns相比微博有特有的东西: 机器人式的交互;单向关注的信息流;名人和机构资源</li>
<li>关于社交游戏是否能在微博流行,还很难讲,大家可以尝试</li>
</ul>
<h2>Big O 小组进度汇报</h2>
<p>微博关键字监控的项目已经申请了搜索接口权限,应该本周能通过. 老谭同学继续做产品原型(完成后会公布出来).</p>
<p><a href="http://t.sina.com.cn/n/%E7%84%95%E5%B2%AD">@焕岭</a><a href="http://t.sina.com.cn/n/%E8%A5%BF%E7%B1%B3%E5%93%A5">@西米哥</a><a href="http://t.sina.com.cn/n/%E9%99%88%E9%95%87%E6%B3%A2">@陈镇波</a> 同学组了一个新队,下周开始做产品设计.</p>
<p><a href="http://oplatform.org/wp-content/uploads/2010/04/DSC01342.jpg"><img class="alignnone size-medium wp-image-160" title="DSC01342" src="http://oplatform.org/wp-content/uploads/2010/04/DSC01342-300x225.jpg" alt="" width="300" height="225" /></a></p>
<h2>Big O 流程存在的问题</h2>
<p>从最近两周的活动,发现原来流程存在的一些问题.</p>
<ul>
<li>要安排一个4~5周的连续时间并不容易.时间安排需要考量.</li>
<li>大家很难在一个较短的时间内讨论出一个有意思的产品,有部分设计和规划考虑放到线上和活动以外.</li>
<li>不同的人感兴趣的项目不同,每次聚会应该召集对相同项目感兴趣的人,这需要我们有一个线上的项目展示,其他人由此考虑是否参加.</li>
<li>大家对6个小时开发时间能作出来的东西没有概念,需要更多的典型应用来给大家整体印象.</li>
</ul>
<p>我们将针对以上问题进行调整,如果你有好的想法和建议欢迎在评论中留言或者发邮件给 easychen@gmail.com .</p>
<p>PS: 之前选定的咖啡馆的顶楼非常不错,但是没想到木有wifi,我们只好又回到了3楼.比较挤&#8230;</p>
<p>下周地点未定,有建议的同学欢迎推荐.</p>
<p><a href="http://oplatform.org/wp-content/uploads/2010/04/DSC01337.jpg"><img class="alignnone size-medium wp-image-161" title="DSC01337" src="http://oplatform.org/wp-content/uploads/2010/04/DSC01337-300x225.jpg" alt="" width="300" height="225" /></a></p>
<p><a href="http://oplatform.org/wp-content/uploads/2010/04/DSC01338.jpg"><img class="alignnone size-medium wp-image-162" title="DSC01338" src="http://oplatform.org/wp-content/uploads/2010/04/DSC01338-300x225.jpg" alt="" width="300" height="225" /></a></p>
]]></content:encoded>
			<wfw:commentRss>http://oplatform.org/archives/156/feed</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>可能性探讨：无需域名的互联网</title>
		<link>http://oplatform.org/archives/148</link>
		<comments>http://oplatform.org/archives/148#comments</comments>
		<pubDate>Wed, 07 Apr 2010 14:25:56 +0000</pubDate>
		<dc:creator>tanchenhui</dc:creator>
				<category><![CDATA[未分类]]></category>

		<guid isPermaLink="false">http://oplatform.org/archives/148</guid>
		<description><![CDATA[by黑传说
开始时间：2010-03-23 原帖发表于“西西河”
ps：胡乱涂鸦的，目前还没理好思路，现在先占坑，以后有空慢慢修正（下面没有任何一段文字可以称为完善的，都需要进行或多或少的修正）。完工之时，此行文字去掉，欢迎有想法的和我合作一起完成，如果能像：why git is the best那样的排版效果，应该会更棒。因为本篇相信会和git与svn的对比类似
思路发起者：黑传说(jobinson99@gmail.com 恩，俺技术不行，所以只能提思路，而不能直接提可实现方案)
核心贡献者：
参与者（按参与时间排列，请按格式自己添加。格式：姓名/号＋联系方式）：
鸣谢：所有研究p2p的人，所有使用p2p网络的人
标题说明：这是一个非严格的标题，之所以非严格，是因为目前尚在设想中，而设想的起点就是：干吗需要域名？反对的是目前的域名体系，而不是域名本身。域名可能可以保留，也可能需要废除，完全根据的是实际目的需要，而这个目的就是：更可靠的、分布式互联网——或者说，是另一个互联网乌托邦体系。
也因此，很多名词需要重构，需要发明一些新词汇来准确表述。比如域名，可能就需要重新定义。
&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8211;
缘起
最近在搞分布式计算的东西的时候，仔细看了bt的kad网络原理，然后今天又在星岛上看到一则新闻：
链接出处
下面是我综述
说goddady等国外域名注册商利用去年寒冬国内大力整肃互联网的时机，向国内站长们狂摇橄榄枝，于是国内有人认为此举违法，需要国内对这些国际域名商 进行制裁………………
看到这个，我吐血了，现在互联网创业的门槛已经够高了，这么穷追猛打，恐怕最终结果，会发展出另外的互联网模式来的，刚好昨晚深夜钻研bt的kad网络原理，就这么把这两件事给挂勾了，一个大胆的设想浮在我的脑海里：干吗需要域名？
目前的域名管理体系：
IP：在互联网上辨别一台电脑的方式是利用IP，但ip因为非语义化，不好记，需要引入符合人类语言的标识方式来指示（就是域名）。
根服务器：主要用来管理互联网的主目录，全世界只有13台。1个为主根服务器，放置在美国。其余12个均为辅根服务器，其中9个放置在美国，欧洲2个（位于英国和瑞典），亚洲1个（位于日本）。所有根服务器均由美国政府授权的互联网名称与数字地址分配机构ICANN统一管理，负责互联网协议(IP)地址的空间分配、协议标识符的指派、通用顶级域名(gTLD)以及国家和地区顶级域名(ccTLD)系统的管理、以及根服务器系统的管理。
目前中国有3个根域名“镜像”服务器。
任何域名解析都要经过这13台根服务器获得顶级索引，但并不是说访问 .com 会经过这些服务器，访问 .cn 就不经过这些服务器。
而每一个顶级域，不管是gTLD(通用顶级域)，还是ccTLD(国别顶级域)，它们都有自己的域名服务器(即该顶级域的NS记录)，比如： 
　　 .com &#038; .net 的域名服务器是：[a-m].gtld-servers.net 共13个
　　 .org 的域名服务器是：tld1.ultradns.net 等6个
　　 .biz 的域名服务器是：[a-h].gtld.biz 共8个
　　 .info 的域名服务器是：tld1.ultradns.net 等6个
　　 .cn 的域名服务器是：ns.cnc.ac.cn 等6个
　　 .jp 的域名服务器是：[a-f].dns.jp 共6个等等。
　　.COM .NET服务器全球也有13个，其中，美国有8个、英国、瑞典、荷兰、日本和香港各有1个。由美国Verisign公司管理。 
此处留着贴图（全球互联网节点分布图／体系架构图）：
用户流程：
浏览器输入地址——》》到最近的域名解析服务器辨识该域名所对应的服务器IP——》》如果找到对应ip，则传送回ip给浏览器，由浏览器使用该ip，到达所需要浏览的网站。
域名解析服务器此时就是一个译码本的作用
性能考虑：访问都由一个256b的数据包完成（一个数据包13块）
特定网站流程：
注册唯一名字（域名）——》把域名绑定在特定ip上——》》在dns上写入域名和ip对应信息
（唵啊吽）问题的核心可能是ip地址资源？？？：域名只是ip的一个马甲，而ip地址分配采用的是集中式管理模式。
劫持ip和劫持域名服务器都可以达到同样效果。既然已经语义化了域名，为何不同时语义化了ip呢？把ip和域名同时统一？为了下面方便讨论，可先假定ip体系不变，而只是域名体系变更。
——————》》简单说域名是ip马甲好像不太准确，因为实际应用中，ip地址并非唯一对应域名，有时是一个ip对应多个域名，有时是一个域名对应众多ip。
ip和域名的区别实际应用中，可能更像是服务器物理地址和应用虚拟地址的区别。
因此，对于应用虚拟地址来说，并没有必要对服务器物理地址体系作颠覆。 应用是用户直接需要的，在新的域名体系下，可以clone到其他服务器里面，但仍然是同一个应用。
现有域名管理体系可能存在的问题
A、太过集中于某个大国阵营：坏处嘛，那就是美国的态度太重要了，不想玩了，就关了根服务器。看哪国不爽了，直接停止该国域名解析（伊战期间，伊拉克国别域名.iq就被停了）。美国太过强势，导致各国都试图建立自己独立的域名系统，把互联网割裂为局域网，不利于世界沟通。
B、太过依赖于十几个节点：假设个极端情况，所有的根域名服务器同时残废了，怎么办？才十几个哦，要同时残废难度还是比较小的。
可能存在的需求
A、大国要求控制互联网，都想控制的结果最终就是联合国安理会模式。（确实就有国家提议由联合国电信联盟（ITU）来管理，但被美国拒绝）
B、大国不想互联网喉咙控制于敌国之手，但网民也不想被国家过度控遏。
C、小国需要互联网的发言权
D、新创业的公司要求打破现有的域名体系，降低成本（好域名都被占光了，却没好好用，创业公司要搞个好域名，需要的成本太高）
E、大公司也备受域名占用困扰：域名的多样性，容易被人钻空子，比如谷姐，北度，八度（不过，他们财大气粗，根本没需要我给他们代言）
F、现有域名体系无法有效保护网民：某个域名是否可信任，无法判断，有必要引入信任机制。
G、现有域名体系，只要有域名，就可以制造无穷多的内容重复性网站，无法有效保护原创网站。所以有必要引入更专注于互联网内容，而不是基于内容关联性弱的域名体系。
H、众多基于互联网的新应用，要求互联网具备更高的可靠性：恩，没错，现有域名体系，导致这些和桌面紧密结合的应用不堪一击，留下了无穷隐患。
目标：
更可靠的互联网
何为更可靠：更不易受攻击，更不易被切断，更不易被欺骗
一个容易理解的标准：无论互联网那个关键节点断了，都不会妨碍其他人在互联网中的穿梭，只会妨碍到该被断节点的访问。
此处也涉及到速度问题，需要和可靠进行平衡。
思路
现在的域名相当于原来bt中的tracker，是为了方便网络访问的快捷方式，但这种方式和原来互联网的设计初衷就不是一致的。
互联网的设计初衷是提供一种生存能力特强的信息传输模式，要生存能力强，那么就要尽量避免只有一个中心，尽量分布式，鸡蛋放在多个篮子里。
而目前最好的实践，莫过于p2p网络下载，原来的bt下载中，bt-tracker还可以利用不同国家的政策，来躲避管理，类似于现在的域名商，利用不同国家的政策来规避不同国家的不同监管。但这种方式终究是有弊端的，谁也没法确保那一天该国不会像对待bt那样进行封杀，尤其是战争时期，这种封杀，不仅对普通的互联网企业，而且将对世界各国的国家安全构成巨大的潜在威胁。
这也是为什么中国一定要在国内也搞一套域名解析服务器的原因。
而如果参考bt的kad模式（为方便讨论，可以暂时把kad的那套全部引入，设想下效果），则根本可以不需要域名：只需要在相邻的节点互相保存对方的信息，那么整个互联网就可以构建起来
现有的域名机制将被推倒重来：
把每个网站都看成一个类似bt中的资源
相关联的因素
包括互联网的控制权，互联网的安全，互联网的易访问性，性能等
一些设想：
A、不再需要注册，不再需要根域名服务器（好像标题应该改为“不需根域名服务器的互联网”，因为实际上还是有域名的，只不过已经不是现在的域名形式了，叫 “站名”更合适）
B、名字可以重名（各种语言文字都可以作为名字，中文／英文／阿拉伯／俄……）：命名并非是像现在的简单命名，而是有附加另外的信息的，比如：sina＋ 新闻，sina＋游戏，可以是两个所有人。更甚的是：sina＋随机码
C、网站指向无关ip：现在很多大网站都不止一个ip的，而小网站很多是共享ip，于是，ip成了一个不痛不痒的鸡肋，除了表明硬件地理位置，几乎没啥别 作用。那么，以后就让ip直接去对应硬件地理位置吧，域名跟ip脱钩，自己可以本身就跨越了几个地理位置（kad中，为了保证节点在线率时时刻刻不是0， 复制了20份资源信息给该id周围的其他节点。此处也参考类似做法，所有网站的信息都自动备份若干份到其他机器上，不过这样可能行不通，毕竟机器是有所有 权人的。）
D、访问网站将类似于bt中的查找资源
E、域名／站名：站点可能是每个网站对应一个唯一的站点信息包————类似于bt 中的种子文件，但可以有短模式，不需要全部输入所有信息，只需要部分信息即可快速 访问——网友“老虎爱吃肉“说的没错，类似于现在google的那个i&#8217;am feeling lucky（其实这种域名访问模式有点类似当年的网络实名、中文实名之类的，只是机制不是集中控制式，而是分布式）。短模式就接近现在的域名形式了。
F、现有域名可以被兼容，但地址不再是硬写的地址，而是作为一个个可选标签，比如有cn标签的，则代表这是中国／中文的网站。
BT种子和新设计域名体系的一些对应关系
目的是为了方便理解，并体验下效果，实际不应该如此繁琐，用户使用上应该和现有方式一样：输入地址，访问之。
…………to be continued
网站唯一性／反伪造
A、引入社会化信任机制：借用搜索引擎的引用权重模式？（根据收藏夹统计结果？）
B、站点信任投票：缺乏投票的新站得不到广泛的引用（可以杜绝临时性的伪造站：长 期经营才有可能有信任度）？？？
性能／资源消耗
现在的域名体系，对域名解析的安排方法，和我这设想里的差别不大。
都不会完全复制，只会复制一小部分：
A、根据语言：这样就排除了绝大部分的了
B、加入类似于skype的supernode机制？
谁负责：浏览器
这种方式的好处很多：
A、网络生存能力/可靠性急剧提高
B、容易实施：不需要世界各国支持，只需要用户客户端改进，即可完成互联网的底层变革。同时，也兼容现有的域名体系（但现有域名体系只是一个可有可无的附庸）。
C、不再受制于任何一国政府：美国无法控制，中国也无法控制
D、允许域名重名（因为名字规则不再单单是名字，还有相应属性：可以在meta中规定），这样现在紧缺的这些域名，都将成为过去式。
E、人人都可以对应一个网站/站名/域名：很多人都非常讨厌自己的blog前面或者后面附上其他网站的地址，比如blog.sina.com.cn/xxxxx ，在新的域名体制下，将完全可以把xxxxx前面的部分去掉，而不影响使用（也无需注册，无需备案）。现有昂贵／廉价的域名，将飞入平常百姓家。
F、域名内容将紧密关联：现有域名和内容关联度不高，域名的指示作用有限，在实施了分布式域名体系之后，域名和内容将直接关联，将更加促进内容的发展。
对于浏览器的影响
A、浏览器输入地址的时候，需要更多的自动提示（类似firefox的智能地址栏， 甚至是opera的图形化标签栏的可见缩略图模式）
B、搜索地址即是搜索相关的资源（参照kad的双字典模式）
C、浏览器将类似于bt客户端，需要提供最初的几个起始点信息（现有浏览器里面默认附带的安全证书，已经在起到类似作用，但仍需扩充）
对于网站的影响
A、不再需要为想要的域名付出高昂费用，域名将不再需要注册。
B、需要更加注重社会评价，评价越低，将越被忽略
C、服务器本身也变成整个分布式域名体系的一部分，保存一份域名列表（类似现在的友情链接，但在此域名体系里面，将需要单独放置在根目录下）————当然，还有另外的方式，比如按机房来，而不是按网站来，这样可以有效降低小网站的负荷，将资源用于急需发展的部分。
假设一个实例？
………………to be continued
原文地址：http://docs.google.com/Doc?docid=0AeoCTmjcpOM5YWpqNjNrYzVqemNxXzgyZGdyNG56Zng&#038;hl=en
我说：异想天开也是一种力量，虽然你可以很明显的指出这个构想里的很多问题。
]]></description>
			<content:encoded><![CDATA[<p>by黑传说<br />
开始时间：2010-03-23 原帖发表于“西西河”</p>
<p>ps：胡乱涂鸦的，目前还没理好思路，现在先占坑，以后有空慢慢修正（下面没有任何一段文字可以称为完善的，都需要进行或多或少的修正）。完工之时，此行文字去掉，欢迎有想法的和我合作一起完成，如果能像：why git is the best那样的排版效果，应该会更棒。因为本篇相信会和git与svn的对比类似<br />
思路发起者：黑传说(jobinson99@gmail.com 恩，俺技术不行，所以只能提思路，而不能直接提可实现方案)<br />
核心贡献者：<br />
参与者（按参与时间排列，请按格式自己添加。格式：姓名/号＋联系方式）：<br />
鸣谢：所有研究p2p的人，所有使用p2p网络的人</p>
<p>标题说明：这是一个非严格的标题，之所以非严格，是因为目前尚在设想中，而设想的起点就是：干吗需要域名？反对的是目前的域名体系，而不是域名本身。域名可能可以保留，也可能需要废除，完全根据的是实际目的需要，而这个目的就是：更可靠的、分布式互联网——或者说，是另一个互联网乌托邦体系。<br />
也因此，很多名词需要重构，需要发明一些新词汇来准确表述。比如域名，可能就需要重新定义。</p>
<p>&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8211;</p>
<p>缘起<br />
最近在搞分布式计算的东西的时候，仔细看了bt的kad网络原理，然后今天又在星岛上看到一则新闻：<br />
链接出处<br />
下面是我综述<br />
说goddady等国外域名注册商利用去年寒冬国内大力整肃互联网的时机，向国内站长们狂摇橄榄枝，于是国内有人认为此举违法，需要国内对这些国际域名商 进行制裁………………</p>
<p>看到这个，我吐血了，现在互联网创业的门槛已经够高了，这么穷追猛打，恐怕最终结果，会发展出另外的互联网模式来的，刚好昨晚深夜钻研bt的kad网络原理，就这么把这两件事给挂勾了，一个大胆的设想浮在我的脑海里：干吗需要域名？</p>
<p>目前的域名管理体系：<br />
IP：在互联网上辨别一台电脑的方式是利用IP，但ip因为非语义化，不好记，需要引入符合人类语言的标识方式来指示（就是域名）。</p>
<p>根服务器：主要用来管理互联网的主目录，全世界只有13台。1个为主根服务器，放置在美国。其余12个均为辅根服务器，其中9个放置在美国，欧洲2个（位于英国和瑞典），亚洲1个（位于日本）。所有根服务器均由美国政府授权的互联网名称与数字地址分配机构ICANN统一管理，负责互联网协议(IP)地址的空间分配、协议标识符的指派、通用顶级域名(gTLD)以及国家和地区顶级域名(ccTLD)系统的管理、以及根服务器系统的管理。<br />
目前中国有3个根域名“镜像”服务器。</p>
<p>任何域名解析都要经过这13台根服务器获得顶级索引，但并不是说访问 .com 会经过这些服务器，访问 .cn 就不经过这些服务器。<br />
而每一个顶级域，不管是gTLD(通用顶级域)，还是ccTLD(国别顶级域)，它们都有自己的域名服务器(即该顶级域的NS记录)，比如： </p>
<p>　　 .com &#038; .net 的域名服务器是：[a-m].gtld-servers.net 共13个<br />
　　 .org 的域名服务器是：tld1.ultradns.net 等6个<br />
　　 .biz 的域名服务器是：[a-h].gtld.biz 共8个<br />
　　 .info 的域名服务器是：tld1.ultradns.net 等6个<br />
　　 .cn 的域名服务器是：ns.cnc.ac.cn 等6个<br />
　　 .jp 的域名服务器是：[a-f].dns.jp 共6个等等。<br />
　　.COM .NET服务器全球也有13个，其中，美国有8个、英国、瑞典、荷兰、日本和香港各有1个。由美国Verisign公司管理。 </p>
<p>此处留着贴图（全球互联网节点分布图／体系架构图）：</p>
<p>用户流程：<br />
浏览器输入地址——》》到最近的域名解析服务器辨识该域名所对应的服务器IP——》》如果找到对应ip，则传送回ip给浏览器，由浏览器使用该ip，到达所需要浏览的网站。<br />
域名解析服务器此时就是一个译码本的作用<br />
性能考虑：访问都由一个256b的数据包完成（一个数据包13块）</p>
<p>特定网站流程：<br />
注册唯一名字（域名）——》把域名绑定在特定ip上——》》在dns上写入域名和ip对应信息</p>
<p>（唵啊吽）问题的核心可能是ip地址资源？？？：域名只是ip的一个马甲，而ip地址分配采用的是集中式管理模式。<br />
劫持ip和劫持域名服务器都可以达到同样效果。既然已经语义化了域名，为何不同时语义化了ip呢？把ip和域名同时统一？为了下面方便讨论，可先假定ip体系不变，而只是域名体系变更。</p>
<p>——————》》简单说域名是ip马甲好像不太准确，因为实际应用中，ip地址并非唯一对应域名，有时是一个ip对应多个域名，有时是一个域名对应众多ip。<br />
ip和域名的区别实际应用中，可能更像是服务器物理地址和应用虚拟地址的区别。<br />
因此，对于应用虚拟地址来说，并没有必要对服务器物理地址体系作颠覆。 应用是用户直接需要的，在新的域名体系下，可以clone到其他服务器里面，但仍然是同一个应用。</p>
<p>现有域名管理体系可能存在的问题<br />
A、太过集中于某个大国阵营：坏处嘛，那就是美国的态度太重要了，不想玩了，就关了根服务器。看哪国不爽了，直接停止该国域名解析（伊战期间，伊拉克国别域名.iq就被停了）。美国太过强势，导致各国都试图建立自己独立的域名系统，把互联网割裂为局域网，不利于世界沟通。</p>
<p>B、太过依赖于十几个节点：假设个极端情况，所有的根域名服务器同时残废了，怎么办？才十几个哦，要同时残废难度还是比较小的。</p>
<p>可能存在的需求<br />
A、大国要求控制互联网，都想控制的结果最终就是联合国安理会模式。（确实就有国家提议由联合国电信联盟（ITU）来管理，但被美国拒绝）<br />
B、大国不想互联网喉咙控制于敌国之手，但网民也不想被国家过度控遏。<br />
C、小国需要互联网的发言权<br />
D、新创业的公司要求打破现有的域名体系，降低成本（好域名都被占光了，却没好好用，创业公司要搞个好域名，需要的成本太高）<br />
E、大公司也备受域名占用困扰：域名的多样性，容易被人钻空子，比如谷姐，北度，八度（不过，他们财大气粗，根本没需要我给他们代言）<br />
F、现有域名体系无法有效保护网民：某个域名是否可信任，无法判断，有必要引入信任机制。<br />
G、现有域名体系，只要有域名，就可以制造无穷多的内容重复性网站，无法有效保护原创网站。所以有必要引入更专注于互联网内容，而不是基于内容关联性弱的域名体系。<br />
H、众多基于互联网的新应用，要求互联网具备更高的可靠性：恩，没错，现有域名体系，导致这些和桌面紧密结合的应用不堪一击，留下了无穷隐患。</p>
<p>目标：<br />
更可靠的互联网<br />
何为更可靠：更不易受攻击，更不易被切断，更不易被欺骗<br />
一个容易理解的标准：无论互联网那个关键节点断了，都不会妨碍其他人在互联网中的穿梭，只会妨碍到该被断节点的访问。<br />
此处也涉及到速度问题，需要和可靠进行平衡。</p>
<p>思路<br />
现在的域名相当于原来bt中的tracker，是为了方便网络访问的快捷方式，但这种方式和原来互联网的设计初衷就不是一致的。<br />
互联网的设计初衷是提供一种生存能力特强的信息传输模式，要生存能力强，那么就要尽量避免只有一个中心，尽量分布式，鸡蛋放在多个篮子里。</p>
<p>而目前最好的实践，莫过于p2p网络下载，原来的bt下载中，bt-tracker还可以利用不同国家的政策，来躲避管理，类似于现在的域名商，利用不同国家的政策来规避不同国家的不同监管。但这种方式终究是有弊端的，谁也没法确保那一天该国不会像对待bt那样进行封杀，尤其是战争时期，这种封杀，不仅对普通的互联网企业，而且将对世界各国的国家安全构成巨大的潜在威胁。<br />
这也是为什么中国一定要在国内也搞一套域名解析服务器的原因。</p>
<p>而如果参考bt的kad模式（为方便讨论，可以暂时把kad的那套全部引入，设想下效果），则根本可以不需要域名：只需要在相邻的节点互相保存对方的信息，那么整个互联网就可以构建起来</p>
<p>现有的域名机制将被推倒重来：<br />
把每个网站都看成一个类似bt中的资源</p>
<p>相关联的因素<br />
包括互联网的控制权，互联网的安全，互联网的易访问性，性能等</p>
<p>一些设想：<br />
A、不再需要注册，不再需要根域名服务器（好像标题应该改为“不需根域名服务器的互联网”，因为实际上还是有域名的，只不过已经不是现在的域名形式了，叫 “站名”更合适）<br />
B、名字可以重名（各种语言文字都可以作为名字，中文／英文／阿拉伯／俄……）：命名并非是像现在的简单命名，而是有附加另外的信息的，比如：sina＋ 新闻，sina＋游戏，可以是两个所有人。更甚的是：sina＋随机码<br />
C、网站指向无关ip：现在很多大网站都不止一个ip的，而小网站很多是共享ip，于是，ip成了一个不痛不痒的鸡肋，除了表明硬件地理位置，几乎没啥别 作用。那么，以后就让ip直接去对应硬件地理位置吧，域名跟ip脱钩，自己可以本身就跨越了几个地理位置（kad中，为了保证节点在线率时时刻刻不是0， 复制了20份资源信息给该id周围的其他节点。此处也参考类似做法，所有网站的信息都自动备份若干份到其他机器上，不过这样可能行不通，毕竟机器是有所有 权人的。）<br />
D、访问网站将类似于bt中的查找资源<br />
E、域名／站名：站点可能是每个网站对应一个唯一的站点信息包————类似于bt 中的种子文件，但可以有短模式，不需要全部输入所有信息，只需要部分信息即可快速 访问——网友“老虎爱吃肉“说的没错，类似于现在google的那个i&#8217;am feeling lucky（其实这种域名访问模式有点类似当年的网络实名、中文实名之类的，只是机制不是集中控制式，而是分布式）。短模式就接近现在的域名形式了。<br />
F、现有域名可以被兼容，但地址不再是硬写的地址，而是作为一个个可选标签，比如有cn标签的，则代表这是中国／中文的网站。</p>
<p>BT种子和新设计域名体系的一些对应关系<br />
目的是为了方便理解，并体验下效果，实际不应该如此繁琐，用户使用上应该和现有方式一样：输入地址，访问之。<br />
…………to be continued</p>
<p>网站唯一性／反伪造<br />
A、引入社会化信任机制：借用搜索引擎的引用权重模式？（根据收藏夹统计结果？）<br />
B、站点信任投票：缺乏投票的新站得不到广泛的引用（可以杜绝临时性的伪造站：长 期经营才有可能有信任度）？？？</p>
<p>性能／资源消耗<br />
现在的域名体系，对域名解析的安排方法，和我这设想里的差别不大。<br />
都不会完全复制，只会复制一小部分：<br />
A、根据语言：这样就排除了绝大部分的了<br />
B、加入类似于skype的supernode机制？</p>
<p>谁负责：浏览器</p>
<p>这种方式的好处很多：<br />
A、网络生存能力/可靠性急剧提高<br />
B、容易实施：不需要世界各国支持，只需要用户客户端改进，即可完成互联网的底层变革。同时，也兼容现有的域名体系（但现有域名体系只是一个可有可无的附庸）。</p>
<p>C、不再受制于任何一国政府：美国无法控制，中国也无法控制<br />
D、允许域名重名（因为名字规则不再单单是名字，还有相应属性：可以在meta中规定），这样现在紧缺的这些域名，都将成为过去式。<br />
E、人人都可以对应一个网站/站名/域名：很多人都非常讨厌自己的blog前面或者后面附上其他网站的地址，比如blog.sina.com.cn/xxxxx ，在新的域名体制下，将完全可以把xxxxx前面的部分去掉，而不影响使用（也无需注册，无需备案）。现有昂贵／廉价的域名，将飞入平常百姓家。<br />
F、域名内容将紧密关联：现有域名和内容关联度不高，域名的指示作用有限，在实施了分布式域名体系之后，域名和内容将直接关联，将更加促进内容的发展。</p>
<p>对于浏览器的影响<br />
A、浏览器输入地址的时候，需要更多的自动提示（类似firefox的智能地址栏， 甚至是opera的图形化标签栏的可见缩略图模式）<br />
B、搜索地址即是搜索相关的资源（参照kad的双字典模式）<br />
C、浏览器将类似于bt客户端，需要提供最初的几个起始点信息（现有浏览器里面默认附带的安全证书，已经在起到类似作用，但仍需扩充）</p>
<p>对于网站的影响<br />
A、不再需要为想要的域名付出高昂费用，域名将不再需要注册。<br />
B、需要更加注重社会评价，评价越低，将越被忽略<br />
C、服务器本身也变成整个分布式域名体系的一部分，保存一份域名列表（类似现在的友情链接，但在此域名体系里面，将需要单独放置在根目录下）————当然，还有另外的方式，比如按机房来，而不是按网站来，这样可以有效降低小网站的负荷，将资源用于急需发展的部分。</p>
<p>假设一个实例？<br />
………………to be continued<br />
原文地址：http://docs.google.com/Doc?docid=0AeoCTmjcpOM5YWpqNjNrYzVqemNxXzgyZGdyNG56Zng&#038;hl=en</p>
<p>我说：异想天开也是一种力量，虽然你可以很明显的指出这个构想里的很多问题。</p>
]]></content:encoded>
			<wfw:commentRss>http://oplatform.org/archives/148/feed</wfw:commentRss>
		<slash:comments>8</slash:comments>
		</item>
		<item>
		<title>Big O活动小组,Open weekend 第一周</title>
		<link>http://oplatform.org/archives/143</link>
		<comments>http://oplatform.org/archives/143#comments</comments>
		<pubDate>Wed, 07 Apr 2010 11:51:13 +0000</pubDate>
		<dc:creator>easy</dc:creator>
				<category><![CDATA[未分类]]></category>

		<guid isPermaLink="false">http://oplatform.org/?p=143</guid>
		<description><![CDATA[Big O活动简介: 技术和产品人员聚集在一起,完成一个小型的互联网应用(开发时间在6小时内).整个过程24小时,第一周讨论产品方向,第二周做产品原型,第三周开发产品,第四周总结和展示.
上周Oplatform的同学在避风塘进行了亲切的会晤和友好的磋商,组成了史上第一个Big O活动小组.
由于我们彼此都很熟悉,于是跳过了第零周和第一周的内容,直接进入了第二周.

开发平台和开发环境
为了能在6个小时内完成产品,我们选择的是Mash Up类的小应用,基于新浪微博开放平台和SAE开发环境.(由于我们在这部分拥有较多的资源和支持,前期我们都会覆盖在这边;如果有其他平台愿意提供技术辅导人员和运行环境,我们也强烈欢迎.)
产品方向讨论
新浪微博作为新兴的应用平台,我们很看好其在媒体和营销方面的作用.由老谭同学提议,在传播效果测量等方面做一些实验式的应用.Easy同学和青焱同学则进行了补充.我们想到的有价值的方向有如下几个:

传播效果测量,观察某些关键字在特定时间内的变化情况
查询机器人,如通过微博查询航班,这是一个很好的票务入口
聚合团购网站,通过微博来做团购,病毒传播效果更好

在充分讨论了各个应用的价值和优先级后,我们决定先开始做传播效果测量.
于是用思维导图完成了以下的基本思考:

每人分配了相应的任务后,本周活动就结束了.下周我们将讨论和制作产品的原型.
Big O计划正在进行中,如果你有兴趣参加或者参与组织,或者有任何建议,欢迎联系我们 easychen@gmail.com
]]></description>
			<content:encoded><![CDATA[<p><span style="color: #ff6600;">Big O活动简介: 技术和产品人员聚集在一起,完成一个小型的互联网应用(开发时间在6小时内).整个过程24小时,第一周讨论产品方向,第二周做产品原型,第三周开发产品,第四周总结和展示.</span></p>
<p>上周Oplatform的同学在避风塘进行了亲切的会晤和友好的磋商,组成了史上第一个<a href="http://oplatform.org/archives/137" target="_blank">Big O活动</a>小组.</p>
<p>由于我们彼此都很熟悉,于是跳过了第零周和第一周的内容,直接进入了第二周.</p>
<p><a href="http://oplatform.org/wp-content/uploads/2010/04/40dfde6f4835479c0648b690.jpeg"><img title="40dfde6f4835479c0648b&amp;690" src="http://oplatform.org/wp-content/uploads/2010/04/40dfde6f4835479c0648b690-300x225.jpg" alt="" width="300" height="225" /></a></p>
<p><strong>开发平台和开发环境</strong></p>
<p>为了能在6个小时内完成产品,我们选择的是Mash Up类的小应用,基于新浪微博开放平台和SAE开发环境.(由于我们在这部分拥有较多的资源和支持,前期我们都会覆盖在这边;如果有其他平台愿意提供技术辅导人员和运行环境,我们也强烈欢迎.)</p>
<p><strong>产品方向讨论</strong></p>
<p>新浪微博作为新兴的应用平台,我们很看好其在媒体和营销方面的作用.由老谭同学提议,在传播效果测量等方面做一些实验式的应用.Easy同学和青焱同学则进行了补充.我们想到的有价值的方向有如下几个:</p>
<ul>
<li>传播效果测量,观察某些关键字在特定时间内的变化情况</li>
<li>查询机器人,如通过微博查询航班,这是一个很好的票务入口</li>
<li>聚合团购网站,通过微博来做团购,病毒传播效果更好</li>
</ul>
<p>在充分讨论了各个应用的价值和优先级后,我们决定先开始做传播效果测量.</p>
<p>于是用思维导图完成了以下的基本思考:</p>
<p><a href="http://oplatform.org/wp-content/uploads/2010/04/weiboguanjianci.png"><img class="alignnone size-medium wp-image-144" title="weiboguanjianci" src="http://oplatform.org/wp-content/uploads/2010/04/weiboguanjianci-300x94.png" alt="" width="300" height="94" /></a></p>
<p>每人分配了相应的任务后,本周活动就结束了.下周我们将讨论和制作产品的原型.</p>
<p><a href="http://oplatform.org/archives/137">Big O计划正在进行中</a>,如果你有兴趣参加或者参与组织,或者有任何建议,欢迎联系我们 easychen@gmail.com</p>
]]></content:encoded>
			<wfw:commentRss>http://oplatform.org/archives/143/feed</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
		<item>
		<title>Big O 活动草案</title>
		<link>http://oplatform.org/archives/137</link>
		<comments>http://oplatform.org/archives/137#comments</comments>
		<pubDate>Wed, 07 Apr 2010 11:20:57 +0000</pubDate>
		<dc:creator>easy</dc:creator>
				<category><![CDATA[Big O]]></category>

		<guid isPermaLink="false">http://oplatform.org/?p=137</guid>
		<description><![CDATA[Big O活动简介: 技术和产品人员聚集在一起,完成一个小型的互联网应用(开发时间在6小时内).整个过程24小时,第一周讨论产品方向,第二周做产品原型,第三周开发产品,第四周总结和展示.
上周经过我们的讨论,确定了Big O计划的基本草案.目前暂定以下流程.
在正式开始之前,Oplatform会自己建立一个小组,将流程走一遍.同时我们会邀请自己的朋友组成第二个小组,和我们一起开始.如果你有兴趣参加或者参与活动组织,欢迎发邮件给我们: easychen@gmail.com.
项目简介
大O计划,类似于国外的Open Weekend.利用周末的空闲时间,召集大家做一些实用的或者前瞻性的应用.
计划的目的是帮助大家了解web应用的开发流程,亲身体会新技术给互联网带来的新体验,为大家模拟一个相对真实的创业环境.
参与计划的流程
1 注册为大O计划参与人
用户注册为参与人,提供联系信息和注明希望参与的角色.
目前预定的角色有

产品设计(设计高保真的产品原型)
应用开发(将产品原型实现)
应用运营和观察员(在应用上线后,邀请好友试用,及时收集用户反馈并整理相关数据;同时负责记录整个过程)

2 项目发起和参与
每个人都可以发起一个项目.有以下必须遵守的规则:

项目全程开源,包括项目策划,讨论时的脑图,原型的源文件,程序的代码.Oplatform将在观察员的帮助下对此进行全程直播(通过博客和微博等).
项目发起人负责说服其他人员加入项目,并控制项目的进度.每个项目的预计开发时间必须在8个小时之内.最长用1个周末的时间完成.
项目产出将在BSD协议下发布,在保留作者信息的情况下,允许网友自由使用.如果项目开发团队觉得项目具有商业价值,可以自行在其上进行商业化,不用向Oplatform申请许可.

3 Oplatform提供的支持

组织和协调会员
和外部平台进行沟通,为参与大O计划的项目申请环境和技术支持.(第一期活动的平台和环境是微博开放平台和SAE)
产品设计,产品原型,平台技术,应用接口等相关技术的讲解和技术帮助

进行流程
第零周 &#8211; 人员预备
在网上预先召集一定数量的人员.按用户情况进行分组,每个小组4~5人.各类型角色不得小于一个.
第一周 &#8211; 应用开发讨论
介绍要开发开放平台和对应的接口,介绍提供的运行环境,介绍我们项目要遵守的规则.参与人员充分认识,并了解各自的技能.第一次聚会结束.留作业:每个人准备自己关于应用的想法.以备下次使用.
第二周 &#8211; 应用项目确定
每人提出自己的想法,在小组内充分讨论,整个小组决定公共项目.各小组决定完项目后,每个小组派一名代表轮流讲述小组项目.各小组项目互相评论.
(课后作业:产品类同学负责整理该类应用的定位,功能,同类产品信息;技术类同学整理相关技术,和可能使用到的技术资源)
第三周 &#8211; 应用项目原型(6小时)
前1~2小时是原型工具课程,由各小组的产品人员向其他成员讲解.产品人员不熟悉的地方,由Oplatform安排的同学进行解答.各小组分别完成自己的产品的原型设计,小组间互评.最终结果:产品定型,技术解决方案确定.
(课后作业:产品人员负责设计简单的界面,技术人员做相关的技术资源收集)
第四周 &#8211; 应用开发(6小时)
产品人员负责文案,流程,开发人员负责项目逻辑的开发;应用从最基本的功能做起,做完即上线,每一个小时追加一次新功能.产品人员负责邀请用户试用,并记录用户反馈.如果产品当天交流未开发完成,作为课后作业.
第五周 &#8211; 应用上线和运营(6小时)
应用正式上线,各小组介绍各自的应用,并分享一周以来的用户反馈和数据,总结经验教训.最新的文档和代码更新到Google code.本次循环结束.
最后再广告一遍   如果你有兴趣参加或者参与活动组织,欢迎发邮件给我们: easychen@gmail.com.
]]></description>
			<content:encoded><![CDATA[<p><span style="color: #ff0000;">Big O活动简介: 技术和产品人员聚集在一起,完成一个小型的互联网应用(开发时间在6小时内).整个过程24小时,第一周讨论产品方向,第二周做产品原型,第三周开发产品,第四周总结和展示.</span></p>
<p>上周经过我们的讨论,确定了Big O计划的基本草案.目前暂定以下流程.</p>
<p>在正式开始之前,Oplatform会自己建立一个小组,将流程走一遍.同时我们会邀请自己的朋友组成第二个小组,和我们一起开始.如果你有兴趣参加或者参与活动组织,欢迎发邮件给我们: easychen@gmail.com.</p>
<p><strong>项目简介</strong></p>
<p>大O计划,类似于国外的Open Weekend.利用周末的空闲时间,召集大家做一些实用的或者前瞻性的应用.<br />
计划的目的是帮助大家了解web应用的开发流程,亲身体会新技术给互联网带来的新体验,为大家模拟一个相对真实的创业环境.</p>
<p><strong>参与计划的流程</strong></p>
<p>1 注册为大O计划参与人</p>
<p>用户注册为参与人,提供联系信息和注明希望参与的角色.</p>
<p>目前预定的角色有</p>
<ul>
<li>产品设计(设计高保真的产品原型)</li>
<li>应用开发(将产品原型实现)</li>
<li>应用运营和观察员(在应用上线后,邀请好友试用,及时收集用户反馈并整理相关数据;同时负责记录整个过程)</li>
</ul>
<p>2 项目发起和参与</p>
<p>每个人都可以发起一个项目.有以下必须遵守的规则:</p>
<ul>
<li>项目全程开源,包括项目策划,讨论时的脑图,原型的源文件,程序的代码.Oplatform将在观察员的帮助下对此进行全程直播(通过博客和微博等).</li>
<li>项目发起人负责说服其他人员加入项目,并控制项目的进度.每个项目的预计开发时间必须在8个小时之内.最长用1个周末的时间完成.</li>
<li>项目产出将在BSD协议下发布,在保留作者信息的情况下,允许网友自由使用.如果项目开发团队觉得项目具有商业价值,可以自行在其上进行商业化,不用向Oplatform申请许可.</li>
</ul>
<p>3 Oplatform提供的支持</p>
<ul>
<li>组织和协调会员</li>
<li>和外部平台进行沟通,为参与大O计划的项目申请环境和技术支持.(第一期活动的平台和环境是微博开放平台和SAE)</li>
<li>产品设计,产品原型,平台技术,应用接口等相关技术的讲解和技术帮助</li>
</ul>
<p><strong>进行流程</strong></p>
<p>第零周 &#8211; 人员预备</p>
<p>在网上预先召集一定数量的人员.按用户情况进行分组,每个小组4~5人.各类型角色不得小于一个.</p>
<p>第一周 &#8211; 应用开发讨论</p>
<p>介绍要开发开放平台和对应的接口,介绍提供的运行环境,介绍我们项目要遵守的规则.参与人员充分认识,并了解各自的技能.第一次聚会结束.留作业:每个人准备自己关于应用的想法.以备下次使用.</p>
<p>第二周 &#8211; 应用项目确定</p>
<p>每人提出自己的想法,在小组内充分讨论,整个小组决定公共项目.各小组决定完项目后,每个小组派一名代表轮流讲述小组项目.各小组项目互相评论.</p>
<p>(课后作业:产品类同学负责整理该类应用的定位,功能,同类产品信息;技术类同学整理相关技术,和可能使用到的技术资源)</p>
<p>第三周 &#8211; 应用项目原型(6小时)</p>
<p>前1~2小时是原型工具课程,由各小组的产品人员向其他成员讲解.产品人员不熟悉的地方,由Oplatform安排的同学进行解答.各小组分别完成自己的产品的原型设计,小组间互评.最终结果:产品定型,技术解决方案确定.</p>
<p>(课后作业:产品人员负责设计简单的界面,技术人员做相关的技术资源收集)</p>
<p>第四周 &#8211; 应用开发(6小时)</p>
<p>产品人员负责文案,流程,开发人员负责项目逻辑的开发;应用从最基本的功能做起,做完即上线,每一个小时追加一次新功能.产品人员负责邀请用户试用,并记录用户反馈.如果产品当天交流未开发完成,作为课后作业.</p>
<p>第五周 &#8211; 应用上线和运营(6小时)</p>
<p>应用正式上线,各小组介绍各自的应用,并分享一周以来的用户反馈和数据,总结经验教训.最新的文档和代码更新到Google code.本次循环结束.</p>
<p>最后再广告一遍 <img src='http://oplatform.org/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' />  如果你有兴趣参加或者参与活动组织,欢迎发邮件给我们: easychen@gmail.com.</p>
]]></content:encoded>
			<wfw:commentRss>http://oplatform.org/archives/137/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>“大O计划”启动中</title>
		<link>http://oplatform.org/archives/131</link>
		<comments>http://oplatform.org/archives/131#comments</comments>
		<pubDate>Thu, 25 Mar 2010 18:50:17 +0000</pubDate>
		<dc:creator>刘青焱</dc:creator>
				<category><![CDATA[Big O]]></category>

		<guid isPermaLink="false">http://oplatform.org/?p=131</guid>
		<description><![CDATA[大O（The big O）是用于描述函数渐进行为的数学符号，在计算机程序中用于描述算法复杂度。
开放平台实验室将联合若干家开放平台、云计算服务提供商共同启动“大O计划”，旨在帮助中小创业者、开源爱好者洞察开放平台生态环境，整合资源，快 速实践创新，并促成优秀作品的社区化或商业化。
与Y  combinator或者Innovationworks不同的是，我们是集市模式，仅发动、组织、指导、整合，不以开放平台实验室名义投资、参股、控 制。也就是说，大O计划是公益性的。我们旨在促进中国互联网创业环境的改善、创新水平的提升以及商业孵化的成功。
详细计划还在制订之中。如果你有好的点子，或者你想参与进来贡献力量，请联系 刘青焱 qingyan123 (at)  gmail(dot)com.
大O计划在开放平台实验室上的固定页面位置是： http://oplatform.org/tbo
]]></description>
			<content:encoded><![CDATA[<p>大O（The big O）是用于描述函数渐进行为的数学符号，在计算机程序中用于描述算法复杂度。</p>
<p>开放平台实验室将联合若干家开放平台、云计算服务提供商共同启动“大O计划”，旨在帮助中小创业者、开源爱好者洞察开放平台生态环境，整合资源，快 速实践创新，并促成优秀作品的社区化或商业化。</p>
<p>与Y  combinator或者Innovationworks不同的是，我们是集市模式，仅发动、组织、指导、整合，不以开放平台实验室名义投资、参股、控 制。也就是说，大O计划是公益性的。我们旨在促进中国互联网创业环境的改善、创新水平的提升以及商业孵化的成功。</p>
<p>详细计划还在制订之中。如果你有好的点子，或者你想参与进来贡献力量，请联系 刘青焱 qingyan123 (at)  gmail(dot)com.</p>
<p>大O计划在开放平台实验室上的固定页面位置是： <a title="http://oplatform.org/tbo" href="http://oplatform.org/tbo" target="_blank">http://oplatform.org/tbo</a></p>
]]></content:encoded>
			<wfw:commentRss>http://oplatform.org/archives/131/feed</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>故事（三）上篇</title>
		<link>http://oplatform.org/archives/122</link>
		<comments>http://oplatform.org/archives/122#comments</comments>
		<pubDate>Sun, 21 Mar 2010 04:04:06 +0000</pubDate>
		<dc:creator>刘青焱</dc:creator>
				<category><![CDATA[未分类]]></category>

		<guid isPermaLink="false">http://oplatform.org/?p=122</guid>
		<description><![CDATA[本文原发于开放平台实验室（http://oplatform.org/），转载请注明出处。
其三 广告的本质
合乎规律不一定成功，但违背规律必然失败。朝向错误的方向，速度越快，错的越远。接下来要讲的，是一个奋力拼搏的团队失败的故事。
互联网的本质之一是新媒体，所以广告自然是互联网一大重要营收来源。广告是后向收费的重要手段之一，早在报纸时代就已经被广泛运用了。
谈起互联网广告，便忆起陆奇来。这个原来执掌雅虎巴拿马广告平台、现在统率微软Bing搜索团队的奇才，是我最崇敬的人之一。犹记当年听陆奇介绍巴拿马计划，他开场短短5分钟，便使我感到醍醐灌顶，更加通彻地了解了互联网广告的规律和趋势。深入浅出，恰如此景。由此5分钟，便对这个身穿T-shirt牛仔裤的SVP崇拜不已。
难怪鲍尔默说，得到陆奇，就等于得到了整个雅虎搜索团队。
闲话暂且不表。单说这互联网（媒体）广告，基本上经历了如下几个阶段：
作为对比，我们把传统的媒体广告列为前互联网时代：大广告商在大媒体上投放广告。平面媒体收费方式：按版面大小和位置收费；视听媒体：按时长和时段收费。
第一阶段：banner时代。大广告商在大网站上投放banner广告。收费方式：CPM（千人次展现费用，或者千次印象费用；按展现次数收费）；CPC（按点击次数付费）。
印象这个词用的还是蛮好的。一次印象就是1个display，不是人而是人次。而印象这个汉语词又有impression的含义，让广告主听起来觉得这个display还给观众留下impression了，很爽。
第二阶段：PPC (Pay per Click)时代。这个overture的专利和Google的搜索引擎结合起来产生了巨大的威力，按点击付费的体系支撑了搜索业务成为一个可行的且非常大的商业模式。这也说明了，一个伟大的商业模式的革新必定包含了技术革新和收入模式革新的最佳结合。PPC搜索广告的出现，使得中小广告商得以在大网站上投放PPC广告。收费方式：PPC。
有人不禁疑问，这个PPC和CPC不是一样的吗？错。有人说，这个PPC就是竞价排名吧，怎么英文字面没有竞价的意思？错。
第三阶段：adsense时代。在线广告的开放平台时代。通过adsense模式，中小网站得以将中小广告商的广告展现在自己的网站上，Google作为大中间商，成为内容和现金的输送管道和中介，从中源源不断地抽取着利润。
显而易见的，这个版图上还缺了一块儿，那就是大广告商在中小网站上展现广告。但是这肯定不是第四阶段，个人观点，欢迎讨论。因为adsense模式其实是大小广告商通吃，也就是第三阶段其实已经覆盖了最后的两块儿，从而完成了整个互联网媒体广告的拼图。
最后一个问题是，互联网广告已经无新可创了吗？
好，接下来我们就对上面的一些问题逐一进行分析。
在分析之前，我们先要分析一下广告主。广告主基本上有这么几种主儿：一种就是要个曝光率的，比如IBM的品牌广告，他的业务都在线下，线上打打广告只是为了宣传品牌和理念；二种就是想让用户知道自己在哪里的，比如线上有个网站，想让用户来看看，并且记下来我的网址以后好常常光顾；三种就是想让来看看的用户进一步转化为自己的注册会员，甚至在线做一些生意的。
这三个种类代表了三种深度。三种深度应该已经涵盖了在线广告的全部深度可能性了。需要注意的是，这三种不存在取代关系，也就是说，深度三很好，但是深度一同样很好。应该说，每种深度的广告都有需求，都有其适合的广告主。不要对深度有偏见。
对深度一的广告，发展方向是丰富性。所以图片、动画、甚至现在有搞视频，什么展现力丰富就用什么。印象印象，什么样子能够让人印象深刻、过目不忘就做成什么样子。
深度一，基本上和传统媒体报纸电视是一个水平的。
深度一，比较传统媒体的优势在于：第一，目标用户区隔，而且这个区隔市场正在快速发展，而传统媒体的区隔市场正在快速萎靡；第二，互联网的优势在于信息的双向流动，因而可以通过数据分析更加精准的推送广告，比如就只把北京本地品牌的广告推给北京本地的网民，从而降低了成本，提高了效率，这是深度一广告比传统媒体革命性的地方。
对深度二的广告，发展方向是相关性。所以基本上文字链的效果往往好过多媒体。最重要的是广告是不是恰恰打动了我的心。
深度二，是对深度一广告的扬弃。去除了其和传统媒体一个水平的部分，从而彻底斩断了互联网广告和传统媒体广告的联系。而更加进一步的利用了互联网的优势，使得引入高阶的技术性更强的数学成为可能，从而实现从广告到目标客户之间更加精准的递达。
深度二，已经将传统媒体广告远远甩在了身后，并且，在这中间，有一条不可逾越的边界，因为，互联网本是一个完全不同的美丽新世界。
深度二的出现，使得传统媒体彻底绝望，因为他们已经不可能追赶。
以深度二为主要广告形态的互联网，已经扬弃了它的媒体性，所以我更愿意把它叫做（广告）发布商。
根据哈佛大学教授Clayton M. Christensen的创新理论，创新可以分为两类，sustaining（递延性的）和disruptive（分裂性的）。相较传统媒体，深度一还是递延性的广告创新，而深度二则通过主动抛弃相似部分、加强区别部分，从而完成了分裂性创新，使得自己从竞争关系中跳了出来，而对方无法跳出来所以无从追赶。
所以，深度一可以用CPC，但是很少用。阻力在媒体本身。既然你做深度一的广告，那么你就应该是个看重曝光率的主儿，我不用CPM而用CPC岂不是亏了我自己给你展现那么多次？
再看看PPC，同样是看点击率，但这次是你情我愿。发布商（搜索引擎）有信心有能力保证点击率，因为有更加精准的相关性匹配。广告主更乐意让真正感兴趣的人看自己的网站/专题，因为这些人更有可能是潜在客户，会更加仔细的看精心准备的专题内容。
所以，为示区别，我们把深度一的点击广告叫CPC，把深度二的点击广告叫PPC。
PPC是竞价排名吗？不是。overture刚刚发明的时候，PPC广告是通过竞价来售卖的。百度所学到的，就是这一点，所以百度说他是卖竞价排名的。PPC是收费模式，竞价是售卖模式。
而到了google时代，google对这个售卖模式进行了改进。因为google发现，是把出价高的广告放在上面还是把相关性高的广告放在上面，这是一个paradox。To be or not to be, this is a question. 最终，google的选择和百度想反。google把相关性高的广告放在上面，通过更高的CTR*稍低的PPC来赚取合理的利润。
我们来简单假设几个数字，计算一下便一目了然：
对同样的展现次数 10000，
Google：高CTR (1%)，低PPC ($1)。自身收益10000*1%*$1=$1000。广告主得到的进入数10000*1%=1000，ROI=1000/$1000=1 entry/$。用户看到了想看的内容，满意度高。
百度：低CTR (0.1%)，高PPC ($10)。自身收益10000*0.1%*$10=$1000。广告主得到的进入数10000*0.1%=100，ROI=100/$1000=0.1 entry/$。用户看到了不想看到的内容，满意度低。
这个演算告诉我们，在维持自身收益相同的情况下，Google能够让它的两个客户——广告主和用户——都满意。而百度让他们都不满意。
那么为什么国内的广告主还是普遍选择百度呢？
这又是一个很有趣的问题。主要有两个原因：
第一个是互联网圈内人士普遍说的，就是国内的广告主由于普遍不是特别懂数据分析和效果追踪，所以对ROI没有概念。没错，搜索引擎对CTR的优化能力其实直接影响到广告主的ROI，这种优化也是搜索引擎所创造的价值。但是我认为，这个是一个重要原因，但不是最主要的。因为路遥知马力日久见人心，即使拍脑袋想，也能感觉出来自己的ROI是好是坏。商人是很精明的。
所以第二个更重要的原因是，金钱的时间价值。
（下午还有个事情，就先到这里。欲知金钱之时间价值为何，且听青焱下回给您分解。）
（待续）
]]></description>
			<content:encoded><![CDATA[<p>本文原发于开放平台实验室（<a href="../">http://oplatform.org/</a>），转载请注明出处。</p>
<p><strong>其三</strong><strong> </strong><strong>广告的本质</strong></p>
<p>合乎规律不一定成功，但违背规律必然失败。朝向错误的方向，速度越快，错的越远。接下来要讲的，是一个奋力拼搏的团队失败的故事。</p>
<p>互联网的本质之一是新媒体，所以广告自然是互联网一大重要营收来源。广告是后向收费的重要手段之一，早在报纸时代就已经被广泛运用了。</p>
<p>谈起互联网广告，便忆起陆奇来。这个原来执掌雅虎巴拿马广告平台、现在统率微软Bing搜索团队的奇才，是我最崇敬的人之一。犹记当年听陆奇介绍巴拿马计划，他开场短短5分钟，便使我感到醍醐灌顶，更加通彻地了解了互联网广告的规律和趋势。深入浅出，恰如此景。由此5分钟，便对这个身穿T-shirt牛仔裤的SVP崇拜不已。</p>
<p>难怪鲍尔默说，得到陆奇，就等于得到了整个雅虎搜索团队。</p>
<p>闲话暂且不表。单说这互联网（媒体）广告，基本上经历了如下几个阶段：</p>
<p>作为对比，我们把传统的媒体广告列为前互联网时代：大广告商在大媒体上投放广告。平面媒体收费方式：按版面大小和位置收费；视听媒体：按时长和时段收费。</p>
<p>第一阶段：banner时代。大广告商在大网站上投放banner广告。收费方式：CPM（千人次展现费用，或者千次印象费用；按展现次数收费）；CPC（按点击次数付费）。</p>
<p>印象这个词用的还是蛮好的。一次印象就是1个display，不是人而是人次。而印象这个汉语词又有impression的含义，让广告主听起来觉得这个display还给观众留下impression了，很爽。</p>
<p>第二阶段：PPC (Pay per Click)时代。这个overture的专利和Google的搜索引擎结合起来产生了巨大的威力，按点击付费的体系支撑了搜索业务成为一个可行的且非常大的商业模式。这也说明了，一个伟大的商业模式的革新必定包含了技术革新和收入模式革新的最佳结合。PPC搜索广告的出现，使得中小广告商得以在大网站上投放PPC广告。收费方式：PPC。</p>
<p>有人不禁疑问，这个PPC和CPC不是一样的吗？错。有人说，这个PPC就是竞价排名吧，怎么英文字面没有竞价的意思？错。</p>
<p>第三阶段：adsense时代。在线广告的开放平台时代。通过adsense模式，中小网站得以将中小广告商的广告展现在自己的网站上，Google作为大中间商，成为内容和现金的输送管道和中介，从中源源不断地抽取着利润。</p>
<p>显而易见的，这个版图上还缺了一块儿，那就是大广告商在中小网站上展现广告。但是这肯定不是第四阶段，个人观点，欢迎讨论。因为adsense模式其实是大小广告商通吃，也就是第三阶段其实已经覆盖了最后的两块儿，从而完成了整个互联网媒体广告的拼图。</p>
<p>最后一个问题是，互联网广告已经无新可创了吗？</p>
<p>好，接下来我们就对上面的一些问题逐一进行分析。</p>
<p>在分析之前，我们先要分析一下广告主。广告主基本上有这么几种主儿：一种就是要个曝光率的，比如IBM的品牌广告，他的业务都在线下，线上打打广告只是为了宣传品牌和理念；二种就是想让用户知道自己在哪里的，比如线上有个网站，想让用户来看看，并且记下来我的网址以后好常常光顾；三种就是想让来看看的用户进一步转化为自己的注册会员，甚至在线做一些生意的。</p>
<p>这三个种类代表了三种深度。三种深度应该已经涵盖了在线广告的全部深度可能性了。需要注意的是，这三种不存在取代关系，也就是说，深度三很好，但是深度一同样很好。应该说，每种深度的广告都有需求，都有其适合的广告主。不要对深度有偏见。</p>
<p>对深度一的广告，发展方向是丰富性。所以图片、动画、甚至现在有搞视频，什么展现力丰富就用什么。印象印象，什么样子能够让人印象深刻、过目不忘就做成什么样子。</p>
<p>深度一，基本上和传统媒体报纸电视是一个水平的。</p>
<p>深度一，比较传统媒体的优势在于：第一，目标用户区隔，而且这个区隔市场正在快速发展，而传统媒体的区隔市场正在快速萎靡；第二，互联网的优势在于信息的双向流动，因而可以通过数据分析更加精准的推送广告，比如就只把北京本地品牌的广告推给北京本地的网民，从而降低了成本，提高了效率，这是深度一广告比传统媒体革命性的地方。</p>
<p>对深度二的广告，发展方向是相关性。所以基本上文字链的效果往往好过多媒体。最重要的是广告是不是恰恰打动了我的心。</p>
<p>深度二，是对深度一广告的扬弃。去除了其和传统媒体一个水平的部分，从而彻底斩断了互联网广告和传统媒体广告的联系。而更加进一步的利用了互联网的优势，使得引入高阶的技术性更强的数学成为可能，从而实现从广告到目标客户之间更加精准的递达。</p>
<p>深度二，已经将传统媒体广告远远甩在了身后，并且，在这中间，有一条不可逾越的边界，因为，互联网本是一个完全不同的美丽新世界。</p>
<p>深度二的出现，使得传统媒体彻底绝望，因为他们已经不可能追赶。</p>
<p>以深度二为主要广告形态的互联网，已经扬弃了它的媒体性，所以我更愿意把它叫做（广告）发布商。</p>
<p>根据哈佛大学教授Clayton M. Christensen的创新理论，创新可以分为两类，sustaining（递延性的）和disruptive（分裂性的）。相较传统媒体，深度一还是递延性的广告创新，而深度二则通过主动抛弃相似部分、加强区别部分，从而完成了分裂性创新，使得自己从竞争关系中跳了出来，而对方无法跳出来所以无从追赶。</p>
<p>所以，深度一可以用CPC，但是很少用。阻力在媒体本身。既然你做深度一的广告，那么你就应该是个看重曝光率的主儿，我不用CPM而用CPC岂不是亏了我自己给你展现那么多次？</p>
<p>再看看PPC，同样是看点击率，但这次是你情我愿。发布商（搜索引擎）有信心有能力保证点击率，因为有更加精准的相关性匹配。广告主更乐意让真正感兴趣的人看自己的网站/专题，因为这些人更有可能是潜在客户，会更加仔细的看精心准备的专题内容。</p>
<p>所以，为示区别，我们把深度一的点击广告叫CPC，把深度二的点击广告叫PPC。</p>
<p>PPC是竞价排名吗？不是。overture刚刚发明的时候，PPC广告是通过竞价来售卖的。百度所学到的，就是这一点，所以百度说他是卖竞价排名的。PPC是收费模式，竞价是售卖模式。</p>
<p>而到了google时代，google对这个售卖模式进行了改进。因为google发现，是把出价高的广告放在上面还是把相关性高的广告放在上面，这是一个paradox。To be or not to be, this is a question. 最终，google的选择和百度想反。google把相关性高的广告放在上面，通过更高的CTR*稍低的PPC来赚取合理的利润。</p>
<p>我们来简单假设几个数字，计算一下便一目了然：</p>
<p>对同样的展现次数 10000，</p>
<p>Google：高CTR (1%)，低PPC ($1)。自身收益10000*1%*$1=$1000。广告主得到的进入数10000*1%=1000，ROI=1000/$1000=1 entry/$。用户看到了想看的内容，满意度高。</p>
<p>百度：低CTR (0.1%)，高PPC ($10)。自身收益10000*0.1%*$10=$1000。广告主得到的进入数10000*0.1%=100，ROI=100/$1000=0.1 entry/$。用户看到了不想看到的内容，满意度低。</p>
<p>这个演算告诉我们，在维持自身收益相同的情况下，Google能够让它的两个客户——广告主和用户——都满意。而百度让他们都不满意。</p>
<p>那么为什么国内的广告主还是普遍选择百度呢？</p>
<p>这又是一个很有趣的问题。主要有两个原因：</p>
<p>第一个是互联网圈内人士普遍说的，就是国内的广告主由于普遍不是特别懂数据分析和效果追踪，所以对ROI没有概念。没错，搜索引擎对CTR的优化能力其实直接影响到广告主的ROI，这种优化也是搜索引擎所创造的价值。但是我认为，这个是一个重要原因，但不是最主要的。因为路遥知马力日久见人心，即使拍脑袋想，也能感觉出来自己的ROI是好是坏。商人是很精明的。</p>
<p>所以第二个更重要的原因是，金钱的时间价值。</p>
<p>（下午还有个事情，就先到这里。欲知金钱之时间价值为何，且听青焱下回给您分解。）</p>
<p>（待续）</p>
]]></content:encoded>
			<wfw:commentRss>http://oplatform.org/archives/122/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>故事（二）</title>
		<link>http://oplatform.org/archives/115</link>
		<comments>http://oplatform.org/archives/115#comments</comments>
		<pubDate>Sat, 20 Mar 2010 04:01:06 +0000</pubDate>
		<dc:creator>刘青焱</dc:creator>
				<category><![CDATA[未分类]]></category>

		<guid isPermaLink="false">http://oplatform.org/?p=115</guid>
		<description><![CDATA[本文原发于开放平台实验室（http://oplatform.org/），转载请注明出处。
其二 麦金赛之殇
我们的第二个故事讲得是一个天才失败的故事。
天才的智商绝对是相当的高。从教育经历看，如果去华尔街做对冲基金经理，想必业绩会不错。但是不幸的是，这个年头很多天才都一窝蜂地选择麦金赛。不因别的，就因为麦金赛NB，世界500强有无数总裁都是麦金赛出品。
所以结论是，去华尔街的天才，金钱欲强；去麦金赛的天才，权利欲强。当然这是因为天才不幸生在华夏。美国土著权利欲最强的肯定是去从政了。
但是从天才的失败中，我认识到了麦金赛其实是一家害人的公司。它培养出来的，都是商业流氓和权利蛀虫。如果你不希望你的业务毁于一旦，请千万不要请从这个公司出来的人主事。但是，如果你现在的业务一团糟糕，下面的VP们流氓成性，监守自盗，那么你应该从麦金赛请一个更流氓的流氓，让他来替你清理门户。我想，这可能就是为什么世界500强公司的董事会那么喜欢从麦金赛请总裁的原因吧。
大部分麦金赛的人，缺乏锻炼，体质孱弱，打不过外面的流氓。那么这种人出来之后，最适合的工作就是总裁秘书，做做文案工作，因为他们的Office用的非常好。
天才VP上位后，很快显示出其麦金赛风格：
首先，在“充分”调查了公司现有状况后，选中了一款不起眼的小产品。不过天才毕竟是天才。他近观广告业发展之历史，远察人类商业文明之长河，遂将该产品包装为历史长河之下一次文明，是改变全人类乃至全宇宙之壮举！
然后，在管辖团队内进行无数轮的灌输、教育。敢有不服者，立斩。将口号印发每一位工程师，贴在工位前方，日日观看。随时走到某工程师面前，提问背诵。答不上来者，拿其经理是问。
我们当时有幸不在其辖区。但是，我们也和他有过一次正面交锋。
那是一个飒爽的天。长阳道，枯藤昏鸦。在天才用极为正确的历史事实和人类发展基本规律“证明”他的观点之后，我们开始质疑。
但是这质疑很快就结束了。因为我们发现，天才也回答不了。他只是恶狠狠的回答：我需要你们认可我，来帮我一起把这事做出来，而不是坐在那里指手画脚！
刀起刀落，只留下残阳血影。
今日回味起来，悟出了麦金赛式逻辑一点有趣的味道：猩猩进化成类人猿，类人猿进化成山顶洞人，山顶洞人进化为现代人，从吃野生食品逐步过渡到吃自己加工的食品，所以下一步我们要吃别人加工的食品，而猪正是吃别人加工的食品的，所以我们敢于断定，下一步人类将进化成猪。
若你质疑，则会遭到反问：别质疑了，赶快来加入我们的行列，思考如何才能尽快进化为猪吧。
当麦金赛只是一个指手画脚的旁观者的时候，讲什么不靠谱的逻辑都是无所谓的，只要你不被他蒙骗而给了他钱就好了。
但是当你请了一个麦金赛者主事，又给了他过大的权利之后，事情就糟糕到了极点：因为他过于强烈地销售他自己的逻辑的本性，会让他在发现正常人无法接受他的逻辑之后，滥用他的权利，去把他的逻辑强加给每一个受他管辖的正常人。这里正常人的意思是指非天才。他的管辖范围越大，对你的公司的伤害就越大。
结果只有两个：血性的人离开了，或者被离开了。隐忍的人留下了，但是革命的种子也同时播下。有没有真正被洗脑的？也许有。但是我们不知道。
结局应该是早已注定。轰轰烈烈的东西，来得快去得更快。只是这“前无来者后无古人”的壮举一举耗尽了公司的能量。美女洞明世事，言其实为公司终亡之本因。
失败的方法：请一个刚愎自用的天才，给他极大的权利，是搞死公司的不二法门。
而根本原因在于，你是否真正珍惜你的业务和你的兄弟，如果答案是是，那么就认真选人、谨慎用人。
（未完待续）
]]></description>
			<content:encoded><![CDATA[<p>本文原发于开放平台实验室（<a href="../">http://oplatform.org/</a>），转载请注明出处。</p>
<p><strong>其二</strong><strong> </strong><strong>麦金赛之殇</strong></p>
<p>我们的第二个故事讲得是一个天才失败的故事。</p>
<p>天才的智商绝对是相当的高。从教育经历看，如果去华尔街做对冲基金经理，想必业绩会不错。但是不幸的是，这个年头很多天才都一窝蜂地选择麦金赛。不因别的，就因为麦金赛NB，世界500强有无数总裁都是麦金赛出品。</p>
<p>所以结论是，去华尔街的天才，金钱欲强；去麦金赛的天才，权利欲强。当然这是因为天才不幸生在华夏。美国土著权利欲最强的肯定是去从政了。</p>
<p>但是从天才的失败中，我认识到了麦金赛其实是一家害人的公司。它培养出来的，都是商业流氓和权利蛀虫。如果你不希望你的业务毁于一旦，请千万不要请从这个公司出来的人主事。但是，如果你现在的业务一团糟糕，下面的VP们流氓成性，监守自盗，那么你应该从麦金赛请一个更流氓的流氓，让他来替你清理门户。我想，这可能就是为什么世界500强公司的董事会那么喜欢从麦金赛请总裁的原因吧。</p>
<p>大部分麦金赛的人，缺乏锻炼，体质孱弱，打不过外面的流氓。那么这种人出来之后，最适合的工作就是总裁秘书，做做文案工作，因为他们的Office用的非常好。</p>
<p>天才VP上位后，很快显示出其麦金赛风格：</p>
<p>首先，在“充分”调查了公司现有状况后，选中了一款不起眼的小产品。不过天才毕竟是天才。他近观广告业发展之历史，远察人类商业文明之长河，遂将该产品包装为历史长河之下一次文明，是改变全人类乃至全宇宙之壮举！</p>
<p>然后，在管辖团队内进行无数轮的灌输、教育。敢有不服者，立斩。将口号印发每一位工程师，贴在工位前方，日日观看。随时走到某工程师面前，提问背诵。答不上来者，拿其经理是问。</p>
<p>我们当时有幸不在其辖区。但是，我们也和他有过一次正面交锋。</p>
<p>那是一个飒爽的天。长阳道，枯藤昏鸦。在天才用极为正确的历史事实和人类发展基本规律“证明”他的观点之后，我们开始质疑。</p>
<p>但是这质疑很快就结束了。因为我们发现，天才也回答不了。他只是恶狠狠的回答：我需要你们认可我，来帮我一起把这事做出来，而不是坐在那里指手画脚！</p>
<p>刀起刀落，只留下残阳血影。</p>
<p>今日回味起来，悟出了麦金赛式逻辑一点有趣的味道：猩猩进化成类人猿，类人猿进化成山顶洞人，山顶洞人进化为现代人，从吃野生食品逐步过渡到吃自己加工的食品，所以下一步我们要吃别人加工的食品，而猪正是吃别人加工的食品的，所以我们敢于断定，下一步人类将进化成猪。</p>
<p>若你质疑，则会遭到反问：别质疑了，赶快来加入我们的行列，思考如何才能尽快进化为猪吧。</p>
<p>当麦金赛只是一个指手画脚的旁观者的时候，讲什么不靠谱的逻辑都是无所谓的，只要你不被他蒙骗而给了他钱就好了。</p>
<p>但是当你请了一个麦金赛者主事，又给了他过大的权利之后，事情就糟糕到了极点：因为他过于强烈地销售他自己的逻辑的本性，会让他在发现正常人无法接受他的逻辑之后，滥用他的权利，去把他的逻辑强加给每一个受他管辖的正常人。这里正常人的意思是指非天才。他的管辖范围越大，对你的公司的伤害就越大。</p>
<p>结果只有两个：血性的人离开了，或者被离开了。隐忍的人留下了，但是革命的种子也同时播下。有没有真正被洗脑的？也许有。但是我们不知道。</p>
<p>结局应该是早已注定。轰轰烈烈的东西，来得快去得更快。只是这“前无来者后无古人”的壮举一举耗尽了公司的能量。美女洞明世事，言其实为公司终亡之本因。</p>
<p>失败的方法：请一个刚愎自用的天才，给他极大的权利，是搞死公司的不二法门。</p>
<p>而根本原因在于，你是否真正珍惜你的业务和你的兄弟，如果答案是是，那么就认真选人、谨慎用人。</p>
<p>（未完待续）</p>
]]></content:encoded>
			<wfw:commentRss>http://oplatform.org/archives/115/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>故事（一）</title>
		<link>http://oplatform.org/archives/110</link>
		<comments>http://oplatform.org/archives/110#comments</comments>
		<pubDate>Sat, 20 Mar 2010 02:39:46 +0000</pubDate>
		<dc:creator>刘青焱</dc:creator>
				<category><![CDATA[未分类]]></category>

		<guid isPermaLink="false">http://oplatform.org/?p=110</guid>
		<description><![CDATA[本文原发于开放平台实验室（http://oplatform.org/），转载请注明出处。
今日京城黄沙漫天，疑又回七年前沙尘暴之盛景。此种天气，正合适在家中舒服。家人又不在，安静得很。故难得片刻之静，思考起近日团队里讨论某创新项目的商业模式的情形来。思绪迅速蔓延，如花盆里的吊兰，抑制不住的想把前数年所亲历种种之失败案例总结出来，供自己抽丝剥茧，找寻商业成功之道；亦不私藏，分享出来，供大家讨论、借鉴。只因都是熟人熟事，故尽可能贾雨村言甄士隐，只将要点抽出进行叙述，如任何人仍有不适，请立即指正于我，定当修正。
引子
成功的原因看似繁杂，但是方法和模式是相似的，失败的方法有很多种，但是原因是有限的。
总结，只是为了透过失败的方法找到失败的原因，从而避免同样去一次次重蹈同样原因的失败。
其一 某领域垂直搜索的二次失败
犹记得数年前，某次年中会议，CTO为众人解惑，曰：我们不做某领域垂直搜索，因为我们的兄弟公司目前占据这个类别80%以上的市场份额，没有必要在这个领域做一个垂直搜索。
至年末，CTO高调宣布，我们要做一个某领域垂直搜索。
至全体管理层会议，我向CTO提问：为何您前后观点有所变化？答曰：因为之前我们认为条件还不具备，现在我们认为条件具备了。
结果：投入数十人半年研发，上线不久，兄弟公司到集团总部施压，于是该垂直搜索成了残废：只允许索引该兄弟公司的数据，而不允许搜索到兄弟公司之竞争对手的信息！再数月后，兄弟公司仍不放心，于是干脆将此项目全盘接收，纳入旗下，而后将其雪藏。
至一年后，新CTO又启动同样的垂直搜索产品。又同样投入数十人半年研发，这次直接自宫，从一开始就只有兄弟公司的数据。beta刚刚露脸，就又被集团指示，由兄弟公司接收，又被雪藏。
失败的方法：明知不可为而为之，却又不清楚自己其实没有改变命运的能力。要么做正确的事，要么有能力把不正确的事变成正确的事，否则就不要做，浪费大家的感情。
深层的原因呢？恐怕是值得我们每一个技术出身、已经是CTO或将来可能是CTO的人深思了。
个人的观点是，技术领导者更重要的是要知道技术和商业的边界。技术可行性不等于商业可行性。有人可能说，这是公司政治。不过抱歉，公司政治也是商业现实存在的一部分。
若不然，你就只能带着你的兄弟疲于奔命：
今天，老板发话：看你们真没出息，赶快给我搞出个石破惊天的创新业务来！
明天，你带着兄弟们累死累活做了一个前景很好的东西。
后天，老板发话：项目立即取消！！！
如果你不能从老板的三个感叹号里悟出点什么，那么下次，你必将重蹈覆辙。
（未完待续）
]]></description>
			<content:encoded><![CDATA[<p>本文原发于开放平台实验室（<a href="../">http://oplatform.org/</a>），转载请注明出处。</p>
<p>今日京城黄沙漫天，疑又回七年前沙尘暴之盛景。此种天气，正合适在家中舒服。家人又不在，安静得很。故难得片刻之静，思考起近日团队里讨论某创新项目的商业模式的情形来。思绪迅速蔓延，如花盆里的吊兰，抑制不住的想把前数年所亲历种种之失败案例总结出来，供自己抽丝剥茧，找寻商业成功之道；亦不私藏，分享出来，供大家讨论、借鉴。只因都是熟人熟事，故尽可能贾雨村言甄士隐，只将要点抽出进行叙述，如任何人仍有不适，请立即指正于我，定当修正。</p>
<p><strong>引子</strong></p>
<p>成功的原因看似繁杂，但是方法和模式是相似的，失败的方法有很多种，但是原因是有限的。</p>
<p>总结，只是为了透过失败的方法找到失败的原因，从而避免同样去一次次重蹈同样原因的失败。</p>
<p><strong>其一</strong><strong> </strong><strong>某领域垂直搜索的二次失败</strong></p>
<p>犹记得数年前，某次年中会议，CTO为众人解惑，曰：我们不做某领域垂直搜索，因为我们的兄弟公司目前占据这个类别80%以上的市场份额，没有必要在这个领域做一个垂直搜索。</p>
<p>至年末，CTO高调宣布，我们要做一个某领域垂直搜索。</p>
<p>至全体管理层会议，我向CTO提问：为何您前后观点有所变化？答曰：因为之前我们认为条件还不具备，现在我们认为条件具备了。</p>
<p>结果：投入数十人半年研发，上线不久，兄弟公司到集团总部施压，于是该垂直搜索成了残废：只允许索引该兄弟公司的数据，而不允许搜索到兄弟公司之竞争对手的信息！再数月后，兄弟公司仍不放心，于是干脆将此项目全盘接收，纳入旗下，而后将其雪藏。</p>
<p>至一年后，新CTO又启动同样的垂直搜索产品。又同样投入数十人半年研发，这次直接自宫，从一开始就只有兄弟公司的数据。beta刚刚露脸，就又被集团指示，由兄弟公司接收，又被雪藏。</p>
<p>失败的方法：明知不可为而为之，却又不清楚自己其实没有改变命运的能力。要么做正确的事，要么有能力把不正确的事变成正确的事，否则就不要做，浪费大家的感情。</p>
<p>深层的原因呢？恐怕是值得我们每一个技术出身、已经是CTO或将来可能是CTO的人深思了。</p>
<p>个人的观点是，技术领导者更重要的是要知道技术和商业的边界。技术可行性不等于商业可行性。有人可能说，这是公司政治。不过抱歉，公司政治也是商业现实存在的一部分。</p>
<p>若不然，你就只能带着你的兄弟疲于奔命：</p>
<p>今天，老板发话：看你们真没出息，赶快给我搞出个石破惊天的创新业务来！</p>
<p>明天，你带着兄弟们累死累活做了一个前景很好的东西。</p>
<p>后天，老板发话：项目立即取消！！！</p>
<p>如果你不能从老板的三个感叹号里悟出点什么，那么下次，你必将重蹈覆辙。</p>
<p>（未完待续）</p>
]]></content:encoded>
			<wfw:commentRss>http://oplatform.org/archives/110/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>连载预告：《移动互联网时代的云计算和创新2.0》</title>
		<link>http://oplatform.org/archives/107</link>
		<comments>http://oplatform.org/archives/107#comments</comments>
		<pubDate>Mon, 15 Mar 2010 17:04:10 +0000</pubDate>
		<dc:creator>刘青焱</dc:creator>
				<category><![CDATA[未分类]]></category>

		<guid isPermaLink="false">http://oplatform.org/?p=107</guid>
		<description><![CDATA[从去年开始就有想法对互联网、开放平台和创新相关的东西做一些整理和总结，只是一直囿于繁琐事务，难以抽身，竟一拖再拖。后来和很多朋友、客户交流讨论，更是深深感觉行业博大精深、风起云涌，可能凭我才疏学浅、精力有限，确实无法一举完成。因此，准备以连载的形式，一小步一小步的去做，随时接受反馈、修改、补充，也许可以慢慢有个积累。
犹记得在鲜果联播上和公军以及lazylorna美女讨论Twitter观察的一篇文章时所说的一句话：很多人都能看到历史的背影，却鲜有人能够看清历史的脚步，就更惶论看到历史的方向了。基本上，我自认为属于很多人的范畴，所以大部分观点都是个人的一些思考，并欢迎任何批评和建议。
计划连载的提纲如下，在连载过程中随时会进行调整。
第一大部分会讲讲移动互联网的兴起是互联网下一个10年的一件大事。电信和互联网的融合会是个怎么样子。又终将鹿死谁手呢？
第二大部分准备谈谈云计算。重点谈谈云计算的一种模型，开放平台即服务（OPaaS）。
第三大部分则引申出创新2.0的开放平台观和生态系统观。并对现存的一些成功的开放平台生态系统进行剖析。然后斗胆预测一下未来的形势。
当然，每一个部分会分成多篇来写。
欢迎大家随时拍砖。
]]></description>
			<content:encoded><![CDATA[<p>从去年开始就有想法对互联网、开放平台和创新相关的东西做一些整理和总结，只是一直囿于繁琐事务，难以抽身，竟一拖再拖。后来和很多朋友、客户交流讨论，更是深深感觉行业博大精深、风起云涌，可能凭我才疏学浅、精力有限，确实无法一举完成。因此，准备以连载的形式，一小步一小步的去做，随时接受反馈、修改、补充，也许可以慢慢有个积累。</p>
<p>犹记得在<a href="http://bo.xianguo.com/">鲜果联播</a>上和公军以及lazylorna美女讨论Twitter观察的一篇文章时所说的一句话：很多人都能看到历史的背影，却鲜有人能够看清历史的脚步，就更惶论看到历史的方向了。基本上，我自认为属于很多人的范畴，所以大部分观点都是个人的一些思考，并欢迎任何批评和建议。</p>
<p>计划连载的提纲如下，在连载过程中随时会进行调整。</p>
<p>第一大部分会讲讲移动互联网的兴起是互联网下一个10年的一件大事。电信和互联网的融合会是个怎么样子。又终将鹿死谁手呢？</p>
<p>第二大部分准备谈谈云计算。重点谈谈云计算的一种模型，开放平台即服务（OPaaS）。</p>
<p>第三大部分则引申出创新2.0的开放平台观和生态系统观。并对现存的一些成功的开放平台生态系统进行剖析。然后斗胆预测一下未来的形势。</p>
<p>当然，每一个部分会分成多篇来写。</p>
<p>欢迎大家随时拍砖。</p>
]]></content:encoded>
			<wfw:commentRss>http://oplatform.org/archives/107/feed</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
	</channel>
</rss>
