开源治理实践和企业案例研究

作者：Ted Liu  | 编辑：舒敏

前言

本文为开源社理事长刘天栋于今年 KubeCon+CloudNativeCon+Open Source Summit (2019年6月25日，上海世博中心) - 开源领导力、战略和治理分会场里的演讲内容。演讲幻灯片可以于此处下载： https://kccncosschn19chi.sched.com/event/eadb457b800e31b3ad95c9c687914941

01

—

Ted介绍

• 开源社理事长、联合创始人

• ASF Member , ASF Incubator PMC Member , Mentor

• 曾历任 Oracle 、Turbolinux 、Microsoft 开源相关职务

邮箱：

ted@kaiyuanshe.org

tedliu@apache.org

领英： https://www.linkedin.com/in/liuted

02

—

开源社简介

开源社成立于2014年10月， 是由支持开源的个人、社区及企业， 依“贡献、共识、共治”原则， 所共同组成的开源联盟， 旨在共创健康可持续发展的开源生态体系， 并推动中国开源社区成为 全球开源软、硬件的积极参与及贡献者。

开源社的使命

开源治理

• 完整的开源治理文

• 档与知识库

• 开源许可证

• 开源流程指导

• 法律顾问委员会

• 中国开源生态系统

• 年度报告

• OSI 联盟成员

社区发展

• 中国开源年会 COSCon

• 高校巡回宣讲 - 开源者行

• 线上/线下黑客马拉松

• 开源社X 系列沙龙

• 社区伙伴合作

• Linux Foundation - KubeCon , OSS Summit

• 云计算开源产业大会

• COSCUP (Taiwan)

 

国际接轨

• Apache Software Foundation

• FreeBSD Foundation

• FOSS.Asia

• GNOME Foundation

• Linux Foundation

• Node JS Foundation

• Open Source Initiative

• Open Innovation Networks

 

开源项目

• KCoin - 开源贡献激 励平台

• Open Hackathon - 开放黑客松云平台 (2018 微软捐赠)

• 微信机器人

• 官网开发组

• 中国开源年度报告(2016, 2017, 2018)

开源社组织架构图

开源社理事会成员– 2019届

刘天栋 Ted 理事长

(社区治理：法务、财务、成员发展、品牌)

陈阳 Emily 副理事长

(国际接轨与资源整合：企业合作、顾问委员会)

庄表伟 执行长

(管理各工作组，及技术项目：基础设施、创新项目)

辛庆 Cynth 理事、秘书

(活动运营：线下活动、比赛活动)

王伟 Will 理事

(教育推广：高校合作、开源教育)

李思颖 Mabel 理事

(财务及品牌运营：财务、媒体)

 

林旅强 Richard 理事

(社区拓展：社区合作、开源生态)

开源社执委会成员– 2019届

庄表伟 执行长

梁尧 法律事务组

王俊波 基础设施组

钟源 成员发展组

 

李思颖 媒体品牌组、财务组

辛庆 线下活动、 社区合作组

赵生宇 高校合作组

陈阳 企业合作组

李建盛 开源教育组

加入我们

关注开源社微信/微博公众号

申请加入开源社社区交流群（微信）

登陆：http://www.kaiyuanshe.com

03

—

开放与开源

04

—

开源治理的实践

开源治理与开源许可证

 

• 开源治理是社会/社交框架

  OSS Governance is a Social Framework

• 开源许可证是法律框架

  OSS License is a Legal Framework - Ross Gardler , President , ASF

 

开源项目办公室 (OSPO)

推荐：每家公司都应设立开源项目部门( OSPO )–李建盛, 2017-03-15,开源之道

行业巨头

Google: https://developers.google.com/open-source/

Intel: https://01.org/

Microsoft: https://microsoft.com/opensource

Samsung: http://commit101.org/

新兴公司

Box: http://opensource.box.com/

Dropbox: https://opensource.dropbox.com/

Facebook: https://code.facebook.com/opensource

Github: 

http://todogroup.org/blog/why-we-run-an-open-source-program-github

Twitter: 

http://todogroup.org/blog/why-we-run-an-open-source-program-twitter/

Twitter 学到的教训

Bootstrap 项目

• 聪明地选择许可证

• 由 Apache License 2.0 转换到MIT

• 一开始就要选对许可证（更 宽容 - Permissive）

• 项目成败难以预料

• 务必确保工程师有时间管理 开源项目（社区）

• 确保项目有一个以上的项目主要负责人或交给社区管理

Mesos 项目

• 与高校/学术界密切合作

  UC Berkeley AMPLab

• 与开源基金会密切合作

  获取更佳实践

  培养协作，加速成长

TWEMCACHE 项目

• 尽量避免分叉 ( Fork )

• 别让上游/主干感到意外

Parquet 项目

• 在开源之前，先在内部分享代码以测量未来潜力

• 与协作伙伴携手发布势头

  2012夏: Twitter与Cloudera合并Parquet计划

  2013三月: 宣布开源

  2013七月: 发布1.0版; 获得来 自5个不同组织的18个贡献

  2014五月: 进入阿帕奇孵化器; 40+贡献者

  2015五月: 项目毕业成为 ASF顶级项目; 60+贡献者

贡献带来影响力

社区不会凭空诞生

开源项目办公室成为核心

问题一#

• 不允许使用任何开源软件

• 仅限于如果没有其他解决方案存在

• 如果开源软件优于其他解决方案
  

• 开源软件和专有软件解决方案一视同仁

• 如有开源解决方案时优先考虑

开源策略

• 组织意图及目标

• 清晰的商业表达

• 发展策略的价值

开源政策

详述规则

• 法务政策

• 获取政策

• 使用政策

• 支持政策

• 管理政策

• 伙伴政策

• 贡献及发布政策

领导支持

• 转化争议

• 预算/资源

• 以身作则

利害关系认可

• 确保遵循流程

• 最佳途径

  高层决心（如软件开发）

  理解开源软件策略

  参与到政策及流程

  快速批准关键活动

  参与定期检讨

问题二#

• 你的企业用何种技术追踪开源软件的使用（可复选）

• 没有用任何正式的软件库存系统

• 每个项目自行报告

• 所有项目自行报告

• 人工审计已经自行报告的软件项目

• 自动化代码扫描工具

资金

• 咨询，软件或硬件解决方案

• 优化管理

  咨询顾问

  代码库的评估

  软件扫描工具

  批准、追踪及管理工具

  技术支持及保障

资源库

• 原因-了解企业现状

• 时机-建立库存清单；定期检查更新

• 内涵-按部就班，逐步拓展

• 选项一：自行报告（耗时耗力，不准确）

• 选项二：扫描系统或应用

配置/准备：调研与认证

• 调研：

  开源替代方案：Osalt

  开源软件发现、评估、协作网站 Ostatic

  专业第三方厂商

  社区数据

  开源项目主页

• 认证：自主/第三方

  社区健壮度，采用度，法务考量，技术 支持等

  企业架构师的评估及推荐

配置/准备：获取代码

• 一般代码资源库：

  GitHub, Soureforge.net, java.net 等

  确认由式来源取得代码

  小心未经审查的镜像（或 Maven 资源库）

• 内部资源库

  自行维护内部资源库

• 咨询服务厂商

  可信赖的代码来源

  已认证的软件

  审核过的代码

运营开源政策

• 需要做什么?

   利用技术手段以强力执行开源政策

•  所需能力？

  依据开源政策允许/避免代码下载

  追踪下载情形

  要求在下载时宣告使用理由

  要求在下载时先取得批准

开源使用守则：六个简单规则

(Ibrahim Haddad  三星美国研究院研发副总裁兼开源小组负责人)

• 将开源代码整合到产品中

• 从第三方接收的软件

• 所有软件 (专有软件组件)

• 产品交付前履行义务

• 开源组件的许可审核

• 任何变更的组件

请求与批准

• 原因? 例外处理原则

• 时机? 下载前，开发前，投产前，或发布前

• 参与者? 申请人及批准者

• 途径?

  人工处理或自动化系统（自行开发或第三方）

  流程及规则自动化，评论及反馈追踪，可客制化

审计

• 原因? 政策，许可证，内部智慧财产权

• 时机? 

  应用生命周期：开发/组建，测试，模拟上线，投产

  定期审计+不定期抽检

• 对象?

  使用中的开源项目及许可证

  选项: 开源软件抄袭 (如果对外发行)

• 手段?

  信息比较：政策，使用者的宣告/请求，代码扫描

  找出违规并矫正修复

报告

• 开源软件库存及更新定期报告

• 开源软件下载及用户宣告

• 请求及批准的状况

• 政策合规及违规状况

• 应用“物料及许可证清单”

开源治理工具

自动化代码检查可扫 描代码库以检查许可 证, 许可证兼容性和 其他因素。

• 方法论：Linux  基金会  SPDX ,

• OpenChain 工具 ：FOSSology , OSS Discovery , BlackDuck , WhiteSource , FOSSid , Flexera …

追踪&审计 

资源库

批准

政策

Google 是如何做开源的

2004年成立开源项目办公室

• 服务7.2万员工，开源项目约 2000~4000

•  15名成员：律师, 推广团队, 工程团队 (开发自动化合规性检查工具，支持其它开 发团队)；跟踪公司范围内所使用开源项目状况，包括构建的合规性、代码引入和 发布的时间等；

• 鼓励公司所有员工，在他们主要的开源工作（图形设计师、技术作者、营销人员 或开发者）之外，要去花20% 的时间去参与到公司其他的项目中去。促进团队交 叉合作，帮助理解并改进公司层面上的全局项目。

坚持三个重要的原则

• 帮助其员工使用开源项目; 发布开源到开源社区; 支持与拓展全球开源生态（如 GSoC，TODo Group …）

相关治理与政策  

( https://opensource.google.com/docs/ )

• 发布一款新的开源项目遵循那些流程

  https://opensource.google.com/docs/releasing/

• 如何为其它开源项目提交补丁

  https://opensource.google.com/docs/patching/

• 如何管理引入第三方的开源项目以及如何使用

  https://opensource.google.com/docs/thirdparty/

• 为何仅仅使用某些特定的许可协议的项

  https://opensource.google.com/docs/using/license/

• 为何所有接受到的补丁都遵循许可协议

  https://opensource.google.com/docs/cla/policy/

TODo Group ( https://todogroup.org/ )

Google 在 2014年协助组建的众多商业公司组成论坛，讨论参与开源的最佳实践和协作。

05

—

选择许可证

开源治理与开源许可证

• 开源治理是社会/社交框架

  OSS Governance is a Social Framework

• 开源许可证是法律框架

  OSS License is a Legal Framework

- Ross Gardler, President, ASF

分辨开源软件与其他

Freeware (免费软件）

– 免费使用

– 限制用途、不给源码

Shareware (共享软件)

– 通常免费使用，有限制 (时间或功能)

– 通常另有商业版本可以购买

– 限制用途、不给源码

Public Domain (公共领域，公共财)

– 著作权期间结束、抛弃著作权

– 没有权利

开源软件的定义

OSI 核准的每项许可协议都符合开源定义( http://www.opensource.org/docs/definition.html ）的条件。该定义包含10项标准。其 中最重要的是软件可以自由再发行，直接访问源代码，以及允许对软件与演 绎作品进行修改并在相同的许可条件下发行。

1.可以自由再发行  Free Redistribution 

2.直接访问源代码  Source Code 

3.衍生作品 Derived Works 

4.作者源代码的一致性 Integrity of The Author's Source Code

5.许可证的分发 Distribution of License

6.不歧视任何个人或团体 No Discrimination Against Persons or Groups

7.不歧视任何特定用途 No Discrimination Against Fields of Endeavor

8.许可证不得限于某个特定产品 License Must Not Be Specific to a Product

9.许可证不得限制其他软件 License Must Not Restrict Other Software

10.许可证必须保持技术中立 License Must Be Technology-Neutral

主流的开源许可证

• Apache License 2.0

  http://www.kaiyuanshe.cn/article/5.html

• BSD 3-Clause "New" or "Revised" license (BSD-3-Clause)

  http://www.kaiyuanshe.cn/article/9.html

• BSD 2-Clause "Simplified" or "FreeBSD" license (BSD-2-Clause)

  https://opensource.org/licenses/BSD-2-Clause

• GNU General Public License (GPL)

  http://www.kaiyuanshe.cn/article/7.html

• GNU Library or "Lesser" General Public License (LGPL)

  http://www.kaiyuanshe.cn/article/8.html

• Mozilla Public License 2.0 (MPL-2.0)

  http://www.kaiyuanshe.cn/article/10.html

• MIT license

  https://opensource.org/licenses/MIT

• Eclipse Public License (EPL-1.0)

  https://opensource.org/licenses/EPL-1.0

• Common Development and Distribution License (CDDL-1.0)

  https://opensource.org/licenses/CDDL-1.0

http://www.kaiyuanshe.org/article/ (中文版)

https://opensource.org/licenses/category (英文版）

选择开源许可证

我该选择哪一种许可证？

• 跟着我喜爱的开源社区？

• 你会生气吗？

• 为你老板省律师费？知名/通用

著作权/著佐权 ( Copyleft )？

• 你想强制他人贡献回馈吗

• 专利保护？

• 允许转为商业用途？

非软件的许可证

文档、视频、图片、多媒体

http://creativecommons.org/choose/

精彩推荐

公交车上的合伙人

微信机器人能够做些什么事？

 开放式组织与开放式协作

 开源是自由的，永远

围绕开源的系列思考 - 个人篇