开源社区的管理模式及开源软件管理 - 开源中国社区
开源社区的管理模式及开源软件管理
oschina 2012年05月22日

开源社区的管理模式及开源软件管理

oschina oschina 发布于2012年05月22日 收藏 30 评论 7

开源社区到底是怎样形成的?开源项目是怎么管理的?

在这篇文章中,我想分享一下我在参与AS7开发过程中用到的管理工具及协作流程,并谈一些对开源社区的理解。

AS7的开发流程主要涉及这样一些核心工具:

  • github – 从AS7开始,几乎JBoss的所有组件的代码库都转移到github上面。
  • Jenkins – Jenkins原名Hudson,是一个CI(Continuous Integration)工具。AS7使用它来进行代码的自动化持续测试。
  • JIRA – Jira用于根踪项目Bug,记录开发任务等。

听起来和普遍的项目管理流程没什么太大区别:几乎所有的项目都会有一个代码仓库,有一个Bug跟踪系统。(当然,可能有的项目并没有集成测试环境,也不写单元测试,质控基本靠人工-这是属于管理水平较低的项目中的情况。)

那么,当一个社区项目成规模,成熟化以后,却可以用看起来和别人没什么不一样的管理工具将项目管理得很好,这里面有什么秘密呢?我觉得差距主要体现在流程细节,工具的使用水平,测试的自动化程度这三个部分。

就JBoss的社区来讲,我想分享一些具体经验。首先我们要知道JBoss社区的Bug管理系统位于:

https://issues.jboss.org/secure/Dashboard.jspa

如果你有社区账号,可以登录进去,就可以看到这里面管着多少项目。以下是部分项目的截图:

可以看到整个JBoss社区的项目规模是非常庞大的,这里面的很多项目既做为组件形成JBoss核心产品JBoss AS7,又可以独立使用并与其它社区项目相结合,比如Hibernate,就是JBoss社区的产品之一。

这些项目的社区里面的开发人员,大部分没有交集,各自在自己的项目中进行开发。也有少数的成员同时给好几个项目贡献代码,这样的开发人员一般是 Red Hat员工(Red Hat也会看社区里面的代码的贡献量;贡献比较大的非Red Hat员工,往往会被高薪挖来成为全职)。

可能对开源社区的运作不太了解的人,会认为社区是“平的”,大家人人可以自由提交代码,有大量的人贡献代码,然后一个好的项目就诞生、成长起来了。这可能是对社区模式的最大误读了。

实际情况恰恰相反,社区的人员组成结构更像是金字塔。真正组成社区的核心开发人员,一般也就那么3、5个人,这些人往往拥有非常强的编码能力,非常 丰富的经验,他们基本上可以在项目中贡献80%~90%的代码,并且项目设计由这些人完成,他们可能同时是标准制定者和代码编写者。

以JBoss项目RESTEasy为例:

http://www.jboss.org/resteasy

这个项目的社区领导Bill Burke身兼多重身份:首先他是Red Hat员工;然后他是JCP标委会成员,参与包括EJB,JAX-RS等多个J2EE标准的制定;同时,JAX-RS标准的框架实现:RESTEasy的 核心部分几乎全部由他一人撰写,同时他参与多个社区的编码工作。而Bill Burke本人也是JBoss社区的创始人之一,在商业上非常成功,做为一名技术人,他的富有程度并不会输给Red Hat核心管理层。

再来看RESTEasy的团队核心成员:

https://community.jboss.org/wiki/ResteasyContributors

几乎都是Red Hat员工,享受公司很好的待遇,从事社区专门的工作。除了JBoss这种由Red Hat直接支持的“商业味”比较浓的社区之外,我们再看下一些由开源基金会支持的“纯正血统”的开源社区。比如Apache社区的一些项目,拿HTTPD为例:

http://httpd.apache.org/

左边有Get Involved链接,分三个部分:Mailing Lists, Bug Reports, Developer Info。

可以看到,代码开发并不是参与社区开发的全部内容。首先我们可以订阅它的邮件列表,对社区中日常工作有一个大概了解,然后可以发现问题后提交Bug给社区去解决,最后是Developer Info,这里面可以找到代码库:

http://svn.apache.org/viewvc/httpd/httpd/trunk/

仔细看下贡献者,发现人数并不太多。除了Apache基金会自己的核心成员,还有不少来自Red Hat,IBM等各家参与开发的公司的员工贡献。在Red Hat的Security Team中,我的不少同事同时也是为HTTPD贡献代码的开发人员。

因此,我们要明确这样一个概念,社区的平等,并不意味着社区是"平"的, 我参与过的所有社区几乎都是金字塔型:核心团队规模保持小而精,贡献绝大部分代码,他们往往就职于商业公司,或者在研究机构或开源组织中从事专业工作-凭 着技术狂热和大量业余时间来参与社区开发,并形成了很大贡献的人也有,但绝对不是社区里面的主流情况。

而用户群体对于社区来讲意味着什么呢?当然,代码写得再好,也得有用户群才成。因此,项目流行程度取决于用户规模,绝大部分用户群体不会贡献代码, 但会贡献使用心得,BUG报告,会帮助项目有意无意的做宣传,贡献各种各样的外围项目(比如Linux Kernel社区会收到各厂家贡献的驱动代码,这样做当然也是因为各厂家有自己的商业利益。)。因此,社区是一个生态系统,必须有阳光,有空气,有水,有 鸟兽鱼虫,它才繁荣。

而不管社区在商业化上是否成功,每一个运营良好的社区其背后管理模式有趋同的倾向。这种模式应该说首先是在Linux Kernel中的应用起来的,我们不能不说Kernel首先使用这种以Git为核心的代码开发流程非常符合实际情况,并且帮助Kernel在商业上取得了 巨大成功。

接下来我们再来看看github,为什么JBoss社区要几乎把所有的项目都迁到github上面来呢?因为它的代码管理流程非常贴合开源项目的金字塔结构。github要求使用Pull Request流程来提交代码。这个流程有这样几个特点:

  • 所有的开发人员不可以直接向项目库提交代码
  • 所有的开发人员必须将项目fork到自己的空间,在自己fork的项目里面写代码
  • 所有的代码必须以Patch的形式提交到大家共用的项目库
  • 所有提交的的Patch必须要由团队核心成员审核后方可入库(有的项目中,有这种权力的人只有一个。比如Linux Kernel,一些核心模块,比如内存管理和进程调度,只有Linus本人有Patch合并权力)

比如我要给RESTEasy项目交代码:

https://github.com/resteasy/Resteasy

首先我要将项目fork到自己的空间:

https://github.com/liweinan/Resteasy

然后clone出来做修改,将修改提交进自己的代码库,并将修改内容生成Patch交由Bill Burke审核:

https://github.com/resteasy/Resteasy/pull/35

可以看到,把代码库迁到Github,不光是改变一个代码库管理工具这样简单,随之而来的是整个流程管理的一种改变。围绕着Git的这种代码管理流 程,是Linux Kernel社区长久以来一直使用的模式,是社区管理成功经验的直接沿用。有关github的Pull Request,可以参考:

http://help.github.com/pull-requests/

接下来我们谈谈质控:在JBoss AS7这个项目中,测试过程基本上是全自动化的,所有的测试最终必须形成单元测试代码,用到的技术也非常丰富,包括:JUnit,Arquillian, Selenium等等。

这些可能和别的项目没什么区别,但AS7的质控流程不只自动化到这种程度,它在所有的“连接环节”也是自动化的。这些环节包括:

  • Github中有Patch提交过来时,自动执行项目测试。
  • Jira中的Bug报告与Github中的Patch相关联。

有了这两点,则从代码提交,到测试,到Bug跟踪记录的过程便全联系在一起了,中间环节不需人工干预。

看下Github与项目测试之间的连接,具体看下AS7的这个Patch提交请求:

https://github.com/jbossas/jboss-as/pull/1676

注意到这两条日志:

可以看到在github中有jboss-as-pull-request这个用户将这个Patch与AS7的Jenkins测试服务器中的代码进行了合并,并触发执行了测试工作:

http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-param-pull/

jboss-as-pull-request这个用户实际上是机器人,用于定时查找提交给AS7的Patch,执行合并测试工作并最终给出测试结 果。上面的地址是AS7的Jenkins测试服务器所在位置,仅能从github上面看到链接但无法从外网访问。因此我将服务器的运行情况截图如下:

有关Jenkins的使用方法,本文不准备展开讲解,有兴趣可看此篇文章: 《基于Jenkins的持续集成》

接下来我们看看github上面的代码流程是如何和Jira结合在一起的。试着打开一个AS7的Bug Report看看:

https://issues.jboss.org/browse/AS7-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:changehistory-tabpanel#issue-tabs

看到有这样一栏:

Github的Pull Reqest与Bug Report连系在了一起。这是通过JIRA与Github之间的插件完成的。下面是JIRA与Github之间相联系的流程,在Jira中进行了定制实现:

通过Jira中的Link Pull Request,将代码与Bug管理联系在了一起。

除了与代码相关的内容,社区必备的组成部分还应有文档,论坛,及邮件列表。还是以JBoss社区为例,JBoss的文档位于:

http://community.jboss.org/wiki

及:

http://docs.jboss.org/

都有专门的文档团队在维护,团队规模并不小。接下来是论坛:

https://community.jboss.org/index.jspa

邮件列表也是社区常用的沟通工具:

https://lists.jboss.org/mailman/listinfo

因此,社区的管理并不是想象中的那么“松散”。相反,社区的组织模式对管理提出了更高要求。而这些协作工具的发展,正是多年成功项目管理的经验模型。希望通过这篇文章能帮助大家对开源社区的工作有更多的了解。

原文链接:http://bluedash.net/t/i3QP12

作者:@阿男bluedash

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:开源社区的管理模式及开源软件管理
分享
评论(7)
最新评论
0
0

引用来自“悟空大叔”的评论

oschina的文章能像新浪微博那样收藏就好了

标题下面就有收藏链接的
0
oschina的文章能像新浪微博那样收藏就好了
0
标题党呀
0
这标题。。。
0
好文,收藏了
0
被标题骗了
顶部