在开源的过程中，遇到困难挫折、喜悦和欢乐，我会将点滴感受记录下来，与各位分享。这是第一次分享（起大早写的）
（原文在网站上面：
http://www.ralasafe.org/zh-hans/2010/10/%e7%a4%be%e5%8c%ba%e5%89%8d%e8%bf%9b%ef%bc%8c%e5%8e%8b%e5%8a%9b%e5%be%88%e5%a4%a7/
 现粘贴过来）

社区前进，压力很大<http://www.ralasafe.org/zh-hans/2010/10/%e7%a4%be%e5%8c%ba%e5%89%8d%e8%bf%9b%ef%bc%8c%e5%8e%8b%e5%8a%9b%e5%be%88%e5%a4%a7/>

Ralasafe已经在社区驱动方面做了尝试。在前进的过程中，遇到了一些问题。现将问题和感受与大家分享一下。

我们募集了10名志愿者，使用邮件列表进行沟通。每周按照计划分配任务，并总结上周任务。我们使用mail list（google
group）做为沟通工具。我是按照功能和前后台两个纬度，对志愿者进行分工和配对（形成小组配合）。我也给出了设计方案，但并不是详细设计方案（细化到功能参数那种）。之所以这么做，我的出发点是：1)
目前任务非常明确，只是对1.0版本的界面重新技术实现（jquery代替gwt)；2）我期望commiter不仅是coder
commiter而且应该是design commiter和idea commiter； 3）希望小组范围内大家沟通起来。

结果，事与愿违。我看到了不好的景象是：1）部分commiter因为工作关系，近期不能参与进来（但任务又分配了）。这点无法预期，最令我头痛；2）时间过去1周多了，还没有人提交代码；3）恐怖的是，也没有人讨论设计，讨论任务。

我总结了原因：1）社区的活力还没有激发出来。社区就这样，有人动作，会带动其他人动作；没人动作，也会影响其他人的热情。有点跟风的味道，但这是好的跟风。2）参与者大多都是第一次做志愿者，没有经验，还不善于分配工作时间和志愿（业务时间）的关系。

因此，本来我将自己工作主要放在项目管理、需求设计和code review方面，目的是保证方向、进度和质量，转移为项目管理、需求设计和代码提交。code
review工作大幅降低。为了保证代码质量，会提高commiter的技能门槛。当然，测试是不可少的。

说到测试，这段时间上海软件评测中心，徐老师对Ralasafe做了非常细致的测试。在此感谢徐老师的辛苦工作，并提出的宝贵问题和建议。徐老师很喜欢这个项目，期待他的测试报告。徐也对Ralasafe的产品宣传很担忧，表示他也将通过社区帮忙推广。感谢。

另外，给我压力很大的就是文档。1）手册格式不够规范；2）很多人看了手册和网站，还不能理解。（这主要是2方面原因：a)Ralasafe是个新事物，大家没有先入为主的观念；b)我们的文档存在不足；c)也有开发者没有好好学习，粗枝大叶随意一看）；3）有几位开发者在呼唤视频教程了。

-- 
Julian Wong
汪金保
Founder and Team Leader
Open Source Access Control Middleware
http://www.ralasafe.org
-------------- 下一部分 --------------
一个HTML附件被移除...
URL: <http://www.zeuux.org/pipermail/zeuux-universe/attachments/20101022/b21091fa/attachment.html>

2010/10/22 Julian Wong <ralasafe at gmail.com>:
> 在开源的过程中，遇到困难挫折、喜悦和欢乐，我会将点滴感受记录下来，与各位分享。这是第一次分享（起大早写的）
> （原文在网站上面：http://www.ralasafe.org/zh-hans/2010/10/%e7%a4%be%e5%8c%ba%e5%89%8d%e8%bf%9b%ef%bc%8c%e5%8e%8b%e5%8a%9b%e5%be%88%e5%a4%a7/ 现粘贴过来）
>
> 社区前进，压力很大
>
> Ralasafe已经在社区驱动方面做了尝试。在前进的过程中，遇到了一些问题。现将问题和感受与大家分享一下。
>
> 我们募集了10名志愿者，使用邮件列表进行沟通。每周按照计划分配任务，并总结上周任务。我们使用mail list（google
> group）做为沟通工具。我是按照功能和前后台两个纬度，对志愿者进行分工和配对（形成小组配合）。我也给出了设计方案，但并不是详细设计方案（细化到功能参数那种）。之所以这么做，我的出发点是：1)
> 目前任务非常明确，只是对1.0版本的界面重新技术实现（jquery代替gwt)；2）我期望commiter不仅是coder
> commiter而且应该是design commiter和idea commiter； 3）希望小组范围内大家沟通起来。
>
> 结果，事与愿违。我看到了不好的景象是：1）部分commiter因为工作关系，近期不能参与进来（但任务又分配了）。这点无法预期，最令我头痛；2）时间过去1周多了，还没有人提交代码；3）恐怖的是，也没有人讨论设计，讨论任务。
>
> 我总结了原因：1）社区的活力还没有激发出来。社区就这样，有人动作，会带动其他人动作；没人动作，也会影响其他人的热情。有点跟风的味道，但这是好的跟风。2）参与者大多都是第一次做志愿者，没有经验，还不善于分配工作时间和志愿（业务时间）的关系。
>
> 因此，本来我将自己工作主要放在项目管理、需求设计和code review方面，目的是保证方向、进度和质量，转移为项目管理、需求设计和代码提交。code
> review工作大幅降低。为了保证代码质量，会提高commiter的技能门槛。当然，测试是不可少的。
>
> 说到测试，这段时间上海软件评测中心，徐老师对Ralasafe做了非常细致的测试。在此感谢徐老师的辛苦工作，并提出的宝贵问题和建议。徐老师很喜欢这个项目，期待他的测试报告。徐也对Ralasafe的产品宣传很担忧，表示他也将通过社区帮忙推广。感谢。
>
> 另外，给我压力很大的就是文档。1）手册格式不够规范；2）很多人看了手册和网站，还不能理解。（这主要是2方面原因：a)Ralasafe是个新事物，大家没有先入为主的观念；b)我们的文档存在不足；c)也有开发者没有好好学习，粗枝大叶随意一看）；3）有几位开发者在呼唤视频教程了。
>
> --

有没有核心人员，靠志愿者我个人认为不是很靠谱。我认为志愿者可能更适合做一些计划外的，如文档，补丁。

-- 
I like python!
UliPad <>: http://code.google.com/p/ulipad/
UliWeb <>: http://uliwebproject.appspot.com
My Blog: http://hi.baidu.com/limodou

> 有没有核心人员，靠志愿者我个人认为不是很靠谱。我认为志愿者可能更适合做一些计划外的，如文档，补丁。
>

从我个人的体会，如果志愿者的水平无法与核心人员相当，或对整个项目的熟悉程序不高的情况下，存在非常多的不定因素。最关键的一个问题就是：无从下手。哪怕是你已经搭好了架子。许多时候他们更擅长的可能是在原有模式上的改进，而不是自行创造。而且，有可能他们的设计思路与你不符。所以，讨论我认为可以，但是设计最好还是由核心人员来搞。然后做出一些模板，让别人可以照猫画虎，这样可能会好一些。但，这样，其实工作量还主要是在核心人员身上。

-- 
I like python!
UliPad <>: http://code.google.com/p/ulipad/
UliWeb <>: http://uliwebproject.appspot.com
My Blog: http://hi.baidu.com/limodou

2010/10/22 Julian Wong <ralasafe在gmail.com>:
> 结果，事与愿违。我看到了不好的景象是：1）部分commiter因为工作关系，近期不能参与进来（但任务又分配了）。这点无法预期，最令我头痛；2）时间过去1周多了，还没有人提交代码；3）恐怖的是，也没有人讨论设计，讨论任务。
>

从几个开源项目的发展、观察和参与，我看到一些现象：

1。对时间有固定要求的内容，必须由自己雇佣的有偿人员完成。
2。社区贡献只提供时间线，例如说翻译必须在某个时间前提交，晚了就只能到下个版本。任务可以自主领用，但是很少被分配，除非是属于自己的bug。

如果你需要在指定时间完成任务，你必须付费雇佣相关人员，否则，这件任务只有等到相关人员有时间并且有兴趣的时候再去完成。

对于几乎没有有偿员工的情况，如果你需要在指定时间发布版本也是可行的，只是你不能期待你想要的特性一定会出现。例如，计划六个月后发布一个版本，计划了10个特性，最终可能有5个都没有完成，没有提交，但是你还是按照六个月去发布，只是那些特性在对应版本就没有了。

免费开源的软件开发过程特点是：每个人在自己感兴趣的时间做自己感兴趣的事。所以你只能给别人增加代办任务列表（例如属于他的bug他得去负责修复），而没法要求他们一定在某个时间内完成某项工作，这本身不合理也不现实。

对于你自己想实现的功能，由你自己完成，别人想改的bug和别人想实现的功能，由别人自己完成。开源软件的开发过程通常就是这样。

2010/10/22 limodou <limodou在gmail.com>:
> 有没有核心人员，靠志愿者我个人认为不是很靠谱。我认为志愿者可能更适合做一些计划外的，如文档，补丁。

如果不拿工资的话，核心人员跟志愿者没有任何区别。

计划内的事情是可以做的，因为计划可以不是刚性的，也就是说，如果他们不能按照计划完成，那么在对应版本中就不发布他们的这部分工作。所谓社区推动的软件，其实关键点就在于虽然对所有成员的任务都可以有计划，但是这个计划可以被延期或者被更改。有目标是需要的，但你不可能对没有达成目标的免费成员问责。

如果你需要刚性的规定在某个时间内完成某项工作，免费的核心人员也不可靠的，只能靠雇员。

2010/10/22 Julian Wong <ralasafe在gmail.com>:
> 我们募集了10名志愿者，使用邮件列表进行沟通。每周按照计划分配任务，并总结上周任务。我们使用mail list（google
> group）做为沟通工具。我是按照功能和前后台两个纬度，对志愿者进行分工和配对（形成小组配合）。我也给出了设计方案，但并不是详细设计方案（细化到功能参数那种）。之所以这么做，我的出发点是：1)
> 目前任务非常明确，只是对1.0版本的界面重新技术实现（jquery代替gwt)；2）我期望commiter不仅是coder
> commiter而且应该是design commiter和idea commiter； 3）希望小组范围内大家沟通起来。

开源软件的免费开发者可能存在一个或者多个这些特性
1。对所开发的目标软件有强烈的使用需求，同时有强烈的兴趣。（简单的说，他是软件的目标用户）
2。对编程有强烈的热爱，并且拥有相当程度的技术能力。（简单的说，他是个极客）
3。有时间和精力。（简单的说，衣食无忧，温饱不愁。）

我感觉你的某些志愿者根本不满足上面三点中的任何一点。所以根本不适合来做开源软件开发，赶鸭子上架也没什么意义。

注意，我认为第一点是最重要的，第二第三点相对来说都是其次。

2010/10/22 Pan Shi Zhu <pan.shizhu at gmail.com>:
> 2010/10/22 limodou <limodou at gmail.com>:
>> 有没有核心人员，靠志愿者我个人认为不是很靠谱。我认为志愿者可能更适合做一些计划外的，如文档，补丁。
>
> 如果不拿工资的话，核心人员跟志愿者没有任何区别。
>
> 计划内的事情是可以做的，因为计划可以不是刚性的，也就是说，如果他们不能按照计划完成，那么在对应版本中就不发布他们的这部分工作。所谓社区推动的软件，其实关键点就在于虽然对所有成员的任务都可以有计划，但是这个计划可以被延期或者被更改。有目标是需要的，但你不可能对没有达成目标的免费成员问责。
>
> 如果你需要刚性的规定在某个时间内完成某项工作，免费的核心人员也不可靠的，只能靠雇员。
>

这个要看具体的情况了。比如我作为核心成员是不是有强烈地愿望要发布版本，还是看个人的时间和精力。不拿工资一样可以做到。

-- 
I like python!
UliPad <>: http://code.google.com/p/ulipad/
UliWeb <>: http://uliwebproject.appspot.com
My Blog: http://hi.baidu.com/limodou

2010/10/22 Pan Shi Zhu <pan.shizhu at gmail.com>:
> 2010/10/22 Julian Wong <ralasafe at gmail.com>:
>> 我们募集了10名志愿者，使用邮件列表进行沟通。每周按照计划分配任务，并总结上周任务。我们使用mail list（google
>> group）做为沟通工具。我是按照功能和前后台两个纬度，对志愿者进行分工和配对（形成小组配合）。我也给出了设计方案，但并不是详细设计方案（细化到功能参数那种）。之所以这么做，我的出发点是：1)
>> 目前任务非常明确，只是对1.0版本的界面重新技术实现（jquery代替gwt)；2）我期望commiter不仅是coder
>> commiter而且应该是design commiter和idea commiter； 3）希望小组范围内大家沟通起来。
>
> 开源软件的免费开发者可能存在一个或者多个这些特性
> 1。对所开发的目标软件有强烈的使用需求，同时有强烈的兴趣。（简单的说，他是软件的目标用户）
> 2。对编程有强烈的热爱，并且拥有相当程度的技术能力。（简单的说，他是个极客）
> 3。有时间和精力。（简单的说，衣食无忧，温饱不愁。）
>
> 我感觉你的某些志愿者根本不满足上面三点中的任何一点。所以根本不适合来做开源软件开发，赶鸭子上架也没什么意义。
>
> 注意，我认为第一点是最重要的，第二第三点相对来说都是其次。

的确，很多时候，项目雷声大，雨点小，很多人是报着学习，参与的态度来的，根本无法深入，所以后面没了兴趣就做不下去了。以至于许多开源项目绝大部分时间是个人在奋斗。
-- 
I like python!
UliPad <>: http://code.google.com/p/ulipad/
UliWeb <>: http://uliwebproject.appspot.com
My Blog: http://hi.baidu.com/limodou

通过上述讨论，引出了另一个问题： *开源、自由这种贡献的社区哲学是否行得通？*

Pan Shi
Zhu提出的人员3个要求，对我感触很大。赶鸭子上架没用。人员要精简高质。这样虽然有难度，但降低了管理风险。风险的降低，从长远来看，也是降低成本的。开源组织不能像公司那样，团队可以很快的聚在一起讨论。



2010/10/22 limodou <limodou在gmail.com>

> 2010/10/22 Pan Shi Zhu <pan.shizhu在gmail.com>:
> > 2010/10/22 limodou <limodou在gmail.com>:
> >> 有没有核心人员，靠志愿者我个人认为不是很靠谱。我认为志愿者可能更适合做一些计划外的，如文档，补丁。
> >
> > 如果不拿工资的话，核心人员跟志愿者没有任何区别。
> >
> >
> 计划内的事情是可以做的，因为计划可以不是刚性的，也就是说，如果他们不能按照计划完成，那么在对应版本中就不发布他们的这部分工作。所谓社区推动的软件，其实关键点就在于虽然对所有成员的任务都可以有计划，但是这个计划可以被延期或者被更改。有目标是需要的，但你不可能对没有达成目标的免费成员问责。
> >
> > 如果你需要刚性的规定在某个时间内完成某项工作，免费的核心人员也不可靠的，只能靠雇员。
> >
>
> 这个要看具体的情况了。比如我作为核心成员是不是有强烈地愿望要发布版本，还是看个人的时间和精力。不拿工资一样可以做到。
>
> --
> I like python!
> UliPad <>: http://code.google.com/p/ulipad/
> UliWeb <>: http://uliwebproject.appspot.com
> My Blog: http://hi.baidu.com/limodou
> _______________________________________________
> zeuux-universe mailing list
> zeuux-universe在zeuux.org
> http://www.zeuux.org/mailman/listinfo/zeuux-universe
>
> ZEUUX Project - Free Software, Free Society!
> http://www.zeuux.org
>



-- 
Julian Wong
汪金保
Founder and Team Leader
Open Source Access Control Middleware
http://www.ralasafe.org
-------------- 下一部分 --------------
一个HTML附件被移除...
URL: <http://www.zeuux.org/pipermail/zeuux-universe/attachments/20101022/49344c9d/attachment-0001.html>

关于自由开源项目的几点想法（并非（只）针对RALASAFE本身）：

＊项目本身要有吸引力 － 否则没人和你玩儿。

＊被忽略比被偷走更可怕 － 绝大多数东西都是废品／半成品，不值得偷（盗版）。

＊研发国际化，运营本地化 －世界是平的，让地球人都能参与进来；国内工程师 
处在温饱阶段，主要精力用于对付住房、教育、医疗和养老问题，没法保证大块时间。

＊做好技术营销 － 像Google学习。

＊重视用户体验 － 绝大多数和＊正常人＊打交道的自由开源软件的用户体验都很 
差，是问题，更是机会。和工程师打交道的会好一些。

＊形成商业模式 － 不能赚钱是可耻的。

＊持久战 － 别急功近利，开源不是灵丹妙药，不要有过高的期望值，它只是一种 
开发模式，并可能形成商业模式。努力做好产品、技术本身。不断积累。


Julian Wong 写道:
> 在开源的过程中，遇到困难挫折、喜悦和欢乐，我会将点滴感受记录下来，与各 
> 位分享。这是第一次分享（起大早写的）
> （原文在网站上面：http://www.ralasafe.org/zh-hans/2010/10/%e7%a4%be% 
> e5%8c%ba%e5%89%8d%e8%bf%9b%ef%bc%8c%e5%8e%8b%e5%8a%9b%e5%be%88%e5%a4%a7/  
> 现粘贴过来）
>
>
>   社区前进，压力很大
>   <http://www.ralasafe.org/zh-hans/2010/10/%e7%a4%be%e5%8c%ba%e5%89%8d%e8%bf%9b%ef%bc%8c%e5%8e%8b%e5%8a%9b%e5%be%88%e5%a4%a7/>
>
> Ralasafe 已经在社区驱动方面做了尝试。在前进的过程中，遇到了一些问题。 
> 现将问题和感受与大家分享一下。
>
> 我们募集了10名志愿者，使用邮件列表进行沟通。每周按照计划分配任务，并总 
> 结上周任务。我们使用mail list（google group）做为沟通工具。我是按照功 
> 能和前后台两个纬度，对志愿者进行分工和配对（形成小组配合）。我也给出了 
> 设计方案，但并不是详细设计方案（细化到功能参数那种）。之所以这么做，我 
> 的出发点是：1) 目前任务非常明确，只是对1.0版本的界面重新技术实现 
> （jquery代替gwt)；2）我期望commiter不仅是coder commiter而且应该是 
> design commiter和idea commiter； 3）希望小组范围内大家沟通起来。
>
> 结果，事与愿违。我看到了不好的景象是：1）部分commiter因为工作关系，近 
> 期不能参与进来（但任务又分配了）。这点无法预期，最令我头痛；2）时间过 
> 去1周多了，还没有人提交代码；3）恐怖的是，也没有人讨论设计，讨论任务。
>
> 我总结了原因：1）社区的活力还没有激发出来。社区就这样，有人动作，会带 
> 动其他人动作；没人动作，也会影响其他人的热情。有点跟风的味道，但这是好 
> 的跟风。2）参与者大多都是第一次做志愿者，没有经验，还不善于分配工作时 
> 间和志愿（业务时间）的关系。
>
> 因此，本来我将自己工作主要放在项目管理、需求设计和code review方面，目 
> 的是保证方向、进度和质量，转移为项目管理、需求设计和代码提交。code 
> review工作大幅降低。为了保证代码质量，会提高commiter的技能门槛。当然， 
> 测试是不可少的。
>
> 说到测试，这段时间上海软件评测中心，徐老师对Ralasafe做了非常细致的测 
> 试。在此感谢徐老师的辛苦工作，并提出的宝贵问题和建议。徐老师很喜欢这个 
> 项目，期待他的测试报告。徐也对Ralasafe的产品宣传很担忧，表示他也将通过 
> 社区帮忙推广。感谢。
>
> 另外，给我压力很大的就是文档。1）手册格式不够规范；2）很多人看了手册和 
> 网站，还不能理解。（这主要是2方面原因：a)Ralasafe是个新事物，大家没有 
> 先入为主的观念；b)我们的文档存在不足；c)也有开发者没有好好学习，粗枝大 
> 叶随意一看）；3）有几位开发者在呼唤视频教程了。
>
>
> -- 
> Julian Wong
> 汪金保
> Founder and Team Leader
> Open Source Access Control Middleware
> http://www.ralasafe.org <http://www.ralasafe.org/>
> ------------------------------------------------------------------------
>
> _______________________________________________
> zeuux-universe mailing list
> zeuux-universe在zeuux.org
> http://www.zeuux.org/mailman/listinfo/zeuux-universe
>
> ZEUUX Project - Free Software, Free Society!
> http://www.zeuux.org
-------------- 下一部分 --------------
一个HTML附件被移除...
URL: <http://www.zeuux.org/pipermail/zeuux-universe/attachments/20101022/4c1ecba9/attachment.html>

2010/10/22 Bill Xu <bill at zeuux.org>:
> 关于自由开源项目的几点想法（并非（只）针对RALASAFE本身）：
>
> ＊项目本身要有吸引力 － 否则没人和你玩儿。
>
> ＊被忽略比被偷走更可怕 － 绝大多数东西都是废品／半成品，不值得偷（盗版）。
>
> ＊研发国际化，运营本地化 － 世界是平的，让地球人都能参与进来；国内工程师处在温饱阶段，主要精力用于对付住房、教育、医疗和养老问题，没法保证大块时间。
>
> ＊做好技术营销 － 像Google学习。
>
> ＊重视用户体验 － 绝大多数和＊正常人＊打交道的自由开源软件的用户体验都很差，是问题，更是机会。和工程师打交道的会好一些。
>
> ＊形成商业模式 － 不能赚钱是可耻的。
>
> ＊持久战 － 别急功近利，开源不是灵丹妙药，不要有过高的期望值，它只是一种开发模式，并可能形成商业模式。努力做好产品、技术本身。不断积累。
>

这个不错。

-- 
I like python!
UliPad <>: http://code.google.com/p/ulipad/
UliWeb <>: http://uliwebproject.appspot.com
My Blog: http://hi.baidu.com/limodou

继哲果然不凡，尽显开源导师风范。
1，开源软件来不得急攻近利的，而且很多开源使用者也不喜欢开源软件随着版本升级，越来越苛刻。比如EXT
2，不要怕被偷走。

 在社区研发方面，也想听你说说。

2010/10/22 Bill Xu <bill在zeuux.org>

>  关于自由开源项目的几点想法（并非（只）针对RALASAFE本身）：
>
> ＊项目本身要有吸引力 － 否则没人和你玩儿。
>
> ＊被忽略比被偷走更可怕 － 绝大多数东西都是废品／半成品，不值得偷（盗版）。
>
> ＊研发国际化，运营本地化 － 世界是平的，让地球人都能参与进来；国内工程师处在温饱阶段，主要精力用于对付住房、教育、医疗和养老问题，没法保证大块时间。
>
> ＊做好技术营销 － 像Google学习。
>
> ＊重视用户体验 － 绝大多数和＊正常人＊打交道的自由开源软件的用户体验都很差，是问题，更是机会。和工程师打交道的会好一些。
>
> ＊形成商业模式 － 不能赚钱是可耻的。
>
> ＊持久战 － 别急功近利，开源不是灵丹妙药，不要有过高的期望值，它只是一种开发模式，并可能形成商业模式。努力做好产品、技术本身。不断积累。
>
>
> Julian Wong 写道:
>
> 在 开源的过程中，遇到困难挫折、喜悦和欢乐，我会将点滴感受记录下来，与各位分享。这是第一次分享（起大早写的）
> （原文在网站上面：
> http://www.ralasafe.org/zh-hans/2010/10/%e7%a4%be%e5%8c%ba%e5%89%8d%e8%bf%9b%ef%bc%8c%e5%8e%8b%e5%8a%9b%e5%be%88%e5%a4%a7/
> 现粘贴过来）
>
>  社 区前进，压力很大<http://www.ralasafe.org/zh-hans/2010/10/%e7%a4%be%e5%8c%ba%e5%89%8d%e8%bf%9b%ef%bc%8c%e5%8e%8b%e5%8a%9b%e5%be%88%e5%a4%a7/>
>
> Ralasafe 已经在社区驱动方面做了尝试。在前进的过程中，遇到了一些问题。现将问题和感受与大家分享一下。
>
> 我 们募集了10名志愿者，使用邮件列表进行沟通。每周按照计划分配任务，并总结上周任务。我们使用mail list（google
> group）做为沟通工具。我是按照功能和前后台两个纬度，对志愿者进行分工和配对（形成小组配合）。我也给出了设计方案，但并不是详细设计方案（细化到
> 功能参数那种）。之所以这么做，我的出发点是：1)
> 目前任务非常明确，只是对1.0版本的界面重新技术实现（jquery代替gwt)；2）我期望commiter不仅是coder
> commiter而且应该是design commiter和idea commiter； 3）希望小组范围内大家沟通起来。
>
> 结果，事与愿违。我看到了不好的景象是：1）部分commiter因为工作关系，近期不能参与进来（但任务又分配了）。这点无法预期，最令我头痛；2）时
> 间过去1周多了，还没有人提交代码；3）恐怖的是，也没有人讨论设计，讨论任务。
>
> 我 总结了原因：1）社区的活力还没有激发出来。社区就这样，有人动作，会带动其他人动作；没人动作，也会影响其他人的热情。有点跟风的味道，但这是好的跟
> 风。2）参与者大多都是第一次做志愿者，没有经验，还不善于分配工作时间和志愿（业务时间）的关系。
>
> 因 此，本来我将自己工作主要放在项目管理、需求设计和code
> review方面，目的是保证方向、进度和质量，转移为项目管理、需求设计和代码提交。code
> review工作大幅降低。为了保证代码质量，会提高commiter的技能门槛。当然，测试是不可少的。
>
> 说 到测试，这段时间上海软件评测中心，徐老师对Ralasafe做了非常细致的测试。在此感谢徐老师的辛苦工作，并提出的宝贵问题和建议。徐老师很喜欢这个
> 项目，期待他的测试报告。徐也对Ralasafe的产品宣传很担忧，表示他也将通过社区帮忙推广。感谢。
>
> 另 外，给我压力很大的就是文档。1）手册格式不够规范；2）很多人看了手册和网站，还不能理解。（这主要是2方面原因：a)Ralasafe是个新事物，大
> 家没有先入为主的观念；b)我们的文档存在不足；c)也有开发者没有好好学习，粗枝大叶随意一看）；3）有几位开发者在呼唤视频教程了。
>
> --
> Julian Wong
> 汪金保
> Founder and Team Leader
> Open Source Access Control Middleware
> http://www.ralasafe.org
>
> ------------------------------
>
> _______________________________________________
> zeuux-universe mailing listzeuux-universe在zeuux.orghttp://www.zeuux.org/mailman/listinfo/zeuux-universe
>
> ZEUUX Project - Free Software, Free Society!http://www.zeuux.org
>
>


-- 
Julian Wong
汪金保
Founder and Team Leader
Open Source Access Control Middleware
http://www.ralasafe.org
-------------- 下一部分 --------------
一个HTML附件被移除...
URL: <http://www.zeuux.org/pipermail/zeuux-universe/attachments/20101022/244447c7/attachment-0001.html>

2010/10/22 Julian Wong <ralasafe在gmail.com>:
> 通过上述讨论，引出了另一个问题： 开源、自由这种贡献的社区哲学是否行得通？
> Pan Shi
> Zhu提出的人员3个要求，对我感触很大。赶鸭子上架没用。人员要精简高质。这样虽然有难度，但降低了管理风险。风险的降低，从长远来看，也是降低成本的。开源组织不能像公司那样，团队可以很快的聚在一起讨论。
>

这个哲学当然是行得通的，前提是你的目标符合这个哲学的特定情况。

例如假定一个企业需要使用 web
server，它是购买一个商业的服务器还是用apache成本更低？这里它的考量是：商业的服务器软件需要让厂家的售后负责定制，需付出的是定制费用，使用开源的
apache 可以由自己的雇员进行定制，需要付出的是人员工资。

软件的特性是每个人都会有不同的需求，因此无论如何你在软件上一定有投入，要么就是投入到厂家售后，要么就是投入到自己更改源代码，再要么就是投入到如何培训人员学会使用这个软件。虽然很多软件都是自由的，但是免费的软件其实并不存在。

所以对于成本的评估在于：使用现有的开源软件在此基础上定制所花的成本与购买商业软件以及后续服务的成本对比。

如果你是想要评估全新的开发一个开源软件跟购买软件之间的成本区别，那么显然这种比较是没意义的，商场上时间就是金钱，绝大多数时候当然不如直接购买一个商业软件来的划算。

开源的优势在于你可以免费的使用那些开源成品，如果你什么成品都没有，什么自己的特色优势都没有，指望社区能够给你贡献开发根本不现实。因为你的半成品东西没有人感兴趣。你只有把产品开发得基本不错的时候，才有人开始关注，有更多人关注才有更多人可能给你贡献代码和补丁的。