原创 网站开源项目思路和基本原则 (ourdev_cn 我们的电子开发社区)

2010-4-22 19:54 818 5 5 分类: MCU/ 嵌入式

*********************************************************************************************

*点击开新帖,发现无从起笔,是因为过了十几天有些生疏,更是觉得有所承担。花了一个小时把旧再看一遍,大脑中一些部分才开始慢慢兴奋起来  

这就把我对项目的若干想法写出来,供大家讨论,同时也是对旧贴171Grant话题的回应:



1.
开源的基本思路--尽可能的开源



2.
协作的基本思路--让参与的每个人在努力、分享与收获中感受快乐。



3.
项目的决策方式--策划和技术负责人的配合



4.
参与者角色--报名、工作认领和承担



5.
网站角色--财务控制和否决



6.
项目跟踪工具 进度 任务分派 项目周报

*****************************************************************************************
1.开源的基本思路--尽可能的开源





  
利益平衡是中国人最容易出问题的地方,无数团队在创业初期可以“共苦”,而略有所成却发现没有“同甘”的缘分,进而丧失进一步发展的基础。ouravr之前的项目中应该不乏人们对于项目谁受益的猜测和纷争,否则armok也不用如此坚决的让邮购部这么好的资源退出项目;Grant不赞成把项目做得太完善,应该也是这方面的顾虑,甚至由于这个顾虑而不愿对参与者提出任何要求。而不管放弃邮购部,还是完全任由参与者来去自由,对于确保项目的成功,影响都不是正面的。 

  
我想到的解决办法就是开源,尽可能的开源,我们要高声的声明,对于任何参与者甚至对这个项目感兴趣的人,我们100%的开放项目过程中的一切内容,我们开放项目需求讨论,开放财务活动,开放硬软件设计,开放PCB源文件,甚至开放PCB生产厂商和零配件供应的细节,我们的目标是在规格说明书范围内把这个方案做到尽可能完美,并不断完善。如果任何人认为在任何时候想用这个方案出产品,你将面临最少的疑问。之所以这么做,是基于商业行为的驱动因素考虑,能够谋暴利,是因为有壁垒,好听点是说“技术领先”,如果把细节摊在阳光下,让一件东西没有难度,谁都可以做,就不存在暴利了。

  
这样做看起来让所有本项目付出工作的人都失去了权力,不管这个权力是不是有实际用途,比如,我们没有声明使用这必须在产品的某个画面显示ourdev,甚至没有声明要求使用者在源代码的开头把源作者的大名务必保留,同时也使创作者失去了利用自己的劳动成果谋取超额利润的可能,这在商业价值观流行的社会看起来是如此的不靠谱。但是,大家想一下,这样带来的好处是可以预见的,参与者不必再有猜疑,大家也没有必要“留一手”,进来做事情,目标只有一个:让这个东西更完美。

  

  
那么参与者得到了什么?看第二点。



*开源并不是完全和商业化对立的,前几年开源进入中国的时候曾经有过这些争论,但现在的主流并不是对立的,开源是另外一种利益平衡。国际流行的开源协议有ApacheBSD,Apache,GPL,LGPL,MIT等不少种(http://www.awflasher.com/blog/archives/939),个人比较倾向于BSD,或者MIT,不是它因为彻底,而是因为在国内,关于BSD协议发生的纷争最少,虽然GPLLGPL使用范围更广,但在国内的可执行性太低,而且口水战浪费了不少资源


********************************************************************************************
2.
协作的基本思路--让参与的每个人在努力、分享与收获中感受快乐。 





 
上一节的思路很不幸的让大家失去了直接通过参与本项目而获取超额利润的机会,那么大家到底能得到什么? 我想到旧贴讨论到的“三个和尚”问题,以体育为例,中国从来都不缺乏单打独斗的高手,所有单人的竞技项目,中国都有出类拔萃的人,但我们几乎无法在超过6人(排球)的组合竞争中保持长久优势。其他领域也是如此,尤其是在西方现代工业革命后的产业体系中,面对西方的大团队合作,我们目前能以应付的恐怕仅限于劳动密集型的低阶段合作,如何汇集多人的智力,而达到某一创造性的目标,是我们急需突破的问题。

 
造成三个和尚没水喝的原因是多方面的,其中相当重要的原因在第一点中提到了,开源从一定程度上解决了利益平衡的问题,虽然有些武断,但也避免了多余的争论。现在问题是,大家为什么走到一起,我们从中都能获得什么? 我对项目参与者预设如下几个观点,供大家探讨:

  

   a.
由于本项目没有直接的物质收益,因此参与者应有可维持的生计,本项目不接受全职工作(这么说是希望大家把握自己的时间和可投入的精力);

   b.
我们参与这个项目,首要的出发点是兴趣,这和在网游中组队打一个怪物,或者在网上召集一个自由行的队伍出游有类似的地方;

   c.
如果您只是初入本领域,需要增长知识和实践经验,那么持续关注是您获取长进的最好途径。更积极一点,让自己的工作对项目有所推进,将是完美的状况了;

   d.
如果您在技术上出类拔萃,并且希望快速在其他技术领域或者管理领域获取经验,比如团队协作和管理,那么您的积极参与将是最好的实践;

   e.
如果您已经拥有成熟的团队,并且有成功的项目经验,我希望您能做为领导者或者指导者参与本项目,带领大家走向成功的同时收获尊重;

   f.
商业企图在本项目中是不被排斥的,如果您是个商人,想获得一个可用的产品方案,那么本项目不排斥你的期望,只是您获得的不再是独占的资源,你可能面临所有人的竞争;

   g.
网站以及项目负责人、项目策划人对本项目没有不可告人的商业目的,决不会通过隐藏某些关键环节的资料而形成技术壁垒,占有“技术优势”而谋取暴利,让其他参与者的成果受到不公平掠夺。这三者从项目的成功中分别收获网站知名度、团队管理经验和个人威望。



   
综上所述,每个人的收获和项目的总体目标的实现程度是正向关联的,因此在现有条件下追求尽可能高的成果应是大家共同的追求(当然,具体做到什么程度也受很多因素限制,但至少应在规格说明书的范围内力争完美)。除此之外,在网站活动中认识自我,展现自我,结识同道,拓宽视野将是大家共同的收获,而这个收获也会因为项目的成就而越发有价值。



 
一个协作的团队和一个人群的区别在于,大家有相同的目标,而且要受到一定约束。本项目不是公共食堂,任何人想来就来,想走就走。但也不同于公司制度下的严格以利益为导向的项目团队,我们必须得有个宽松而可执行的约束机制,我对于约束的建议如下:



   a.
在项目的全过程中,鼓励所有人都有广泛发表意见,但已经经过决策的问题不应反复提出(关于项目决策,下一节说明);

   b.
参与者自愿或受到邀请承担某项工作,则应根据自己的能力和时间安排,制定工作计划并接受定期跟踪约定,及时反馈工作进展,若面临困难,应及时拿出来供大家讨论,若实在无法完成,应果断声明中止,以便及时安排其他人参与;

   c.
在项目特定阶段,例如做为测试PCB和试验器件的接受人,则应积极与项目负责人沟通,确定大家共同接受的工作计划,并按期递交工作成果。

   d.
所有这些约束,都仅存在于道德范畴,没有人会因此而承担法律上的惩罚(但在社区中损失声望是可能发生的事情)。



 
虽然有这些限制,但我希望在分解任务的时候坚守一定原则,细到一定粒度,并充分估计任务中可能面临的问题,确保在1-2周以内可以完成为最好。避免让参与者担负过重的工作压力,从而失去乐趣。让一个有责任心的人由于压力而失去乐趣,对于开源项目相当于犯罪。



 
大家知道为什么中国足球几乎永远无法超越欧洲?让我说那是因为兴趣,中国人玩足球是时髦,是谋生的手段,欧洲人玩足球,是在享受生活。因此让项目的参与者建立在兴趣之上,并维持充分的工作热情,是我们是否能够成功的关键。



 
这也是我在考虑项目管理规范化时很犹豫的地方,做为IT业者,我参与或者观察了为数不少的软件项目,发现他们让人失望的共同之处是僵化的引入过程控制理念,例如在java领域,过多的应用软件工程理念,滥用的设计模式和框架结构,把软件开发过程变成了像东莞无数电子厂生产主板或显卡那样的流水线作业(这并不是软件工程的错,软件工程本来要解决的就是软件生产工业化的问题),每个环节的参与者只需要按标准做事,按说明书编写代码即可,大连有为数众多的日资软件外包企业,那里有些程序员甚至连自己写的代码是干什么用的都不用搞清楚。这达到了前几年大家大为赞赏的印度软件模式,带来了可观的经济收益,但可惜的是,他们也丧失了激情,开发纯粹成了谋生手段。



 
我们不需要代工电子厂那样的软件行业,我们不能把人变成牲口,至少我坚定地这么认为。自始至终我都认为研发是和艺术绘画或者小说写作等类似的创造性行为,而创造力最主要的源泉在于兴趣和自由的空间。因此,我很强烈的愿望是不管这个项目做到什么样,大家都应该矢志不移的在这个过程中寻找快乐,承担一个力所能及的事情并完成,是件快乐的事情,自己的建议和工作成果被团队接受和肯定也是乐趣,而成功的完成这个项目,向所有人展现一个完美的开源解决方案,应是我们最开心的一件事情。


*********************************************************************************************
3.
项目的决策方式--策划和技术负责人的配合 



昨天重新通读过旧贴的之后,我就发现立即面临的其实是这个问题,缺乏项目决策的规则,导致近一周没有任何进展(这中间大部分原因在于我自身调节的原因没有尽快开展工作,再次深表歉意)。但是在没有表达清楚开源和协作的思路之前,项目的决策方式缺乏足够的说服力,因此还是把项目的决策方式放在第三点来讨论。这个问题形成共识之后,希望大家尽快让事情运转起来。



*
开源项目由于某一个人的欠缺产生停滞,不是一个好的状态,理想状态是建立一种广泛参与,足够平等的决策机制,每个角色都有候选人进行补充,充分发挥群体智慧的结果是,整体的成败不依赖单个人,从另一个角度来讲,就是不被任何人或机构完全控制和左右。这个目标可能是太理想化了,我也没有足够的能力设想那样一个团队是如何达到的,只有象Linux这种全球范围内的巨型社区才具备这样的特性,而Linux是如何一步步走成这样,恐怕也是任何一个人都始料不及的,因此这种境界也几乎是不可复制的。我们还是从实际的角度一步步来。



由于站长决定项目分成组织规划(如果大家不介意的话,称策划比较简单点)和技术总负责人共同承担的方式,那么解决这两个角色的分工合作,是首要问题。至于主次先后之分,我的本意旧贴已经表达,由于本项目团队和任何企业架构下的团队都不同,因此过多的讨论也全无太大意义,不妨搁置名份,先讨论分工和协作。个人觉得,这两个角色的分工和协作原则应具备如下几点,希望大家提出意见:



  1.
作为一个开源项目,首先广泛地吸取所有人的意见,在相互尊重的基础上讨论并适度决定取舍是必要的;

  2.
在目前的情况下,某个提议或方案最终是否接纳、是否延期考虑、是否完全不考虑的决定,在缺乏广泛共识的情况下由网站、技术负责人和策划人三者之间产生;

  3.
决策活动中,网站需要考虑投入和总体时间,技术负责人需要考虑项目规模和工程难度,策划人需要考虑是否可跟踪,能够确保完成;

  4.
技术负责人负责项目的总体路线,技术方案的确定,工作分解结构的制作,提出对参与者的要求,分发任务并检验结果;

  5.
策划人负责外围支持,协助完成团队建设和维持,提出适度的项目管理策略,并执行项目跟踪,整理项目资料,确保文档有序;

  6.
技术负责人和策划人若有交叉的工作范围,若对方没有提出问讯或反对意见,则认为没有意见;

  7.
技术负责人和策划人若有意见分歧,应以团队成员的总体意见为重,同时网站的意见应加重权值。



技术总负责人和策划人是两个互补的角色,负责人决定方向,决定如何达到,策划人负责后勤,为技术主力提供有效支持。分工的目的是为了协作,分工不是建立壁垒,成为相互等待的借口,相反当一个角色低沉时,另一个角色应主动承担,希望这也是项目中任何分工的基本原则。



这个提议不知Grant如何看?希望尽快提出意见。



我赞同您于旧贴171楼工作步骤的划分方法,下一步我们可以开始“1、设计规格书 ”的工作,可以把旧贴里的相关讨论摘出来分别发新帖专项讨论。



本文档还有三个要点没没有写,分别涉及参与者角色、网站角色、和项目跟踪具体策略的设计。参与者角色的内容目前想到是报名表的格式等一些便于大家沟通的建议,网站角色部分打算明确网站在项目中的作用,并对网站提出一些具体要求,比如做为项目信息的宿主,必须保持信息的完整性,是否允许镜像,以及如何处理转贴/备份等问题。项目跟踪工具主要是几个固定的表格和记录的规范问题,做项目日志和跟踪,也是以沟通协调为目的东西。我尽可能在周5之前全部写完,供大家讨论。



********************************************************************************************
4.
参与者角色--报名、工作认领和承担 



开源项目与封闭项目相比最大的优势在于广泛参与,在社会分工越发精细的现在,开源“大集市”的方式,模糊了很多界限,看似反其道而行,其实不然。越是精确分工的团队,沟通交流和信息传递的成本越大,越容易形成官僚作风。开源看似无章的放开,带来的结果是信息的无障碍流通,类似头脑风暴式的快速交流中,任何一个有价值的提议,在广泛讨论的基础上,都有可能被优先实现。



虽然本项目强调协调和项目管理过程,但把它变成一个死气沉沉、按部就班执行的传统项目,则是从一个极端走向了另一个极端(因此说,开源的成功有相当的智慧在里面)。因此对于参与者角色,本项目的原则应是开放、尊重、接纳、交流、提高,下面是关于参与者的几个假设,供大家探讨:



 1.
欢迎大家以任何方式就任何问题发表意见,可以跟帖也可以开新帖,我们会尽量在文档整理中收集所有对项目有价值的信息;

 2.
您可以以报名的形式参与项目,从而有可以受到邀请做完成某些任务;

 3.
在项目的特定阶段,负责人可能通过发布任务需求的方式将需要做的任务贴出来,大家可以选择认领,并完成;

 4.
您当然也可以选择埋头苦干,把自己的想法实现,并以开源的形式发布出来,如果真的是精品,最终被项目接受也是可以预见的;

 5.
参与者可以是个人,或者是任何形式的实体;

 6.
参与者应协调好自己相关的利益各方,比如,在某项任务中需要使用公司的设备或者其他资源,则应主动与所有者进行沟通,避免可能出现的纠纷(虽然这个可能性很小);

 7.
参与者认领任务的同时,需要与技术负责人协商工作计划,并承担工作量,合理安排时间,并努力完成;

 8.
项目管理者承诺,任何参与者在项目活动中作出的工作,都将公平、详实的予以记录,并伴随项目成果永久存在。



以“报名”形式或接受“邀请”加入项目的朋友,应在“报名贴”中递交自己的基本情况,以便交流联络,报名贴中递交的内容至少应该包括:



 1.id

 2.
个人简介

 3.
技术背景或者管理经验

 4.
对项目的哪些部分感兴趣,在项目中希望参与哪些任务及其类型,参与属性*

 5.
自己可用的资源情况,开发环境,软硬件设备,特殊工具等

 6.
可供安排的时间,可以用 小时/周为单位,或者“从0811日到331日,每周一个休息日,两个工作日夜晚”等描述

 7.
是否接受工作邀请/我只认领任务,选择

 8.E_mail
地址

 9.QQ
MSN或其他IM工具地址,是否经常在线



*
任务类型视项目分工定,比如“硬件设计”“软件设计”“器件询价采购”“项目规划”“文档整理”等,参与属性可以设置为“主力承担”“辅助提高”等,以声明您可以在此任务有信息做攻坚主力,还是在其他朋友的引导下,一起完成工作,积累经验。



项目活动主要以网站id的身份参与,项目进展到合适阶段,可能需要参与者提供真实身份信息,项目管理者将维护并管理网站id到真实身份的映射表,并在必要提供澄清旁证(尊重本人隐私的前提下)。



********************************************************************************************
5.网站角色--财务控制和否决 



写到这里,应该仔细考虑一下网站这个角色,我想下面叙述的内容,可能有一定理想化的成分,如果站长或者其他朋友有不同看法,请直接说明,以便在最终的《项目计划书》修改定稿。



本项目是一个开源项目,如何理解网站和技术负责人、策划、参与者之间的关系,避免未来可能发生的争论,是有必要的。其实armok已经在多个帖子中反复表达了网站在这个活动中期望扮演的角色,大致我的理解是下面几点:做为项目发起人,提供财务支持(包括募捐和直接捐助),不从中谋利,组织参与性活动,提高网站影响力,把ourdev网站建成国内领先电子网站为最终目标。我想在此基础上,再把约定和约束写的更具体一些,供大家讨论。



网站做为项目的协作平台,是项目过程和结果在虚拟世界的载体,应首先做出可靠性和信息完整性承诺,我假设如下:

   1.
网站做为项目在虚拟世界的信息载体,必须维持足够的可靠性,并在项目尚有价值的时期内,尽力保护项目版区可以访问;

   2.
项目的结果是所有参与人共同的努力结果,网站应公平的确保所有信息不被篡改、隐藏、删除,从而使参与者的辛勤劳动变得无迹可循;

   3.
项目技术负责人和策划人做为版区版主,必须支持并配合网站维护2的原则,主要体现在不随意删贴。



项目参与者在网站不违反承诺的前提下,应该做出符合网站期望的对应承诺,假设如下:

   1.
始终以ourdev做为本项目在虚拟世界的主载体,项目活动和成果需首先在本网站发布;

   2.
做为开源项目的参与者,应尽可能详实的分享信息,把自己的工作结果和心得及时在网站上发布,达到活跃网站讨论的目标,不应从利己角度考虑问题,做出私藏成果,隐藏信息的行为;

   3.
发起讨论或在讨论中,必须遵守网站的发帖要求限制,以及网安相关部门对公共社区的技术要求,不给网站的可靠安全运行制造麻烦;



在大家都遵守承诺的前提下,参与者自由参与,分享快乐等一切合理的活动都是受到鼓励的,参与者参与项目所作的工作,以及做为参与者身份出现在网站发布的资料中,是受到保障的。



而网站有能获得哪些保障呢?假设如下:



    1.
财务控制,网站做为项目的资金的筹集者,具有从成本考虑,对某方案或者支出的一票否决权;

    2.
项目冠名,项目有个合适的名字,对于网站来说,不是没有意义。如果项目做得足够完善,最终一定会被广泛转载,有一个响亮明了的名字,对提高网站的影响力是有直接促进作用。项目冠名权,我设想是给出资人的权力,网站在运用冠名权的时候应照顾到捐助者的利益(或者说与捐助者共同分享冠名权);

    3.
项目对外发布的文档,程序,硬件设计图,在醒目的位置,应使用logourl,文字描述等方式声明本网站的宿主身份,引导更多的人参与本项目的同时,扩大网站影响力;

    4.
捐助者的信息也会在项目发布的相关资料中获得陈述(比如,出现在参与者清单之后);



做为和网站相关的部分,顺便说一下我对于网站转载应用的看法,对于其他网站对项目信息的转载和引用,在遵守“网站资源转载必须标明出处”这一底线能够满足的前提下,我们应该欢迎转载和引用。



对抗项目成果被盗用再发表,我的哲学和开源思路一样:“与其担心被人偷偷拿去用,不如主动大力宣传扩大影响力”,试想,盗用一个家喻户晓的项目不是掩耳盗铃吗?鼓励项目的正面信息广泛传播,也就打压了盗窃者的生存空间。项目组欢迎各位感兴趣把项目的进展状况和各阶段成果传播开来,包括对资料进行备份,整理,转载到其他网站上,甚至在其他网站上做项目镜像,前提是遵守下列要求:

     1.
不能抹杀ourdev做为项目主站的声明和相关url地址;

     2.
不能删除项目参与者信息;

     3.
不能删除捐赠者信息。



项目组会定期发布版本包,文档包,精华讨论包,以方便大家收藏和转载。



*
上述关于转载的约束和项目开源思想并不冲突,准确的说上述只是互联网虚拟世界信息转载基本道德要求,事实上发生冲突的机会也并不是很高。而现实社会中,有人要拿这些资料去做产品卖钱,参与者包括网站能够把握的机会就太小了,还是不要自寻烦恼的好 



**********************************************************************************************

6.项目跟踪工具 进度 任务分派 项目周报 




需置顶,并随时保持更新的帖子:



1.
项目启动文档,项目计划书和技术规格说明书;

2.
报名贴,所有报名的朋友,请在此跟帖按照第4点建议的内容跟帖报名;

3.
项目组成员和状态公布(每个跟帖为一个参与者信息,由版主维护,记录每个参与者当前的工作状态,以及参与过的任务历史日志);

4.
任务分解结构,以及进度和现状,可用图表形式表达,力求做到一目了然;

5.
任务招领贴(包括历史日志);

6.
财务收入跟踪(捐款贴);

7.
财务支出跟踪(消耗贴);

8.
关键任务的交流和进展状况(顶楼由版主维护,跟帖为任务内部交流,如果问题较多,也可以分别开贴讨论,在顶楼挂接相关子议题的url地址)

9.
版本发布贴,跟踪相关可下载信息(原理图,PCB,程序,文档)的最新版本,以及版本发展历史;

10.
项目周报,可包括电路设计、PCB 设计、程序设计的周release包,文档包,本周精华贴连接清单。



出之:www.ourdev.cn
 网友:  Cocal  
智能充电器(网站开源项目)思路和基本原则

http://www.ourdev.cn/bbs/bbs_content.jsp?bbs_sn=834011&bbs_page_no=3&bbs_id=1026

   



PARTNER CONTENT

文章评论0条评论)

登录后参与讨论
我要评论
0
5
关闭 站长推荐上一条 /4 下一条