GitHub 第一年的 10个启示
openkk 13年前
<div id="news_body"> <p> 英文原文：<a href="/misc/goto?guid=4958331554767163981" rel="nofollow" target="_blank">Tom Preston-Werner</a></p> <p> <strong>导读：</strong>这篇博客写于 2008 年 12 月底，时至今日已经 2 年的光景。它一直在我的草稿箱里，等待完成剩余的2%。我从未发布这篇文章，因为它不在我的列表之内。对我而言它就是对过去的一个提醒，让我时刻记得那些事情。在我写下这些的时候，我们已经从 4 个人发展成为 26 个人的团队，搬进了写字楼，安装了一台饮料机，并且仍然没有从外面募集资金。在某些方面，事情已经发生了巨大的变化，但在核心问题上，还是和过去一样。想到这一点，我的脸上充满了喜悦。</p> <p> 年末的时候，准备一杯你最喜欢的饮料，调低光线，紧靠着壁炉坐下来，想想过去的 12 个月里有哪些收获。</p> <p> 对我而言，2008年里我参与了设计、开发并启动了 GitHub。建立新公司是一个非常紧张的学习过程。一年中经历了许多的失败和成功，我从中得到了很多宝贵的经验。下面就是其中的一部分。</p> <p> <strong>尽早起步</strong></p> <p> Chris 和我在 2007 年底开始创建 GitHub 的时候，大多数人只知道 Git 是一个版本控制系统。当然，对于 Linux 内核开发者而言，他们从一开始就是用 Git，但是在那个小圈子之外，很少有开发者会在日常的工作中使用。我第一次接触 Git 是由 Dave Fayram 介绍的，他既是我的好友也是 Powerset 一起工作过的同事。作为早期接纳 Git 的开发者 Dave 非常典型，在我看来他在 Ruby 社区以及之外的领域推广 Git 不遗余力。</p> <p> 回到 2007 年，那时 Git 的土壤还非常贫瘠。在1.5版本发布之后，Git 才逐渐被普通开发者采用。真正提供 Git 服务的网站也只有 <a href="/misc/goto?guid=4958331555585464575" rel="nofollow" target="_blank">repo.or.cz</a><em>。</em>我感觉它提供的服务非常有限，显得笨拙而且设计很糟糕。没有什么商用 Git 服务可供选择。尽管如此，在 Ruby 社区人们开始谈论 Git，以及它有多么的优秀。但有的时候 Git 还是有些问题。Git 的设计理念就是提供分布式的代码服务，但是如何在共享的同时保证私有代码的安全？你唯一的选择只有在 Unix 上创建一个账号，并将它作为临时的解决方法。没有理想的解决办法。</p> <p> 因此 GitHub 应运而生。然而，在 GitHub 诞生之时市场上还没有收费的 Git 服务。我们需要打开这个市场。还清晰地记得当时我是这么告诉人们：“我不期望 GitHub 会马上成功。Git 需要一段时间才会被大家接受，而那时我们已经准备就绪。”无论是我或是 Chris 都没有期待这会马上发生。那时我在 Powerset 做全职工作，Chris 是一名 Rails 顾问且收入颇丰。选择一项小众的技术并基于它及早地进行开发，我们能够在没有经营成本、没有竞争的情况下，利用业余的时间创办了一家公司。</p> <p> 译注：Rails:一个高效的 Web 开发框架。</p> <p> <strong>适应你的客户</strong></p> <p> 这是一个看上去矛盾的建议：倾听你的客户，但是不要听从他们让你去做的事情。请容许我解释一下。考虑这样一个功能请求，比如“GitHub 应当允许我通过 FTP 上传项目文档。”实际上用户真正想要表达的是：“我想要一个发布项目相关内容的简便方法。”由于用户习惯了现有的技术，因此他们会按照对于他们更加熟悉的方式提出要求。我们如果完全按照用户要求做，那么会实现某种糟糕的 FTP 服务。但如果我们看到了请求背后的真正问题，就会像现在的做法一样，允许用户通过自己的帐号向 Git 仓库发布内容。这不但实现了用户要求的功能，而且解决的方式非常简洁。</p> <p> 另一家能够基本理解这个概念的公司就是 Apple。我肯定有很多人要求 Apple 生产一款手机，但是 Steve Jobs 和他的团队知道在这个要求背后人们想要的究竟是什么：一个美观、易用、同步方便的移动设备，用上它会让你变得很酷。这就是秘诀。不要按照他们要求的去做，给他们真正<strong>想要</strong>的东西。</p> <p> <strong>享受乐趣</strong></p> <p> 我在加里佛利亚一所叫做 Harvey Mudd 的学校里上的大学。是的，我知道你没有听说过。但是如果还记得高中时期很迷信的那本由《美国新闻和世界报道》出版的《全美最好的大学》那本书（好吧，也许你并不迷信，但我是信了），Harvey Mudd 是所有工程类大学中每晚家庭作业最多的大学。对的，比 MIT 和加州理工还要多。我可以告诉你，事实的确如此。在我的记忆中，有很多关于异常复杂的弹簧、质量和阻尼系统，以及按照双螺旋方式给一个圆柱体缠上线圈的可怕经历。我们学习得很刻苦——非常刻苦。但是我们也玩得很疯狂。这是唯一能够让我们保持理智的事情了。</p> <p> 创业有点像大学生活。你和世界上最好的朋友一起疯狂地做项目，而且（通常）有很多时间。在这两种环境下，你都需要彻底放松这样才能保持平衡。筋疲力尽是一个真正危险的信号。营造一个好玩并有创意的环境，对于保持身体健康和公司的良好状态（得到好的创意）都是至关重要的。</p> <p> <strong>关注 推ter</strong></p> <p> 我发现 推ter 上的即时反馈非常有价值。如果 GitHub 网站因为某些原因变得很慢，推ter 会如实地告诉我。如果在某些国家网站不能访问（比如中国），我会通过 推ter 了解到。如果刚发布的新功能很棒，我会从 推ter 搜索的结果中受到鼓舞。</p> <p> 人们会在 推ter 上抱怨 GitHub 所有细小的 bug，通常结尾会带上令人不快的“失败”字眼。这些看起来令人厌烦，但总的看来还是值得注意。通常这些无知的 bug 会告诉你，是否应该将一个隐秘的 bug 加入待解决的列表。我们也在 推ter 上创建了一个 GitHub 账号用来回复那些负面的评论。这样的支持服务通常会让客户的心情由阴变晴。</p> <p> 如果你有 iPhone，我由衷地推荐 Fanzter 公司的 <a href="/misc/goto?guid=4958331556389087874" rel="nofollow" target="_blank">Summizer</a> 应用程序。它会让你在 推ter 搜索、查看以及回复变得非常容易。</p> <p> <strong>随心所欲地部署！</strong></p> <p> 在第一次 RailsConf 上，我有幸聆听了 Martin Fowler 的精彩演讲。在会上他对敏捷开发使用的一些聪明的隐喻，在这里我将使用它们并进行一些篡改。</p> <p> 假设要求你设计一款计算机控制的手枪，能够精确地设计到 50 米开外的目标。这是唯一的需求。一种方法是设计一个复杂的机器，能够在射击之前够测量所有可能的因素（例如风速、射击角度、温度等），然后发射。另外一个方法是设计一个简单的机器，能够快速射击并检测每次射击命中的位置。它能够使用这些信息为下一次的射击提供校正，在很短的时间内最终击中目标。</p> <p> 这两种方法的不同之处在于是否意识到子弹是很便宜的。在第一种方案完善了检测风速设备的时候，你已经用简单的武器击中了目标。</p> <p> 在 web 开发中，这个目标就是你提供的创意，而子弹就是你部署的网站以及客户提供的反馈。网站第一年提供的功能是很有吸引力的。你的客户通常可能是早期的适用者，他们乐于尝试每隔几周推出的新功能。只要新功能很好，即使产品发布有一些推迟，他们也很容易原谅。在 GitHub 的早期，我们在一个下午发布了 10 次，不断逼近那个目标。</p> <p> 第一年值得好好利用，因为一旦有重要的客户开始上门，你就得小心使用这种粗放的射击方式。在接下来的游戏中，宕机和糟糕的部署会带来经济损失，因此你需要更多地依靠工具来预测工作的方向。</p> <p> <strong>你不需要办公室</strong></p> <p> GitHub 所有全职员工都在旧金山工作，然而我们没有设立办公室。但我们也不是完全地在网络上工作。事实上，一周几次你会发现我们在北滩的一个咖啡馆里，围坐在一个由2×4米老式公告栏订起来的正方形桌子周围。虽然不如谷歌园区，但租金很便宜而且饮料非常可口。</p> <p> 这并不意味着我们没有开始寻找可以落脚的地方。恩，我们差不多快要租下了一个旧的酒吧，但最后还是没有仓促做出决定。我们一直在等待一个完美的办公室。直到那个时候，我们才会将攒下资金投入到公司中，或者落袋为安。我认为目前只要有沙发和咖啡就足够了。</p> <p> 当然，如果没有 37signal 公司的 <a href="/misc/goto?guid=4958331557190361230" rel="nofollow" target="_blank">Campfire</a> web 聊天工具以及如虎添翼的 <a href="/misc/goto?guid=4958331557998384954" rel="nofollow" target="_blank">Propane</a> OSX 桌面应用软件，这一切都不会发生。我强烈推荐这两个产品。</p> <p> <strong>通过开源项目招聘</strong></p> <p> 在 GitHub，除了 3 个联合创始人，我们还雇用了一个全职开发者（Scott Chacon）和一个兼职支持专员（Tekkub）。</p> <p> 我们雇用 Tekkub 是因为他不但是 GitHub 的最早用户之一，而且为 GitHub 上的 75 个项目（大多数为魔兽世界的插件）积极进行维护，同时在 GitHub 早期积极地给我们提供反馈。他甚至还在 IRC 频道里为大家提供帮助，仅仅因为他很享受这个过程。</p> <p> 我认识 Scott 是在旧金山举办的一次 Ruby 见面会上，他展示了自己开发的众多基于 Git 项目中的一个。Scott 比会场中的其他人更早使用了 Git。在我在自己的 Git Binding 上 fork/exec 的时候，他已经开始用纯 Ruby 实现 Git 了。对我来说形势已经非常明朗，要么他成为我最强有力的同盟，要么他就会是我最具威胁的敌人。幸运的是，我们在会后一起把酒言欢并成为了朋友。不久之后，Scott 开始为我们提供咨询并编写了 <a href="/misc/goto?guid=4958331558806011007" rel="nofollow" target="_blank">Gist</a> 的全部后台程序。那时我们已经意识到，无须任何的面试或者推荐，我们会不惜一切代价将 Scott 招至麾下。我们已经了解所有需要知道的信息，并毫无保留地给他 offer。</p> <p> 这一次我们得到的经验是，通过考察候选人过去的表现而不是预测未来的表现，会更简单且风险更低。由此得出的一个结论是：如果你打算加入创业公司（为打算创业的人工作），可以在相关的社区参与开源工作。用你的时间和编写的代码证明你就是这份工作的最佳人选。</p> <p> <strong>信任你的团队</strong></p> <p> 没有什么比事必躬亲的上司更让我痛恨的了。5年前，当我还在做图形设计咨询的时候，我有一位客户几乎就是柏拉图式的事无巨细。他坚持让我到他的办公室里，坐在小黑屋里用一台破旧的 Mac 设计图标、目录，并给泳衣模特照片润色（这部分工作并不是那么糟糕！）。当我在干活的时候，他会从我的面前飘过并厉声道出他的建议。“太红了！你不能把这些字弄的更小一点吗？马上把这些瑕疵去掉！”这些几乎让我陷入疯狂。</p> <p> 这位客户一般在早上会给我安排工作，然后离开去忙他的生意，6个小时以后回来。我会把他交代的内转换成 Photoshop 操作，并用 2 倍于机器人的速度弄出更好的设计。他这样的安排，不仅忽视了我的设计能力，同时也是对时间和才能的浪费。</p> <p> 事无巨细地领导风格是一种信任的缺失。治疗这种症状的方法就是，聘请专家并且相信他们的判断。在一家创业公司，事必躬亲地管理会打击士气，而给与信任会鼓舞团队。当一个团队中的人才互相信任并决心做出优秀产品的时候，会取得令人惊讶的成果。</p> <p> <strong>你不需要风险投资</strong></p> <p> 最近有很多关于风险投资市场正在发生变化的文章。我不打算假装成这个问题的专家，但我可以肯定像我们这样的 web 创业公司不需要任何外部资金就可以成功。得出这样的结论，因为我们没有从投资者那里拿过一毛钱。我们开始创办这家公司的时候只有几千美元，在向大众开放的时候就开始盈利并对注册用户收费。</p> <p> 最后，每家创业公司都是与众不同的，唯一能够确定外部投资是否有意义的人就是你自己。也许有成千上万的理由会让你寻找并接受投资，但你必须确保这会将你的利益最大化，因为很有可能你并不需要这么做。我上一次离职的理由之一就是“我的收入不会再增加了”。如果我们接受了投资，我再也不能说出那样的话。</p> <p> <strong>尽可能地开放源码</strong></p> <p> 为了让 GitHub 能够操作 Git 仓库，我创建第一个 Ruby Git binding。逐渐的，这个库逐渐完善，接着我们面临一个选择：我们应该将它开源还是保持私有？这两个选择都各有利弊。选择开源就意味着</p> <p> <strong>注意：本文到此结束，时至今日还没有新的内容。我打算在不久的将来写一篇关于 GitHub 中的开源哲学。我肯定解开这个悬念的时候肯定会让你大吃一惊！</strong></p> <p> 编译：<a href="/misc/goto?guid=4958185140659301754" target="_blank">伯乐</a>在线 – <a href="/misc/goto?guid=4958327305355149094">唐尤华</a></p> </div>