The Future of E-Mail
周一, 2004-12-20 01:47
真正促使我考虑这个题目的是本周会议上 jasper 给我演示 QQ 里面'群'的功能,(我的确是个土人,虽然知道QQ群很长时间了,但从没有想过去使用它),结果我看到这个界面就喊出来:这不就是邮件列表吗?
从此事件后我就开始思考电子邮件和即时通信(包括IM和短信)之间的联系,越想越觉得从服务的本质上,电子邮件和即时通信就是一个玩艺儿,只不过一个是拉(pop)信息,另一个是推(push)信息。且慢,服务的实现方式真的会是它们的分水岭吗?blackberry 显然给我们另一个扩展想象力的方向——原来EMAIL也可以push到手机上。QQ很聪明,正在把电子邮件中很成熟的应用慢慢的挪到IM上,我敢打赌, 2005年腾讯就会推出QQ别名的服务来让用户随时生成一个临时别名和未经认证的peer联系(aha,手机上的一卡多号早就实现了;或许这样的服务QQ 已经有了,只不过土人我还不知道而已?)
即时通信会是EMAIL的终结者?看看电子邮件的问题正一点点的在即时通信上显现出来:病毒、垃圾信息...所谓电子邮件的继承者也继承到了电子邮件的不良基因;同时它们恰恰没有继承EMAIL最优良的DNA——开放的协议。开放的SMTP现在受到多人诟病,但请别忘了,正是开放的协议使得用户得以享受更佳的服务,因为任何人都可以轻松参与竞争,所以服务提供商时刻不能停下脚步,想想GMAIL吧;自从ICQ问世以来IM软件有什么本质变化吗?是 QQ的离线消息还是MSN的传情动漫和闪屏?Foxmail有特快专递,而一个大学本科生稍作些研究就可以作出更酷的EMAIL客户软件。虽然SPAM正是利用开放的协议得以传递,但我看到的是在中国就有30家以上,或许有100家厂商在试图解决这个问题。写到这里,觉得开放协议类似市场经济,总有看不见的手会调整一切,专有协议类似计划经济,表明上看起来理想,真正遇到问题马上束手无策。
"Death of EMAIL"...网上已经开始讨论这个话题,计算机世界好像也有一个煽情的题目《EMAIL死于2078》。EMAIL会死吗?当然会的,就如同任何事物一样,有起始就会有终点;但在我看来,就如同WEB/HTTP现在俨然已成为网络计算的标准一样,日后的Message服务肯定也是由 EMAIL/SMTP领衔的标准协议族(其实MIME就已经是个很好的尝试;虽然有了 Jabber,但在SMTP协议上扩展IM服务并非完全不可能),EMAIL眼下正值盛年,对它还应给予更多期望(希望IETF和厂商们能象对待WEB/HTTP一样更加积极些)。从某种意义上来看或许第三大杀手应用永远不会出现,除了网络计算和个人信息传递,我们还需要别的什么呢 :)
最后看看我的题目,或许改名叫《The Future of E-Message》更加合适。到了岁末,正是感怀光阴,激荡文字的好时候,现在有了blog工具,计划再慢慢写几篇辞旧迎新的东东供自己yy
WinFS 狂想
周二, 2005-03-08 09:16
一直以来,MS 试图寻找一个使用文件和目录的最佳方案:Windows 95 提出了 "C:\Program Files" (这不就是 UNIX 上的 /usr/local 或者 /opt 么?),慢慢的基本上所有的软件产品商都会把自己的缺省安装目录放在这里;Windows 98 提出了"C:\My Documents",一切以文档为中心的概念,弱化了程序(Program)的地位,把"我的文档"提升到"桌面"上,成为和"我的电脑"一样重要的对象;2000 引入了 "C:\Documents and Settings" 目录,对多用户的文档存放支持更佳(微软在这里应该是借用了 UNIX 的 /home 的思想);在 2000/XP 下标准的文件保存对话框中,缺省的文件保存路径就是"My Documents"。不过说实话,作为一个非常熟练的 Windows 使用者,在 Windows 下保存管理我的文件,仍然是一个非常困难的任务。
我的确非常欣赏"My Documents"的概念,不过不能在安装过程中指定缺省的"Documents and Settings"所在盘符,我觉得是一大败笔,就好比在安装 Linux 过程中无法给 /home 指定一个分区一样。仅仅是因为这个原因,重装 Windows 变成了一个风险非常大的活动...难道微软真的认为用户从来不会重装他们的操作系统么(居然现在狂妄到在线激活Windows也要取消)?试问有多少人知道可以重新映射"My Documents"的 target location,即使是有了这个功能,每次重装系统之前,我都要寻找到放在一个隐秘地方的 outlook.pst 把它备份出来,还要备份"My Favorites",备份所有的连接设置(包括 ADSL 的帐号和密码),最后,还有"Desktop"上的所有文件...
虽然有种种不便,但在和 windows 不断的抗争中取得了不少经验,所以长期以来都在得过且过,真正促使我去思考一个好的文件系统/操作系统应该能提供什么样的文件管理服务的,是 MSN Messenger 的使用。突然有一天,我需要一份很久以前别人通过 MSN 传给我的文档,我这才发现自己原来根本不知道 MSN Messenger 缺省把文件存储在什么地方,忘了有什么关键字,所以搜索不出来,无奈之下,只得在 MSN 上请求别人随便给我传一个文件,这才知道原来是在"My Documents"的一个子目录下,打开这个目录一看,乖乖,已经存放了一百多个文件,而我从来没有加以整理利用。这个事件对我影响很大,我一直觉得使用分区/目录/子目录..这样的分类方式保存文件是天经地义的,可一旦一个应用程序自己偷偷使用了一个目录,而这个应用程序又被卸载掉,怎么在成千上万个文件中找到自己想要的东西就异常困难;尤其是随着互联网的应用越来越广泛,我机器上大部分的文档都是从网上而来,而非自己创建,很难事后回想起搜索文档都需要什么keyword,而以后不属于自己创建的文档应该会越来越多:html、chm、pdf、ppt、doc、mp3、、swf、rm、jpg、 png、url link..想想都头疼。
当然也有光明的一面,outlook(不是OE) 在组织外来文档和自建文档方面就很得心应手,我根本不需要考虑我的文档存放在什么地方,只需要打开 outlook,那么它们就全部在那里,以至于后来我一度不再使用 notepad,转而用 memo 存放一些小的文本。这听来好像从"以文档为中心"退回到了"以程序为中心"的时代,其实不是这样,操作系统/文件系统完全应该更智能一些,它应该能给我所有的文件一个全局的视图,好比 outlook 全局管理邮件、日历、便笺一样。为什么我要去考虑:D 盘存储文档,E 盘存储 MP3,F 盘存储 avi/rm,G 盘存储 jpg...然后在 E 盘下创建一个流行、港台男、港台女、大陆男、大陆女、乐队什么什么这些个目录,港台男下再创建张学友、刘德华...问题又来了,有些目录是按地域划分的,有些目录是按音乐性质划分的,有些目录是按组合性别划分的,它们之间会有交错..那么该怎么办?
我刚刚开始思考这个问题的时候只是感觉操作系统不应该把 C: D: E: 这么丑陋的东西强加给用户,不应该把决定朴树是属于"大陆男"还是"摇滚"的压力推给用户;只要信息容易搜索就对了,哪怕它们是放在一个目录下面。后来知道了 WinFS 的研发计划,了解到它的一些 meta info 等数据库特性,"于我心有戚戚焉",颇有相见恨晚之感,对微软认同感大增。现在看,furl、google 已经实现了类似的方案,那就是标签,无论 tag,还是 label,和 meta 应该都是一回事,只是不知道 meta 究竟能有多大的扩展性和灵活性,以及将如何和性能平衡。想象未来的保存文件对话框,除了输入文件名以外,还有一个"点击此处创建新的 meta"的链接,好玩,不晓得微软将把 meta 翻译成什么中文单词,"元信息/元数据",这个概念可比"标签"艰深多了呢。
Indigo 狂想
周五, 2005-03-11 10:22
真正让我感到 MSN 的可怕是 MSN Shell。起因是我发现一个同事的头像突破了普通大小的限制,问他才得知是这个插件的功劳,于是下载试用,发现提供了颇多实用的功能。再继续在网络上搜索,竟然发现 MSDN 上有专门的章节阐述 Windows Messenger 的扩展开发,而且有论坛讨论交换 MSN 插件的信息。我一下子就联想到 Internet Explorer 的 ActiveX plugins,MSN 显然是把 Messenger 作为下一个通讯平台,鼓励开发者在 Messenger 上给用户更丰富的使用体验,就好比现在的 MyIE2/Maxthon。后来出现的 Msnok 更加应证了我的想法,虽然 MSN 还没有在中国落地,但是移动 SP 通过插件开发,就可以支持 MSN 和 SMS 的互通,这更涉及到 MSN 底层的通讯协议。虽然 MSN 协议早已公开,也有 gaim,jabber-MSN gateway 这样的开源产品一直在使用 MSN 的通讯协议,但这次是我看到的首个大企业公开利用 MSN 协议以及 MSN 软件作自己的增值应用,和 QQ 闭关自守的心态有天壤之别。
Indigo 是下一代 windows 操作系统通讯协议的统称,现在大家都关注在 Indigo 将提供的 web service 支撑,我却在想,MS 在这套接口里面,会不会干脆把 MSN Messenger 会话,消息,应用等统统集成出一套简单的接口,软件厂商通过这套接口就能很容易开发出自己的 IM 产品?(以前只是猜想,但前两天刚刚看到另外一个 IM 厂商提供给我们的 IM SDK 文档后我发现这是一个很简单很现实的事情)只不过所有的登录 ID 必须是一个合法的 passport 帐号。其实 passport 也不是什么难题,我百分之百相信,未来如果你没有一个 passport 帐号,就根本无法登录 windows。不是吗,现在在 xp 中,已经可以看到在用户的 profile 中绑定了这个帐户曾使用的 passport 信息,未来把这二者双向绑定绝非难事。另一方面,windows 95 发布的时候还包括 13 张软盘,到了 windows 98 就没有了软盘,因为...如果你没有一个光驱就不配使用 windows;到了 windows xp,如果你没有联接网络也就无法激活你的操作系统(当然现在 MS 取消了这个,但更多是盗版因素),同样是因为...如果你没有联网就不配使用 windows;aHa,完全可以推导,总有一天你会发现,为了使用 windows,必须绑定一个 passport 帐号才能登录,而且说实话,取得 passport 的成本比买一个光驱便宜多了。
真到了那一天,马化腾还能去干什么呢?或许经营游戏更现实一些,或者干脆去作 MSN 插件,我看 avatar 插件就是一个很不错的主意,虽然 MSN 可以自己上载图片,但如果能很方便的自己组合形象,还是会有少男少女使用这种服务的,只不过这样作会导致一个很拥挤的竞争环境,当然也的确应该如此,本来成本也不高,现在的 QQ 简直就是强买强卖么,一点技术含量也没有。唯一可以让腾讯安心的是,现在中国还有 1/3 的机器在使用 Windows 98,也就是说有 1/3 的机器还没有 MSN 的缺省安装--中国网吧催生了一个很奇怪的产业环境(我们现在就特别痛恨保证 IE 5.0 这么烂的浏览器兼容,因为它占有了中国 20% 的浏览器市场)--但这一天总会过去,这个操作系统毕竟已经 7 年了,早就过了正常的支持周期。
真到了这一天,eyou 还能作什么呢?现在我能想到的答案还是 jabber,虽然 MS/IE 很强大,虽然有 Netscape 的前车之鉴,但是 Mozilla/Firefox 的兴起还是给我些许信心,开放的协议开放的心态才是我们生存之本。
对于 QQ 购买 foxmail 的看法
周四, 2005-03-24 09:38
2004 年 7 月,yahoo 收购了 oddpost。哈,你听说过 oddpost 么?我是 04 年年初知道 oddpost 的,因为它在界面中集成了 RSS 订阅,所以我特地上去试了试。结果我一下子就被震了,不是因为 RSS 订阅,而是这个 web-based 的 email 看起来完全就是一个 outlook express,menu、toolbar、sidebar、statusbar、dialog 等元件一应俱全,统统是用 javascript 画出来的。因为有 oddpost 在先,所以后来 gmail 的所谓的 ajax 技术我也只觉得尔尔,毕竟 oddpost 已经有了一个更酷的界面,虽然只支持 IE。现在想起来,yahoo 极可能是因为 gmail 的威胁而收购的 oddpost,但 yahoo 收购 oddpost 后也没见 yahoo mail 有什么变化,都有些怀疑 oddpost 是不是在巨大官僚机构里面被消化掉了。不过最近有一回访问雅虎中国,我小心翼翼的问起 yahoo 有没有感觉到 gmail 的压力,回答是没有;再问 oddpost 怎么样了,结果告诉我可能会在近几个月有相关的产品出来,aha,我真是非常期盼这个新产品的出现呢。
絮絮叨叨说了半天 oddpost,就是想说明一个事儿,网络服务的未来是 web,绝对不是客户端;这一点在最近大家关于 RSS 在线订阅还是客户端订阅的讨论中已经表现的很明显;Giga mail 的出现更是让客户端失去了最后的一点意义。单纯从终端功能的角度而言,foxmail 的黄金时代早已经过去,OE 和现在大大小小的 webmail 在不停的挤压 foxmail 的生存空间。另一方面 foxmail 被博大收购就是一个错误,foxmail 研发团队走了一个大大的弯路,被迫在自己不擅长的服务器市场上奋斗了一段时间,拖累了它本来的优势项目;我们还曾经一度担心 foxmail server 给我们软件业务的压力,最后发现它实在是不行。
Ajax/XMLHTTP 的影响极为深远,oddpost/gmail 给我们展示了即使只是浏览器,仍然可以做出很眩的效果;而且进一步封装出 web service 来是非常容易的(web services 一定会是未来的潮流,看看现在的 RSS 就知道了)。当我第一次接触到 XMLHTTP 的时候,立即想到用这玩意实现一个 web chatroom 太现成了;微软很早很早以前也有了 webmessenger.msn.com;jabber 更是觉得基于 cookie 的 http polling 还不够好,又提出一个 http binding 来改进。而一心打造另一个超级 web portal 的 QQ 怎么就不弄一个 webqq 出来呢?岂不能更有助于实现它的目标?哪怕是做一个 flash qq 客户端也不错啊。
QQ 看来是已经把目标锁定在占领用户桌面上,下一步他会做什么?收购网易解散的 P2P 团队?收购 Maxthon??甚至收购豪杰???收购金山????如果我是马化腾,说不定会弄个 qq 桌面搜索来玩玩,不过估计他还没有能酷到这个地步。
其实 dev.eyou.com 的来源应该追溯到 oddpost,虽然我很早就知道了 channel 9,但从没有想过做一个 PR blog。yahoo 购买 oddpost 大大刺激了我们,因为...yahoo 显然不可能短时间内再购买另外一家 web MSP,于是我们上下反思我们哪点做得比 oddpost 差,结果老板的结论之一就是从 oddpost 的 blog 可以看出这帮家伙是一群非常酷、非常喜欢自己的业务、非常有才华的人,这样 dev.eyou.com 就这么开始了。
嘿嘿,我要这里郑重声明一下,我们是一群非常酷、非常喜欢自己的业务、非常有才华的人。拜托你们同时也去告诉杨致远让他来看我们的 blog 吧。
和大富翁握手
周五, 2005-03-25 14:48
虽说周老板的 1.5 亿是以美元计算,但其中水份颇多;今天碰到一个可能比盛大陈老板还有钱的大款,坐在一起聆听了一会儿教诲。
这里就不多介绍 NetScreen 和邓峰的背景了。只简单谈谈他给我们建议中的两个:
1. 要抵抗诱惑,不要偏离自己的目标
2. 一般而言,要先完成对老用户的承诺,再去考虑新用户的需求
中国软件公司能做到这两点的能有几家?至少 eyou 做的不是很好....
今天你写汉字了吗?
周一, 2005-04-18 14:56
题外话:很久以来关于输入设备一直是我们研发部门午饭中 brain storm 的热门话题之一,因为程序员整天都在和键盘打交道,尤其是 UNIX 下的程序员,终端下不管是 vi 还是 emacs 都没有对鼠标的支持,什么样的输入设备可以取得更高的生产率是我们非常关心的事情。在听说有人发明了脚踏板来替代 emacs 里面的 ALT 后,我们开发人员的思维更是在此基础上进一步发散,后来大家公认乐器非常有希望取代键盘成为程序员的下一代新宠。hehe,大家可以想象一下以后使用 USB 接一个吉他或一个手风琴聊天的情形。
育通笔的原理说起来十分简单:整套设备分成两个部分,一个发射超声波的基座通过 USB 连接在主机上,取得附近一支特制的笔运动中的轨迹,计算出实际的坐标返回驱动生成位图;实质上就是另外一个类型的手写板,只不过变成了无线方式。这样一来任何计算机在有了这么一个外设后立刻变成一个 Tablet PC!当然还是缺乏电子墨水这样一些 Tablet OS 内置的应用。为了让演示看起来更有说服力,捷通员工的笔记本屏幕上都被一个透明膜覆盖着,做演示的时候就在屏幕上设定好一个矩形区域,然后在这个区域内开始写写画画,看起来确实和 Tablet PC 没有什么两样。育通笔也可以包括一个真正的笔芯,这样可以在白纸上写草图,写完后计算机上也多了一份 copy;或者更大,做成一个白板笔,这样可以轻松获得所有的板书...比传统那种巨大的电子白板成本低多了。
育通笔的意义并不仅仅是手写输入,是他们老总的话促使我在这里免费给他们做广告:希望提供更廉价更方便的手写方案来保持我们的汉字系统在 cyberspace时代内的竞争力。的确,比什么保护北京四合院更重要的问题是,现在我们(而且是受过高等教育的一批)几乎都不怎么写汉字了。
今天你写汉字了没有?你的字写的好看么,是不是像鸡爪子爬出来的(我老爸总这么批评我)?我建议是三点:
1. 所有字写的不好看的人立刻买一本字帖,每天练一练,这比抵制日货重要得多
2. 如果有时间,那么就学习用五笔输入吧
3. 还有,请把你的手机输入法切换成笔画输入
同时再推荐一下桑葚的一篇关于正体字和简体字的 blog。
Mozilla vs Longhorn -- 用 Xul Runner 打造你的下一个桌面程序
周三, 2005-04-13 14:12
在看了 XULRunner 的简介后,禁不住要把它和传说中的 avalon + indigo 对等起来比较:networking、web services、IPC between gecko-based apps 这些已经和 indigo 差不多了;xul + svg 也有了 avalon 基本抗衡的能力;Gecko 以及其内置的 JavaScript 引擎作为界面显示内核;再加上 Extension Manager、 Auto-update support、 APIs and user interface for installing, uninstalling, and upgrading XUL applications 这些东东......XULRunner 如果真能做到这一切,而且能给社区提供非常良好的支持(什么时候 mozdev 能做成 MSDN 那样啊),那 XULRunner 的发布绝对是一个划时代的事件!!
XULRunner 应该是把目前 firefox 和 thunderbird 的重复工作抽象出来,成为独立的组件,而日后 firefox、thunderbird 包括 mozilla 的 sunbird 等项目的开发,其实不过就是基于 XULRunner 创建应用程序而已。基于 XULRunner 开发桌面应用的一个显而易见的好处就是程序是可移植的,不论是 windows,还是 gnome、kde,甚至 MacOS,理论上用 C++ 写的 XPCOM 组件都能很好的在各个平台上编译,嵌入进 XULRunner。写到这里,我都有些手痒痒,恨不得立刻就写一个 Hello World 出来。
做两个简单的预测:首先nvu 很快会切换到 XULRunner 平台上,事实上现在 Nvu 的架构离它已经很近了;然后就是 2005 年会出现一个 RSS 聚合器是通过 XULRunner 实现的。
我的一个很大的遗憾就是起步之初,由于缺乏经验(当时也没有什么好的选择),很多底层的支持库都是自己做的,现在这些 legacy 代码必须继续使用维护而且精力实在有限,现在已经很难切换到那些被证明是很成熟的库上去,比如 glib 和 apr,这就是所谓先发劣势吧。现在出现 XULRunner 我觉得是一个很好的机会,如果 eyou 打算开始做一些桌面应用,比如 jabber 客户端(甚至 email 客户端???),XULRunner 肯定会是一个重点考虑的对象。
草案:Policy on Public Discourse
周四, 2005-04-28 10:38
注意:本文档仅仅是一个内部讨论草案,并不是亿邮公司的官方正式观点
版权声明:本文档所有版权由 eYou.net Corp 版权所有,任何转载和发布都不得去掉版权声明信息
作为公众社会的一个实体,我们鼓励公司员工自由向公众发布和公司相关的信息,以促进公司内外部间的信息交流。
为了保护员工以及公司,不会因为不当的信息发布而处于不利境地,制作此文档作为信息发布的参考。
以下内容属于不当信息而不能空开发布:
1. 属于公司或者其合作伙伴的,受法律保护的专利权或者知识产权范畴的内容
2. 和公司财务相关的内容,包括:商业合同、招标信息等
除非获得明确授权,也不能公开发布以下信息:
1. 未发布产品的独特特性,该特性并不在任何已知的竞争产品中出现
2. 产品路线图或新产品发布日期
3. 公司客户的信息
不当信息的类型还有其它很多,以上仅仅是为了保护公司和合作伙伴的商业秘密,以及客户的隐私而制定的基本准则。
员工在工作中(甚至包括工作时间以外)通过智力活动会产生一些和工作相关的奇妙的想法、点子、概念...等结果,理论上而言这些结果应该属于公司财产之一部分,但实践中我们认为公司没有能力强迫,甚至也不应该强迫员工将这些结果对公众封闭。因为在智力领域,只有意识独立,不受束缚,才能获得真正的结晶;另一方面只有接受更广泛的评论和意见才能总结出更好的结果。我们仅仅建议员工在公开此类信息(比如某个算法或者方法的实现细节)之前做如下两个判断:
1. 是否会导致竞争对手的事先采纳,从而给自己和公司造成压力?
2. 是否会在未来成为公司专利权或者知识产权的一部分?
我们信任员工的智识和判断力,因此不予对信息公开发布做更多干涉。
新型存储方案 AoE
周日, 2005-05-01 18:07
总体上而言,AoE 应该和 iSCSI 一样,都归结到 SAN 的范畴里面去。只不过传统的 SAN 是在光纤通道/光纤交换机上跑 SCSI 协议,iSCSI 是在 IP 网络上跑 SCSI 协议,而 AoE 是在以太网上跑 ATA 协议。具体说就是 Coraid 这个公司生产一种存储设备,通过网线直接连接到服务器的以太网口上,经过驱动程序把以太包翻译成ATA指令,或者把ATA指令翻译成以太包,就这样服务器可以把这个设备当作一个 ATA 块设备来 mount。
那 AoE 的优缺点是什么呢?和 iSCSI 一样,相对于传统 SAN,可以省去昂贵的光纤设备的投资,这可就好几万了,缺点就是需要花额外的 CPU 时间来做协议的翻译,当然以后可能会有类似 HBA 卡那样的 AoE 硬件,不过我估计这个东西的价格肯定比 HBA 便宜。和 iSCSI 相比,AoE 部署起来更加方便,不过同时也丧失了 IP 层路由的灵活性,另外,由于工作在数据链路层,它的效率肯定比 iSCSI 要高,这里有一个图片演示了这一点。
纯粹从技术上看,AoE 是 iSCSI 的直接竞争者,缺乏大厂商的支持是一个很大的障碍,不过似乎 cisco 这样的巨头对 linux 不太热心,而 AoE 目前只支持 Linux/FreeBSD,如果自由操作系统在服务器市场上越来越成功的话,说不定 Coraid 最后也能在 SMB 市场上有自己的一席之地。不过不论 SAN、AoE 如何发展,要真正做到跨广域网的异地容灾的话,还是只能用 iSCSI
看起来 AoE 很适合家庭使用,我早就想在家里弄一套存储设备以容纳 DV 产生出来的家庭录像,它绝对比 USB 硬盘盒更好用,而且不需要额外买机器来挂它。如果它能更酷一些,比如做一个 ATA-over-Wireless 就好了,54Mbps 的带宽,做 1394 采集应该够用了,而且这玩意真正进入家庭的时候,家庭无线的带宽会更高。
无线环境的家居生活是多么美好啊,另一方面,以后会出现 SCSI-over-Ethernet 么
jabber、opensource、eyou、business model
周三, 2005-05-11 19:28
不去评论这个公司,就事论事,除了去年底的一篇枪手稿以外,点石到现在似乎没有任何的新动作,就我个人的感觉,这块石子带来的涟漪都已经消失了。
我非常理解点石,因为在 2001 年的时候,我曾经咨询过一个素不相识的网友——他当时是linuxforum的一个版主——“如果eyou的邮件产品开源的话会给市场竞争和产品销售带来什么样的优势?”。他给我的意见有相当高的质量,现公开这些历史档案,呵呵
我是xxxx公司的Consultant,负责在中国地区的企业解决方案和合作伙伴的联系以及solution的制作.
你和我说的那麽多贵公司的信息,我觉得都挺好,不过根据我的猜测,贵公司在商务上并不是很成功,或者没有大量的专业商业从业人员在阻止你们的市场策略。
我很能够体会你们对自己产品的骄傲和自信,但是产品的好坏根本不能够给一个公司以出路,从你们公司从.com到ASP,我个人觉得就是一种非常盲目的表现。
我实在猜不出你们的产品是哪个方面的,因为我一开始以为是eMail,但是根据我所获得信息,email供应商的日子并不好过,而且我绝目前应该是CRM日子最好过,呵呵。
Open Source和你们的软件怎么捣鼓没有必然的联系,还是要根据你们的发展策略走。
你们通过将软件Open Source后,将不可能从软件本身获得任何的利润。
我以前效力于国内较有名的一家风险投资公司,所以我认为你们现在先不要做引入资金的梦。个人愚见,你们当务之急是要做以下的几个事情.
1. 确立公司核心盈利模式
确定到底是通过软件赚钱,还是通过服务赚钱?
2. 评估公司的市场地位和竞争策略
在你们的核心盈利模式确定后,可以判断你们主要的细分市场是在哪里,细分市场上的壁垒有多高,竞争对手有哪些?
3.把你们的三张财务预算表给做出来, 最重要的现金流量表,然后是损益表,最后是资产负债表。不要告诉我你们老板不会或者不熟悉这个东西,如果不清楚的话,了么你们离开与大公司合作就有很长的路要走了。
因为你不可能空口说白话,欺骗别人说你们是赚钱公司。
至于OpenSource 与否,其实根本不是问题的关键.可能你一下子无法理解我说的,但是我看到过好多你们这样的公司,除了一个优秀的产品之外,只有很不成熟的市场策略,然后就是越做越不好,渐渐失掉先机和市场。
我的结论是Open Source不是你们公司所面临的主要问题。
你们要讨论的就是我上面提出的几个必须要做的工作
我不知道你是否是你门公司的决策人员,如果是的话,可以给我打电话
xxx-xxxxxxxx
呵呵,由于我不是公司的决策人员,所以无法给他电话,于是继续写信询问
看了你的Reply,我觉得的还是很困惑,因为很明显你们准备走服务的路线,但是后来你又提出的了你们的产品。
我绝的如果以服务这条路线,你们就应该将服务本身包装成一个产品化的东西,有专门的sales来销售服务,有市场报价,有针对服务的质量保证,还有用户购买你们的服务后的售后服务,就是"服务的服务".
在这种营销模式下,你们的产品如何高级,是否要OpenSource已经很不重要了,因为公司的真金白银都是从每一次的服务中获得的。产品甚至可以在给用户的解决方案中完全免费。
你后来说售后服务,让我觉得更加困惑,我总觉得你们对服务商品化的理解不是很对。这样导致的直接后果就是一方面扔下很多人力来搞传统意义上的服务,一方面花人力对产品进行深度开发,一边在市场上和软件供应商打仗,完全没有把自己作为市场互补者的地位考虑。
我见过不少你们类似的企业从一个以软件为主的转向服务,很多都转型失败,原因很简单,就是往日所倚重的软件产品,在新的销售模式下必须要放弃以往的地位和角色,成为整个服务体系中的一块平凡的砖头。
如果你不相信,可以看看你们公司将来的运作,如果一边要走服务,一边还在大力销售你们的软件,最后会产生很多市场壁垒的,会活的很痛苦。
祝你们一路走好!
可惜鄙人十分驽钝,还是以井蛙的心态考虑问题,回信争论,结果得到一封挨骂口气的信
我们讨论了半天,我还是对贵公司"基于优秀软件的服务模式"有很大的疑惑。
如果你们还不能将你们的"优秀软件"降格到一个服务组件的地位,将服务本身的条理化和专业化提升到一个商品的地位,呢么你们在以后的10个月中很快就会陷入产品和服务互相争夺客户的怪圈,如我在8,9,10三个月中所见,我咨询的83家中国IT企业中,有一些已经步入了这样的窘迫境遇,这也是所有靠软件起家的公司所面临的一个重大问题。
类似你们这样的公司,我现在“照顾”着的就有2家,均在上海,事实表明,以一个具体的产品为服务核心的模式很快就会因为产品本身(技术水准,核心开发人员的去留,市场需求的变动,外来同类产品的冲击等),影响到整个服务和客户群,最终导致失去应有的市场份额。
类似你们这样的企业在中国有,而且很多,但是均没有非常成功的案例。
我个人总感觉你们太看好自己的产品,忽视了对整个市场的仔细分析和预测,近些日子,国外中小型软件公司大量进入中国,我也是做软件出身,我就不相信你们的软件居然能够给你们如此大的信心,以至于盲目乐观到认为那个xxx万/年的市场就是你们的盘中餐,特别是你们有这样一个弱小的市场和商业队伍,怎么能够书生气十足的和商业老手打仗?
这个是我对你们公司的建议的最后一部分,你们好自为之吧。
现在已经过了整整4年,无论是我个人,还是公司,都已经和那时候远远不同,但我还会偶尔看看这三封信,每次都会为当年的弱智而羞愧。时间过了这么久,解密这些档案应该没有任何问题了。结论:opensource 是开发模式,而不是商业模式;opensource 不能保证开发出好的产品,正如封闭模式不能保证开发出好的产品一样。希望能对大家有启示。
gcc saga
周五, 2005-05-20 18:19
1997年,以 Cygnus(第一个开源商业公司,后来被 RedHat 收购)为首的开发团队决定独立开发 egcs,因为 RMS 认为 gcc 最重要的是稳定,然而 Cygnus 迫切需要扩展 gcc 到更多平台上(它的商业产品 GNUPro 和 eCos 就是面向嵌入式市场的)。分歧不可避免,尤其是 Cygnus 的三位创始人从 1990 年开始就成为 gcc/g++/binutils/gdb 的重要开发人员(可以参考洪峰翻译的那本开源软件文集),这次分裂对 gcc 带来的挫伤是非常严重的。
在 egcs 发布前夕,gcc 迫于压力,发布了 2.8.1,事情发展到这一步已经有政治斗争的意味。egcs 毫不示弱,如果运行 egcs --version,它的版本号显示是 1.x,但如果运行 egcs 符号链接到的 gcc --version,版本号显示为 2.91.x。尽管 Linus 一直在推荐使用 gcc 2.7.2.3 编译他的 linux kernel(稳定性的确是最重要的),可事情最终还是向着有利于 egcs 的方向发展,尤其是 RedHat 收购 Cygnus 后,egcs 就成为这个最流行的 Linux 发行版本的缺省编译器。那个时候,Eric Raymond 发起 Open Source 运动,VA 和 RedHat 相继上市,RMS 和 FSF 的确有衰落的迹象,egcs 取得最后胜利眼看指日可待。
事情的结果现在我们也都知道了:gcc 2.8 无疾而终,RMS 交出 gcc 的管理权,gcc 从 GNU C Compiler 改名为 GNU Compiler Collection,egcs 改名 gcc 2.95。
偏房最终扶正,但 RedHat 的冒险仍在继续,当 RedHat 7.0 里面再一次出现 gcc 的时候,版本变成了 2.96。RedHat 为了跨平台更强的 gcc 3.0 而不惜拿忠实用户做 beta test,Linux kernel、Apache、MySQL...纷纷建议使用 2.95.3 编译它们。亿邮也跟风使用 2.95.3 编译自己的软件,呵呵。我可能也正是因为这个原因而喜欢上的 debian,2000 年的 potato 给我的 gcc 是 2.95.2,2002 年的 woody 则是 2.95.4!!从此我就坚信 debian 是比 redhat 更可靠的发行版本。
虽然 saga 读起来很有些激动人心,但说实在的,类似 gcc 这样的传奇还是越少越好。
产品和服务
周三, 2005-06-08 18:50
1. 如何避免"陷入产品和服务互相争夺用户的怪圈"
2. 如何布局"产品只是整个服务体系中一块平凡的砖头"
但引用KES0的观点来看产品还是很重要的:“没有产品做依托,谁要你的服务啊?”,但我觉得这里他犯了一个错误,就是专业的服务提供商是把自己的服务作为一个独立产品对待的,一个例子就是 IBM 服务部门是可以在方案中使用非 IBM 的硬件的,否则不足以和第三方的中立的组织竞争。
Alan Cooper 有一个观点:"顾客驱动的死亡螺线"。有这么一个对比:
出售自己解决问题的专长和出售过去积累的经验,即出售“头脑”和“灰发”。为了我的头脑而雇佣我的人,肯定是对我有相当的信任,他们对我的期望是前所未见的;相对来说出售灰发要简单些。
当从头脑生意转为灰发生意的时候,那种特有的、使我能够成为一个顾问的能力就开始衰退了。我们提供的服务不再是利用才智解决问题,而是执行一个普通的任务。我作为一个顾问的需求萎缩了,而本来的客户也开始给一些低水平的,降低身份的任务。同时,客户开始寻求其它水平更高的顾问——那些更多运用头脑的人。
写到这里发现有些偏离本 blog 的初衷,没关系,继续发挥吧。我觉得很多软件公司的失败都和顾客驱动有关系,第一个产品大卖后就丧失了对自己产品的控制权而一味听从客户。而且,当我们的高级研发人员发现他的“头脑生意”正在慢慢衰退的话就就考虑另外一个业务模式了...苦笑两声。
周五, 2005-06-10 09:20
这两天又总结了一下关于服务客户的思路:
服务客户,而不是臣服客户
分析需求,而不是听从客户(参考First Rule of Usability? Don't Listen to Users)
我认为软件厂商和客户的关系更应该是合作伙伴的关系,尤其是在增加了服务因素之后。如果客户把我们看作他的供应链的上游,那么关系才能理顺;我们必须认识到我们销售产品和服务不仅仅是两个组织之间的价值交换,还是我们在帮助客户创造价值,我们才能在合作中取得心理优势平衡。
现实是,如果客户购买我们的产品和服务仅仅是政治的需要,那我们只会像狗一样被唤来唤去。
从 qyb 身上赚钱
周五, 2005-06-24 09:14
知道这个消息后我很是反省了一下自己,看看自己究竟给互联网经济做了哪些贡献。现总结如下:
1. 数码相机是从论坛上找的商家买的,当面交易
2. 手机是从易趣上买的,当面交易
3. 从 china-pub、amazon 买书
4. 很久很久以前的三星Yepp N64好像是从网上买的
5. tiffany 小豌豆虽然是商店交易,但也是在网上先看定了样子和价格才托人买的
6. 老婆从卓越、当当、旌旗买书无数,我也搭了好几次车
7. 老婆从网上买的那些玩具......应该也有我的一半吧
看来并不是我在网上一毛不拔,而是盛大和腾讯提供给产品和服务我根本不想要。所谓很难从互联网高端用户身上赚钱是因为本身这个群体已经拥有了很多免费的或者说容易获得的资源,一些初级用户看来很有价值的服务对于高端用户是没有多大意义的。即使是 bluetent,已经算很高端的用户了吧,一样老老实实去买域名和虚拟主机,因为他确实找不到其它的免费替代品。
问题的关键在于想从我身上赚钱的人是否真的知道我究竟需要什么,如果当当知道我在 cal.eyou.com 上设置的目标:"买 About Face 2.0",它可以书一印出来就给通知我,那真就意味着它赚到了钱而 china-pub 少了一桩生意。问题的关键还在于想从我身上赚钱的人是否真的考虑过我的情感,就好比卖保险的推销员让我觉得好像我的生活有了重大缺陷但我无法自理他必须要像先知那样指引我,那些不断弹出的广告,垃圾邮件除了惹人讨厌还真想让我点击么?问题的最最关键是想从我身上赚钱的人是否有清白的身家,骗子、强盗、赌博庄家、皮条客,我可不想和他们发生任何关系,人民心里雪亮着呢。
compose
周二, 2005-07-05 09:16
后来观察到我们一个竞争对手:快客的解决方案是在邮件编辑界面中用 javascript 画一个正在倒计时的时钟,当 session 过期时间还差 5 分钟的时候时钟就开始变红、闪烁,当用户提交的时候,提示用户 session 已经过期,请用户把输入内容拷贝到剪贴板上,重新登录后再粘贴回去。当时看到这个方法后觉得太棒了,于是也依葫芦画瓢如此实现。
自从对人机交互感兴趣后我开始试图分析怎样才是真正人性化的设计,怎样让软件用起来更像一个好的助手而不是冷冰冰的计算机。在上述老的设计中,我发现软件已经犯了几条致命的错误:
1. 软件毁灭有用的数据!!!
2. 软件让用户解决软件本身的问题(session过期导致程序无法继续),却没有考虑怎么解决用户的问题(只想发一封邮件而已)!
3. 软件向少数操作妥协,降低了大部分操作的安全性(从 30 分钟session到 4 小时)
4. 软件给了用户压力(显示倒计时时钟,红色,闪烁,就差放一颗定时炸弹了)
5. 软件强迫用户学习并使用其他工具(什么是剪贴板?怎样来使用它?你为什么要我使用它?)
你可能会想,计算机工业一直是这样的啊,像你我这样由于生计必须长期和计算机打交道的人已经习惯了这样情景,并把之归类到自己的错误:我本应该在 notepad 上写完这封文章再发的,阿哈,它居然会提示我 session 过期并使用剪贴板,真是好主意,这个软件太棒了。
如果我有一个秘书,当我开始写信的时候,和秘书说:帮我叫快递公司的人来,我将写一封信,希望以最快的速度送出去。当我在第31分钟的时候写好信,交给秘书,满怀希望他能把信给快递公司投递出去。这时候我的秘书把信扯个粉碎,然后和我说快递公司的人在1分钟前刚刚离开,我应该在半小时内重写这封信。
你说这样的秘书我应该怎么对待?
于是我很诚恳的和秘书沟通,我有时候写信时间很长,半个小时太短了,秘书想了想,给我找了一个可以在门口等 4 个小时的快递服务,一个月下来发现由于使用了 4 小时等待服务,快递费用大大超支。而且只要超过 4 个小时,秘书仍然会把我的信件撕个粉碎。
我很苦恼,于是看看隔壁的快客公司是怎么处理这个问题的。
快客公司的秘书是弄一个定时装置放在老板的办公室,很明显这个东西来自于好莱坞道具工场通常是核弹的一个有趣配件,当倒计时快完成的时候,它会发出刺耳的噪音,提示老板赶快把信写完。如果快递公司的人等不耐烦走了,秘书会提醒老板应该把信重新用 clipboard 复印机复印一份,然后同样把信撕个粉碎。虽然 clipboard 复印机看起来很神秘,但是似乎多用几次后也很顺手。我想,他的生活是多么美好啊。。。。。。
我就是首先设想这篇寓言后才总结出上述软件的五个致命错误以及真正的解决之道是什么:
1. 我的秘书发现快递公司人走了之后,应该能重新叫回他们
2. 叫回快递公司需要我的用户名和口令。且慢,我的秘书应该总记得我的用户名是什么,我应该只重新声明一次口令即可
3. 永远永远不要撕我的信,如果快递公司的人回来了,把信给他们就好了
4. 的确有可能一些附件会丢失(因为还存在一个后台进程在试图清理过期信息),秘书应该记得曾经提交过什么附件,并提示我再次准备好这些附件。更进一步,附件应该让它很难丢失,把可能性降到最小。
PS: 星期一开会,听了我们一个新产品的功能设计,我的感觉是对程序员来说功能很灵活很强大,但对于用户来说就很难控制了。舒马赫跑圈用的法拉利的确很棒,没有车迷不喜欢的,但如果真要车迷坐进那个车舱里,谁会指望这辆车能安全开出 100 米呢?
为什么 python 现在这么流行
周六, 2005-07-23 16:06
我的答案是 MySQL 一开始就是对 Windows 支持的很好, 而 PostgreSQL 直到最新的 8.0 版本, 才摆脱了在 Windows 下运行需要一个 Unix 抽象层的 cygwin 的需求. 正是因为庞大的 windows 开发人员的支持, 才造成了 MySQL 目前的统治地位. 同样的道理还适用于 apache, 如果不是因为它能在 Win32 下跑, 能不能有现在的地位还真难说.
本来 Unix/Linux 上最流行的脚本语言是 perl, 从服务器管理到web开发, 似乎一切工作都能胜任, 但且慢, 你可曾听说过 perl 怎么在 Windows 上运行? 就算你知道 ActivePerl 这个东西, 你可能也会象我一样暗自嘀咕: perl 和 activeperl 是什么关系? windows 下的 activeperl 能得到 Unix/Linux 那样很好的社区帮助么?
另一个方面, python 对于 Windows 下的脚本开发的意义在于它提供了一个天然的 shell. 我没有用过 activeperl, 所以不知道 perl 在 win32 下表现如何, 但我觉得脚本语言和 shell 是相辅相成的, windows 那弱智的 cmd, 能比得上 bash/csh 十分之一的功能么? 而 python 的仿 SHELL 模式我觉得会深受 windows 开发人员喜欢的. ( zhb 以前向我指出由此而导致的 python 的一个劣势, 就是 python 由于提供的 SHELL 特性反而使得它和 SHELL 的交互远不如 perl, 甚至不如 php, 因此 Unix/Linux 中作系统管理或需要自动运行的脚本用 python 制作的还是非常罕见的)
除了对 Windows 用户友好, python 还有一个巨大的优势就是业界巨头的支持. 除了 O'REILLY, 好象没有什么大企业对 perl 支持. 而 python 我相信很多人接触它是因为 RedHat 使用 python 来编写了系统安装程序以及图形化的管理工具。最近随着 google 神话般的崛起, python 也因此越来越越受到关注. 最近 python 又和 microsoft 联系到了一起....
第三, 由于 python 与生具来的 OO 特性, 使得作 GUI 快速开发用它成为第一选择. (我就把 python 当 VB 使). 现在 python 和 wxWindow/gtk/QT 都有相应的 binding.
最后, Eric S. Raymond 在他的经典文章"如何成为一名黑客"里面对于 python 的推荐可能也起到一定作用.
我也来乱评一下 perl/php/python 吧:
1. 系统管理:perl > php > python
2. WEB 开发:php > perl > python
3. 图形开发:python > perl > php
4. 程序设计入门/Windows应用:python
一般来说,php/perl 两者学习其中一种就差不多了。如果如果你已经熟练掌握 PHP 或者 perl,可以考虑再学习一下 python。尤其对于C 程序员,强烈建议学 python。“兵者,国之凶器”,同样,成功的 C 程序员应该懂得 C 这个东西还是少用为妙。如果大小事情都要用 C 来解决,除了 Dennis Ritchie 那样的人,估计谁也承受不了这样的压力。对于我们公司的 C 程序员而言,至少掌握 PHP 的一些函数也是好的。
想唱就唱
周四, 2005-08-04 11:19
在关注超级女声之前,我弟有一回提议我们两个去玩 Podcast,连名字他都已经想好,叫做"QQ YY BT"组合。我倒是挺有兴趣,不过觉得 Podcast 比起 Blog 来说制作成本太高了,实在是没有时间鼓捣那玩意,于是不了了之。
看了超女以后,感觉其本质就是一个现场卡拉OK Party,湖南台只不过提供了一个很好的平台以及精良的制作队伍,从而就获得了巨大的成功。如果土豆网能提供类似的服务,很有可能三年后超级女声们就不再上电视,而是在 Podcast 网站上争芳斗艳了。
keso 今天提到了数字音乐的前景,质疑为什么可以花两块钱下载老鼠爱大米的彩铃,而不愿意花钱买 mp3?我觉得除了盗版因素外,彩铃是"秀",听MP3是"暗爽",两者的层次是不一样的。不过伴音音乐下载和后期制作可能是一个好的方向,我们 BT 组合放出的第一支歌曲已经计划好做陈升的"北京一夜",但总不能清唱吧,因此获得高质量的伴奏就成为我们 Podcast 的巨大瓶颈,如果能把这部分的成本有效降低,出现一种相比而言类似 Movable Type 那样的制作软件/服务,Podcast 事业就会同 Blog 一样立即放飞。
PC 已经把文字出版的成本大大降低,下一个浪潮应该是音频处理了。想想你上次去钱柜或麦乐迪花了多少钱,你又愿意为把你的声音传播给 10 万个听众花多少钱呢?音乐的版权是一个比较核心的问题,不知道超级女声是怎么处理的,作为一个商业活动,超级女声使用了那么多歌曲,总该捐些钱给音乐协会吧。
说说微软捆绑销售 IM
周日, 2005-08-07 03:02
里面说的很清楚,很多年以前,大家认为操作系统只需要能驱动硬件,管理任务,再加一个 shell 就可以了。在大家开始攻击微软捆绑 IE 限制竞争的时候,却无法定义操作系统究竟应该包括什么功能,但是操作系统如果不包括一套桌面系统,那就是自取灭亡。而由于桌面应用正在向 web 上转移,所以浏览器就是桌面,所以操作系统就应该包括浏览器!(当时我看好 Java Applet,没想到 sun 如此不济,甚至不如 flash)
网易和腾讯显然也和以前的 Netscape 一样很不爽,于是时不时跳出来嘟囔两句。这里我要象 6 年前那样坚定的为 Microsoft 辩护,"IM 就是浏览器",正如当代操作系统绝对应该包括一个浏览器,所以它也绝对应该包括一个 IM Client。虽然这个 Client 只能使用微软的服务,但毕竟它是完全免费的,我为了更换我的头像无需订恶心的短信服务或者去浪费电力资源。
我从来就不是微软的拥护者,我也绝对拥护国产软件产业。但微软一个高管的话让我印象深刻,“微软对竞争对手最狠,但对用户最好”,我非常相信这句话,微软能取得今天的成就绝非偶然;还有一句话来自微软的浏览器研发主管:“虽然人们对 IE 支持 web 标准多有诟病,但别忘了 IE4 IE5 IE5.5 IE6 刚问世的时候都是当时对标准支持的最好的浏览器”。
为什么说"IM 就是浏览器?",很简单,一方面,一些简单的 web 应用开始嵌入到 IM 客户端里面,即使是 QQ 也在作 mini 页面浏览,另一方面,从微软的动作来看,它已经把 Messenger 作为一个应用平台来看待,当作当年的 IE 那样去经营。QQ/popo/uc 如果要和 msn messenger 斗,行政保护是没戏的,只能在用户体验上下功夫,只能抱着比微软更开放的心态面对竞争。Yahoo 从来没有抱怨过,多学学人家是怎么作的。如果觉得自己无法和 Yahoo 相提并论可以去看看 Firefox 是怎么卷土重来的。谁是真正的垄断者?是谁在妨碍竞争?谁在 FUD?解决好自己的问题再叫喊吧。
金山通行证
周五, 2005-09-30 09:52
两个星期前我和我弟各买了一套金山词霸 2006,第一次使用必须电脑联网,输入包装盒内的金山通行证用户名口令后才可完成注册过程,然后才能开始使用这套软件。我弟极为愤怒,因为他现在住的地方还没有宽带,难道不能上网的话这买来的软件就成废物了么?打电话给客服,呵呵很难打通,接通后客户说在包装盒上注明了这个问题,现在包装盒已经拆封不能退货的。靠,在软件盒背面最底下的字谁看啊。即使是微软也允许电话注册,凭什么金山就认为他比微软还要牛。
没关系,我安慰我弟,反正你已经有正版 license 了,不管你的电脑安装的是什么你都已经是正版用户,一张可以用金山通行证注册光盘,和网上随处可下载的 crack 没有任何区别。
windows 95 销售介质还包括 13 张软盘,到了 windows 98,Hardware Requirement 可能就开始这么写:
486 DX66
16 MB Memory
200 MB disk
4X CDROM
或许 windows 2010 版就会有这样的需求:
...
512K Internet Access
MSN Passport Account
其实金山词霸已经在这么做了.
《大败局》
周二, 2005-10-25 00:35
《大败局》是大约两年前在一次管理课上老师推荐的,终于最近买来一看,现在只粗看了前三个案例。还在继续有一搭没一搭的看着...
作者在序里面总结了这些案例里面企业家的失败基因:
1. 普遍缺乏道德感和人文关怀意识
2. 普遍缺乏对规律和秩序的尊重
3. 普遍缺乏系统的职业精神
但不论成功失败,我们所做的一切都是这个国家改革历史的一部分。所以我们更应当以敬畏,而不是鄙夷的态度打开这本书,认真去了解作者所尽力发掘的真相。
题外话:关于我们这种成王败寇的精神,在体育场上也表现的挺明显的。比如全运会的唯金牌论,总奖牌榜无人关注,得了银牌铜牌就狗屁不是。所以老百姓离体育越来越远,因为我们是有体而无育,有精神而无道德。
全球化竞争
周六, 2005-11-05 14:32
我认为自己去年犯的最大的判断失误,就是忽略了 gmail 对于中国免费邮箱服务市场竞争的影响力,gmail 是去年 4 月推出的,而我在去年 9 月份的时候还只在关注 163/sina,到去年底风云突变,市场格局一下子被打乱。
email 服务已经非常成熟,所以首当其冲。如果不再以全球化的标准来要求自己,势必会在某一天处于更加悲惨的境地。
不晓得腾讯、阿里巴巴、携程包括现在最新的所谓 web 2.0 网站有没有考虑过全球化竞争,至少看起来大家还能偏安一隅,靠本地化吃饭,但以后会是什么情况呢?
WAP 已死?3G 终端革命——Opera Mini
周四, 2005-12-01 18:18
但如今已完全不同,一方面 3G 开通在即,用户希望能在 3G 网络上无障碍的访问现在 IP 网络上丰富的应用,另一方面终端也在日新月异的发展,我们可以看到 Nokia 中端产品的 S40 第二版已经支持 XHTML-MP,第三版已经开始支持 ECMAScript. 未来的移动浏览体验必定完全超越现在的 WAP.
但传统互联网服务业者,将发现把应用程序移植到 XHTML-MP 不是那么一件简单的事情,除了要让页面符合 OMA 的这个规范外,还需要在输出的时候修改 MIME-TYPE 为 application/vnd.wap.xhtml+xml,这就是说维护工作几乎要提升一倍,才能给移动用户提供服务,但移动用户能占总用户数的百分之几呢?
W3C 给出了一个解决方案,就是专门在 css 的 media 属性中,增加了 handheld 来适应小屏设备浏览。基本上现代浏览器很容易就可以支持这种小屏设备,比如 Windows Mobile 上的 IE,再比如 Mozilla 的 minimo 而遵循 W3C 标准的开发人员只需要多维护一个 css 文件,无需任何附加成本,就能支持小屏幕访问了。
可以想象,传统互联网开发人员,会倾向于采取 W3C 标准(比如我们),而传统的移动 SP,会倾向于使用 XHTML-MP 升级现有的 WAP 应用。那样对用户来说,使用同时支持这两种标准的浏览器就非常必要了。
Opera Mobile 就是这样的产品,它不但支持上述两个标准,更包括 SSR 技术,使得传统制作的 HTML 页面能够较好的在小屏幕上进行显示,但它的问题是价格昂贵——29 USD,另外对设备的要求也高,只支持 S60 和 Windows Mobile,基本上是对目前 80% 以上的手机说 no.
现在 opera 有了一个更天才的想法,就是 Opera Mini。Opera Mini 基于 J2ME 开发,就是说可以跑在近两年所有的中高端手机上。它的原理是在一台服务器上内置 Opera 的网页处理引擎,Opera Mini 浏览网页的时候通过特殊协议向该服务器发送请求,由这台服务器将网页处理后(包括 SSR处理),然后返回给 opera mini。对用户而言即能完美的浏览各类型的网络服务,而且还降低了网络流量费用!!!
那么这个软件将如何收费呢??据说 google 将同 Opera Mini 合作。hehe,还记得 google web accelerator 么?这种 proxy 的模式很对 google 的胃口,它想掌握用户所有的浏览历史。所以或许这个软件将会免费也不一定,只要你是从 google 的网站上下载的,而显然它的 proxy 指向会是 google 的服务器。
最后透露一个消息,Opera 中国目前正在寻找合作运营伙伴,有谁希望 google 那样喜欢研究用户隐私的,可以考虑哦..而且由于它是基于服务器的服务,所以做收费运营不是不可以. 至少我现在比较动心. :)
所有的程序员都应该写 blog
周二, 2005-12-13 19:21
看看 Joel 给计算机系毕生生建议的第一条是什么——"毕业前学会写作"
学会表达,学会倾听,自如的和他人交流,这些是最重要的能力。。。类似的概念从诸如卡耐基成功学里面也能看到,只不过 Joel 这次是专门讲给开发人员的。还记得伟大的 ESR 在《如何成为一名黑客》里面是怎么说的么:学会流畅地用母语写作。尽管程序员不能写好文章的错误看法相当普遍, 但是有令人惊讶数目的黑客(包括所有我知道的最棒的)都是不错的作家。
事实上我在看简历的时候,一个家伙说他有一个 blog 比说他精通熟读 Linux 内核源代码都更抓住我的眼球。
写 blog 很难么?坚持是最难的.. 事实上对于任何行业做任何事情来说,坚持都是最难的。写 blog 不但锻炼你的写作,而且展现你的态度.
GNU/Solaris ???
周三, 2006-02-01 22:44
SUN 正在慢慢的改变自己以往的固守在单一硬件平台和操作系统的策略。随着 Intel CPU 过去几年在服务器市场上的高速增长,SUN 损失了不少市场份额,而老对手 HP 和 IBM 虽然自家的 PA-RISC 和 PowerPC 处理器也不敌 Intel 的紧逼,可是他们通过自己的 x86 服务器和对 Linux 的支持,仍然在服务器市场上保持了地位。SUN 现在也认识到如果没有一个 x86 策略,必定会完蛋,没看到连 Apple 也放弃 PowerPC 了么.
一年前,无论从哪个方面看,Solaris x86 都是一个被边缘化的产品。Solaris 是被设计在公司的核心产品 UltraSPARC 上运行的,而 x86 平台上最成功的操作系统是 Windows 和 Linux,客户为什么要购买一台安装 Solaris x86 的服务器?可当 AMD64 + Solaris 10 推出后,一切看起来那么顺理成章:市场上唯一的廉价可靠的高性能 64 位计算解决方案。因为把原来 UltraSPARC/Solaris 上的应用软件移植到 Solaris x86 上显然比把这类软件移植到 64 位的 Windows 或 Linux 要方便可靠的多。
除了推出 AMD64 服务器外,SUN 前不久提出的 OpenSPARC 计划可以称得上离经叛道。按照 SUN 的设想,独立的第三方芯片厂商可以据此改进/生产兼容的 SPARC 平台,甚至替这类公司想好了退出市场的途径——被 SUN 收购。SUN 想必从 GNU/Linux 过去十几年和 UNIX/Windows 的抗争中学习到,向 Intel 这么强势地位的公司挑战仅靠企业间的联盟合作是不够的,必须依赖社区的支持,才能在控制研发成本的同时,有效的提升产品性能和质量。
Jonathan Schwartz 现在是不是从 Linus 的言论中看到了新的机会?请注意 Linus 表示 Liunx 内核不会转变为 GPLv3 是 1 月 25 日提出的,而仅仅 2 天后,Schwartz 就发表了这篇 blog。比尔盖茨说的没错,Linux 正在侵蚀 UNIX 的市场,按照现在的趋势发展下去,Linux 统一中低端 UNIX 服务器市场是迟早的事情,甚至通吃高端市场也不是不可能。Solaris x86 虽然和 AMD64 配合得很好(还顺便打击了 SUN 最大的敌人 Intel),但长期看肯定是大大的鸡肋。IBM/HP/SGI 都在将自己在 UNIX 操作系统研发过程中积累的大量经验和代码(还包括了大量专利)放到 Linux 内核里面去,SUN 已经是远远落后了,现在好不容易出现这么一个向 FSF 和社区示好的机会岂能轻易放过。
开源社区的另外一个领袖人物,Alan Cox 也表示了对 GPLv3 的支持。我个人猜测,因为欧盟前阵子对软件专利的态度,可能导致欧洲的开源社区对软件专利/DRM这样的东东更加深恶痛绝,因此会偏向于支持 GPLv3。如果最后 the entire Solaris Enterprise System 都是按照 GPLv3 发布,将会出现一个什么样的情况。
SUN 虽然看起来是家硬件厂商,可它的软件产品线上的 OpenOffice/Solaris/Java/J2EE,正好和 MS 旗鼓相当。就各自在服务器和个人电脑的领域而言,SUN 很类似 Apple,SUN 目前也正如 Apple 前些年的步步维艰。但现在 Apple 放弃了不那么主流的 PowerPC,操作系统采纳了 BSD 的内核,大家反而对它的期望越来越高。我感觉 SUN 现在也正是在走类似的道路,希望它未来能给我们带来更多惊喜。
作为挑战者定位
周四, 2006-02-23 09:47
前天看市场营销学的 ppt,里面给老大定位为“领导者”,老二定位为“挑战者”,其他定位为跟随者。想起了《定位》奉为挑战者定位经典的 Avis 做的定位,看看这个全美租车行业第二的公司是怎么做广告的。
基本上每个行业都是由老大和老二把持的,留给后来者的空间很小。以我们熟悉的 IT 行业为例:Intel 和 AMD,DELL 和 HP,IE 和 Firefox,Windows 和 Linux,移动和联通,用友和金蝶... 能成为领导者当然最好,如果实力不济,成为老二也不错。华为的成功之处就在于它把自己和人们心目中的老大——思科拉上钩,即使公众不接触市场分析报告,但每天看到华为的新闻就能看到思科,看到思科的新闻就有华为,久而久之,自然认为华为是路由器的老二
老二的位置很宝贵,首先是获得的关注一点不比老大少,其次是人们天生有同情弱者心理。身为老二最大的不幸,就是掉到老三...身为老二最大的不智,就是向老大地位发起正面挑战.
现在免费邮件市场的老大无可争议,老二是谁?好像没有定论,如果 sohu 或 sina 觉得自己是 No.2,赶快学习 Avis 吧...
清谈 Web 开发
周三, 2006-05-31 00:10
zhanzuo.com 上的 WebIM,单纯从功能来说没有问题,但从整个系统的整合程度考虑,还是有一些不爽的地方。
主要是关于跨域的 iframe 之间交换数据的事情。由于 webim 的后台实现涉及到 c 和 php 两门不同的开发语言,而且基于伸缩性的考虑,也得出恐怕还是不同类型的服务部署在不同的系统上,并且使用不用的域名提供访问。而 Fx 在安全性上实现的更完整一些,导致 WebIM 系统上了后,以前的一些跨 iframe 的数据传输的程序必须修改,否则 Fx 无法使用。
真正好的解决方案应该是同一台服务器既能提供 WebIM 所需的持续化连接支撑,又能够做常规的 Web 开发。至此 Apache + PHP 的问题就暴露无遗,PHP 离服务器核心太远,而 Apache 本身又不好扩展,即使可以去做 Module,但是很难对进程/线程环境进行控制,更别说其中所需的开发经验和开发周期都是很高的成本。
相对来说 Application Server 能提供一个概念上更完整的开发环境,面对于上述的这种窘境,感觉 Java 或者 Python 都应该能做出相应的方案(甚至包括 Ruby?),虽然目前的 Tomcat/Zope 可能并不能达到需求。再比方为了做 URL 美化,rewrite 模块的确功能强大,但从另一个角度来说也可以认为程序再受限于它;而在 Application Server 中就可以被得心应手的控制。
断断续续用 Python 写了一些代码,从通过 com 口 连接手机发短信到创建 jabber 组件,在这个过程中感受最深的就是它的 package 机制——所需要的任何构件,似乎都已经有维护的很好的 package 在等着被人使用。
当然可能这也是 Python 和 PHP 开发者的立场不同导致的,PHP 最初的目标就是快速 Web 开发,而 Python 用户主要是对主机编程,久而久之,社区慢慢形成不同的文化。
即使是在 PHP 4 升级到 5 的这个过程里,Zend 开发者们心中考虑的竞争对手也肯定是 JSP 而不是 python/perl,因此可以看到 PHP5 语法靠 Java 更近,猜想他们是要吸引 java 的开发者转到 PHP 上。
由于 PHP 语言本身的缺陷,以及用 PHP 开发大型应用的越来越多,最近的一年,各种各样的 framework 如雨后春笋层出不穷,从 cake 到 symfony,国内廖宇雷的 Flea,以及 Zend 自产的 framework。现在连我们也在准备自己的框架了,哈哈哈
Zend Framework 可以说就是 PHP5 的 PEAR,并不是面向快速代码生成。zhb 的意见是我们仿照 Zend,目的也是提供一组库,但这里核心的是 package。其实可能也不能称之为框架,只是在 PHP 开发里面增加 package 概念,并不影响开发人员同时使用 Zend Framework.
XTech2006 上关于未来 Javascript2 的演示,package 也将是新特性之一.. 目前看,PHP6 似乎仍然不打算在核心引擎上有太大改进,不能不说是很遗憾。
最新评论