四、第三代开源协作模式 到了 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极力鼓吹“礼物文化远远胜过交换经济”,但是:“在一个庞大的社区,各种各样的事务都需要有人去完成,而且还不能漫无章法。” 因此:“某种调节手段、协调者与协调机制、甚至是看不见的手”之类的东西,会慢慢的回到社区。 如何在社区里平等、高效的协商? 目前来说,依然只能是线上讨论+线下开会。虽然,很多开源社区,开始学习《罗伯特议事规则》这样的开会圣经。但是,开会依然是最令程序员感到苦恼的事情。在这方面,将来会不会出现更好的辅助工具,这方面很值得期待。 结束语 唯有变化,是不变的。开源协作模式,同样如此。惟愿我们,能够成为推起其前进的力量之一。(文章转载自庄表伟博客) |