Open Source means crossing organizational boundaries
jGit - pure Java Git handling
JGit is an EDL (new-style BSD) licensed, lightweight, pure Java library implementing the Git version...
Two weeks ago (due to vacation) the
discussion was about Chevotrain, and the fact that Open Source comes in multiple flavors. This week it's time to expand on that in a third direction, where the open source doesn't end up in our SAP branded Github site - but instead, is donated to one of the many open source communities. Our example for the week is jGit, another library (like Chevrotain) but not created at SAP, and not run by SAP. Instead, SAP helps contribute to it, as part of a collaborative effort.
Introducing jGit
Git - the incredibly popular open source Source Control Management system, was developed by the Linux community as their own version control system after their original system was no longer available.
By April 2014, it was the most popular open source SCM. As it grew in popularity, it also became an important feature of other open source platforms, like the very popular Eclipse IDE.
In 2008, SAP joined with Shawn Pearce as part of the eGit/jGit project at Eclipse. It took the engineers about 1 1/2 years to get permission from SAP to move forward (and why that long? is another blog post coming soon...). By 2009 the project was approved and working towards a 1.0 release. By 2010, the release had gone out, and Eclipse was using it as part of the GIT libraries for the IDE.
The project has multiple contributors from many companies (and organizations), including 5 developers from inside our SAP engineering organization.
Oh, yeah, right, was is JGit, anyway? If you are working in Java, and need to communicate directly with a Git SCM (for example, to clone, commit, or pull from repositories), this tool can do all that work for you in Java. The great part is that it does all this in Java directly, without needing to call an external compiled library, so the code is entirely portable. (For those who aren't familiar, Git repositories are basically all files, so updating or modifying them can be done by code in any language).
Feel free to try it out for yourself, you can download it from here:
https://www.eclipse.org/jgit/
Open Source organizations
The difference between this project and the others we have discussed so far is the organization who runs the project. In the first two examples, the organization was SAP - so we decided everything about the organization how to publish the code.
The open source community, however, is made up of more than just individual companies. Open Source organizations are one of the other players (or "actors" if we want to get specific). Open Source Organizations can come from many different places, but they tend to come from two sources.
First, they can be created by a corporate entity. This is what happened with the Eclipse Foundation (owners of the Eclipse IDE). Eclipse was originally written by IBM in 2001, but by 2004 it was spun out to be a completely separate entity, an Open Source Foundation. The foundation is funded by its sponsors (usually other companies) and uses a board system to decide on new features and projects. Another example of this is CloudFoundry, which was spun out of VMWare through Pivotal.
Second, an organization can be founded by a group of companies that want to promote a concept to become a standard. One example of this is OpenStack, a joint collaboration by RackSpace and NASA.
The difference between the two can be a little vague - after all, almost all start with a company or two companies coming together. The major difference between them is what they are working on. Eclipse, and CloudFoundry, were developed in-house before the companies realized they should become open source. The OpenStack initiative was a conceptual idea, which benefited from having everyone sign on while software was in development. (Yes, the two can easily mix, and nothing is that simple, but it gives an idea of how these types of organizations can come about.)
In both cases, the outcome is an organization that operates separately, and which only creates open source code.
Made it this far? Good. Because the important point, which should be the next question, is "why would anyone do this"? That answer leads directly towards industry standards and commoditization. And again, I'm leading to a sequel, because this entire life-cycle problem (and how Open Source fits in to it) is yet another blog post for another day.
(Feel free to jump the gun and research yourself, it's fascinating stuff.)
Challenges of working with separate organizations
TL;DR: get me past the history, please.
OK, so let's talk about the rough edges for a second. Because working with multiple companies and with organizations means we don't get to do everything in our own way.
Every software engineer who has ever been on a team knows this problem - as an individual, it's easy to coordinate. ("Hey, me, should I do this? Sure, me, go ahead! Great, thanks me!") When working on a larger team, however, things get messy fast. ("Hey, team, can I do this? What, I have to meet with the committee? Ugh..")
One part of this is the organizational dynamics. Each software company (SAP included) has certain things they are working on, goals they want to achieve, and pet ideas to try out. When working on one of these projects, the team has to coordinate all of that with the steering committee. And it has to review code with the team.
That's the easy part. (WAIT, what?)
Inside of SAP, however, it's also hard. We have a certain number of Open Source rules and licenses we have approved internally. When working on a project owned by someone else, the rules and license are decided by someone else. This means going back to our legal department and making sure that the licenses we use don't conflict with the license for the project.
Wait, it's worse still. Because, of course, SAP has all kinds of proprietary (and sometimes patented) software that we are using or working on. When contributing to an outside group, we have to make sure we aren't publishing anything that might hurt another internal group. Or worse, invalidate one of our patents (by accident, I mean, because we sometimes do that on purpose.) Uh oh, that's bad.
Commitment to the community
It's not all downside, however. Working with the community helps in a number of important ways.
First, it makes the entire community stronger. Open Source is the backbone of a lot of the things we do. It appears in everything from SAP software to the latest iPhone and Android, and also in all kinds of systems from huge to embedded. It's part of the very foundation of modern computing.
Contributing allows us to be a "good citizen" to that community. Each company that contributes helps all the other companies, and computing in general. We gain from the work of others, and they gain from us. (The rising tide lifts all boats, that sort of thing.)
It also allows us to have a voice in the overall ecosystem. If you want to help move everything forward, you need to speak up! And projects are most receptive to the contributions who bring both good ideas and good code.
Building the Ecosystem Picture
This adds another important step to our ecosystem picture. Large scale and small scale Open Source now joins with "joint" Open Source.
The difference here is that Open Source doesn't start (and end) with our individual organization. To be a part of the larger community, we need to be involved at multiple levels.
Those contributions mean putting in both time and effort, to coordinate and to write code that can be shared between different groups.
If you are a Java programmer, take a look at jGit.
And thanks for stopping by Open Source Monday. Looking forward to more soon!
