如何管理好开源软件社区:开源项目管理方法

本帖最后由 jimila 于 2012-10-5 12:55 编辑

转自：http://www.12306ng.org/thread-911-1-1.html

原文：http://www.ltesting.net/ceshi/open/kyrjcsxw/2012/0713/205272.html

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

在这篇文章中，我想分享一下我在参与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. ... 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/ ... 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   
        　　因此，社区的管理并不是想象中的那么“松散”。相反，社区的组织模式对管理提出了更高要求。而这些协作工具的发展，正是多年成功项目管理的经验模型。希望通过这篇文章能帮助大家对开源社区的工作有更多的了解。  
        　　国内开源社区产品到现在也有七八个年头了，过去的开源社区产品比较单一，我们叫作传统论坛社区，其核心就是单一的论坛产品。站长们用论坛产品做社区也有很长时间了，开源论坛产品经历这些年头的风风雨雨，也服务了很多企业和个人站长。  
        　　当互联网在中国的不断发展，互联网概念在中国网民心中不断变化，很多模式也经历了出现、繁荣、没落的过程。从 web 1.0到 web 2.0时代的演化，甚至有人开始提web3.0的概念;从文本、bbs、blog、cms、podcast到近年热门的电子商务、sns、miniblog等等，不同概念不同模式都承载了不同时代互联网的特征和 需求 。  
        　　有很多模式在中国互联网发展的潮流中倒下了，如单一的blog模式，因为找不到更好的盈利模式，国内有几家当年极为流行blog托管站点都萎靡不振;有些模式在这个潮流中被融合和混搭了，如sns，08年红红火火，但因为用户门槛高，烧钱厉害，这种模式逐渐被混搭到其他站点上来增加用户黏度，成了站点的一个标准配置。传统论坛社区在经历这些年互联网的变迁，单一的论坛社区产品再也不能更好的承载信息和价值。新社区成了很多站长共同的需求，产品的mash up(混搭)也成了开源社区的企业必须要做的事情，此时，开源社区产品多模式化的概念由此诞生。  
        　　如何满足不同的站长在新时期互联网的大环境大市场下能更好的运营，更好的去承载信息和价值，是开源社区需要思考的。  
        　　社区产品多模式化，真正实现mash up(混搭)!              
开 源社区产品设计跟做纯粹的运营站点产品设计有很大不同。运营性站点只要考虑针对本站点设计所需要的功能和体验，但开源社区产品需要考虑不同运营定位、不同 模式(地方社区、垂直社区、商务化社区、 新闻 资讯类社区等等)下的站点需求。因此，在产品的规划和功能的设计上不会设计过于个性的功能，同时也会考虑在产 品的模式上需要多模式来支持站点的运营。  
        　　化龙巷是国内本地门户社区运营的比较出色的站点之一。这个站点的架构就是典型的站点混搭。将门户模式、传统论坛、sns进行了mash up，并融入了电子商务元素。多模式让化龙巷满足了它提炼价值信息、增加用户黏度和实现本地社区商务化的需求。  
        　　唯伊网，是一个做社会化商务的站点。这个站点在架构上同样也采用了一种混搭的模式，实现cms、bbs、sns、b2c混搭而成。这个站点是08年开始尝试社会化商务的网站，一年时间用户人数达几十万注册量，而且高粘度用户占很大一个比例。  
        　　降低站长的运营和维护成本  
        　　1、实现产品统一管理、灵活操作 
         　　开 源社区产品多模式化，必定会出现一个问题：就是模式多了，统一性会大大削弱，这就给产品设计者提出了更高的要求。怎样让运营多模式产品的站长和管理员能够 更好的去维护和管理站点信息和用户，怎样更加灵活的让站长和管理员实现灵活的操作管理。这是摆在产品设计者面前的大需求，在给站长提供开源的产品同时，让 站长能够减少运营成本这同样至关重要。做产品跟做服务是互补的，产品设计的好了，易用性强，体验友好，其实就是在做优质的服务，无非这个时候做服务是我们 做在产品里的，让站长自己去感受而已。  
        　　2、给站长更多的运营自由  
        　　过 去开源社区产品设计更多的是站长随着产品的设计来适应，单一的论坛产品在站长的需求把控上也很容易去实现。随着多模式社区产品的需求出现，站长的运营需求 越来越个性化，每个站长都希望自己运营的站点有特色从而区别于其他站点的;同时有一个现实的问题，很多站长他不会技术，没有技术团队支持，但又希望能个性 化建站。这个时候就要求在设计功能和模块的时候能给站长更多的自由。实现站点适当自定义化，例如导航的自由定义，app的自由嫁接而不仅仅存在于sns模式里。在产品的功能上给站长自由的目的是降低站长的运营和维护成本，当然给站长的自由也同样需要有一个度的把握，过于自由就等于没有自由，这反而会给站长增加了站点维护和运营成本。  
        　　强大的开放平台 
         　　目前业内做开源社区企业的开放平台也就无非开放了娱乐性app接口，开放了论坛风格规范，开放了插件规范。面对未来社区的多模式化发展，开发平台之路得走的更open。  
        　　娱乐性app要开放接口，站点实用性app也可以考虑部分第三方制作;不仅论坛开放风格规范体系，同模式的 模板 体系也可以提供开放规范，实现从多模式到超模式的延伸;  
        　　开放平台的主要目的是实现让更多的人更多的力量来为站长服务;同时让站长能够有对模式和功能有更大的选择余地。  
        　　抓住关键客户需求  
        　　目前的社区站点主要分几类，从用户基数和发帖量来区分从大到小分别为：大社区站点、门户社区站点、优质社区站点、长尾社区站点。  
        　　做开源社区产品，最忌讳的就是想什么类型的客户都能笼络到自己门下用自己的产品，这样做的结果就是产品设计的四不象，还会导致产品线铺得过广而消耗内力。  
        　　抓住关键客户，是开源社区产品需要做的一件重要事情——目标用户怎样选择。 
         　　大社区站点在国内主要有天涯、猫扑等站点。这类站点都有一个庞大的团队在支撑运营，他们也拥有自己强大的研发力量，也不大会用开源社区产品来架构。即使用了开源社区产品，也不会受开源产品的企业左右。因此，这类客户并不是目标客户，在做产品设计的时候也不必过于考虑这类客户。  
        　　门 户社区主要有两类，地方性社区和垂直类社区。这类站点每天发帖量都很大，而且一般都会有一支运营团队在支撑这些站点，盈余也很可观，以上提到的化龙巷就是 其中之一，这些站点基本都是以更少的团队力量去创造高额的盈利。这些站点同时还会是优质站和长尾站的风向标和意见领袖，它们的一举一动都会影响着小站的跟 风。  
        　　优质社区，每天会有一定的发帖量，流量也不错，是一类高不成低不就的站点。这类站点很能跟风，并没有自己独立的想法和策略。 
         　　长尾站点，就是那些零零散散有发帖，但形不成规模的小站。  
        　　从四类站点的分析来看，运营门户社区站点的站长才是我们的关键目标客户群，把这类客户的 需求分析 到位，才能抓住我们的主流客户群，才能巩固目前的市场地位。  
        　　商务化社区是未来趋势 
         　　2009年号称为中国电子商务的元年，不管是不是元年，但从08年到09年中国的电子商务的确是发展的如火如荼，再加上经济危机在全世界的蔓延，互联网的冬天到来，VC撤资等等，很多社区站点都把电子商务植入到站点中开始运营商务化社区。 
         　　这之中有交友社区，如facekoo;有本地门户社区，如19楼;有旅游社区，如米胖网;有体验式社区，如唯伊网;化妆品行业社区，如妆点网等等。  
        　　在主观上，很多站点都希望通过电子商务的引入来缓解危机的压力，有很多站点也想通过植入电子商务从而在这次经济乱世中脱颖而出。客观上，国内一些做电子商务的大站，如淘宝网、***商城、卓越亚马逊等为国内网民培养了网上购物的习惯和氛围。 

         　　记 得有句名言“潮流来了，你挡也挡不住”。在这个电子商务火红的年代里，社区商务化是趋势，这是改变不了的趋势;但与此同时，作为开源社区产品的企业，需要 冷静的去面对这一趋势，不能盲目引导站长去跟风，要对站长负责。怎样引导站长理性的去认识商务化社区的概念，让站点健康的运营下去，这是做开源社区产品的 企业需要和站长一同面对的。 

berryreload:

开源项目免费申请JIRA的license

http://www.atlassian.com/software/views/open-source-license-request