工作与社区奉献并不矛盾

caolong

工作与社区奉献并不矛盾
                                         
                                                                   Xoops国际项目负责人 姜太文
　　参与开源社区有着多种多样的形式，而本文作者作为开源CMS系统Xoops的国际项目负责人，将讲述他是如何参与到开源社区当中的，并在参与社区研发的同时，如何平衡个人本职工作与社区奉献的关系的。
　　
开源项目根据其运作模式和规模，大致可分为三类。

　　由商业公司支持的开源项目，项目的开发者和社区管理者一般是商业公司的雇员，由商业公司开放部分或全部源码，并形成一定的用户社区这类项目的代表国外有OpenSolaris，国内有互动在线的维客开源版， Mysee 公司的OpenMysee，以及近来开始在国内发展的Oracle的Berkeley Db社区等。这类项目在管理上依托于商业公司，具有较多的公司管理色彩。其中一个特色：源码是开放的，开发是封闭的。这一点在国内的一些开源项目中由于对版权协议的特别定义而体现得尤其明显，因而也突出了自由软件与开源软件的区别。
　　由个人和小规模团队组成的团队型开源项目，由于核心开放和管理团队规模较小，复杂度不高，项目的管理比较简单直接。这类项目包括近来比较流行的WYSWYG在线web编辑器FCKeditor等。
　　由开源社区自发产生和支持的社区型开源项目，无论是开发者、管理者还是用户都来自社区，以志愿者身份贡献于社区。SourceForge上绝大部分最活跃的项目大都属于这一类，比如论坛程序phpbb、内容管理XOOPS等。
　　社区型开源项目体现了最彻底的开源精神，源码是开放的，项目的开发过程是开放的，团队和社区的管理也是开放的。这类开源项目可以看作团队型项目开放式发展后的结果，但由于在团队成员的流动性、社区组成上的复杂性和管理上的松散性等因素，它们在开发管理上有其独特性。

开放源码、开放开发、开放管理

　　社区型开源项目是由来自社区的成员在志愿的基础上靠个人兴趣和爱好参与开发的，保护团队成员尤其是核心的热情显得尤其重要。然而不可回避的是来自社区的开发者在开发能力和代码风格等各方面都存在差异，如何在保证开发质量的同时使每个团队成员受到足够的尊重甚至是鼓励，这是项目负责人是要特别重视的。
　　在我们项目这几年的发展过程中，就有一些成员因各种原因热情受到打击而离开了社区，其中有极为关键的核心成员，对项目的发展造成不同程度的伤害。
　　我自己从几年前开始接触目前的开源项目，在提交的代码受到肯定后开始积极的参与各个子项目组的开发，自己的能力不断得到提高，最后成为整个项目的负责人和主开发；这其中团队成员之间的相互鼓励和交流学习起了至关重要的作用。
　　目前我们的开发团队有100多成员，其中核心开发组是流动性的，规模维持在10人左右。进入开发团队时间比较短的或是对项目了解还不是很深的，我们会鼓励其参与团队的讨论；当他的开发水平或是对项目的熟悉达到一定程度之后就可以获得SVN的提交权限，此时会特别协助他掌握对协同工具的使用和对代码质量的控制，在其提交有问题的代码后通过私下交流协助更正。这种开放式开发的方式虽然增大了工作量，但对团队的建设和长期发展是必需的。
　　同时随着项目的发展壮大，团队组织结构的复杂性增大，但却缺乏明确的监管机制。在这样的情况下，需要制定相对繁琐的管理规则，使各个项目组的工作具有一定的透明度，形成开放的管理机制。这势必降低某个特定项目组特定任务的效率，但却保障了项目长期发展的稳定性。开源社区里的合与分
　　社区型开源项目的团队成员来自五湖四海，成员之间缺少类似于商业公司的雇佣关系，团队组织结构相对松散无序。团队的存在和发展完全依靠成员之间愉快的合作关系。而作为一个国际性的开源项目，成员之间主要是通过在线论坛或是IM交流；开源项目的开发者原本就具有比较强的个性或是重视个人自由度，而不同成员之间形形色色的表达方式和高低不同的语言能力更增加了成员之间交流的复杂程度。
　　另一方面，随着国际化程度的提高，不同文化之间的差异日益缩小，特别是在开源社区，来自东西方不同国度不同行业的成员可以在同一社区内交流学习；然而文化差异带来的交流障碍依然不能忽视，特别是东亚文化的内敛矜持和欧美文化的开放直接之间的差别在某些特定环境下会激化团队中存在的矛盾。
　　我们这个开源项目最初是由来自东亚和欧洲的核心成员共同主导，其中主开发来自日本；后来团队核心中欧美成员逐渐占绝大多数，主开发与其他成员之间的交流存在某些障碍，日积月累，矛盾的激化使核心团队的协作无法正常进行，最终以投票的方式请原来的主开发离开团队。这种直接甚至于有些无情的方式，在我们看来是很难接受的，但对项目的发展确实必要的。当然这位主开发一直是受社区尊重的，他是这个项目的创始人，为了项目的发展他接受了这个决定而没有采取过激的行为。
　　不过从另一方面来讲，在开源社区项目以分支（Fork）的形式分裂发展是一种正常现象，至少不是消极的行为。一个开源项目发展到一定阶段，由于核心成员之间对长期发展规划和开发思路存在不同意见，就会有一部分成员单独成立一个新的项目，这就形成了分支。开源社区里不同分支之间不是相互仇视的敌对关系，更多的是具有一定竞争性的相互激励关系，比如操作系统里众多的Linux分支和Web CMS里众多的Nuke衍生项目等。

完美主义与实用主义的结合

　　开源项目的开发者大部分具有Geek情结，把项目当作自己的作品而不仅仅是一个产品或是商品，追求完美的设计开发，醉心于代码的精雕细刻。但是作为一个完整的开源项目的另一边，用户却更专注项目提供的代码的实用性；换句话说用户希望得到的是一个产品设置是商品，他们希望不断看到有新的版本出现，对软件新功能和性能改进的关注甚于对代码质量的关心。作为一个健康发展的开源项目，必须要处理控制好代码设计开发的质量和软件开发周期之间的平衡关系，
同时开发者要舍得牺牲自己追求完美的目标，兼顾用户对产品功能和易用性的需求。社区型开源项目产生于社区，其开发者也来自社区，用户群的存在和壮大是这类开源项目发展的基础。
　　在我们的项目中曾经发布过一个系列，以用户的功能需求为导向，追求新功能和发布速度，忽略了开发质量，给后续开发埋下了隐患，其结果是导致了整个项目的开发停滞了较长一段时间。这个系列对项目的负面影响到目前还没有完全消失。
　　在基于Web的开源项目里有一对具有对比性的例子。WordPress是目前应用最广的Blog系统，拥有大量的用户和活跃的开发团队。在它的初期版本中，在结构设计和代码实现上存在不同程度的问题，不过它为用户提供了一个简单易用而功能新颖的个人发布系统，满足了用户的需求，同时很好的控制了发布周期，逐渐吸引了大量的用户，形成了稳定的用户社区，并与开发团队形成了良好的反馈。另有一个Web CMS系统，与我们的项目差不多同时从Nuke中形成分支。他们的开发团队做了长期复杂的设计开发工作，在发布的时候已经是一个很优秀的CMS系统，但是由于开发周期过长，同时系统设计过于复杂，造成用户群的流失，已经很难再恢复良好的开发和反馈机制。

本职工作与开源奉献之间的平衡

　　与受雇于商业公司而参与开源项目的开发源不同，社区型开源项目的参与者大部分都是在自己的业余时间参与开发和管理。如果自己日常工作内容与所参与的开源项目没有太多相关性，就会存在个人和工作时间安排的问题。特别是开源项目的开发一般都是开发者个人的爱好和强烈兴趣点所在，在控制不好的情况下对开源项目的过多投入会影响到日常工作和个人生活，对参与者个人和项目的长期发展都是不利的。这个问题无论在欧美国家还是在国内，都是存在的。
　　我们项目的上一任主开发员在一年前辞掉自己的工作，全时做新版本的架构设计和底层开发；一开始他自己充满信心，团队成员也很受鼓舞。然而随着时间推移，来自经济和家庭生活的压力逐渐显现，经过大概半年时间，他已经无法继续维持高效的开发。后来由于身体和心理等方面的原因，终止了对这个项目的参与，对项目开发和团队建设的持续性带来了双重伤害。
　　我们中文社区有一位成员，从四年前开始参与项目的设计和开发工作。当时他还是初二学生，从简单的文档写作和教程开始，参与的工作逐步深入。他很好的处理了自己的学习和项目参会之间的平衡，只有在假期和周末才参与社区的工作，平时基本以学习为主。几年下来，他已经为项目提供了很多经典的文档和设计作品。
　　一个成功的开源项目不仅仅是一个软件，而是一个由开发团队、管理组织、用户社区等各方面形成的有机体。项目的成长依赖于每个方面的稳定健康的发展。

《开源》电子杂志　2008年第8期

caolong

(原文件名:1.JPG)


http://bbs.linuxpk.com/thread-12999-1-1.html

主页：http://www.linuxpk.com/