设为首页收藏本站

LUPA开源社区

 找回密码
 注册
文章 帖子 博客
LUPA开源社区 首页 业界资讯 开源资讯 查看内容

三代开源社区的协作模式

2015-3-5 16:56| 发布者: joejoe0332| 查看: 3417| 评论: 0|原作者: 庄表伟博客|来自: 庄表伟博客

摘要: 据说,人之区别于禽兽,最大的特征在于利用,甚至发明工具。在没有任何其他工具时,我们只能借助于自己的肢体,一旦有了工具之后,我们的能力将会大大的增加。在开源社区,事情变得有些不一样。虽说开源社区也有“领 ...


四、第三代开源协作模式

  到了 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个不同的扩展服务,其中较为热门的服务有:

  • 与其他项目管理工具集成(Bugzilla,Asana, Basecamp,Redmine,JIRA,ZohoProject)
  • 与持续集成服务集成(Travis,Bamboo,CircleCI)
  • 与消息通知服务集成(Amazon SNS,Email,IRC,Jabber)
  • 与DevOps服务集成(AWS OpsWorks, DeployHQ)

  Github 开放平台与 API,基于 Github OAuth API,其他网站可以支持开发者用自己 Github 账号登录,并使用一些有趣的服务。

  Cloud IDE,用 Github 账号登录,直接在浏览器里打开一个 IDE,编辑自己在 Github 上的开源代码

  Resume Service,根据开发者在 Github 上的各种社交行为与开源项目贡献度,自动生成格式化的简历

  这些扩展服务,极大的丰富了开源生态圈的内涵。

  总结:社区天生就应该是社交化的,Social Coding 与开源社区,简直就是天作之和。


五、开源协作模式的新探索

Git:作为标配

  目前看来,Git 作为分布式配置库的王者地位,已经不可动摇了。能够初步总结的原因,至少有三个:

  • Git 与 Github 互相促进,作为全球最大也最流行的开源社区,他的标配是 Git。这也导致越来越多的开源项目,选择 Git 作为标配
  • 众人拾材火焰高,越是参与开发的人不断涌入,越是帮助 Git 发展得更快。这是一个赢家通吃的世界
  • 开源生态圈的出现,使得围绕 Git、Github 发展出一大批相关的开源项目、开源工具以及次级社区。这一现象,在 Docker 横空出世之后,再一次得到展现。


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极力鼓吹“礼物文化远远胜过交换经济”,但是:“在一个庞大的社区,各种各样的事务都需要有人去完成,而且还不能漫无章法。”

  因此:“某种调节手段、协调者与协调机制、甚至是看不见的手”之类的东西,会慢慢的回到社区。


如何在社区里平等、高效的协商?

  目前来说,依然只能是线上讨论+线下开会。虽然,很多开源社区,开始学习《罗伯特议事规则》这样的开会圣经。但是,开会依然是最令程序员感到苦恼的事情。在这方面,将来会不会出现更好的辅助工具,这方面很值得期待。


结束语

  唯有变化,是不变的。开源协作模式,同样如此。惟愿我们,能够成为推起其前进的力量之一。(文章转载自庄表伟博客


酷毙

雷人

鲜花

鸡蛋

漂亮
  • 快毕业了,没工作经验,
    找份工作好难啊?
    赶紧去人才芯片公司磨练吧!!

最新评论

关于LUPA|人才芯片工程|人才招聘|LUPA认证|LUPA教育|LUPA开源社区 ( 浙B2-20090187 浙公网安备 33010602006705号   

返回顶部