开源项目
一，概述
我们经常可以在所安装的开源软件中见到License文档，而你对这些软件许可证及其中的一些概念了解否？这里是最近我收集的一些资料。
先来看看几个概念：
1. GUN（指GUN计划）
* GNU是“GNU's Not Unix” 的递归缩写。GNU计划，又称革奴计划，是由Richard Stallman在1983年9月27日公开发起的。它的目标是创建一套完全自由的操作系统。Richard Stallman最早是在net.unix-wizards新闻组上公布该消息，并附带一份《GNU宣言》等解释为何发起该计划的文章，其中一个理由就是要“重现当年软件界合作互助的团结精神”。UNIX是一种广泛使用的商业操作系统的名称。由于GNU将要实现UNIX系统的接口标准，因此GNU计划可以分别开发不同的操作系统部件。GNU计划采用了部分当时已经可自由使用的软件，例如TeX?排版系统和X Window视窗系统等。不过GNU计划也开发了大批其他的自由软件。
2. Open Source（开放源码）
* “Open Source”用于描述那些源码可以被公众使用的软件，并且此软件的使用、修改和发行也不受限制。开放源码软件通常是有版权（copyright）的。它的许可证可能包含这样一些限制：着意维持它的开放源码状态，著作者身份的公告或者对于开发的控制。实际上，开源软件同时涉及源码本身和开发过程，涵盖了三个方面的意义：免费分发的源代码、模块化的体系和集市式的开发。在这种开发方式中，任何地方的任何人都可以参与最终产品的制造，三个方面互相之间有密切的联系，集市式的开发过程给开源软件以强大的改错能力，因为它将程序中的错误公开给了数量巨大的观众，他们都是潜在的改错者。另一方面，任何人都可以复用和发行开源软件的代码这一事实又支持了公众利益，因为创新的观念被整个集市所共享。另外，“open source”这一术语还被延伸到其他智力团体中，指那些可通过公开手段获得的智力资源，比如报纸、教学课件等。
3. Shared Source（共享源码）
* “Shared Source”是2001年5月微软发布的一项新战略，承诺将与合作伙伴、客户“共享”Windows的源代码，同时不破坏知识产权保护，在与客户、合作伙伴共享源代码与支持R&D所需的IP保护之间寻找一种平衡的途径，是微软应对开放源码的战略部署。但是并不表明微软准备放弃其商业化、私有化的本质，Shared Source Initiative的许可证存在着不同程度上的限制。例如，“reference licence”仅仅允许用户查看代码。当然微软已经提供了多种多样的Shared Source License，针对不同产品有着不同的限制。
4. Free Software（自由软件）
* “自由软件”是指用户使用、复制、研究、修改和分发软件的自由，更准确地说是指三种层次的自由：
1. 研究程序运行机制，并根据你自己的需要修改它的自由
2. 重新分发拷贝，以使其他人能够共享软件的自由
3. 改进程序，为使他人受益而散发它的自由
* 自由不是免费，自由软件它不能保证有免费获得的自由。自由软件在分发/获得方面是双模式的，就是说，可以免费共享，也可以商业买卖。
5. Open Source Software（开源软件）
* 开源软件，简称为OSS，就是在开放源码许可证下发布的软件，以保障软件用户自由使用及接触源代码的权利。这同时也保障了用户自行修改、复制以及再分发的权利。严格地说来，开放源代码软件与自由软件是两个不同的概念，只要符合开源软件定义的软件就能被称为开源软件。自由软件是一个比开源软件更严格的概念，因此所有自由软件都是开放源代码的，但不是所有的开源软件都能被称为“自由”。为了保护初始源代码的完整性，原创者可以通过有关许可协议，对开源软件源代码的后续修改行为规定一定的限制。但在现实上，绝大多数开源软件也都符合自由软件的定义。比如，遵守GPL和BSD许可的软件都是开放的并且是自由的。
二，许可证
不同开源软件许可证开放程度的异同
* 共同点
1 、发布的义务 —— 将获得的源代码再发布；
2 、对发布的源代码的要求 —— 须保证源代码的完整和可以被获得；
3 、允许修改 —— 可以根据获得的源代码产生演绎作品。
* 不同点 ……
OSI（开放源码计划 - Open Source Initiative）协会网站上批准的许可证：
The Approved Licenses
For your convenience, we have collected here copies of the licenses approved by OSI. If you distribute your software under one of these licenses, you are permitted to say that your software is “OSI Certified Open Source Software.”
The “classic” licenses, GPL, LGPL, BSD, and MIT, were the most commonly used for open-source software before the Mozilla release in early 1998. The Mozilla Public License has since become widely used. Many other licenses have been submitted for review and approval by OSI. As you can see, the list of approved licenses is growing.……
开源项目管理
一，概述
“开放源代码不仅仅只是软件源代码而已，它们也悠关自由、分享和社群精神；创作、美和黑客所谓的‘有趣’。它们也悠关人人心中的密码，是我们心中至善的根源，反抗至恶，永世长存。”——匿名
开源的魅力——一群素不相识、甚至不能谋面的人因为开源而聚到了一起，并为了共同的目标而兴奋的工作着。
另一方面，教导比较年轻的一代采用比较笨的方法，可以确保老人的竞争力……
二，开源项目的开发模式
1. 小型开源软件开发模式 2. 中型开源软件开发模式
其特点为拥有3-5 名核心维护人员，参与开发的人员10人-40 人之间，采用CVS 进行代码管理，通过maillist/irc进行开发交流，有明确的开发计划和日程。用户提出的错误报告和修正数量很多，并且有一些分支产生。 3. 完全封闭的商业Open Source软件 4. 比较封闭的大型Open Source软件的开发 5. 由商业软件转化过来的大型Open Source软件开发. 6. “独裁”式的大型Open Source软件的开发. 7. “民主”式的大型Open Source 软件的开发.
三，开源项目的风险
１，人员交流：开发志愿者多是异地，因此交流会成为最大的障碍。网络的普及在一定程度上缓解了这个问题，但如果不贯彻落实反而会在一定程度上掩盖了交流的风险。为了规避“人员交流”的风险，可重点考虑招募能够见面的志愿者。
２，开发时间：开发志愿者是在业余时间进行开发，因此开发时间很难保证，更要为中途被迫离开项目组的坏消息作准备。
３，开发热情：完全凭借的热情能维持多久。
４，人员水平：能找到经验与技术上的高手自愿参与么?
四，开发志愿者加入的动机
1．被开源吸引。
2．被项目本身吸引。
3．想通过参与提高自己。
五，人员招募方式
1．尤其在小项目中，可以从身边找几个志同道合者。但是项目较大，人较多的话往往就不合适了。 2．如果自认为项目有足够的吸引力，不妨通过sourceforge，共创软件联盟（http://www.cosoft.org.cn/）等开源网站招兵买马。也可以考虑完全通过网络开发。 3．如果项目已经有了足够的影响、不是从头做起，并且有足够信息的话，也完全可以亲自发布广告，招兵买马。
六，基本运作方式
通过和项目顾问共同商量确定基本运作方式。根据需要可借鉴封闭开发模式的内容。
１，开发队伍组织模式：分散开发人员通过Internet组成开发队伍
２，发布版本时间:固定时间发布，但有模块完成时尽早发布模块
３，提供源码对象：对公众发布
４，负责测试部门:无专门测试部门
５，管理手段：按照项目生命周期管理，强调协作，自愿参与
项目团队建立起来后，就开始了正式的团队运作。为了加强交流，对于能够到会的人员每周进行一次项目例会，不能到会的则参与每周一次的网络会议。项目的第一次例会在X月XX日启动，原计划在X月XX日结束，以周为时间划分，共计X周。整个开发周期计划从X月XX日至X月XX日，共X个星期。
为了规避风险，最理想的当然是全部严格遵循软件工程（可借鉴TSPi小组软件开发过程的思想)。但开源团队实际上是松散的，单纯的较严格开发方式反而并不高效，所以要进行调整，比如项目采用迭代式开发，分为两个阶段。在项目总体采用两阶段的需求、设计、实现、测试的基础上，根据功能的需要，在某些独立模开的开发上采用下面两种并行的开发方式。
一、对于需求非常明确、有相当的把握开发成功的成熟的独立模块，可以交付给熟练的开发人员独立开发，开发人员可以按照自己喜爱的开发方式，只要在规定的时间内完成开发即可，不必严格遵循软件工程的各个流程、但要保证开发的模块的质量。
二、对于无把握的或需要探索的新功能模块的开发，由于风险很大，也独立提出。要求本模块的开发人员在较短的时间内完成功能演示的开发。因为只是功能演示，对其代码质量不进行要求，但需要能够明确模块的实现方法，便于真实系统的应用。
这样，整个开源团队就存在这三个并行前进的三条线路：遵循软件工程进行迭代开发的主团队、进行成熟模块开发的小分队、以及进行新功能尝试的探索的探险队。
七，组织结构
小项目人员少，组织结构简单。由于项目组长实际对项目的把握较熟和可时间投入较多，可以同时承担开发经理的工作，并直接领导美工。顾问协作项目组长的工作。每个核心开发人员负责一个具体子系统的开发，考虑到项目组长工作较重而繁琐，其中一个核心开发人员同时承担一些开发经理助理的工作，项目组长本身不担任核心开发工作。
如果人员招展到了十数人甚至更多，就要调整组织结构了。按照一般的做法，可把开发团队分成2－3个小组，每个小组选出组长，组长则向项目领导汇报。但如果是项目中途进行这个调整又是相当困难的：一方面开发工作已经开始进行，让原有人员调换角色或者调整开发内容将是非常困难的；另一方面，整个开发团队中除了项目组长之外，其它人都缺乏对全局的系统的足够了解和足够的工作时间，因此很难选出合适的人员承担小组长的角色。所以要进行协商，如最终的组织结构如下：
1． 保证已经开始工作的核心开发人员的工作内容基本不变，辅助开发人员配合核心开发人员工作；
2． 为了不增加核心开发人员的管理工作量，没有设置开发小组长的角色；管理工作直接由项目组长负责；
3． 为了防止项目组长事务工作过多，加强开发经理助理这一角色的作用；同时多安排一个辅助开发人员来配合其工作。
这样会使项目组长要承担很多的管理、协调工作，在实际中还有一些开发工作，比别人辛苦。如果他是全职投入，那是最好的。
八，工具的使用
对于通过网络协作开发的开源项目，协同开发工具自然也不可少。现在想来，我们用到的工具还真是相当的多。
１，网站：首先建立自己的网站，确保团队内外的人都能明确了解项目的进展，这是整个项目对外的起点和窗口。
２，版本控制工具：由于代码量越来越大，在开发中，每个成员都要保留一个副本，在开发中非常容易引起冲突。因此版本控制工具是非常必要的。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也是现在一个比较流行的发布工具，也可以考虑。
10，Bug管理：可以考虑使用Bugzilla，不过我们还没有使用任何bug管理工具。
11，最重要是交流的工具：
空气是最有效最重要的。另外可通过即时通信工具(QQ，MSN), 网络语音聊天工具，论坛，短信息，邮件列表，网络会议，wiki，电子邮件等等，尽量弥补无法当面交流的风险。
九，商业模式
其实开源项目的最大魅力之一就是商业。开源<>免费，开源和商业并不是冲突的。
软件作为一个以人的智慧结晶为主要成本的数字产物，主要通过销售将源代码编译、打包、包装过的软件包获得商业价值。程序源代码作为软件的基础材料，具有可察看、可复制、可复用等特点。开放源代码是使软件开发者散失了获得劳动回报的主要途径，因此程序员必须在这种新的开发模式下通过其他商业模式获得回报。
从上世纪八十年代开始，从事和关心开源运动的人们就不断探索能够为开源程序员获取回报的开源商业模式。随着时间的推移，开源运动在发展过程中逐步形成了一些较为可行的商业模式，这些商业模式主要包括：
１，双授权：典型实例：mysql
通过针对个人/商用进行不同授权或不同版本（基本版本、 企业版本）进行不同授权。
２，咨询顾问：典型实例：jboss
提供技术文档、培训服务、咨询服务、系统规划实施等技术服务；
３，应用服务：提供基于开源软件的网络应用服务（ASP）；
４，硬件捆绑：捆绑赞助商或开源软件开发商硬件，如Widget Frosting：一个主要生产硬件的公司（其中的某一部分软件不做为主要利润来源）会选择开源软件来提供更好的产品，比如 IBM 塔式计算机就预装了 Turbolinux 操作系统；
５，卖附属品：包括书籍、T恤衫、咖啡杯，以及Linux企鹅玩具……
６，提供服务：典型实例：Redhat
jboss虽然送出产品，但是卖的是品牌，卖的是服务，Redhat 一直在这样做；
７，市场策略：通过提供开源软件使自己占有市场，Netscape 曾经因此决定公布 Navigator 的源代码。
十，开源的不成熟与危机：多数的开源软件还并不够好。开源网站绝大部分开源项目只是开发者个人在工作，少有人问津，真正推出稳定的1.0版的软件只占很少的比例。
十一，实战：
【项目大事记】
* 项目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%的“人天”是大家完全不能工作的） 从图中可以看出，在整个开发过程中，存在着大量的成员不能参与工作的时间段，具体的原因主要有五一长假、期末复习、假期回家、外出等。这个似乎是开源项目不可避免的问题，在做计划时需要特别注意。
工作热情也是项目启动时担心的一个风险，从事后回顾来看，这个风险并没有发生，大家的热情都很高，没有发现谁最后对项目缺乏热情而离去。
再来谈“开发人员的水平”，从我们这次招募的人员来看，总的说来人员的技术水平属于中等偏上，对搜索引擎的技术了解则普遍不多，基本没有什么招到技术高手，不过这一点丝毫不影响我们项目整体的进展。
最后再来谈谈另一个风险——“交流”，这个确实是最大的风险。因为开发成员都是志愿者，大家分布在不同的实验室，甚至不同的省市，交流起来比较麻烦。尽管我们使用了尽可能多的交流方式，但依然感觉到交流的明显不足。我们在第一次跌代结束后做过一个调查，其中一个问题就是“你认为第一阶段中出现最大问题是什么？”从大家的回答的结果来看，交流不足是最大的问题。我们在第二阶段有意识加强了交流。主要通过：管理上制定一些制度，迫使大家必须交流；提供更多的交流途径（比如发现论坛大家用的不多就启用了邮件列表），大家有意识加强交流等。从收效上来看确实有一定效果，但依然感到交流不足。
参考资料：
Eric Raymond 1999年《魔法大锅炉》/《大教堂与市集》(TheMagicCauldron)
大概是其中最为重要的一篇。这篇文章分析了开放源代码现象不断发展的经济基础。首先推翻了一些流行的关于程序开发资金和软件价格结构的神话。给出了一个关于开放源代码协作稳定性的搏弈论分析。给出了九种开放源代码开发的可发展模型，其中两种是不盈利的，七种是盈利的。接着发展了一种定性的理论，说明什么时候封闭代码在经济上是合理的。然后考察了当前市场上发明的几种新颖的开放源代码开发的盈利方法学，包括赞助系统和任务市场的引入。最后做出了结论，试着对将来做了一些预测。
使用open source产品组装你的web应用架构 http://www.cnblogs.com/kavenmo/archive/2004/10/05/49101.html 基于Internet的软件工程策略http://www.csiaspb.org/show.asp?id=34
参见
Ralasafe开源数据级权限管理中间件发布1.0 RC2版
开源磁盘加密软件Truecrypt发布了7.0版
id Software创始人和著名游戏开发者John Carmack同时宣布公布两款游戏的完整源代码：《重返德军总部》和《重返德军总部：敌战区》
微软再次向开源开发者示好，它宣布发布Web Sandbox的源代码。Web Sandbox是用于测试Web网站内容和确保环境安全的程序。Sandbox源代码采用Apache 2.0许可证发布，这一开源许可证允许内容创作者保持版权，同时允许其他人开发他们自己使用的产品。
EULAlyzer會為你分析軟件的條約之內的Advertising、Third Party以及Web Site Address範疇，從而讓你對這協議有初步了解。如果你不願仔細去翻閱這些EULA，但又希望在安裝軟件之前稍為了解EULA內有沒有甚麼「不平等條約」，那可以試試。若果你在當中發現甚麼特別的地方，你便可以仔細進入這協議的內容去看。
Alpine 1.00邮件客户端源代码和文档，向上兼容现有的Pine用户。Alpine采用Apache License 2.0，源代码可以让使用者从用户界面到底层邮件引擎进行彻底改造，Web email 用户也可以用它作代理接受邮件。
开源硬件Open source hardware, what is it? - A start...
两篇不错的论文，值得一读：
1. 开放源代码软件及其许可证的法律特征研究:发表在北大法律信息网上，作者马骁。这篇论文收录于法律出版社出版的《网络法律评论》一书的第二卷中。
2. 开源软件的知识产权问题研究——制度诱因、规则架构及理论反思:发表在同济大学知识产权学院网站上，作者张韬略。这篇也收录在《网络法律评论》一书中的第5卷上。
附：维基百科（wikipedia.org）网站上有关的具体内容（每篇里都有一些这里未提到的其它概念的链接）：GNU计划 自由软件 开放源码