来自CSDN的文章，作者zihui.

一个真实的案例,可以说是一个具有开源特点的项目管理过程,对于开源的项目运作,是有借鉴作用.更可贵的是,他记录的非常完整和全面.

【【开源尝试】】
　　2004年4月至8月，作者有幸进行了一次开源开发，期间感受颇多，在此撰文向大家做一简单介绍我们开源项目的前前后后，并穿插很多开源相关的知识，以飨读者。

【背景】
 在教育网，尤其是高校的学生中，北大天网文件搜索引擎（旧称北大天网FTP搜索引擎）大概是使用频率最高的文件搜索引擎了。它是一个运行了多年的较成熟的文件搜索引擎，每天有大约30万的查询量。我有幸从它的主要开发者陈华手中接过它，作为唯一的维护、开发人员。但系统从2000年至今，经过多次的增删改，结构相当复杂，加之秉承了高校项目的一贯问题——文档不全、代码可读性较差，致使后续维护和开发相当困难。
　　人力问题大概是首要的问题，我首先向负责老师申请学生和我共同开发，但由于实验室本身容量的限制，已经不可能有其他人和我共同工作了。或者说，封闭

开发这条道路已经被堵死了。
　　不得已，我只有另择它途。如果从外面吸引人，传统的开发模式已经不适用了。很快，“开源”这条路映入了我的脑海，也许这是一条通往成功之路。

【开放源码项目的开发模式】
 光有目标是不够的，还需要脚踏实地，我决定先学习前辈的经验，看看开放源码项目的具体开发模式是怎样的。
 现有的成功的开放源码开发模式主要有：
1. 小型开源软件开发模式
2. 中型开源软件开发模式
　　其特点为拥有3-5 名核心维护人员，参与开发的人员10人-40 人之间，采用CVS 进行代码管理，通过maillist/irc进行开发交流，有明确的开发计划和日程。

用户提出的错误报告和修正数量很多，并且有一些分支产生。
3. 完全封闭的商业Open Source软件
4. 比较封闭的大型Open Source软件的开发
5. 由商业软件转化过来的大型Open Source软件开发.
6. "独裁"式的大型Open Source软件的开发.
7. "民主"式的大型Open Source 软件的开发.
  在了解、比较了各种开发模式后，考虑到自己项目的特点，决定采用“中型开源软件开发模式”，并根据我们自己的特征作适当调整。

【开源项目的风险】
　　“风险是项目管理的最大敌人”。
　　确定了开发模式，又了解到中国开源的现状，我决定首先把风险一一列出，防止项目半途夭折。
　　和一般的项目相比，开源项目主要的风险有：
　　人员交流：由于开发人员往往不在同一个办公室，因此交流会成为最大的障碍。网络的普及在一定程度上缓解了这个问题。“但同时也在一定程度上掩盖了交流的风险”。
　　工作时间：由于开源项目的开发人员都是志愿者，大家是在业余时间进行开发，因此开发时间很难保证，更要为中途被迫离开项目组的坏消息作准备。
　　开发热情：没有资金、没有设备、没有薪水，甚至没有一杯水，完全凭借一腔热情，靠的住吗？这也是一个问号。
　　开发人员的水平：在一般人眼中，开源项目的开发者，尤其是国外的开源项目的开发者，往往都是经验丰富，编码水平甚高，擅长Linux开发的高手，甚至是编码的天才。但我们招的到这样的人吗？什么人愿意参与项目开发呢？
能找来志愿者吗？
 究竟会不会有志愿者来参与我们的项目呢？我想起我曾经在较早的时候做过一次调查报告。调查分成7天，每天一个问题，最后一个问题是“你是否会作为志愿者参与我们的项目，并选择何种工作？”这个问题当时共485人参与回答，结果为：
参与美工（9.1%),网页设计（16.2%),栏目管理（16。2％），编程（18。3％），运作与策划（29。9％），不参与（10。2％）
　　但考虑到本次投票时长和前6次一样，（约24小时），但得到的票数却是最少的，对于这次减少的票数，初步分析是他们默认选择为“不参与”，因而没有投票

，因此我们将对上面的数据重新整理。上面几次投票的平均投票用户数为1281 人次，考虑到前一天投票数量已经有所降低（850 人），我们不妨假设这次为1000 人。而这1000 人中没有投票的用户的选取均为“不参与”，则数据重新整理为：
参与美工（4.5%),网页设计（8.1%),栏目管理（8。1％），编程（9。2％），运作与策划（15。0％），不参与（55。0％）
　　可以看到，虽然多数人并不愿意成为志愿者（约55％），但仍有相当多的人愿意参与天网文件搜索引擎的开发、运作，考虑到天网每天仅30万的查询量，这个是一个非常可观的数字了。由此看来，招募志愿者本身应该没有什么问题。
　　究其原因，为什么会有这么多人愿意成为志愿者呢？我想可以归纳为以下三个原因。
1． 想参与开源项目的开发。如果我们招募志愿者，我们必定会以开源项目的方式运作，国内虽然成功的开源项目不多，但有热情的人员还是很多的。
2． 被天网本身吸引。这个不是大话，在教育网内，天网确实知名度较高。比如在我们的这次调查中，就有一个署名wb_fly@sohu.com的用户留言说“ 天网带给我很多的方便和乐趣，我非常愿意为天网做事。”
3． 想通过这次开发工作提高自身。我不了解国外的同行持这种想法的人多不多，不过这确实是一个合情也合理的动机。

【人员招募方式】
　　说干就干，确定了开发模式、分析了风险后，决定立即启动我们的开源项目的第一步工作：人员招募。
　　开源项目的人员招募通常可以采用以下方法：
1． 从身边入手，拉上几个志同道合者。这个方法简单实用，在小的开源项目中还是不错的方法。而且同身边的人一同开发在交流合作上都较方便。但是项目较大，人较多的话往往就不那么试用了。
2． 通过sourceforge等开源网站公布自己的项目计划，吸引开发者。如果自认为项目有足够的吸引力，不妨考虑完全通过网络开发，通过一些提供开源开发支持的网站进行开发。在中国有“共创软件联盟”http://www.cosoft.org.cn/ 等网站。不过采用这种方法要确保你的项目有足够的吸引力，否则也许会发生过了一两个月还没有人报名的尴尬事情。
3． 自己撑起一面大旗，招兵买马。不过项目已经有了足够的影响、不是从头做起，并且有足够信息的话，也完全可以亲自发布广告，招兵买马。
 考虑到天网搜索引擎本身的的吸引力，我决定自己动手。
　　首先我通过北大的一个linux社团进行一场类似“宣讲会”的报告。报告在2004年4月10日进行，在简要介绍了文件搜索引擎技术之后，重点介绍了新的开发计

划以及招募活动。报告本身很成功，吸引了相当多的听众。但是报名的人却少的可怜——只有人。现在分析，我认为听众多半是希望了解天网文件搜索引擎的技术，而非希望参与项目开发。
　　一招不灵，另换一招。我直接在我们的大本营——天网文件搜索引擎上面做了一个链接广告说明开源项目一事，并安排了约10天的报名时间。网上的报名果然相当踊跃，而且各个省市、各种背景的人都有。很快就有超过100人报名，主要都是应聘开发人员。
　　最终的招募情况是：核心开发人员5人，美工1人，项目顾问2人，法律顾问1人，由于对于一般开发人员的人数需求和工作内容都尚未明确，因此没有确定一般开发人员的名单。实际招募开发人员还是以学生为主。
　　在人员招募的过程中，我首先招募了项目顾问，然后才开始开发人员的选取。考虑到前面的风险分析，为了规避“人员交流”的风险，我们重点招募了能够见

面的北大学生。最终五名核心开发人员的分配为：北大学生3名，北京学生1名，外地学生1名。这样，即使在最坏的情况下：即如果只有能够当面交流的开发人员参与了开发，仍然有60%的开发人员的保证。招募的五名核心开发人员对搜索引擎的了解都非常有限，技术水平属于中上。
　　在后续的开发中，随着具体开发工作的需要，又有多名开发人员加入，最多时整个项目组达到了16人。

【基本运作方式】
 前面已经说道，我们招募了项目顾问。我们的基本运作方式也是通过和项目顾问共同商量确定下来的。这让我在项目开始前已经感受到开源的作用了。
 下面是我们的开发模式（这里暂且称为“千帆开发模式”）与标准的封闭源码开发模式和标准的开放源码开发模式的比较。可以看出我们是在一般的开放

源码开发模式的基础上又借鉴了部分封闭开发模式的内容。

千帆开发模式

开发队伍组织模式：
分散开发人员通过Internet组成开发队伍发布版本时间:
固定时间发布，但有模块完成时尽早发布模块提供源码对象：对公众发布负责测试部门:
无专门测试部门管理手段：
按照项目生命周期管理，强调协作，自愿参与
　　
　　为了加强交流，对于能够到会的人员每周进行一次项目例会，不能到会的则参与每周一次的网络会议。项目的第一次例会在4月28日启动，原计划在8月15日结束，以周为时间划分，共计16周，

【第一次大会】
　　在4月27日下午，也就是项目启动的前一天，我紧急联系了刚刚招募的在天津的美工王志寿，希望他能在第二天下午之前完成我们的项目网站，好在第二天正式启动我们的项目团队。我现在还清楚的记得，当天下午我通过QQ和他进行沟通，简单表达了自己的想法后，他在几个小时后，也就是当晚八、九点钟的样子，就给我展示了网站的首页——一个看上去很成熟的站点首页，并于第二天按时发布了我们的网站。如果这个工作由我个人来做，可能也能够完成，但质量一定远远不如他，并且一定会影响第二天的会议准备。
　　那边是美工在忙，这边我也赶紧找来另一个成员陈朝岩，他帮着我们很快假设好了我们的服务器——一台装有Redhat 9 Linux的服务器。
　　通过大家的不懈努力，我们于4月28日发布了我们的工作网站，并于当天晚上召开第一次项目会议。在这次会议的筹备过程中，大家就已经深深感受到了开源的魅力——一群素不相识、甚至不能谋面的人因为开源而聚到了一起，并为了共同的目标而兴奋的工作着。
　　第一次会议大家兴致很高，在各自完成自我介绍后，我向大家畅想了我们美好的“前程”，大家也都谈论了各自对于新系统的一些想法。会后大家合影留念。

【多种开发方法并行】
　　项目团队建立起来后，就开始了正式的团队运作。
　　为了规避风险，我们最初曾经考虑全部严格遵循软件工程，并借鉴了TSPi（小组软件开发过程）的思想。整个开发周期计划从4月28日至8月15日，共16个星期。项目采用迭代式开发，分为两个阶段。
　　但很快发现一个现实，面对一个松散的开源团队，单纯的较严格开发方式反而并不高效，我们便调整了开发方式。我们在项目总体采用两阶段的需求、设计、实现、测试的基础上，根据功能的需要，在某些独立模开的开发上采用下面两种并行的开发方式。
　　一、对于需求非常明确、有相当的把握开发成功的成熟的独立模块，可以交付给熟练的开发人员独立开发，开发人员可以按照自己喜爱的开发方式，只要在规定的时间内完成开发即可，不必严格遵循软件工程的各个流程、但要保证开发的模块的质量。
　　二、对于无把握的或需要探索的新功能模块的开发，由于风险很大，也独立提出。要求本模块的开发人员在较短的时间内完成功能演示的开发。因为只是功能演示，对其代码质量不进行要求，但需要能够明确模块的实现方法，便于真实系统的应用。
　　这样，整个开源团队就存在这三个并行前进的三条线路：遵循软件工程进行迭代开发的主团队、进行成熟模块开发的小分队、以及进行新功能尝试的探索的探险队。

【工具的使用】
　　对于通过网络协作开发的开源项目，协同开发工具自然也不可少。现在想来，我们用到的工具还真是相当的多。
　　网站：首先建立自己的网站，确保团队内外的人都能明确了解项目的进展，这是整个项目对外的窗口，我们的美工在第一时间完成了一个精美的网站，一下子给人以高起点的感觉。
　　版本控制工具：由于代码量越来越大，在开发中，每个成员都要保留一个副本，在开发中非常容易引起冲突。因此版本控制工具是非常必要的。CVS是个可以用在小组协作环境下的源码版本管理系统。同类的软件有AT&T的SCCS（Source Code Control System），还有PVCS等。CVS是用得最为广泛的，因此我们选择了它，它从技术上可以提供如下功能：同步修改、维护不同的版本、查找历史记录。
　　开发工具：因为项目较大，人员较多，我们使用的开发工具也不少。
　　建模：稍大的系统就需要一个全局的规划，这方面我们使用了Rose和Visio。
　　代码开发：vi, emacs都是常用的linux下的工具，eclipse +CDT也是一个不错的选择，magic c++是我们发现的另一个有点“神奇”的工具，它可以让你在windows下通过类似VC的界面来编写、调试linux下的程序，在我们这次开发中也得到了广法的应用。
　　文档建立工具：doxygen，我们发现是一个不错的文档建立工具，可以通过分析源码中制定的标记建立多种不同形式的文档。
　　代码格式化工具：这方面虽然工具不少，但我们还没有足够的精力去挑选。唯一使用的工具ident，居然把我们的源码修改错误了，造成编译无法通过。
　　编译、调试工具：我们选择了应用最为广法的GCC, GDB。
　　发布工具：随着项目的进行，也许需要发布了，autoconf，automake，tar是必须的。rpm也是现在一个比较流行的发布工具，也可以考虑。
　　Bug管理：可以考虑使用Bugzilla，不过我们还没有使用任何bug管理工具。
　　除了上面说的这些开发相关的工具，我们发现最重要的其实还是下面这些用于交流的工具：
　　空气：“空气是交流工具吗？”，它是我们当面交流时声音传输的媒介啊！没错，经过实践，我们发现当面交流依然是最重要、最高效的交流工具。所以只要有可能，还是当面交流吧，而不必要通过QQ去和身边的开发者说悄悄话。
　　即时通信工具：如QQ，MSN等，它几乎已经成为第二高效的交流方法了。
　　此外，网络语音聊天工具，论坛，短信息，邮件列表，网络会议，wiki，电子邮件等几乎全部能够想到的方式几乎都被我们采用了。而且事实证明——这依然毫不过分，交流是最重要的！

【第一个模块的发布】
 项目只运作了不到三个星期，我们“进行成熟模块开发的小分队”的谢翰就发布了第一个模块——TCP端口扫描模块，用于搜寻提供FTP服务的主机的扫描器。这个模块采用了新的方式，把原先需要1个月才能完成的工作提高到只需要几个小时！
 第一个模块的发布大大提高了整个开源团队的士气，我们这个项目在民间的影响力也初步体现。

【问题不断】
 项目继续进行，第三周很快过去，没有什么特别的事情发生。随着第四周的到来，相当多的成员面临期末考试的压力，只好停止开发工作。整个项目在第四周的前几天基本上出于停滞状态。我决定改变这个现状，临时招募了几名没有期末考试压力的成员，但因为是半途加入，在很短的时间内工作开展的又不是有效。
 一个百无聊赖的第五周结束后，发现在核心开发人员缺席的这段时间内项目进展的非常缓慢。随着第六周的到来，多数开发人员已经结束期末考试，我们的黄金开发时期——假期已经到来。但紧接着又出现了新的问题：开发人员一下子多了起来，原先的组织结构已经不能适应新的状况了。

【组织结构的变化】
　　项目启动之初，人员不多，组织结构也较简单　　
　　考虑到实际对项目的把握和时间投入，项目组长同时也承担了开发经理的工作，并直接领导美工。顾问协作项目组长的工作。每个核心开发人员负责一个具体子系统的开发，考虑到项目组长工作较重而繁琐，其中一个核心开发人员同时承担一些开发经理助理的工作，项目组长本身不担任核心开发工作。
　　到了第六周，人员达到了16人的规模，原有组织结构已经不能满足此时的管理要求，调整势在必行。起初我们想按照一般的做法，把开发团队分成2－3个小组，每个小组选出组长，组长则向项目领导汇报。如下图：
　　
　　但这个调整又是相当困难的：一方面开发工作已经开始进行，让原有人员调换角色或者调整开发内容将是非常困难的；另一方面，整个开发团队中除了项目组长之外，其它人都缺乏对全局的系统的足够了解和足够的工作时间，因此很难选出合适的人员承担小组长的角色。经过和项目顾问的多次商讨，最终的组织结构如下：

 这个看起来略显复杂的结构其实基本思想很简单：
1． 保证已经开始工作的核心开发人员的工作内容基本不变，辅助开发人员配合核心开发人员工作；
2． 为了不增加核心开发人员的管理工作量，没有设置开发小组长的角色；管理工作直接由项目组长负责；
3． 为了防止项目组长事务工作过多，加强开发经理助理这一角色的作用；同时多安排一个辅助开发人员来配合其工作。
 总的说来，新的组织结构图在实施中还是比较合理的。但项目组长要承担很多的管理、协调工作，在实际中还有一些开发工作，比别人辛苦。但作为唯一的全职工作人员，这一点还是可以接受的。

【第一次迭代】
 到了假期这个开源项目的黄金时期，我们的项目进展恢复正常。
 项目开发从4月28日启动，一共16个星期，第一阶段由于涉及五一长期、期末考试等较多不利因素，我们安排了10个星期的时间。实际第一阶段在第11周结束，比计划推迟了一周。从开发的质量来看，基本上达到了要求。

【第二次迭代】
 经过了第一次跌代，第二次迭代阶段则要顺手的多。
 项目第二阶段从第12周开始，计划第16周结束。由于在第11周很多开发成员为了赶进度，工作相当辛苦，另外考虑到我们是开源项目，我做了一个相当大

胆的决定：在第12周放假一周！
 第二阶段实际上从第13周开始。最后的开发也延期了一周，在第17周结束。后期由于遇到了一些技术问题，对部分功能作了裁剪，但整个系统的主题功能已经完成，可以说是取得了相当不错的战绩，基本完成了预期的目标，取得了成功！

【项目回顾】
　　成功完成了项目，自然要回顾一下。
【项目大事记】
* 项目2004年4月5日开始第一次正式的制定计划，算是正式启动；
* 4月10日：第一次招募，采用类似宣讲会的形式；
* 在第一次招募结束后，在4月15日进行了为期十天的网络招募；
* 4月27日：确定了成员名单：核心开发人员5人，美工1人，项目顾问2人，法律顾问1人；
* 4月28日：发布项目网站
* 4月28日：项目组召开第一次大会，以后基本每周进行一次例会；
* 5月16日：发布第一个模块
* 5月25日：第一次尝试正式的网络会议，感觉效果是“可以接受”
* 5月25日至6月4日，多数开发人员复习考试，项目进入低潮
* 6月5日：假期开发计划开始实施，项目进度恢复
* 7月12日：项目的第一次迭代在一周结束
* 7月13日至7月19日：多数成员休息一周
* 7月29日：项目的第二阶段启动
* 8月23日：整个项目在延期一周的情况下成功完成
【基本数据】
 项目从4月5日开始筹备，到8月23日完成，共计141天。如果从4月28日第一次项目组会议开始计算，则共历时118天，约17周。
 项目成员最多时达到16人，其中开发人员13人，其他为顾问和美工。
 实际开发的系统的总文件数为239个，总行数39583行，类的个数为135个，类成员/方法数为1171个。
【风险回顾】
 项目基本取得了成功，让我们来回顾一下项目初始时提到的各个风险，看看解决的如何。
 首先看工作时间，由于是开源项目，成员的工作时间得不到保障，这是我们预期的，但实际的情况比我们预想的还要糟很多，下表是成员的工作时间统计情况，横轴是从项目启动到结束的时间，小格是天，大格是周；纵轴是各个成员，图中深色的部分表示成员完全不能参与工作的时间段。
（图传不上来啊，看不到，不过可以说数据是，整个项目中24.8%的“人天”是大家完全不能工作的） 从图中可以看出，在整个开发过程中，存在着大量的成员不能参与工作的时间段，具体的原因主要有五一长假、期末复习、假期回家、外出等。这个似乎是开源项目不可避免的问题，在做计划时需要特别注意。
 工作热情也是项目启动时担心的一个风险，从事后回顾来看，这个风险并没有发生，大家的热情都很高，没有发现谁最后对项目缺乏热情而离去。
 再来谈“开发人员的水平”，从我们这次招募的人员来看，总的说来人员的技术水平属于中等偏上，对搜索引擎的技术了解则普遍不多，基本没有什么招到技术高手，不过这一点丝毫不影响我们项目整体的进展。
 最后再来谈谈另一个风险——“交流”，这个确实是最大的风险。因为开发成员都是志愿者，大家分布在不同的实验室，甚至不同的省市，交流起来比较麻烦。尽管我们使用了尽可能多的交流方式，但依然感觉到交流的明显不足。我们在第一次跌代结束后做过一个调查，其中一个问题就是“你认为第一阶段中出现最大问题是什么？”从大家的回答的结果来看，交流不足是最大的问题。我们在第二阶段有意识加强了交流。主要通过：管理上制定一些制度，迫使大家必须交流；提供更多的交流途径（比如发现论坛大家用的不多就启用了邮件列表），大家有意识加强交流等。从收效上来看确实有一定效果，但依然感到交流不足。

【商业模式】
 经历了这四个月，对开源项目有了较多的认识，但其实开源项目还有很多魅力是我们没有感受、接触到的，其中最重要的一点就是商业。 很多人误以为开源就是免费，其实这是一个相当错误的认识。开源和商业并不是冲突的。
　　软件作为一个以人的智慧结晶为主要成本的数字产物，主要通过销售将源代码编译、打包、包装过的软件包获得商业价值。程序源代码作为软件的基础材料，

具有可察看、可复制、可复用等特点。开放源代码是使软件开发者散失了获得劳动回报的主要途径，因此程序员必须在这种新的开发模式下通过其他商业模式获得回报。
　　从上世纪八十年代开始，从事和关心开源运动的人们就不断探索能够为开源程序员获取回报的开源商业模式。随着时间的推移，开源运动在发展过程中逐步形成了一些较为可行的商业模式，这些商业模式主要包括：
* 双授权
典型实例：mysql
　　通过针对个人/商用进行不同授权或不同版本（基本版本、 企业版本）进行不同授权。
* 咨询顾问
典型实例：jboss
　　提供技术文档、培训服务、咨询服务、系统规划实施等技术服务；
* 应用服务
提供基于开源软件的网络应用服务（ASP）；
* 硬件捆绑
捆绑赞助商或开源软件开发商硬件，如Widget Frosting：一个主要生产硬件的公司（其中的某一部分软件不做为主要利润来源）会选择开源软件来提供更好的产品，比如 IBM 塔式计算机就预装了 Turbolinux 操作系统；
* 卖附属品
这个听起来有点夸张，但确实也是一条路。可以出售的商品包括书籍、T 恤衫、咖啡杯，以及 Linux 企鹅玩具……
* 提供服务
虽然送出产品，但是卖的是品牌，卖的是服务，Redhat 一直在这样做；
* 市场策略
通过提供开源软件使自己占有市场，Netscape 曾经因此决定公布 Navigator 的源代码。
　　如果想更深入的了解，可以参考在这一方面的一些经典文章，由国际自由软件知名人士Eric Raymond 在1999年夏天发表的一篇重要著作 《魔法大锅炉》(TheMagic Cauldron)大概是其中最为重要的一篇。这篇文章分析了开放源代码现象不断发展的经济基础。首先推翻了一些流行的关于程序开发资金和软件价格结构的神话。给出了一个关于开放源代码协作稳定性的搏弈论分析。 给出了九种开放源代码开发的可发展模型，其中两种是不盈利的，七种是盈利的。接着发展了一种定性的理论，说明什么时候封闭代码在经济上是合理的。然后考察了当前市场上发明的几种新颖的开放源代码开发的盈利方法学，包括赞助系统和任务市场的引入。最后做出了结论，试着对将来做了一些预测。
开源的危机
 开源的发展也并非一帆风顺，我们也经常能够听到很多不利的报道：
　　RedHatLinux将不再面向普通的个人用户出售（eNet硅谷动力，2003年11月15日）
　　欧洲软件专利法有变，开源社区面临重大打击（太平洋电脑网，2004年05月15日）
　　Redhat公司高官Chris Sharp跳槽微软，并说研发开源软件费钱不讨好（zdnet，2004年5月24日）
　　即时像sourceforge这样的开源软件集散地，有人专门研究过其上的项目。其实绝大部分开发项目也只是开发者个人在工作，少有人问津，真正推出稳定的1.0版的软件只占很少的比例。
　　虽然媒体对开源，对linux的报道总的说来是褒多贬少，但我们也不能忽视多数的开源软件还并不够好这样一个事实。
结语
　　经过四个月的尝试，作者对开源算是有了一些切身的感受和理解，尽管它还不成熟，还面临一些问题，但我们有理由相信：
　　“开放源代码不仅仅只是软件源代码而已，它们也悠关自由、分享和社群精神；创作、美和黑客所谓的‘有趣’。它们也悠关人人心中的密码，是我们心中至善的根源，反抗至恶，永世长存。”——匿名