开源意味着跨越组织边界

JGit是一个EDL（新型BSD）许可的、轻量级的纯Java库，实现Git版本控制系统。

两周前（由于休假），讨论的是Chevotrain，事实上，开源有多种不同的风格。本周是时候向第三个方向扩展了，开源并没有出现在我们的SAP品牌Github网站上，而是捐赠给众多开源社区中的一个。本周我们的例子是jGit，另一个库（如Chevrotain），但没有创建在SAP，而不是由SAP运行。相反，SAP作为合作努力的一部分，为it做出了贡献。

推出jGit

Git–一个非常流行的开源控制管理系统，是Linux社区在其原始系统不再可用后开发的，作为他们自己的版本控制系统。到2014年4月，该系统已经发布最流行的开源SCM。随着它的日益流行，它也成为了其他开源平台的一个重要功能，比如非常流行的Eclipse IDE。

2008年，SAP与Shawn Pearce联合，作为Eclipse的eGit/jGit项目的一部分。工程师们花了大约1年半的时间才获得SAP的许可才能继续前进（为什么会这样很久了？很快就会有另一篇博客文章了……。到2009年，该项目获得批准，并朝着1.0版本发展。到2010年，数据分析和大数据，该版本已经发布，Eclipse将其作为IDE GIT库的一部分使用。

该项目有来自许多公司（和组织）的多个贡献者，包括我们SAP工程组织内部的5名开发人员。

哦，是的，对了，反正是JGit吗？如果您使用Java，并且需要直接与Git SCM通信（例如，克隆、提交或从存储库中提取），此工具可以在Java中为您完成所有工作。最重要的是，它直接在Java中完成所有工作，而不需要调用外部编译库，所以代码是完全可移植的（对于那些不熟悉的人来说，Git存储库基本上是所有的文件，所以可以用任何语言的代码来更新或修改它们）。

您可以自己尝试，您可以从这里下载：https://www.eclipse.org/jgit/

开源组织

本项目的区别到目前为止，我们讨论的其他组织是运行项目的组织。在前两个例子中，组织是SAP–因此我们决定了关于组织如何发布代码的所有事情。

然而，开源社区，开放源代码组织不仅仅是由单个公司组成的。开放源代码组织是其他参与者之一（如果我们想说具体的话，可以称为"参与者"）。开放源代码组织可以来自许多不同的地方，但它们往往来自两个来源。

首先，这就是Eclipse基金会（Eclipse IDE的所有者）所发生的事情。"Eclipse"最初是IBM在2001编写的，但到2004，它被拆开成为完全独立的实体，一个开源基金会。这个基金会由其赞助商（通常是其他公司）资助，并使用一个板。系统来决定新的功能和项目。另一个例子是CloudFoundry，它是通过Pivotal从VMWare中剥离出来的。

第二，一个组织可以由一组希望将一个概念推广成为标准的公司创建。一个例子是OpenStack，RackSpace和NASA的联合合作。

两者之间的区别可能有点模糊——毕竟，几乎都是从一个或两个公司走到一起开始的。它们之间的主要区别在于它们所从事的工作。Eclipse和CloudFoundry是在公司意识到它们应该成为开源。OpenStack计划是一个概念性的想法，它得益于在软件开发期间让每个人都登录。（是的，看云，两者可以很容易地混合，没有什么那么简单，但它给出了这些类型的组织是如何产生的想法。）

在这两种情况下，结果是一个独立运作的组织，悠哉返利机器人，只创建开放源代码？很好。因为重要的一点，也就是下一个问题，云指，是"为什么会有人这样做"？这个答案直接导致了行业标准化和商品化。再一次，我要引出一个续集，因为这个整个生命周期的问题（以及开源如何适应它）是另一天的又一篇博文，这是很有趣的东西。）

与不同组织合作的挑战

TL；DR:请让我回顾一下历史。

好的，因此，让我们先来讨论一下这个问题。因为与多个公司和组织合作意味着我们不能按自己的方式做每件事。

每一个在团队中工作过的软件工程师都知道这个问题——作为一个个体，协调起来很容易。（"嘿，我，我应该这样做吗？当然，我，说吧！太好了，谢谢然而，在一个更大的团队中工作时，事情很快就会变得一团糟？什么，我要去见委员会？呃.."

这其中的一部分是组织动态。每个软件公司（包括SAP）都有他们正在做的某些事情、他们想要实现的目标和想要尝试的想法。当从事其中一个项目时，团队必须与指导委员会协调所有这些，并且必须与团队一起审查代码。

这是最简单的部分。（等等，什么？）

然而，在SAP内部，这也很难。我们有一定数量的开源规则和许可证，我们已经在内部批准了。在处理别人拥有的项目时，规则和许可证由其他人决定。这意味着回到我们的法律部门，确保我们使用的许可证与项目的许可证不冲突。