【51CTO精选译文】Debian和Ubuntu都有一组官方授予的针对贡献者的成员角色,他们可以以参加选举或其他官方决策等方式参与到项目的治理中,同时这也是给贡献者分配工作的一种手段,大部分贡献者对他们获得的身份都感到很自豪。
在一个发行版的发展过程中,成员结构扮演中重要的角色:它定义了受项目欢迎的贡献者类型,以及项目对贡献者的期望和贡献者拥有的权利。***,这种方式形成了项目招募新贡献者的吸引力,而只有不断吸收新贡献者才能使项目保持活力。
在《开源社区是如何运作的——Ubuntu篇》中,我们介绍了Ubuntu社区委员会的组织形式。本文抛开委员会的结构不谈,将以Debian和Ubuntu对比为例,介绍不同背景的社区成员是如何进行贡献以及官方认可的。
简介
在具体介绍开始之前,先由51CTO编辑为大家简单的介绍一下Debian和Ubuntu这两个项目。
Debian是由各种开源协议下的自由软体组成的作业系统,由“Debian计划”组织维护。Debian计划并没有盈利组织支援,它的开发团队完全由来自世界各地的志愿者。Debian经常被认为是一个Linux发行版,但实际上Debian所涵盖的并不仅仅是Linux,还有GNU、FreeBSD等多种作业系统,因此Debian的官方称呼叫做“Debian通用操作系统”。
采用Linux核心的Debian GNU/Linux是后来很多Linux发行版的基础,Ubuntu正是其中最知名的一个发行版。Ubuntu的官方支持者是Canonical公司,六个月一次的Ubuntu新版本发布都是由Canonical负责,但大部分编码、分发、文档、翻译等工作都是由社区志愿者完成。
参考阅读:Debian与Ubuntu 父与子的对比哲学 | 寻找Linux的“根”
接下来,让我们进一步了解这两个项目的成员结构。
#p#
Debian的成员结构
Debian只有两种官方背景的成员角色:Debian开发者(DD)和Debian维护人员(DM)。《Debian宪章》中定义了Debian开发者的权利,而Debian维护人员则是在2007年的总决议中才做的定义。DM一职被整合到Debian官方的进程十分缓慢,而现在,自愿者在申请成为DD之前***是先申请成为DM。
DD的主要职能是提交代码以及进行自己负责的包的维护。他们具有进入Debian服务器的权限,并可以参与社区投票(比如一年一次的选举)。
DM是一个没有多少权限的角色,他们只能为那些在Maintainer或Uploaders字段里包含他们的名字、并已经被DD指定了DM-Upload-Allowed: yes标记(意思为允许DM上传)的包执行上传的工作,除此之外他们没有别的权利,而他们访问Debian资源的权限也十分有限。
除了这两个官方角色外,还有一些非官方身份的包维护人员。但他们的名字只出现在Maintainer字段,因此他们不能执行上传操作,所有上传操作都由DD完成并进行校验。如果DD信任这些非正式任维护人员,他们通常希望维护人员去申请正式的DM角色,这样可以将上传的工作移交给他们来执行,以减轻自己的负担。
要成为一个Debian贡献者,一般的途径是先成为非官方的包维护人员。在其包维护的能力和人品得到DD认可并推荐之后,则可以申请成为DM。DM任期满6个月后,则可以通过Debian New Maintainers进程申请成为一个DD,这个过程也需要其他DD的推荐。
Ubuntu中的开发者角色
Ubuntu从一开始就定义了一个官方的“Ubuntu成员(UM)”角色,它包括所有贡献者,如开发人员,文档编写人员,翻译人员,美工等等。有了这个身份后才可以参与Ubuntu社区委员会的选举,也才有机会参与Planet Ubuntu计划(51CTO编辑注:这是一个类似于集体博客的计划),此外,还可以获得一个@ubuntu.com邮件别名。
对于开发人员,情况更复杂:Wiki页面列出了不少于5种身份。最初,开发人员分为Ubuntu核心开发人员(UCD)和Ubuntu宇宙大师(MOTU),后者负责universe/multiverse部分的归档,而前者则有main/restricted部分的上传权限。不过,受到Debian维护人员角色的启发以及在归档方面面临的一些具体问题,Ubuntu修改了底层结构,以提供更细粒度的包上传控制。(51CTO编辑注:Ubuntu主要分为四大组件:Main,Restricted,Universe,以及Multiverse。Main指由Ubuntu团队支持的、在Ubuntu发行版中列入标准配置的自由开源软件;Restricted指的是Ubuntu发行版中默认配置的专有软件,主要是硬件驱动;Universe主要是来自第三方、不由Ubuntu团队负责的开源软件;Multiverse则是来自第三方的专有软件。)
Ubuntu现在可以为每个包授予上传权限,也可以用相同的粒度进行权限委托,于是就诞生了新的“单包上传者(PPU,Per Package Uploader)”身份——他们是仅对一组有限的包具有上传权限的Ubuntu成员。Ubuntu开发者身份现在包含多个不同的开发团队,分别被委托以不同包集合的上传权限。目前,已经有Ubuntu Desktop,Mythbuntu,Kubuntu和Edubuntu四个团队,每个团队可以规定自己的策略,在遵循开发者成员委员会规定的基本原则下,可以自行增加新成员。
Ubuntu贡献开发人员是一种中间身份,他还没有为成为其他开发者身份做好准备,但表达了成为Ubuntu成员的决心。
所有这些身份都可以通过类似的方法取得:创建一个Wiki页面列举你过去所做出的贡献;从与你一起工作过的现有成员那里收集证明;将你自己添加到下一次委员会会议的议事日程中,并准时参加会议。委员会成员将会查看你的Wiki页面,并根据你在会议(以及平时的开发者邮件列表)上的作答情况,以及其他人对你的意见,审核你是否能通过。
最重要的委员会成员是由社区选举产生的,而其他一般的角色是由社区委员会任命的。这些治理主体包括Canonical员工,但并没有想象的那么多人:开发者成员委员会总共有8人,其中2人是Canonical员工;社区委员会总共也只有8人,其中2人是Canonical员工;技术委员会的6个成员全部是Canonical员工,这6名成员全部由Mark Shuttleworth亲自任命,社区对此没有任何话语权,在确认投票时只能选择同意。很明显,作为Ubuntu的创始人,Mark Shuttleworth希望牢牢控制该项目的发展方向,也只有他是社区委员会和技术委员会***性成员。
#p#
Debian和Ubuntu身份对比
下表列出了这两个项目给开发者授予的权利对比。
权利 | Debian | Ubuntu | ||||
DM | DD | UM | PPU/UD | MOTU | UCD | |
通过监督进行包维护 | 有 | 无需监督 | 有 | 有 | 有 | 无需监督 |
官方的Email邮件别名 | - | 有 | 有 | 有 | 有 | 有 |
参与成员投票 | - | 有 | 有 | 有 | 有 | 有 |
参与开发者投票 | - | 有 | - | 有 | 有 | 有 |
上传权限受限于预先核准的包 | 有 | - | - | 有 | - | - |
上传权限受限于归档部分 | - | - | - | - | 有 | - |
无限制的上传权限 | - | 有 | - | - | - | 有 |
贡献者人数(截止2010-7-27) | 117 | 904 | 462 | 27 | 85 | 63 |
注解:DM=Debian Maintainer
DD=Debian Developer
UM=Ubuntu Members
PPU/UD=Per Package Uploader/Ubuntu Developers
MOTU=Master of the Universe
UCD=Ubuntu Core Developers
请注意这里的Ubuntu贡献者人数不是100%的精确,因为同一个贡献者可能拥有多个身份。
从上表可以看出,Ubuntu提供的身份选择更多,因此被官方定义了的参与者也更多,但Debian具有明显更多的开发者人数。虽然所有工作都是贡献者来完成,但最关键的权利还是只有少数人才能获得。Ubuntu贡献者中,Canonical员工居多,63名核心开发人员中有36人使用 @canonical.com邮件后缀注册launchpad帐号,他们放在Ubuntu发行版上的时间比Debian成员更多,如果能比较一下他们的工时数将非常有意思。
Debian已经意识到成员结构的缺点,就是否增设专门的打包人员也讨论过多次了,但遗憾的是每次都只是讨论讨论就结束了,始终没有拿出一个解决方案。
可能的演变
Ubuntu方面,底层结构变化最近已经结束,他们近期不再打算做出进一步变化,但他们计划让每个团队可以更好地控制与自身相关的包上传权限,这样可以让每个独立的开发者可以成为单包上传者。
在Debian方面,Debian项目列表上最近又对某些糟糕的术语进行了讨论,大部分人都赞同将“新的维护者进程”改名(建议改成“新的开发者进程”),但Debian帐号管理者Christoph Berg认为应该叫做“新的维护者团队”,他表示成员结构改革是新的维护者团队的头等大事。
自上一次努力改革已经过去两个年头了,新的维护者团队已经招募了许多新成员,新成员的表现都非常不错,刚刚闭幕的DebConf大会也就Debian成员结构改革进行了大讨论,并逐渐成为讨论改革事宜的重要集会。
原文出处:http://lwn.net/Articles/398158/
【编辑推荐】