XOOPS发布有期：谁说开源不计划？
1.写在前面
近年来，开源软件在中文用户中日渐流行。尤其是今年，随着微软黑屏时代的降临，很多用户终于抛弃坚守多年的盗版方针，开始发现和探索开源软件。虽然开源进入中国已经相当长时间，可是在普通用户甚至 IT 业界人士中，仍然存在很多认知误区。这一点是所有参加开源项目的人们应该注意并努力改变的。
这些误解中，关键的错误是对开源项目管理的理解。比如，很多人以为，一个开源项目就像从长江源头开始漂流的一叶轻舟，兴之所至，漂到哪里算哪里，停留和出发都仅仅是偶然的。这种误解造成的严重后果就是对开源软件某种程度的怀疑。确实，一群人毫无计划地聚在一起、纵横捭阖地做出来的东西，听起来虽然潇洒，可是恐怕不够严谨细致。
其实，计划对于开源项目来说，至关重要。可以说，开源项目如果没有计划，必定失败。
2.为什么认为计划是开源项目最重要的？
开源项目与公司体制下的商业项目相比，在开发管理模式上缺乏强制性的组织管理机制，从而决定了开源项目计划的重要性。开源项目一般都是由来自不同地方的参与者在志愿方式的基础上进行远程管理协调和开发测试，在开发过程中缺乏面对面及时有效的交流沟通。开源项目参与者的工作需要依靠统一的计划保证进度的统一性。如果没有灵活完善的项目计划，基于松散组织的开源项目的开发必将会陷入各自为政的混乱状态，无法保障项目的健康发展。因此，如何设计并制定灵活有效的计划对于开源项目特别是有多人异地参与的较大规模开源项目来说是至关重要的，也是随着开源项目的发展壮大而不断更新的研究课题。
3.开源产品经理与其他产品经理的不同点在哪？
在商业公司或团队中，产品开发计划由产品经理负责制定并监督执行。在开源项目中，不存在“产品经理”这个职位，其功能职责一般由相关团队负责人共同完成。
商业团队的产品经理根据公司一定时期的发展策略和相关规划设计产品功能并制定开发计划，并依此配备相关人力资源，保证产品开发的进度和质量。而开源项目的项目开发计划则主要根据主开发和架构师的前瞻规划并参考来自用户社区的需求制定一个时间段的项目设计和开发计划。同时考虑到开源项目参与者组织模式和开发模式的特殊性，开源项目的计划制定更侧重于功能计划，难以对时间进度作强制规定。同时无论功能计划还是时间进度规划都要根据可用开发资源即开发者的时间可用性和不断变更的社区功能需求作及时更新调整。
4.具体来说，开源项目的计划一般应该怎么做？
一个成功的开源项目是一般由两部分组成，开源软件本身和由开源软件开发者和用户组成的社区。
具体来说，主开发员和架构师制定项目的整体开发路线图，并制定任务分解方案；核心程序员按开发路线图制定并分解核心功能开发计划；普通参与者可根据细分的计划方案制定个人开发计划，与系统开发步骤保持一致。社区管理团队制定社区管理方案和年度活动组织计划，每个功能团队根据社区年度计划制定自己团队的工作计划，与相关团队协同开展工作。
5.作为Sourceforge十佳项目的开源项目，门户管理系统XOOPS是怎么做的？
XOOPS是世界上流行的一个开源门户系统，产生于2000年底，至今已有八年的开发历史。XOOPS 系统分核心层和模块两部分，核心团队负责核心层功能的设计和开发，功能模块由第三方开发者或公司提供。
核心功能如何定义？XOOPS第一个版本的故事
与其他大部分开源项目一样，XOOPS 是由一群有共同开发兴趣的开源开发者和爱好者共同发起的，在phpnuke基础上对原系统做了重写，经过大约一年的设计开发在2001年底发布XOOPS第一个公开版本。
XOOPS社区建立的TODO list
XOOPS是一个纯社区支持的开源项目，无论是开发者还是社区管理者都是由开源参与者自愿组织开展工作。自项目成立伊始，就依托于世界上最大的开源项目管理平台 Sourceforge，采用 Sourceforge提供的项目管理工具和自己的社区网站对项目进行规划管理。普通用户在论坛或文章评论里对XOOPS核心或模块提出自己的改进建议和功能需求，由社区志愿者协助整理到Sourceforge 的功能需求列表。考虑到普通用户的使用习惯，在社区网站的Wiki里也建立相应的功能列表，便于用户查阅修改。在XOOPS各地分语言支持站也建立相应机制，由各支持站大使负责向总站汇总功能需求。核心开发团队则根据XOOPS核心开发计划和社区功能需求定期制定发布XOOPS开发路线图和详细的TODO list，并定期报告TODO list完成状况。
如何吸纳有经验的代码贡献者以及他们在项目中的角色
XOOPS的代码管理早期采用Sourceforge提供的CVS，后来改用SVN系统。XOOPS的核心代码由核心开发团队维护。主开发负责整体架构设计和任务划分，每个核心开发员根据自己的特长和时间负责相应部分的代码开发和接受并验证其他开发者提供的代码。对于长期提供核心代码的开发者，经过一定时间的培训考核后赋予相应的代码提交和维护权限，逐步成为核心开发员，并帮助其他开发员参与核心代码的开发。同其他开源项目一样，XOOPS在某些特定时间段可能会存在两个甚至更多开发版本同时存在。这种情况下，主开发员会指定某个核心开发员总体负责相应版本的开发和版本发布。
在这种自愿参与的机制下，循环往复，维持了XOOPS核心团队的稳定和不断成长。
版本升级的功能定义及裁剪
XOOPS 的发展轨迹是由大的版本和不同水平细分的小版本发布构成的。到目前为止，最新公开稳定版是2.3，内部开发版是3.0。
大的开发版本主要涉及到架构的演进和模块开发重要接口模式的调整。这类新版本的设计规划一般由主开发员支持，由核心团队成员共同讨论制定，并结合社区反馈意见作相应开发进度调整。该类版本的功能和特征主要由主开发员和核心开发团队制定并发布给社区。一个大版本的发布一般要分别经历多个Alpha、Beta和RC发布，最后发布最终版，开发周期一般在一年甚至更长。
中间版本主要在维持当前架构和模块开发接口的前提下，对功能和性能进行改进，并根据情况增加调整新功能。这类功能调整和增减大部分来自社区的需求和反馈。发布一般要经过一个或多个Alpha/Beta版，然后进入RC版。在RC版和最终版之间维持至少两周的测试反馈期，以保证社区测试的充分性。每个版本开发周期一般是三个月或半年。
小版本主要是bug修正，一般不涉及功能的调整。每个完整发布一般由一个或多个 RC 版和最终版构成。RC 和最终版间隔遵从两周的时间规则。但是在出现安全问题的情况下，核心开发团队会尽快发布补丁，不再遵从时间间隔规则。
计划管理bug和日常工作
与需求管理类似，XOOPS团队采用Sourceforge的Bug Tracker和社区网站的论坛对管理 bug 报告和修复。用户在论坛里报告XOOPS的问题，由社区志愿者协助整理到Sourceforge的Bug列表。核心开发人员会及时分析 Bug List，在 SVN 提交修正并在 Bug Tracker 里更新 bug 状态。在下个版本发布时对相关 bug 做必要的说明解释。
XOOPS开发团队还提供了安全问题报告机制，主开发员负责安全问题的分析，并及时作出修正，必要时会采用临时应急处理措施。
社区维护以及反馈的规划怎么做？
XOOPS 组织由项目负责人即主开发员和社区负责人领导下的数个功能团队构成，分别负责项目开发和社区组织管理的相关工作。团队成员根据用户意愿和精力不定期调整。
社区维护团队的工作主要以论坛维护的方式体现，志愿团队在社区帮助新用户了解学习使用XOOPS系统，并整理用户报告的问题和提出的功能需求，协助开发团队做好开发及测试规划。
6.无冕之王的开源产品经理小结
开源项目“产品经理”对开源项目的成败是至关重要的，是一个开源项目从项目策划到开发及应用顺利进行的保障。█