openshift开源

过去一周， Github上的OpenShift Origin存储库看到一些来自外部贡献者的主要代码合并 ，这些代码将 MSFT .Net功能添加到OpenShift Origin平台中 。 测试了数千行新代码，并将它们成功合并到OpenShift Origin代码库中，然后该代码库立即可供任何人下载和部署。

.Net代码库的合并展示了OpenShift Origin社区如何成功利用GitHub的社交编码服务来帮助建立敏捷和开放的开发过程。 在Origin的文档部分中，可以找到出色的Contributor入门技术指南 。

除了使OpenShift在技术上易于构建，开发和测试之外，Origin的开放社区文化还使高效协作变得容易。 这种文化是从Red Hat的一些历史协作实践演变而来的，这些实践为社区带来了非常有生产力的效率，并使社区变得更加敏捷。

在红帽，我们认为，对于开源项目的未来增长和采用，拥有与供应商无关的精英管理流程以及适当的知识产权管理以取得成功至关重要。 这就是为什么我们选择Apache V2.0许可证的原因-并且为什么我们选择不要求提供者许可证协议（CLA）或建立基础。 这些选择通常会引起一些注意，因此，我想我将在本周的博客文章中借助Red Hat法律顾问Richard Fontana解决这些问题。

公开协作

加入开放社区时，您的第一个切入点是通过技术基础架构。 对于OpenShift Origin，该入口点是GitHub 。

对于开放源代码项目，基础结构的选择对项目本身的文化具有巨大影响。 GitHub之类的工具不仅通过提供版本控制，源代码管理，问题跟踪和社交协作机制来帮助我们构建项目，而且GitHub还使社区能够以开放透明的方式做出贡献和进行协作。

贡献有多种形式

OpenShift Origin项目的递归和开放性质在项目基础结构的许多层次上都可以看到，因为贡献形式多种多样。 通过对原始服务器核心项目的贡献，增加了对基于dotNet的环境的支持。 但是，许多贡献是以社区快速入门和墨盒的形式出现的。 通过Bugzilla提交错误报告，通过Trello协作进行功能跟踪，并加入StackOverFlow论坛上的讨论，也是做出贡献的好方法。 这些贡献的公共性质是赋予项目生命的力量。

克里斯·凯利（Chris Kelly）在他的《两点：自由软件的文化意义》一书中，谈到了“递归公众”，即围绕构建，修改和维护赋予其生命的基础设施的能力而组织的公众。

正如凯利所说：

“递归公众是非常关注物质和实际维护以及对自身作为公众存在的技术，法律，实践和概念手段的修改的公众；它是一个独立于其他形式的权力和能够通过产生实际存在的替代品来表达现有的权力形式。” - “两位：自由软件的文化意义”

OpenShift Origin社区是基于绩效的力量模型。 它是一个“递归公众”，它驱动着社区努力的方向，树立了包容性的基调，并确保了流程的公开透明。 权力掌握在做出贡献的公众手中。 一些捐款人是由其雇主支付报酬的，但是他们制定项目的权力是基于优点而不是基于任何按需付费模型。

开放式许可

每当有大量代码合并到项目中时，通常都会询问有关贡献的许可证问题。 从历史上看，Red Hat起源于Linux运动，在文化上与开放源代码许可的GPL模型紧密相关，尽管总是有例外。 在过去的几年中，许多重要的Red Hat项目（oVirt，OpenShift Origin和JBoss的关键部分）都根据Apache许可证发布了-这比GPL（总体）要宽容得多，产生的阻力较小我们的贡献者社区。

造成这种情况的原因很多，但最重要的原因可能是信任问题。 如果人们认为我们放弃了更多的控制权，那么我们更有可能围绕一个以Red Hat代码开始的项目建立成功的社区。 这与CLA问题有关，因为CLA是控制和施加不对称性的机制。 当公司发布开源代码时，Apache License 2.0非常擅长向社区发出“信任我们”的信号。 派生一个Apache License项目很容易，即使竞争对手也几乎没有限制如何将代码商业化。 参与是安全的。

降低参与障碍

红帽发起的开源项目比其他任何公司都多，其中绝大多数从未使用过任何CLA或版权分配。 大多数例外是来自收购的项目（例如，Cygwin或JBoss的各种项目），尽管即使项目来自收购，我们最近的趋势是消除任何现有的版权转让或CLA使用-例如其中就是GlusterFS。 红帽通常不使用CLA的原因与传统和文化有关-红帽是开源社区文化的真实产物，通常开源项目不使用CLA，实际上在开源社区中不使用CLA和版权出于上述所有原因，多年来分配工作一直是极具争议的政治问题。

Apache许可证2.0项目不需要CLA的原因还有一个特殊的附加原因：Apache许可证2.0实际上包含一个明确的许可证条件，该条件实际上表明，默认情况下，提交给上游项目的补丁程序将以相同的条款获得许可。贡献者收到了项目代码，即Apache License 2.0。 即使忽略上述所有其他要点，如果曾经有不需要CLA的许可证，那就是Apache许可证。

由于上述原因，我们决定在启动OpenShift Origin时不使用CLA。 CLA不是必需的，只会限制我们围绕OpenShift Origin建立协作和信任社区的努力。

为什么基金会，行业协会和其他围墙花园仍然坚持使用CLA

一些开源项目组织正在慢慢接受“社交编码”，但是仍然像非对称CLA那样紧紧地限制了参与障碍。 并非总是很清楚为什么要使用这种CLA。 一些公司在使用CLA时故意使用了不公平或繁重的条款，因为实际上是出于基于优点的考虑而劝阻“外部”参与的意愿。

这些公司希望他们的项目看起来像社区项目，而实际上却是围墙花园。 在其他情况下，似乎认为出于某些法律原因，CLA是必需的，但从来没有真正解释过。 我们甚至已经看到一个项目的特殊案例，该案例显然将其CLA的积累 （特别是如果由“大型”公司签署）视为以某种方式证明其生态系统健康。

但是，CLA的大多数用法有一个共同点，就是贡献者的不对称和繁文tape节。 CLA通常会给一家公司或组织带来特权，并为寻求参与和贡献的人们带来法律障碍。

贡献者保护的错误信念

有时我们会误以为，CLA对于保护贡献者和用户免受IP问题​​是某种必要的。 现实情况是，典型的CLA根本无法保护贡献者。 相反，它们要求贡献者承担超出开源许可本身要求的法律义务，因此，如果有的话，会增加其参与开源项目的风险。 这就是为什么这种CLA（和类似的版权转让制度）成为阻碍社区贡献的一个原因。 CLA也不保护用户，至少比项目的出站开放源代码许可证保护用户更多。 下游用户无法调用CLA来防御某种IP风险。 用户需要代码是开源的，并具有所有合法的权利，但这是开源许可证提供的。

CLA的唯一真正受益者是将其强加为捐款要求的公司或基金会。 即使在那儿，收益也比实际收益更虚幻，并且相对于项目承担的成本而言，收益几乎是很小的，因为采用CLA会使他人更难以做出贡献或难以根据其技术来对待贡献值得。

对于像OpenShift Origin这样的项目，该项目是根据Apache License 2.0许可的，这可能是最容易看到的。 Apache许可证提供了来自贡献者的非常慷慨的版权许可，并且贡献者还明确授予了专利许可。 这些权利被授予所有人。 许多Apache License 2.0项目也使用CLA，但从贡献者的角度来看，这些CLA始终是更具限制性的法律义务，这些义务对一个组织而不是对社区有利。 与Apache许可证不同，Apache许可证就像所有开放源代码许可证一样，无需额外的法律手续或文书工作即可运行，而CLA的结构通常类似于常规合同，需要某种形式的正式批准和官僚程序。

在Red Hat，我们不认为需要对赞助的项目进行如此严格的控制。 用克里斯·凯利（Chris Kelly）的话来解释：“对项目的技术，法律，实践和概念性手段的实质性维护和修改是非常公开的提交过程的一部分”

例如，不需要CLA授予用户期望从Apache License 2.0项目获得的权利。 权利来自Apache许可本身，由该项目的各个贡献者直接授予。 对于OpenShift Origin，当经过身份验证的github用户提交github pull请求时，将授予这些权利。 否则，将意味着绝大多数开源软件，包括一些使用最广泛的代码库，都存在致命的法律缺陷，因为这些代码中的大多数源于未使用CLA或版权分配的项目。 这种观点是不负责任的，但也被那些相同的开源项目构成了充满活力的社区和商业生态系统的基础这一事实所驳斥。

避免付费游戏行业协会开源基金会之路

一些开源项目选择走基础路线。 随着大型项目计划从公司中产生，我们已经看到了许多情况下的情况，即成立贸易协会基金会以利用公司资源来支持他们的项目并推广更具按需付费功能的模型。 在您真正开始参与项目之前，这种基于基金会的方法将第一个切入点移至“首先加入基金会”模型。 这通常需要一种“付费游戏”模式来获得席位。 偶然的是，大多数这样的基金会也对项目贡献者施加了CLA要求，但是按需付费模式是一个障碍，即如果有什么要比要求开发者签署不必要的或重复的许可协议重要得多的话

现实情况是，企业补贴并不构成真正开源的集体独立供电项目。 付费游戏协会开放源代码基础模型实际上是建立在老式标准联盟之上的，该联盟实际上早于开放源代码开发的兴起，这代表了更加敏捷，透明和平等的技术开发方式。 在某些方面，开源可以被视为替代标准的开发。

结论

在OpenShift Origin中，我们不是通过计算CLA签署者的市值，而是通过对代码库的实际贡献来衡量参与度。 按合并的拉取请求数排名时，此方法使我们进入GitHub上排名前五的社区项目 。 我们的开放式，社交协作基础设施模型，我们采用Apache V2.0许可证以及我们不需要捐赠CLA（或向基金会捐款）的良好意识相结合，才使我们成为最成功的开源提供PaaS 。

参加OpenShift社区

• 加入OpenShift Origin Google社区，并给我们您的反馈意见
• 阅读《 OpenShift原始贡献者指南》 ，今天就贡献力量！
• 在Trello上查看OpenShift起源路线图
• 询问OpenShift问题并获得有关StackOverflow的帮助

最初发布在OpenShift Blog上 。 经许可重新发布。

翻译自: https://opensource.com/business/14/4/lowering-barriers-open-source-contributions-openshift-origin

openshift开源