开源、社区、囚徒困境及其他

亚当斯密在《国富论》中写下

我们期望的晚餐并非来自屠夫、酿酒师和面包师的恩惠，而是来自他们对自身利益的关切。我们不是向他们乞求仁慈，而是诉诸他们的自利心

#开源 我是一名开源拥趸，从大学起便热衷于参与开源项目以及相关活动，无论线上还是线下。

上半年刚读完《大教堂与集市》,这本书被大家视其为开源世界的《圣经》，也的确担得起这个赞誉。

书中关于开源为何取得如此成功的论述,令人震惊。在作者的观察下，技术社区广泛接受开源几乎是理所当然。即便作为经济学上的理性人，也必然会采取这种做法。

###个人层面 作为个人，愿意参与开源，理由是充足的

• 从这些优秀项目源码中学习编程技巧
• 在这些项目基础上开展自己的工作来节省时间，提高工作效率
• 通过github与世界各地优秀程序员协作，学习协作工具的使用以及协作方式本身（这比我通过看书来学习git和其他项目管理工具效率高上数倍）
• 享受编程的乐趣，而乐趣预示着效率的峰值
• 与世界上最好的程序员一起工作，而不是与那些恰巧为他们的公司所雇佣的少数几个程序员一起工作，是一种无与伦比的享受（《大教堂与集市》）
• 个人在团体中声望的提升是志愿者活动背后的基本驱动力（同上）

###公司层面 可作为逐利的公司，参与其中（目前正如火如荼），乐意贡献自己的代码，我是十分不解的（读这本书之前），它们不怕竞争者吗？它们不怕搭便车吗？它们出于社会责任感吗？出于情怀吗？

开源运动取得今天的成就,不是因为"开源是道德正确的"或"软件闭源是错误的"，而仅仅是在不断演化的军备竞赛,闭源世界输给了开源社区，因为后者可以在一个问题上，投入比前者多几个数量级的熟练技术工时

当更多人试用你们的代码，目光聚集的地方，bug是无处隐藏的。

对于公司而言，公开源代码是利用外部资源的最佳方式。公司开源出自己代码，引起了社区的兴趣，那么对于公司的产品而言，就等同于获得了整个社区的开发力量

这个项目将不断茁壮，贡献了这个项目的公司，其内部开发者往往也是社区的核心，那么项目解决的需求/痛点首先是该公司最需要解决的。

当这种收益大过成本和风险时，诸如该技术不涉及公司业务核心，只是基础性的技术工作，联盟中不存在直接竞争对手，或是即便存在对手，但在这个项目上合作是双赢时，这些时候，公司作为经济学上追求自身利益最大化的“理性人”，便有动机这样做。

实际上，有趣的是，“你已经上船了”，公司的确可以官方申明说不参与，却无法阻止其员工参与，上边列出了个人参与社区的激励因素。社区能提高员工效率，更少的加班，更多的时间陪妹子（假设程序员是有妹子的！尽管是个弱假设），他自然有动机去求助和协作。公司说你不许参与，这种行政式的限制，除了无效，还容易把员工推向竞争对手。

拥抱趋势往往比抗拒来得明智。

参与社区的公司，在共同完善他们使用的开源项目，随着项目的完善，得到行业内的认可，最后这个项目可能成为业界首选平台，这实际上是在拓宽他们的市场，而成果往往由成员公司内部分割。

同时参与社区的开发者们，对该项目已经熟悉，他们都是公司的潜在的雇员啊，连培训成本都免了，这对于开发者匮乏的领域，尤其有利，目前edx用户便是处于这样的境地

此外公司乐于开源当然还有其他因素：提高公司对开发者的吸引力，让员工获取外部信息，提高他们的效率之类。我相信，肯定也有道德因素，一些优秀的公司出于社会责任感，与回馈社区的热心（毕竟我们用的都是mit和哈佛开源贡献的东西（edx））

我们在情感上喜欢这些乐于分享的公司，可能的话，也愿意加入他们，不过，道德是用来律己的而不是律人，我们愿意分享却无法要求别人也这样做，道德不是一种健壮的机制，尤其在商业世界，我们应当做的是让大家意识到开源许多时候在经济上也是一件理性行为。

我们目前也看到国外确实很多围绕edx的公司在贡献自己的工作成果。诸如appsembler，IONISx等。

###edx与开源 edx本身是个开源项目。
由mit和哈佛大学于2013年6月开放源代码。
截止到今天（2015.07.18），edx项目组一共建立了106个相关项目，单单为核心组件edx-platform贡献过代码的就有来自世界各地的231人，仅在主分支上就获得31583次commit，被1191个公司或个人fork。

#社区 Community>Code

这是Apache社区的口号，意思是Community Over Code（社区胜于代码）

一个开源项目的可用性，很大程度依赖于社区的生态环境，这关系到项目的潜力，项目的健壮性，采用这个项目时，遇到问题能否被及时解决，或者是否可能被解决，是否有足够数量和能力的开发者群体，这些都关系到最终用户是否愿意采用这个开源产品，以及采用这个产品的公司在发展壮大过程中，遇到的技术瓶颈能否被快速解决。

如果社区健康茁壮，参与其中的开发者的日常工作便十分轻松，遇到问题可以随时解决，参与其中的各家公司在使用该开源产品的时候，节约的远远不止是资金成本，更重要的是时间成本，后者对于初创企业的价值是不可用金钱衡量的

###edx国内社区现状 edx国内社区的现状就是没有国内社区。尽管国内edx用户已经不少，而且据我所知还在不断增加，多数是在埋头而做，重新踩一遍前人踩过所有的坑，花个一年半载的时间，才理清最基本的工作流。

目前我们能看到的热心分享的开发者并不算多，在群里也都是熟脸：热心于edx的推广的@MT兄,热心于分享技术的@竹轩兄,在群里热心于回答新手问题的@DatoChen兄，@萧峰兄，等等，在此不一一列举

我接触edx较迟（14年），在入门edx之初，除去官方社区的帮助，便是在国内的这些博客中受益最大。

平时与一些采用或决定采用edx的公司/团队闲聊的时候，他们多数期待有一个可以依赖的社区。这样可以极大降低edx用户的风险，这是是否采用这个产品的重要影响因素。

###edx社区的必要性 上边已经提了很多。再补充一些。
由于国内网络环境的特殊性，我们在国内使用edx的时候。有许多需要自力更生解决的问题。即便是在难度相对不高的安装门槛上，就让许多公司望而却步，而继续往前的小伙伴，也多是跌跌撞撞，头破血流。

更遑论本地化相关的东西：主题定制，课程拓展，课件打造(xblock)，购物车，开发数据接口，数据分析和可视化…

一些强大的功能，edx都为我们打造好了，由于依赖于S3，amazon计算组件，目前在国内多数无法正常使用，这些是本地化的难处所在。

而这些核心组件的本地化，各个公司之间并不涉及直接的竞争（都是edx公开的源码），而是一根绳上的蚂蚱。mooc平台也不只edx，尽管我认为它是最强大的，可是目前在国内，许多强大的特性拿不来用，那么原本打算采用edx的公司，转而采用外表看去更华丽的mooc平台，这是整个edx用户群的损失。

那么以上这些基础的工作，是每个公司势单力薄地都踩一遍坑呢，还是集大家的力量，一起提高平台的可用性。

###社区运作 关于社区如何运作，我最初的想法十分简单，几乎觉得这是一件不必多想的事呀，就像大多开源社区那样就好啦，集市一般，大家凭兴趣参与，自由松散，在github上，喜欢你就fork我。

可是《大教堂与集市》里也提到

显然，你不可能从零开始实施集市模式。可以用集市模式测试、排错和完善项目，但以集市模式从零开始一个项目是非常困难的。Linus没有这么试过，我也没有。开发者社区从成立伊始，就需要一个可以运行和测试的东西

而目前edx适合国内的生产版本并没有，我此前发布过基于docker的国内开发版本：发布基于docker的edx birch-1国内版本，目前已有数名开发者愿意一起来推进docker版的生产版本

社区如何起步的问题，其实我们此前都没想好，陆续面对一些质疑，才认真考虑这个问题。

这些质疑主要集中在：如何保证这样一种松散的组织能高效的运作，尤其在最艰难的初期；如何应对参与各方的利益冲突；如何保证核心开发者在受到利益诱惑的时候，不会中途跑路。

@yuquan兄大半月前同我说的openstack国内社区核心人员的聚散，令人唏嘘。这些都是不得不面对的问题。

我们还面临以下问题

#囚徒困境 这里主要谈论参与社区的各家公司之间的博弈。

我们知道，长期协作对社区参与者群体是有益的，纳什均衡趋于帕累托最优，可是对于参与协作的各方（公司），在寻求自身利益的最大化的时候（无可厚非），存在这样一种激励：获取社区成果的同时，不对外贡献。这样一来在获得到他人成果的同时，还保留了自己的私货。

这显然是协作中对每个参与公司而言的最佳策略。

这种行为，最糟糕的地方，不在于自私，而是如此一来会极大打击贡献者的意愿，最后的结果便是社区逐渐萎靡。

国外的情况有些不同，往往是大公司开源基础组件，社区去完善它，有核心团队支持，有资金支持，有热心且时间充裕的编程爱好者，如此一来激励因素变得多元。

而目前我们的境地是，edx门槛不低，又不是通用的技术，注定小众，有开发能力的参与者，多数分布在各个以此为产品的公司，纯粹的编程爱好者是十分少见的，如此一来，对公司的激励因素就很容易造成囚徒困境。

我们知道，囚徒困境的解决方案之一是重复博弈，重复博弈后的结果就是趋于合作。

那么如何形成重复博弈的局面呢

对于以上的这些问题，在与一些热心开发者以及部分公司交流中，我们大致理出了以下的框架

#基金会 初期我们需要保证事情的效率，在推出本土化的社区版之前，松散的协作方式并不合适,也许我们需要一个基金会来推动它

成立基金会的动机有很多：

• 独立于任何一家公司的控制
• 参与社区的公司，通过基金会赞助社区。社区以此做一些基础性的事务，诸如：
  • 社区购买国外测试服务器，每周定期安装edx-platform，这样各个公司不需要定期安排人员去跟踪新特性，这样节约大量资金和时间
  • 推进社区发布版，在官方发布新的稳定版的时候（好比最近准备发布的Cypress版），保持跟新，负责将edx社区版update到新版本上，愿意尝试新特性的人，只需要docker pull下来就行，复杂度都移交给了社区
  • 可以随时建立小分队，利用开发者的业余时间，对一些难啃的基础问题进行攻克，诸如数据分析和可视化，相信这些特性大家都垂涎很久了。
  • 文档翻译和汉化的问题，也可以由社区赞助来推动，目前@MT号召学生在做这件事，如果社区愿意赞助他们的话，支付的成本并不高，却可以获得实时跟进的汉化版本，而各个公司不必再为此费心
  • 此类基础性的工作还有许多，通过社区赞助的方式，让大多数公司能够从这些琐事脱身，而专注在各自的业务领域
• 对核心贡献者予以激励,防止其中途被拐跑。个人爱好者业余时间的参与若能获得相应激励，其对推动项目的意义可能大于大多全职人员。
• 如此一来，在最坏的情况下（开发者们参与热情不高），也至少能通过调整激励机制，使这件事不至于夭折。而一旦初期稳定版本形成，社区很可能就围绕它进入良性循环了

###公司为何愿意参与基金会 实际上是调整对公司的激励因素。

它们将获得如下收益：

• 优先获得社区的技术支持。支付不到一名开发者的成本，获得的往往是超过一整支优秀团队的技术回报
• 搭建国外代理服务器，用于方便国内服务器安装edx，由于资源有限，各个公司在赞助社区的同时，优先获得这些便利资源，来节约时间成本和降低开发难度
• 参与社区日常任务的起草与计划
• 作为内测成员，最先取得项目的进展和特性
• 方便各方在不涉及业务的前提下，交换经验，各自增强自己的平台，我相信在群里热衷于交流的公司已经体会到这种甜头了
• 一些可参考方案（为了克服囚徒困境），诸如每年评估参与公司对社区的贡献（赞助社区的热心已经贡献源码反馈bug的热心）来调整基金会成员
• and so on

大体先这样，大家觉得需要吐槽的地方,不用顾虑，我心里素质很好哒，发我邮件，或是在群里直接吐槽都好: )