Why “Git”?

By Philippe Magne

No-one in our industry can have missed the seemingly unstoppable rise of Git.  In this article, we will attempt to shed light on the reasons behind its popularity and to what extent this is justified. Then from ARCAD’s unique standpoint as the technology “bridge” between traditional development and open source worlds, we will look specifically at the relevance and the value of Git on the IBM i (aka iSeries, AS/400) platform.

On the face of it, Git is a simple, open source tool designed for managing source code across multiple projects.  It has all but eliminated its predecessor, CVS.  Somewhere between the two, SVN had its moment of glory in the 2000s but has steadily been losing ground to Git.  So far, nothing unusual in the technology market.

So why has Git achieved such an outright dominance? Does it possess some game-changing features that outstrip its competitors?  No, that’s definitely not the case.  Or because the founding father of Git is none other than Linus Torvalds, the creator of Linux?  This is closer to the truth.   In fact, Git adoption grew in line with the success of Linux itself…

1. De facto standard

Git has become a de facto standard. What does that mean exactly? A tool or a language that, even if it’s not perfect, has the huge advantage of being familiar to the greatest number of people. The consequence of this is that skills and expertise are transferred naturally within the various teams. SQL is a prime example of a de facto standard, the one and only language used for relational databases today.

In the case of Git, the tool delivers value way beyond the simple management of source code. To illustrate the point, let’s take the most typical case, the management of hardware configurations.  Since the advent of Cloud architectures, we only hear about “infrastructure as code”.  So, what is the added value of Git in this context?  Of course, it is the ability to track each and every configuration change. Some Cloud players could have developed their own version management tool but instead, they each decided to use the prevailing standard.

But there is an even more symbolic example.  Undeniably, Microsoft – whatever you may say or think – is one of the main players in software development tooling, and the software giant from Redmond adopted Git as standard many years ago now.  Microsoft’s endorsement of Git reached a whole new level when the company acquired GitHub in 2019.  Was this a technology-motivated acquisition?  Definitely not.  Microsoft could have very quickly developed an equivalent product. The attraction was GitHub’s community of 32 million developers and the prospect of being able to influence their technology choices.

Git’s success would not have been so massive without its commercial offshoots and hosting services: GitHub, Bitbucket and GitLab. Using Git on the command-line may suit the student or geek, but when it comes to establishing Git as enterprise standard in your company, it is far safer to opt for a richer Web interface along with all the necessary security aspects such as integration with an organization’s single-sign on solutions.

2. “Social coding”

What changes have the “social coding” tools really introduced?  Nothing less than a radical change in developer behaviour.  Developers are no longer alone in their corner.  They are both part of an individual team but also part of a global network.  They have also become much more extrovert than before.  They learn and improve by sharing ideas and code much more readily with their peers.  This sharing has become a key factor in both quality and productivity of a final solution they are building together.  The old era when a developer would individually lock him or herself away for a number of days to finalize their algorithm is (almost) over.

Some large groups purchase social coding tools without even questioning their ability to implement them in their organization, simply because they act as a platform for attracting new developers.  In these days of digital transformation, the competition between companies to recruit and retain developers is becoming more and more fierce.  Creating a user-friendly and above all a familiar hosting environment does not do the whole recruiting job for you, but it certainly paves the way.

3. Git in the IBM i world

It is for all these reasons that it is so important for the IBM i world to take a serious interest in Git.  Even if Git is not perfectly adapted to IBM i (for reasons we will explore later), its overriding advantage is that it naturally encourages dialogue and collaboration between developers from different technology backgrounds.  Further, Git has the potential to quickly become the backbone of an IT organization by allowing staff to share the same code, innovation ideas and even development tools.

Let’s look more closely at this claim that Git is not “perfectly adapted” to the IBM i world.  The reason boils down to architecture.  In the world of distributed systems, the developer can work completely independently on his own machine.  He can manage his source code, compile it, debug it and run it.  In the IBM i world however, though the developer can manage his source code locally, he or she is absolutely required to be connected to the IBM i server for all subsequent tasks.  So, this leads to the next question, “How do you manage multiple projects in parallel?”

For an in-depth look at that particular topic, I encourage you to reach the excellent blog article by our technical director, Michel Mouchon:  Empower your IBM i teams: the extraordinary potential of Git.

4. ARCAD, indispensable for Git adoption

It is by resolving that challenge with Git on IBM i – the management of multiple projects in parallel – that ARCAD technology stands out on the market.

The ARCAD system was designed from the outset to manage development on as many parallel projects as needed, without imposing any constraints on the user.  Each project is efficiently partitioned, managed and tracked and specific versions of programs can be tested independently of each other. This unprecedented degree of automation coupled with parallel streams of development naturally accelerates the rate of change, so that IBM i organizations can innovate more quickly, respond faster and deliver more functionality within each release.   Accelerated and secure delivery serves to safeguard your organization’s strategic competitive advantage.

This is why most organizations who are adopting Git for IBM i development require the ARCAD technology layer.  The way to be successful in adopting open source technology on IBM i is to complement the open source with commercial licenses from ARCAD.  This model has many advantages:

– Smooth transition to industry standard tooling with a natural integration of technology,

– Seamless vendor guarantee of stability, security and efficiency of the open source integration layer,

– Built-in ARCAD DevOps methodology to reduce risk in the development process,

– Ecosystem around ARCAD’s development tools to refresh and modernize core IBM i team skills (training, consulting resources, etc.)

In short, this ARCAD-led approach to open source tooling on IBM i combines the best of both worlds, to secure the transformation of your teams and ready your IT organization for a faster, smarter future.

Philippe Magne

CEO, ARCAD Software

Philippe Magne is CEO and Founder of the ARCAD Software, global ISV specializing in the areas of DevOps, IBM i Modernization and Data Masking. As Quality Assurance manager at the European Space Agency, Philippe initiated the ARCAD software lifecycle management project in 1988. He then created the ARCAD Software company in 1992 to assure the development and marketing of the software. Since, he has steered the company to produce a complete and integrated range of solutions distributed by IBM worldwide. Today ARCAD Software is recognized as the worldwide leader in DevOps for IBM i. Philippe is an unceasing champion of enterprise modernization and frequent speaker at events across the world.