B. 开源管控
什么是管控
开源项目中有个重要的但被忽略的方面:开源管控模式。软件许可决定使用、copy和修改的权限,而管控决定透明度,影响力,创造衍生物能力。许可适用于源代码,管控适用于项目或者平台。更重要是管控模式描述了开源项目的控制点,是功败与否的关键。
许可 | 管控 | |
权利 | 使用、拷贝、修改 | 透明度、影响力和创建衍生能力 |
使用 | 7个许可覆盖70%的开源项目 | 没有统一定义 |
例子 | GPL、LGPL | 没有正式例子 |
法律 | 有法律约束 | 无法律约束 |
在OSS项目中,管控模型决定:谁来决策项目的路线图?决策的制定过程是否透明?是否任何人都可以在社区中加入讨论和会议,并在社区建立自己的地位?是否任何人可以基于项目创建衍生品?有哪些兼容需求以及它们如何强制执行?
总之,管控决定谁对项目或者平台具有影响力和控制力,不包含在开源许可中。如今以商业为导向的移动开源项目,仅了解开源许并不足够。管控模式决定项目是“开放”还是“封闭”。
管控模式分析
membership状态(Eclipse)。
调研超过半年时间,包括分析这些著名的开源项目,和社区领袖,项目代表,学院和开源学者之间的访谈。我们认同《West and O’Machony》观点,特别是突出管控、公开性和透明度的重要性,我们将重点放在管控模式,作为开源控制点来描述。下面的表格列出评判这些开源项目开放性的关键,用于说明项目属于开放的管控模式还是封闭的管控模式。
管控的关键点
- 获取
- 是否开源代码可以被所有开发者在 同一时间自由获取?
- 源代码许可是否宽松(permissive)的OSI许可?
- 开发者支持机制:项目邮件列表,论坛,bug跟踪数据库,源代码库,开发者文档,开发工具是否可被所有开发者开放?
- 项目的路线图是否公开?
- 透明的决策机制:项目会议纪要/讨论是否公开以便了解为何以及如何决策? 开发
- 透明的贡献和接受进程:是否代码贡献和接受过程是明晰,对贡献进展更新(通过Bugzilla或类似)?
- 项目贡献的透明度:能否确定源代码贡献来源?
- 成为提交者:是否有如何成为贡献的需求和进程文档?进程是否公平(是否所开发者都可成为提交者)。提交者是指向开源项目提交代码的开发者,在有些项目中也称为维护者和reviewer。
- 提交者的透明度:是否可确定谁是项目的提交者?
- 是否贡献许可要求版权签署,版权许可或者专利授权? 衍生物
- 是否通过商标来控制如何和在何处使用平台,在发布前是否需要通过强制的兼容测试?
- 应用衍生物推向市场的是否受到项目的批准、发布和发现的限制? 社区架构
- 社区结构是扁平还是分层次(也就是是否根据成员身份有权利的区分?)