衡量开放性
我们目标是衡量开放性，考察开源项目是“开放”还是“封闭”。这方面很少公开讨论或者并许可所掩盖。我们通过透明和全面的方式定义衡量开源项目的管控，如同定义开源许可，分类为“copyleft”，“宽容”等等。
和开源许可不同，管控模式由隐晦术语，条件，以及项目访问，影响，决策和衍生物控制点组成。我们研究8个移动开源目：Android， MeeGo， Linux， Qt， WebKit， Mozilla， Eclipse和Symbian。我们访谈了社区领袖，项目代表，学院和开源学者，了解管控如何在项目中发挥作用，如何衡量和定义好的实践方式。
在报告中，通过开源管控指数衡量开源项目的开放性。指数包含4个方面共13个指标：
1、访问：最新源代码可获取性，开发者支持机制，公开路线图和透明的决策过程。
2、开发：开发者对项目内容和方向的影响力。
3、衍生物：开发者从源代码中创建和发布衍生物的能力。
4、社区：社区架构公平对待开发者。
开放管控指数 | |
Android | 23% |
QT | 58% |
Symbian | 58% |
MeeGo | 61% |
Mozilla | 65% |
WebKit | 68% |
Linux | 71% |
Eclipse | 84% |
我们根据开源管控指数进行了排序，越高分数说明越开放。开源管控指数衡量项目在透明度，决策制定，重用性和社区架构方面的开放性。
开放管控和开源相伴，用于确保开发者和用户自由使用、修改和build。很多方面，开源管控所涉及的都是开源许可未覆盖。我们希望研究可改变公众对开源使用透明度的理解。
Access方面：
1、是否开源代码可以被所有开发者在同一时间自由获取？
得分：Android（1）Eclipse（4）Linux（4）MeeGo（4）Mozilla（4）Qt（4）Symbian（4）Webkit（4）
评分 4：Yes
评分 3：No - 在下面方面有差异 a：开发者；b: 源代码；c：时间
评分 2：No - 在上面所讲的2个方面有差异。
评分 1：No - 在上面所讲的所有方面都有差异
2、源代码许可是否宽松（permissive）的OSI许可？
得分：Android（4）Eclipse（3）Linux（2）MeeGo（2）Mozilla（3）Qt（3）Symbian（3）Webkit（3）
评分 4：Yes - 提供宽松的许可（也就是Apache，BSD，MIT）
评分 3：Yes - 提供弱copyleft许可（也就是EPL，GNU LGPL v2/v3）
评分 2：Yes - 提供强copyleft许可（也就是GNU GPL v2/v3）
评分 1：No - 不提供许可/采用私有许可
3、开发者支持机制：项目邮件列表，论坛，bug跟踪数据库，源代码库，开发者文档，开发工具是否可被所有开发者开放？
得分：Android（2）Eclipse（3）Linux（3）MeeGo（3）Mozilla（3）Qt（3）Symbian（3）Webkit（3）
评分 3：Yes - 开发者支持机制对所有开发者公开
评分 2：No - 开发者支持机制受限，例如Android不提供bug跟踪数据库的访问
评分 1：No - 差的开发者支持机制
4、项目的路线图是否公开？
得分：Android（1）Eclipse（3）Linux（2）MeeGo（1）Mozilla（3）Qt（4）Symbian（3）Webkit（2）
评分 4：Yes - 全部路线图可以获取，有明确路线贡献要求
评分 3：Yes - 路线图信息可以获取，但没有对贡献的要求或类似的
评分 2：No - 没有正式的路线图，但在buzilla上有对提交者和贡献者的需求
评分 1：No
5、透明的决策机制：项目会议纪要/讨论是否公开以便了解为何以及如何决策？
得分：Android（1）Eclipse（4）Linux（3）MeeGo（4）Mozilla（3）Qt（2）Symbian（4）Webkit（3）
评分 4：Yes
评分 3：Yes - 有一些信息，但是比较难获取而且不完整
评分 2：No - 但计划提供更多的信息以及让过程更公开
评分 1：No
开发方面：
6、透明的贡献和接受进程：是否代码贡献和接受过程是明晰，对贡献进展更新（通过Bugzilla或类似）？
得分：Android（1）Eclipse（2）Linux（2）MeeGo（2）Mozilla（2）Qt（1）Symbian（1）Webkit（2）
评分 4：Yes - 贡献和接纳过程清晰，并给出进度状态
评分 3：Yes - 贡献和接纳过程清晰，但没有进度状态提供
评分 2：No - 提供贡献过程，提供过程状态。
评分 1：No - 提供贡献过程，但不提供过程状态。
7、项目贡献的透明度：能否确定源代码贡献来源？
得分：Android（2）Eclipse（4）Linux（4）MeeGo（3）Mozilla（2）Qt（2）Symbian（2）Webkit（2）
评分 4：Yes - 有好的统计，并提供这些信息
评分 3：Yes - 需人工查找和收集不同来源的信息
评分 2：No - 可通过每个文件/贡献物的版权声明来查看这些信息
评分 1：No
8、成为提交者：是否有如何成为贡献的需求和进程文档？进程是否公平（是否所开发者都可成为提交者）？
得分：Android（1）Eclipse（3）Linux（3）MeeGo（2）Mozilla（3）Qt（1）Symbian（2）Webkit（3）
评分 3：Yes - 过程有文档锁门，所有开发者都可成为
评分 2：No - 过程模糊不请，无法确定是否对所有开发者都可以
评分 1：No - 提交处理限制为某些项目特定成员
9、提交者的透明度：是否可确定谁是项目的提交者？也就是那些有权利提交源代码到baseline的开发者。
得分：Android（1）Eclipse（3）Linux（3）MeeGo（3）Mozilla（1）Qt（1）Symbian（2）Webkit（3）
评分 3：Yes - 有好的项目统计提供相关信息
评分 2：No - 需通过人工查询，并从不同的来源收集这些信息
评分 1：No - 相关信息没有提供
10、是否贡献许可要求版权签署，版权许可或者专利授权？
得分：Android（3）Eclipse（3）Linux（2）MeeGo（2）Mozilla（3）Qt（3）Symbian（3）Webkit（2）
评分 4：Yes - 要求版权签署和专利授权
评分 3：Yes - 要求版权许可和专利授权
评分 2：Yes - 要求版权许可/“sign-off”过程（要求贡献者表明代码是他们自己并且是合法的自由软件）
评分 1：No - 没有贡献许可
衍生物方面
11、是否通过商标来控制如何和在何处使用平台，在发布前是否需要通过强制的兼容测试？
得分：Android（1）Eclipse（2）Linux（2）MeeGo（1）Mozilla（2）Qt（2）Symbian（1）Webkit（2）
评分 2：No - 可以自由贡献代码，可以使用项目商标，无完整正式兼容要求
评分 1：Yes - 在发布之前，代码必须通过正式兼容过程
12、应用衍生物推向市场的是否受到项目的批准、发布和发现的限制？
得分：Android（2）Eclipse（4）Linux（4）MeeGo（4）Mozilla（4）Qt（4）Symbian（3）Webkit（4）
评分 4：No -
评分 3：Yes - 批准、发布或发现有限制
评分 2：Yes - 批准、发布或发现中有两者受限。
评分 1：Yes - 批准、发布和发现都受到限制
社区方面
13、社区结构是扁平还是分层次（也就是是否根据成员身份有权利的区分？）
得分：Android（1）Eclipse（2）Linux（2）MeeGo（2）Mozilla（1）Qt（2）Symbian（1）Webkit（2）
评分 2：No - 没有正式成员关系，或成员和非成员之间的在开发和获取方面不存在差异
评分 1：Yes - 根据成员所处位置有不同的权利
