作者文章: Fenng

阿里巴巴 B2B 的失误以及错失的未来

看到微博上和各种媒体总有人将阿里巴巴 B2B 平台上的欺诈和淘宝上的假货混为一谈。B2B 上查出 0.8% 的不良商家,有人进一步问淘宝假货不止 0.8% … 这是一种什么逻辑呢?

如果不是贪图小便宜的话,在淘宝上买到假货的可能性是微乎其微的。淘宝上的所谓假货,更多的是 A 货仿品。通常说的淘宝假货,可能是根本不能用的伪劣产品(淘宝一经发现就处理),也可能是完全能用的仿造品,这是另外的话题了。

什么是欺诈?百度百科的解释是 “欺诈是指以事人发生错误认识为目的的故意行为。当事人由于他人的故意的错误陈述,发生认识上的错误而为意思表示,即构成因受欺诈而为的民事行为。”

淘宝的另一个伟大之处,是降低了消费品的成本,削弱了所谓”名牌”们的虚高价值。同样质量的东西,贴名牌标签几千块,A货一两百块,这是一场革命。尽管有些残酷。

上面这句话引发了不少质疑。所谓”革命”,都是有血腥的。可这就是发生了。这是用户在用鼠标做的投票。质疑的人都可以投反对票,在这个大潮中同样会被淹没,洪水是灾难,洪水退后会使得土地更加肥沃。

但 B2B 的问题是欺诈。所谓 0.8% 的商户,那是说这些人通过了阿里巴巴的认证体系(中国供应商、诚信通,这个体系是给阿里巴巴带来利润的),而这么多骗子卖家能进来,没人帮着做弊是不可能的。这真的动摇了阿里集团的价值观,是阿里巴巴整个集团赖以生存的东西,是底线。所以,马云必然会震怒。

(旁白:自鸦片战争以来,可能中国人和外国人打交道终于占了外国人的便宜,而且屡战屡胜,遗憾的是以欺诈这种下作的方式。另外,受骗的不止是外国人,中国人更多。)

某业内人士质疑 “CEO 和 COO 和 100 多销售人员都不理解马云价值观” ?这人应该不懂什么是价值观,价值观,理解容易,坚持下去则非常之难,尤其是面对利益诱惑的时候。阿里巴巴 CEO 和COO 等人是为了承担责任,而不是说没理解好价值观,基本的逻辑要搞懂,否则就真的管不好自己刚上市的公司了。

卫哲和这次波及的高层之前为什么不彻查骗子卖家?最可能的解释,一个是他们认为解决不掉,二来,因为这些卖家交钱给阿里,转身去骗买家,买家几乎不给阿里带来利润,卖家才是。卫哲和管理层为什么要做利润?股价才会好看。很多人会追求自己利益最大化,你应该懂的。

卫哲的做法是拍苍蝇,发现有受害者举报的就进行处理,也不排除会局部掩盖有苍蝇这个事实。人之常情。

供需合在一起才是整个生态,这个平衡不能打破。马云关心的肯定不是阿里巴巴的短期利益,所以,老马可以果断的设置纱窗,杜绝苍蝇继续往里面飞。纱窗是否也会有漏洞? 那是后话。

卫哲最大的失败不是在对待欺诈事情的处理上,而是 1688.com 突围无效,B2B 找不到下一个增长点。”无名良品” 看起来接下来也会是淘宝的产品,B2B 想拿也拿不走。

Alibaba 在上市后最应该做什么?不是”研发”新的产品,打通和淘宝的联系,而应该去做收购,大手笔的收购,整合。B2B 现有的几笔收购几乎都没什么成色。这个应该没有人提出异议吧?尝试摸索新产品的过程中,阿里巴巴 B2B 错过了外贸 B2C 这一块大蛋糕,也错失了可能的未来。

外贸 B2C 是能够讲出很好听的故事的,很遗憾,阿里动手 (AliExpress) 太晚了。

马云说,男人的胸怀是委屈撑大的。这句话后来被演绎成了”男人的胸怀是委屈撑大的,女人的也是”。一家处于风口浪尖的公司,所有的事情必然都有猜测和演绎。

卫哲的离职有其它原因么?也许有,也或许,他就是太累了。

[此为 Twitter @Fenng 上的辑录,稍作整理。旁观者的一家之言,媒体如引用,指明出处,禁止抄袭。请勿骂战。]
EOF

此文作者:, 位于 Review 分类 标签: on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

为什么 Stack Overflow 会如此成功?

最近问答类网站相当的热门。说起问答(Question & Answer)网站,很多人会第一反应想起 Quora ,实际上,这类网站中 Quora 并非做的最好的(但或许是借了 Facebook 的风头),最为成功的要数 Stack Overflow 。更为准确的说,是 Stack Exchange Network,Stack Overflow 现在只是 Stack Exchange network 的子站点而已。

Stack Overflow 由 Jeff Atwood 和 Joel Spolsky 这两个非常著名的 Blogger 在 2008 年月创建,7月小范围的进行 Beta 测试,直到 9 月份才开始公开的 Beta 测试。Joel Spolsky 大家应该熟悉,国内已经引进了他的数本大作,影响力最大的应该是《软件随想录》,此外,Joel 还拥有 Fog Creek 这家运转得不错的软件公司;Jeff Atwood 是著名技术技术 Blog Coding Horror 的作者。有趣的是,这两个人过去还 打过嘴仗。Stack Overflow 面向编程人员群体,在其推出一年之后,又推出了面向系统管理员的 Server Fault ,2009 年8月正式面向一般计算机用户的 Super User。用这个方式不断进行横向扩展,到现在为止, 旗下已经有 43 个问答站点,甚至包括英语和烹调这样的主题。到2010年年末,Stack Overflow 单个站点在 Alexa 的 Rank 是 160 ,月度独立访客超过 1600 万,每月Page View 超过 7200 万 (refer)。Stack Exchange Network 在 2010 年 5 月接受了来自 Union Square Ventures 的 600 万美元的投资,在 2010 年扩大并完善了整个团队,从三个全职工程师发展到了 20 多人的队伍,搬进了 7500 平房英尺的豪华装修的办公室(当然每个人都坐着1000美元一把的椅子)。从各项指标来看,同样作为 Startup,Quora 距离 Stack Overflow 的还差得很远,虽然拿到了更多的钱、吸引了更多眼球。

StackOverflow_vs_quora.png

Stack Overflow 为什么会如此成功?

你当然可以说是众包(Crowdsourcing)的功劳,但哪一个成功的社区能少了众包的功劳呢?如果实际一点说,不可或缺的因素我想是两个创始人的技术和社区基因。作为两个著名的 Blogger,没有人会质疑 Joel 和 Jeff 在 目标用户(开发人员)需求的精准把握。何况在上线前后,Jeff 通过技术社群又进行了大量的调研和反馈(Joel 倒是似乎第一次做 Web 项目,Fog Creek 主要是软件开发)。此前市场上已经有 Experts-Exchange 之类的老牌产品,Stack Overflow 则反其道而行之(Anti-Experts-Exchange),作为技术人员,你一定遇到过搜索技术问题到了 Experts-Exchange 网站,但是你发现问题下面并没有合适的解答,仅仅有人提问,但是没有有效的激励回答者则是没有价值的。Stack Overflow 参考 Reddit 等网站的用户激励机制,关注问题质量,其做法是通过威望值(Reputation Point) 与徽章(Badge) 建立起信任评价体系,并且做到对参与者的有效激励。我是否说过技术人员都是”好面子”的?没有,那么现在记住这句话吧。

此外,秉承独特的设计理念。Stack Overflow 绝对没有多余的或是跟风的功能(比如一些不必要的 Social Network 特性)。如果看过 Joel 的书或是订阅他的 Blog,你应该知道他是个相当偏执的家伙,尤其是在产品设计方面,他认为对的事情绝不会妥协,参见他在《软件随想录》中的《别给用户太多选择》以及《用软件搭建社区》等章节。我不知道究竟团队在功能设计上是怎么分工的,但 Joel 一定是毫无质疑的植入自己的设计理念。另外要补充的是,Stack Overflow 重新将”标签”化腐朽为神奇,也是相当值得称道的。

横向的业务扩展模式。与 Quora 综合性的问答不同的是,Stack Exchange network 采取攻其一点,再进攻其余的方式。在面向开发人员的 Stack Overflow 获得验证并且成功之后,向类似话题领域扩展;然后与不同团队进行合作,逐渐引入更多的主题(比如 Ubuntu、面向物理学的话题等等)。最后,如果把几十个话题合起来,恰好是一个庞大的 — 论坛。Stack Overflow是否重新”改造”了论坛这个古老的交流模式?

技术?是个关键因素,但不是主要因素。作为 Startup,罕见的使用微软了技术体系进行开发,但也用开源软件。观察 Stack Overflow 所用的技术方案,会觉得是个大杂烩,除了 C# 、ASP.net 、SQL Server 等,也有 HAproxy、Redis 这些解决方案。 据 Joel 说,效率和成本也还不错。扩展模式上则首选 “Scale Up”, 总之,就是有点特别。但是,用户体验相当好,这个是最难模仿的一个地方(另一个是运营套路)。

或许,Stack Overflow 的成功因素不止这些,你认为呢?

补充,来自霍炬 (@virushuo) 的观点:首先工具本身非要重要。有足够好和专注的工具。其次,种子用户非常重要。So,小范围测试的时候奠定了基础,之后始终按照这个确定的方向积累。

补充, Joel 的说法是”push for high-quality content and its decision to segment the service into well defined verticals”。

延伸参考:

EOF

此文作者:, 位于 Startup 分类 标签: on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

Facebook 如何发布代码 (How Facebook Ships Code 译文)

按:这篇 How Facebook Ships Code 提供了大量的细节信息,之前已经有朋友提供了一个翻译版本,阅读之后发现有些许错误,并且原文有更新,所以基于前面的翻译版本我重新翻译了一个(完整的)版本。一并谢过。希望这个版本对大家也有所参考。

我对 Facebook 的运作方式着迷。这是个非常独特的环境,很难被复制(这个方式并不适合所有的公司,即使有些公司尝试过这么做)。下面这些笔记来自我和Facebook的许多朋友的交谈,关于他们开发、运维与软件发布等方面。

好像很多人都对 Facebook 感兴趣… 这家公司的工程师驱动文化(Developer-driven culture)已经被公众大加研究,并且其它其它公司也在探求是否/如何实现工程师驱动文化。Facebook 的内部流程实在够神秘,当然,工程师团队也会发布一些关于新功能以及部分内部系统公开备忘,不过这些大多数是”说明”类的文章(What),而非讲述”机制”(How)… 所以,外部人员很难明白 Facebook 的创新以及如何比其它公司做到更有效的对服务进行优化。我作为外部人员尝试深入理解 Facebook 的运作,汇集了几个月来的这些观察信息。出于对信息来源的隐私保护,我去掉了特定功能/产品的名字。我又等了6个月以后才发布这些记录,所以,有些信息肯定过时了。我希望发布这些信息会有助于了解 Facebook 的管理机制如何在组织中进行决策的推行而非逐步陷入混轮…很难说这与 Facebook 的成败或是 Facebook 的产品协作相关。我相信很多面向消费者的互联网公司会从 Facebook 这个案例受益。

*非常*感谢那些帮助我整理这篇文章的 Facebook 内部的朋友们。也要感谢项 epriest fryfrog 这样的朋友,他们协助我进行对本文进行校正、编辑。

记录:

  • 截止到2010年6月,Facebook有将近2000名员工,10个月前只有大约1100人,一年之间差不多翻了一番!
  • 工程部和运维部是两个最大的部门,每个大概都有 400-500人。这两个部门人数大约占了公司的一半。
  • 产品经理(PM)与工程师的比例大约为1-7到1-10。
  • 每个工程师入职时,都要接受 4 到 6 周的 “Boot Camp” 培训,通过修复Bug 和听更资深的工程师的课程来熟悉 Facebook 系统。每次 Boot Camp 大约有 10% 的人无法完成课程而被淘汰。
  • 培训结束后,每个工程师都可以访问线上的数据库【标准课程”能力越大,责任越大” ( “with great power comes great responsibility”) 对此有阐释,另有一份明晰的”不可触犯的天条”,比如共享用户的隐私数据】。
  • [修改, 感谢 fryfrog] “Facebook 有非常牢靠的安全保障,以免有人(你可以想象内部有人有这个权限的)不小心/故意做了些糟糕的的事。如果你已经”成为”了需要别人支持的人,事由将被记录,并且有谨慎的审计。这里不允许钻空子。
  • 任何工程师都可以修改Facebook的代码库,签入(Check-in)代码。
  • 浓厚的工程师驱动文化。”产品经理基本可以被忽略”,这是Facebook一名员工的话。工程师可以修改流程的细节,重新安排工作任务,随时植入自己的想法。[评论] “本文的作者是一个产品经理,所以这个论断引起里我的注意。你看完整篇文章后会发现,很显然,Facebook 的文化实际上是拥抱产品经理的实践的,所以,不是产品经理的角色被忽略,而是,这家公司的文化看上去是想让”每个人”感受到对产品的责任”。
  • 在每月的跨部门会议上,由工程师来汇报工作进度,市场部和产品经理会出席会议,也可以做些简短的发言,但如果长篇大论的话,将如实反馈给他们的主管,”产品人员在上次会议说的太多”。他们确实想让工程师来主导产品的开发,对自己的产品负责。
  • 项目需要的资源都是自发征集的:
  • 某个产品经理把工程师们召集起来,让他们对自己的想法产生兴趣。
  • 工程师们决定开发那些让他们感兴趣的特性。
  • 工程师跟他们的经理说:”我下周想开发这5个新特性”。
  • 经理会让工程师独立开发,可能有时会让他优先完成一些特性。
  • 工程师独立完成所有的特性 — 前端 JavaScript/后端数据库,等等所有相关的部分。如果需要得到设计人员的帮助,需要先让设计人员对你的想法产生兴趣(专职的设计师很少)。请架构师帮忙也是如此。但总体来说,工程师要独立完成所有的任务。
  • 对于某个特性是否值得开发的争执,通常是这么解决的:花一个星期的时间实现,并在小部分用户中(如1%的内华达的用户)进行测试。
  • 工程师通常乐衷致力于架构、扩展性以及解决”难题”,那样能获得声望和尊敬。他们很难对前端项目或用户界面产生太大的兴趣。这跟其他业务为导向的公司可能正好相反,那些公司人人都想做客户能直接接触到的东西,然后会指着某个特定的用户体验说,”那是我做的”。在 Facebook,后端的东西,比如 News Feed 算法、广告投放算法、Memcache 优化等等,是工程师真正倾慕的项目。
  • News Feed 因为太重要了,扎克会亲自审查任何变动。这是个特例。
  • [更正, 感谢 epriest ]”所有的代码变更都要经过强制性的代码审查(比如一个或者多个工程师)。我相信这篇文章只是说 扎克并不自己审查每一个变更”。
  • [更正, 感谢 fryfrog ]”所有的修改至少要被一个人审查,而且这个系统可以让任何人很方便地审核其他人的代码,即使你没有邀请他。提交未经审查的代码,将被视为恶意行为”。
  • 工程师负责测试、Bug 修复以及启动对自己项目的维护。有单元测试和集成测试的框架可用,但很少使用。
  • [更正, 感谢 fryfrog ] “补充一下,我们是有 QA 的,只是没有正式的 QA 组而已。每个办公室或通过VPN连接的员工会使用下一版的 Facebook,这个版本的 Facebook 会经常更新,通常比公开的早 1-12 小时。所有的员工被强烈建议提交 Bug,而且通常会很快被修复”。
  • 回复:很奇怪只有很少的 QA 或自动测试 — “大部分工程师都能写出基本没有bug的代码,只是在其他公司他们不需要这么做。如果有 QA 部门,他们只要把代码写完,扔给他们就行了” [编辑:请注意这是很主观的,我选择包括这部分内容是因为这和那些其它公司的标准开发实践完全相反]
  • 回复:很奇怪,缺少产品经理的影响和控制 — 产品经理是很独立的和自由的。产生影响力的关键是与工程师和工程师的管理者搞好关系。需要大致了解技术,不要提一些愚蠢的想法。
  • 默认情况下,所有提交的代码每打包一次(周二)。
  • 只要多一分努力,终于一天会发生改变。
  • 星期二的代码发布,需要所有提交过代码的工程师在场。
  • 发布开始前,工程师必须在一个特定的 IRC 频道上候命,否则将会被公开问责。
  • 运维团队通过逐步滚动的方式进行代码发布:
  • Facebook 有大约 60000 台服务器。
  • 有9个代码发布级别。
  • [更正 感谢 eriest] “九个级别并非同轴的(concentric)。有三个同轴的阶段(p1=内部发布, p2=小范围外部发布, p3=完整的外部发布),其余六个阶段是辅助层,比如内部工具、视频上传主机等等”。
  • 最小的级别只有6台服务器。
  • 比如,星期二的代码发布会先发布到 6 台服务器上(第一级),运维组会观测这 6 台服务器,保证代码正常工作,然后再提交到下一级。
  • 如果发布出现了问题(如报错等等),那么就停止下一级的部署,提交出错代码的工程师负责修复问题,然后从头继续发布。
  • 所以一次发布可能会经历几次重复:1-2-3-修复,回到 1, 1-2-3-4-5-修复, 回到1, 1-2-3-4-5-6-7-8-9。
  • 运维团队受过严格训练,很受尊敬,而且极具有业务意识。他们的工作指标不止包括分析错误日志,负载和内存使用状态等等,还包括用户行为。比如,如果一个新的发布导致一定比例的用户对 Facebook 功能进行声讨,运维团队将查看相关指标,可能基于他们的调查停掉该次发布。
  • 在发布过程中,运维组使用基于 IRC 的通知系统,可以通过 Facebook、Email、IRCIM SMS 通知每一个工程师,如果需要他们注意的话。对运维组不做回应会被公开问责。
  • 代码一旦发布到第9级,并且稳定运行,本周的发布宣告结束 。
  • 如果一个特性没有按时完成,也没什么大不了的(除非外部依赖严重),下次完成时一并发布即可。
  • 如果被 SVN-blamed(应该指没按照规范提交代码会受到的惩罚)、公开问责(Public shamed, 示众?还是通告批评?)或工作经常疏忽就很可能被开除。”这是一个高效的文化”。不够高效或者不够聪明的员工会被剔除。管理层会在 6 个月的时间里观察你表现,”你不能适应这种文化,只能说再见”。每一级都是这个待遇,即使是 C 级别和 VP 级别,如果不够高效,也会被开除。
  • [更正, 感谢 epriest ] “人们不会因为导致 Bug 而被解雇,只有在发布他们的代码时导致问题,而他们恰恰又不在场(也找不到其他可以替代的人)”。
  • [更正, 感谢 epriest] “被问责不会导致解雇。我们特别尊重别人,原谅别人。大部分高级工程师都或多或少犯过一些严重的错误,包括我。但没有人因此被解雇”。
  • [更正, 感谢 fryfrog] “我也没有遇到过因为上面提到过的犯错而被解雇。我知道有人不小心将整个网站宕掉过。一旦有人犯错,他们会竭尽全力修复问题,也让其他人得到了教训。就我来看,这种公然蒙羞与被解雇的恐惧相比更为奏效”。

分析 Facebook 的研发文化如何随着时间演化是件非常有趣的事。特别是当公司发展壮大到数千员工的时候,这种文化是否还能够延续?

你觉得如何?在你公司里,”开发者驱动(developer-driven)文化” 将会可行么?

译者后记:很多时候是管中窥豹也是非常有趣的,而且,应该细致一点儿。另外,或许我们更应该关注为什么 Facebook 能够形成这样的文化。你说呢?

译者后记续:Facebook 能形成工程师主导的文化,应该和 Facebook 的产品形态有很大关系。毕竟 Facebook 人人都会用 Facebook … 换言之,如果是 Amazon / eBay 这样面向商业的用户的公司,业务逻辑会让工程师陷入五里雾中。

EOF
延伸阅读:Hacker News: What I Learned from Zuckerberg’s Mistakes

此文作者:, 位于 Arch 分类 标签: on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

年度技术回顾之数据库、NoSQL、开源软件

本文已经首发于InfoQ中文站,版权所有,原文为年度技术回顾之数据库、NoSQL、开源软件,如需转载,请务必附带本声明,谢谢。

InfoQ中文站是一个面向中高端技术人员的在线独立社区,为Java、.NET、 Ruby、SOA、敏捷、架构等领域提供及时而有深度的资讯、高端技术大会如QCon、免费迷你书下载如《架构师》等。

年终岁尾,做个总结吧。要说过去的这一年,起码国内的技术会议多了很多,甚至是几千块的门票也有市场了,可能也是物价上涨的副作用?像 QCon(Beijing)、SD 2.0 、微博开发者大会、TUP、UCD 年会、D2 年会、Verlocity(Beijing) 等会议,参会人都非常踊跃甚至有些会议一票难求,这是好现象,相信 2011 年有更多有价值的会议值得我们参加。再说说技术方面的事儿吧,下面是我的几个关注点。

数据库

Oracle RDBMS 、SQL Server 、DB2 等几大商业化产品似乎没什么值得一说的事件。Oracle 公司收购 Sun 之后,MySQL 前途曾一度堪忧,现在看起来 MySQL 生命力依旧顽强,只是在今年开发节奏明显慢了不少,也或许是 Oracle 在调整节奏,不过 5.5 版本的发布还是让不少 DBA 颇为惊喜,除了 InnoDB 成为默认的存储引擎之外,其他的一些特性倒是差不多都来自技术社区的反馈或是驱动,比如来自 Google、Facebook 的改进,多少对新的 MySQL 特性产生了一定影响。值得注意的是,这一年中 PostgreSQL 发展相当的迅猛,随着 9.0 的发布,引入了更为高级的复制技术,弥补了功能上的一个短板,MySQL 的命运多舛给 PostgreSQL 带来了契机,令人感慨。以前我期待的 SSD 虽说已经逐渐成熟,但似乎没有像预期的那样对数据库软件带来更大的影响。

NoSQL

去年的回顾文章中我说到 “就数据管理方式的趋势来看,NoSQL在将来会成为一个非常重要的数据解决方案”。一年之后,NoSQL 的确已经成为网络架构中一个基础的组成部分了。涌现出来的 NoSQL 相关的产品,最成功的要数 MongoDB,在新型 Startup 中颇为流行,赢得了不少创业技术团队的青睐 (比如,引领创新潮流的 LBS 先驱 FourSquare就是采用的 MongoDB ,尽管为此吃了不小的亏 ),创建 MongoDB 的 10gen 技术团队甚至在年底拿到了红杉的风险投资。除了 MongoDB 之外, Redis 的发展也不错。来自名门大厂的 Cassandra、Dynamo、CouchDB 等产品的发展倒是稍显平淡。作为 MySQL 的 NoSQL 插件出现的 HandlerSocket 的让人感到惊喜。这个技术方案会给很多应用场景带来新的契机,相信新的一年会有很多技术团队大胆的采用 HandlerSocket。其它几个 DB,似乎到现在仍没有类似的解决方案出现。

我有一个猜测是 Redis 从 VM 转向 Diskstore 模式后,有可能超越 MongoDB 么?

开源试水

Yahoo! 发布的 S4 不出意外的话,极有可能成为 Hadoop 那样有影响力的项目,对于实时计算领域会带来极大的冲击 。相信今年国内会有用户进行尝试。LinkedIn 开源的 Kafka 也有必要关注一下。针对招聘类网站会有一定的借鉴意义。

2010 或许可以称之为中国互联网企业回馈开源领域的试水之年。先是淘宝网开源平台,淘蝌蚪 (code.taobao.org) 的上线并且推出分布式 Key-Value 存储及高性能缓存系统—-TAIR,随后开放了淘宝文件系统以及 WebX 框架,足见诚意。說起 WebX,人人网也发布了自己的开源 Web 开发框架 Rose。然后有盛大创新院开源哼唱检索引擎,随后在互联网口水大战尘埃落定之后,金山的启动金山卫士开源计划,甚至百度也发布了 JavaScript 开发框架 Tangram –喊了一年终于开源了一个产品出来,颇为不易阿。而淘宝系的前端工程师们的开源项目 KISSY 发展也颇为迅猛,推荐关注。更早一些的开源项目,豆瓣的 BeansDB 在年底进行了大幅度更新,再次引起技术社区的注意。此外,射手播放器作者沈晟发布的基于MongoDB的短网址分支项目 SESO 也很有意思,希望能继续发展下去。基于 Key-Value 的开源产品多了不少,天涯也开放了一个 Memlink

以团队为单位进行的产品开源,很容易变成一个只是”公开代码”的项目,开源,还应积极鼓励技术团队成员积极的与技术社区互动,输出更多文档,用更多的案例支撑,这样才能相辅相成,才能取得真正的收益。否则的话,容易被看成为了开源这个”名”而开源,有始无终。

期待在 2011 年,腾讯能在开源领域做点表率?还是网易开源一个游戏引擎呢?只有拭目以待了。也期待国内互联网企业能积极支持开源社区,不要只顾着开源自己的那几个产品。开源比封闭更值得欣赏,心态也比姿态更为重要。

说到开源,顺便说一下”开放平台”,2009年喊着做开放平台的各大网站,现在已基本偃旗息鼓,国内这一年中也没有一家将所谓的”开放平台”真正的做起来,倒是经过一年多的铺垫,新浪以微博为基础的的应用平台已经具备了一定的潜力和规模,2011年值得期待。如果说开源,看的是心态,那么,开放平台,则看的是企业的心胸。

2011 做点什么?

眼看着越来越多的解决方案,越来越开放的技术分享,不由得让人生疑:架构是否已经不再重要?其实,构建一般中到大型的站点,已经没什么秘密技术可言(比如,还有人一度放出来”腾讯大讲堂”这样的内部信息资料,颇为戏剧性,但大家看了之后也就是新鲜几天而已,网络中更有价值的信息已经是比比皆是了)。重要的是如何用成熟的技术将产品做好,加快开发节奏,更快改进产品质量。

所以,对我自己而言,新的一年重要的还是回归基本技术,和团队一起将丁香园( http://dxy.com )的产品做好,”望着天上的星,也要看着脚下的坑”,关注新东西,更要避免因为技术冒进造成不必要的人力物力浪费,说起来容易,真的做起来,怕是也没那么简单。

EOF

此文作者:, 位于 OpenSource 分类 标签: on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.