Why We Selected GitLab over GitHub to Host flexiWAN Open Source SD-WAN

At the end of 2019, flexiWAN lived up to its promise and published its code as open source. Before doing that, we had an internal discussion to decide where to publish it. The immediate suspect was GitHub, as that is the go-to platform when looking for open source. But GitHub is not the only version control system out there. Actually, we have been using a different platform for our work so far—GitLab.

To reach our decision, we analyzed the pros and cons of each option with reference to our requirements. While the opinions of the different team members varied, eventually, given the reasons below, we reached the decision to opt for GitLab instead of GitHub.

We thought that it would be a good idea to share our considerations with the community, hence, this is how this post came to life.

Background Story

There are several public version control systems for code publication. Probably the most common ones are GitHub and GitLab.

These version control systems provide, in addition to code maintenance, web-based capabilities such as issue tracking, documentation, and wikis.

Naturally, each has its pros and cons, both technically and pricing-wise. Both GitHub and GitLab are good and stable repositories, this blog post captures our own considerations, we are not trying to say that one is better than the other but rather simply say what were our requirements and which of them was found to best answer them.

Our Reasons for Putting flexiWAN on GitLab vs. GitHub

Community and Popularity

GitHub has existed for a longer time and has more projects, contributors, and community. GitLab is ramping up but is still behind GitHub. Therefore, from a business and marketing point of view, GitHub is the preferable alternative 

CI/CD

At the time we started our development, GitLab had integrated CI/CD tools which we used regularly for our code commits. GitHub released the Actions capabilities more recently.

In our case, the CI/CD was mainly used for unit tests and code checks that run on every commit.

We also use external Jenkins-based automated integration tests, which test the entire solution regression.

Issue Tracking

Both GitHub and GitLab provide issue tracking with labels, reports, and filters.

We use the GitLab issue commands for setting issue estimations and development progress.

We read the data via the GitLab API and used it in our issue management tools. We didn’t find the same capabilities in GitHub besides adding the tracking information inside the issue body.

Private Issues

GitLab allows for the creation of private issues that are only exposed to the creator and the project members. 

This capability is important for us in order to manage customer-specific information that we can’t expose publicly, as well as flexiWAN private information. GitHub does not provide this capability.

Existing Issues and Tools

Initially, we started our work on flexiWAN on GitLab private repositories, and we have all of our issues and tools around GitLab.

We didn’t find an easy tool to convert the data between GitLab and GitHub, which means a significant effort from our DevOps side.

Cost

Since we keep a few public and private repositories with multiple collaborators, we found the cost for GitHub higher.

Summary

Both platforms are good and do the job. Each company has its own technical requirements and priorities between them.

Additionally, GitLab offers more value in their free option when starting off the project, and at the beginning, when we started flexiWAN, this was an important factor (not that cost is not important for us today or for any other established company).