四、第三代开源协作模式 到了 MySpace、Facebook 与 Twitter 这样的 SNS 网站的兴起，开源项目的协作模式，受到 SNS 的启发，也随之进入了第三代，以 Social Coding 为核心的开发协作模式，这样的模式在以 Github 为代表的网站上，体现的最为充分，众多的模仿者也层出不穷。过去的开源项目与托管平台，都是以项目为中心来打造，而 Github 则是围绕着参与开源的人来打造。首先满足的不是项目的需求，而是个人的需求，由于对人的黏性大大增加，也使得 Github 成为近年来最具吸引力的开发社区。 围绕着 Github，一大批周边扩展服务被建立起来，构成了一个更加有活力的生态圈。而程序员们，不仅在 Github 上参与开源项目，更在 Github 上结交朋友，分享经验，增进能力。甚至这样的协作模式，还拓展到了编程领域之外，成为开放式协作的流行模式。 激励机制 第三代开源协作模式，以 Github 为代表，以 Social Coding 为精髓，这一代模式想要解决的问题，是激励机制的问题。 第一代开源协作，虽然创造了一批大大有名的项目，但事实上却是一个非常小圈子的事业。即使是最为成功的 Linux 内核开发，也不过1000~2000人。一旦人多事杂，就会出现管理混乱的现象。 第二代开源协作，虽然借鉴了很多企业界的规范管理经验，但是在事实上，却是不适应开源软件的风格的，举一个例子：在 Redmine 中存在的角色、权限、工作流之类的东西，实际开源项目使用的，却非常少。 第三代开源协作，借鉴了社交网络中的各种数值化模型，关注者数量，Star 数量，Fork 数量，Issue数量，Pull Request 数量，都在显要位置标示出来，对于开发者形成正向激励，还有很多的统计图表，形象的展示了项目的活跃程度。 开源社区，原本就有非常深厚的，统计补丁数计算贡献度的传统，这一点在 Github 被发扬光大，可以说是优秀的继承与创新。 基于 fork/pull request 的协作机制 在 Github，一键就能够fork自己的分支，然后可以跟原有的分支毫无关联，也可以非常方便的提交pull request，这就带来了更加频繁的分裂，使得分裂常态化了。 原来的开源社区，开发者修改了代码，希望能够贡献给社区，需要穿越种种障碍，如果社区不接受，最后开发者只能逼不得已，自己开一个新的分支，变成一个新的项目。 在分裂是异常的状态下，分裂是罪恶的，是不应该的，是会带来阵痛的。当分裂变得常态化，pull request 也变得常态化，分分合合，以每天N次的速度发生，恰恰因为如此，他不再是一种罪恶，而是一种健康的、向上的、以更快速度进步的模式。大家不再是在一个版本下，各自贡献，而是在各自的版本下，独立发展，想分就分，想合就合。 Pull request，从一个代码合并的方式，变成了开发者之间主要的交流方式，他们发现，最好的交流，正是通过源代码来交流，一切的讲道理，都不如用源代码来讲道理。这恰恰是程序员们最习惯，也最喜欢的一种交流方式。 围绕 Github 出现的扩展服务 较之上一代的平台，Github 提供了优秀的开放扩展机制：OAuth、API、SDK、WebHooks、ServiceHooks 等等，使得围绕 Github，扩展各种满足项目特定需要的服务，变得非常容易。 这就是从上一代平台的开源大社区，进化为“围绕 Github 的开源生态圈”。 到目前为止，Github一共支持超过170个不同的扩展服务，其中较为热门的服务有：
Github 开放平台与 API，基于 Github OAuth API，其他网站可以支持开发者用自己 Github 账号登录，并使用一些有趣的服务。 Cloud IDE，用 Github 账号登录，直接在浏览器里打开一个 IDE，编辑自己在 Github 上的开源代码 Resume Service，根据开发者在 Github 上的各种社交行为与开源项目贡献度，自动生成格式化的简历 这些扩展服务，极大的丰富了开源生态圈的内涵。 总结：社区天生就应该是社交化的，Social Coding 与开源社区，简直就是天作之和。 五、开源协作模式的新探索 Git：作为标配 目前看来，Git 作为分布式配置库的王者地位，已经不可动摇了。能够初步总结的原因，至少有三个：
Code Review：必不可少 开源社区，一直有非常悠久的 CodeReview 的历史，哪怕在最早的 mail & patch 的时代，Review 也是开源协作的头等大事。仅仅梳理 Review 的历程，也可以看到其中工具与流程的发展。 最初是邮件Review，然后是在集成平台上内置 Review 功能，或者提供更强大的 Review 插件。到Github 创新的提出 pull request，则是一种更加方便有效的 Review 模式。 与此同时，独立于集成平台的专门的 Code Review 工具，也开始发展起来：Review Board、Google Gerrit、Facebook Phabricator 是其中重要的几个代表。 Workflow：百花齐放 在Git逐步流行之后，大家发现基于Git可以选择的“玩法”实在是太多了。从最初写下一行代码，到最终出现在项目发布的版本之中，期间可以有无数的“路径”。 在 git-scm.com 官方教程《ProGit》里，提及了三种：集中式工作流、集成管理员工作流以及司令官与副官工作流。 在蒋鑫的《Git权威指南》里，又提及基于TopGit、基于 submodule、基于 subtree、基于 repo、基于 gerrit、以及 Git 与 svn 配合使用的不同工作模型。 再后来：GitFlow、Github 的 Pull Request、以及基于 Github 的 Github Flow 等等工作模式，堪称百花齐放。 为什么会出来这么多 Workflow？因为团队与项目的差别，实在太大了。现在到我们简直无法想象：那些在各种情况下都坚持使用 SVN 都开发者，是怎么熬过来的？ 当然，从另一方面来说：选择太多，也会带来另一种烦恼。 CI、CD、DevOps 从 Everything as Code 到 Everything Automation，是另一个越来越明显的趋势。前两天，我从机场出来，正好看到两个并列的广告牌，一个广告的大意是：“UPS 助您打通全球供应链”、另一个则是“中国银行助您打通全球供应链”。这真的很有意思，看来在各行各业，大家都开始在关注整个生命周期的各个环节之间的打通。 只是，在软件领域，我们会感觉到这是一种回归。毕竟，最初的软件开发，都是很简单的。在一台计算机上，自己写程序，自己编译，自己调试、运行，最后发布。既不用依赖他人，更不用等待什么流程。 随着项目越来越复杂，参与的人越来越多，我们的软件，不能仅仅运行在自己的机器上，或者需要部署到服务器上，或者需要发布到某种平台上。在协作者众多的情况下，如何分工合作？ 在开发者水平参差不齐的情况下，如何保证质量？在分工、协作、流程与质量保证的要求之下，如何提高效率？ 这些都是 DevOps 致力于解决的问题，也是 DevOps 不断得以发展的原动力。 总结：开源社区，始终在进步，Github 代表的也只是“一代”而已，新的一代协作模式，还会被创造出来的。 六、暗线：工具、习俗背后的逻辑 过去是如何？未来又会怎样？想要回答这类问题，其实需要更加深入的思考：“开源社区的协作模式，为何会变？变化背后的逻辑是什么？” 开源社区研发工具的两大目标：降低门槛，提高效率 开源社区，与普通的软件开发最大的不同，就是参与者多多益善。在《大教堂与集市》中，Eric Steven Raymond总结到：“如果开发者协调者有至少一个像Internet这样好的沟通媒介，并且知道如何不靠强制来领导，那么多人合作必然强于单兵作战”，这简直就是绝妙的预言。虽然当年的ESR也许并未预测到，基于Internet会出现那么多辅助开源的相关工具（他们当时还只有邮件列表）。 所以，开源社区一直在致力于两个看上去相反的目标：“吸引尽可能多的人，以尽可能简单、便捷的方式，参与到开源中来”、“在人多得超乎想象的情况下，依然能够保持，甚至不断提高效率”。 如何计算参与者的贡献？ 开源社区，不会给参与者发工资，因此激励是一个大问题。公平、公开、公正大计算所有参与者的贡献，以所有人都能够接受都形式，计算并公布各种排行榜，可以说是开源社区特有都「刚性需求」，因此SNS与开源社区的结合，成为必然。以后，面向开源协作的大数据分析，也一定会出现。 如何激励、吸引、回报参与者？ 计算参与者的贡献，仅仅是公平激励的基础。让激励变得有趣，变得有价值，变得有意义，则是吸引与回报参与者的不二法门。因此：游戏化的思路，会被越来越多的引入到开源社区中来。 如何保障项目质量？ 开源项目保障项目质量都最大利器，是引入数量众多都热心测试者。但是，仅仅有人愿意测试，主动、积极都帮助测试，已经越来越不够了。随着项目越来越复杂，开源项目必须逐步走出仅仅依赖肉眼、依赖人多＋运气的质量保障模式。 自动化测试、以及更加规范的Review流程，则是必然出现，而且将越来越重要的环节之一。 如何协调一致的工作？ 自由与规范，计划与变化，兴趣与责任。经常会在社区里，成为争论的热点话题。虽然在《大教堂与集市》中，ESR极力鼓吹“礼物文化远远胜过交换经济”，但是：“在一个庞大的社区，各种各样的事务都需要有人去完成，而且还不能漫无章法。” 因此：“某种调节手段、协调者与协调机制、甚至是看不见的手”之类的东西，会慢慢的回到社区。 如何在社区里平等、高效的协商？ 目前来说，依然只能是线上讨论+线下开会。虽然，很多开源社区，开始学习《罗伯特议事规则》这样的开会圣经。但是，开会依然是最令程序员感到苦恼的事情。在这方面，将来会不会出现更好的辅助工具，这方面很值得期待。 结束语 唯有变化，是不变的。开源协作模式，同样如此。惟愿我们，能够成为推起其前进的力量之一。（文章转载自庄表伟博客） |
