If there is something that Microsoft has excelled at, it is selling software to enterprises. GitHub, as a Microsoft-owned company, has been trying to add more features in an attempt to appeal to enterprise software. I personally have used GitHub for years, since it has a reputation as the undisputed champion of software version control. Even Azure DevOps, another service by Microsoft, falls short of the brand recognition that GitHub has.
I have always had mixed feelings about GitHub. On one hand, it is an amazing platform for open source software. On the other hand, they only recently allowed free users to have unlimited private repositories, and even though I am part of GitHub for Education, I didn't want to be stuck once I am no longer a student. For this reason, I have spent the last couple of months evaluating various version control services.
Many other Git hosting services focus on version control. Of course, that is what they are designed for. However, they add other features, like Issues, Wikis, and CI/CD. These extra features are what turn a version control platform into a development hub, and these extra features are what make development a positive experience.
Azure DevOps feels very similar to GitHub. It has the same basic features, including Pipelines, Artifacts, Repos, and project management. I think that it makes a lot of sense for developers who use Visual Studio, because they are very tightly integrated. I, however, do not use Visual Studio, and don't want to get involved with VS licensing. It doesn't stand out for users who aren't involved with Microsoft technologies, especially individuals (like me).
Bitbucket is a similar story, but for users of Atlassian software. It has amazing integrations with the Atlassian suite, especially Jira and Confluence. However, the standalone tools are far from extraordinary. The other problem that I see with Bitbucket, is that in order for it to make sense to use, you have to invest in the convoluted and exorbitantly-priced Atlassian ecosystem. There is a free tier, and their pricing makes sense for very small or very large teams, but I do think that once the other services are added, the prices can get very high.
Independently of Bitbucket, it can also be confusing what services are needed for an effective Atlassian deployment. There are four different products (all of which need different licenses) that use the name Jira, and even after using them, I still am not clear on who should use what product. The convoluted nature of the ecosystem is a huge deterrent for me to use it and invest in it long term.
At this point, the GitHub community as well as lackluster features from competitors made me keep on wanting to go back to GitHub. That was until I ran across GitLab. GitLab is a Git/Ops application that can be deployed on a server or through the cloud. They are trying to establish themselves not only as a git service, but a complete solution for the development process, and I immediately fell in love.
My Favorite Features
I think that this is one of the most underrated aspects of any technology, but GitLab looks much better than other solutions. The indigo, orange, and white default color scheme looks amazing, and I did not find myself wishing for a dark mode. The layout is also very intuitive, with a bar along the top for global navigation with a sidebar for contextual navigation. The design and development team also clearly cares about details. One of my favorite attention to detail features is that the GitLab logo plays a little animation when you navigate between pages. It certainly isn't critical, but it is makes the experience mildly more enjoyable and shows that they care about details.
Service Desk is one of those features that you wouldn't think would be important, but actually ends up being very useful. Basically, it creates an email address that your users can send an email to, and it will automatically create an issue. The user then will get notified whenever an update is made to the issue.
While not as full-featured as a dedicated service desk tool (like Jira Service Desk or Zendesk), it probably is enough for an open source project or SMB. It also integrates very nicely with GitLab Issues (GitLab's project management tool). While I absolutely think that if you have unlimited budget, the Atlassian Suite might make more sense, but a common theme with GitLab is that it excels when it comes to value.
This is a more general section, but I think that it would be difficult to be super specific. GitLab simply has more features than other pieces of software. This image is from the GitLab documentation:
Of course, GitLab has an interest in portraying themselves as better than GitHub. However, I think that chart accurately represents the difference between GitHub and GitLab. GitLab has invested heavily in becoming a full featured platform, and it really shows. I have only begun to scratch the surface of the capabilities of GitLab, and it handles almost everything I need. You can check out a comparison below of the features between GitHub and GitLab.
I have not had any problems with GitLab so far. Of course, bugs always exist in software, but I have not had any problems with GitLab. This differs from a situation that my robotics team had recently, where GitHub told us to inspect element and insert an HTML button because it was not there (and they did not give an estimate on when it would be fixed). For a developer-oriented community, this is not difficult for the users, but it is an annoyance. That being said, I have not had any bugs with GitLab and they seem to have a company culture that emphasizes supporting users.
GitLab has solidified themselves as a leader in the development life cycle. That is great, and if they continue on their path, the project will continue to become even better. They have a clear path with features that I will love to see, emphasizing the categories that are mentioned in the comparison to GitLab: Manage, Plan, Create, Verify, Package, Secure, Release, Configure, Monitor, and Defend.
I think that there is one category still missing: post-release. I have built several small programs that are open source, but not tightly integrated with developing. A good example is my FRC team's scouting application, where we had to help people who aren't familar with git tools use our tool. This application was managed in GitHub, because my team uses GitHub, but as far as I can tell, GitLab does not have a better solution.
The two biggest things that I needed were a landing page and knowledge base. For this project, I decided to go with a hugo template for the knowledge base and a simple html page for the landing page. It wasn't too difficult, but there was a fair amount of work involved with getting the Hugo site set up and creating stylesheets for the html page (I wasn't happy with many of the Jekyll themes). I also needed to create more repos, which meant that our documentation was in a different place from our code.
The wiki seems like the perfect solution to this, except there was one big problem: wikis, for both GitHub and GitLab, are part of the standard UI, and as far as I can tell, they cannot be separated out. GitHub wikis are barely functional, if at all, on mobile, and GitLab turned out to be very complicated for people to use, especially people who aren't used to GitLab already.
Look at this image from a GitLab wiki being run in responsive mode. If I want to navigate to a different page, where am I supposed to click? There are four menus, three of which are hidden hamburgers. To me, intuitively, I would think that the hamburger next to the breadcrumb is where I would navigate, but when I tap on that, it brings up the GitLab project navigation:
By contrast, my Hugo site has only one hamburger menu, that is much easier to follow
The one thing that I would absolutely love from GitLab would be a wrapper around wikis designed for end users. Wikis are incredibly powerful and much easier to set up than a dedicated knowledge base in Hugo.
So if there is one future that I would love to see in GitLab, it would be a wrapper around wikis designed for end users. Ideally, it would have:
- Minimal GitLab branding
- Minimal GitLab global interface
- Only one menu (that handles navigation for the entire wiki)
- Search functionality
- Domain mapping (through CNAME)
- Export page/wiki as HTML/PDF
If what I am saying sounds like ReadTheDocs, that is because it basically is. I just want a ReadTheDocs-like product that integrates with GitLab Wikis, because the rest of the development cycle already takes place in GitLab.
I even think that if GitLab got rid of the top global bar, move the wiki navigation button to where the project navigator currently is, and get rid of the page history button, it would have a solid UI.
My iPad plays a major role in my development workflow, especially because of the GitHub app. I frequently will pull up reference code on my iPad or manage issues on there while keeping my IDE on my primary screen. I also find it helpful to easily be able to view code on the go, and an app is simply a better experience than a web app.
The lack of a mobile app is by no means a dealbreaker, but it does make GitHub a more appealing option. From anectode, I have heard that many people, not just me, use the GH mobile app because of the convenience factor. The GH mobile website is admittedly much worse than the GitLab mobile website, which is part of why I think not having an app is excusable, but in an increasingly-mobile world, I think a GitLab mobile app would allow a more efficient and mobile-oriented world.
One of the most underrated aspects of GitLab is their very open and transparent culture. They extensively and publicly document their work culture, their experience with remote work, and their feature roadmap. Part of the reason why I trust GitLab so much is because they have made it clear that transparency and community support are at the core of their company.
Personally, I found the GitLab transparency not only helpful for establishing trust, but also as a learning opportunity. My sophomore year of high school, I suddenly found myself leading a team of seven high school programmers with zero leadership training and minimal adult support. I read through the entire blog and public handbook, and it was very insightful.
GitLab Cloud vs Self Hosted
I personally use the free GitLab cloud tier. You can upgrade your plan or use self hosted GitLab. I have not used self hosted GitLab, but it seems to be a good value, especially when data control is critical. I have heard that GitLab self-hosted is very popular in tightly-regulated industries.
One of my biggest concerns with SaaS solutions is what would happen if I choose to move away from the service. Some software, like GSuite, Microsoft 365, and Adobe Creative Cloud do everything that they can to keep you using the software, which makes sense from a business perspective. Since there is a self hosted solution, GitLab gives me extra peace of mind, since I know I can control my own data if I need to.
Given that it can be self-hosted, the free option looks very appealing, especially when compared to other less-powerful tools like Gitea. However, I don't think that it makes sense unless you are in a very tightly regulated industry where data management is a must. The cloud hosted solution is very reliable and doesn't require IT support.
Community- The Biggest Problem
Supporters of GitHub argue that GitHub is better than GitLab because of the community. GitHub is the undeniable champion when it comes to the open source community, and anyone who starts an open source project will probably use GitHub. Looking at the explore page on GitLab and sorting my most stars, most of these project are either ones that I have not heard of or owned by GitLab.
How To Achieve
I do not contribute to often to open source projects, but it is a huge part of developers' lives and I imagine plays a huge role in GitHub's current dominance of version control across business and open source projects. I am certain that the team at GitLab is aware of the problem, and if someone on their team stumbles across this article, I have some suggestions on how to play a bigger role in the Open Source community.
Talk to the Open Source Community
Firstly, GitLab needs to have frequent communication with open source community, especially with people who don't use GitLab. I don't personally maintain large projects, but I have to imagine that there are lots of complexities involved. If they could get a couple of major open source project to move development efforts over to GitLab, it would durastically improve GitLab's credibility in the open source community.
The way to achieve this is to create the features that open source project leaders need to reduce the stress on them as well as make lives easier for open source contributors. But it has to be a major community, since they will bring contributors over. A small project would likely be forgotten if it moved over to GitLab, because people are already invested in GitHub.
If I were involved with the GitLab project, I would be reaching out to every Google Developer Group in the world in a desperate attempt to spread the word about GitLab and also get feedback from open source contributors. They seem fairly open to sponsorship of events, but sponsorship alone is not enough to get users over to GitLab. They need feedback, and they need the open source community to feel like GitLab cares about them, because without the open source community, I don't think that GitLab will survive.
Promote Explore More
It took me a very long time to even realize that GitLab explore exists. I just happened to stumble across it one day, but it was not clear that it exists. I personally think that GitHub's global search has swung too far in the direction of open source software, but they at least promote that there are other repos on GitHub fairly openly. Explore has a dedicated button on the top menu, and their website also makes it very clear that open source projects are on the platform. The GitLab front page does not have an obvious mention that open source projects exist, and I think that it could be cool if the about.gitlab.com webpage had a trending repos section, just to make people realize that GitLab can be used for open source projects.
GitLab should be the go-to solution for version control for high schools and universities. These are relatively new users who are not amazingly tech oriented (especially in high school), and don't have loyalty to an existing platform. My FRC team uses GitHub because my high school uses GitHub, which means that if I were to start a new project for school, I would probably use GitHub.
Once again, it would be worth reaching out to high school teachers and university professors, and asking them what would make their lives easier from a grading perspective. With schools, GitLab needs to target the teachers, because the students will use what they are told to use. GitHub Classroom is a tool that is somewhat underutilized, and I think that they could make a similar system and promote it heavily to teachers.
Take Advantage of COVID-19 to Get the Education Market
Short development times are not ideal, but the 2020-2021 school year is the perfect time for GitLab to try to get involved in education, especially high school education. If GitLab writes tools to help CS teachers do remote learning (which is increasingly looking likely for the 2020-2021 school year, especially in California), there would be a real value proposition for teachers to switch over to GitLab.
The other benefit, especially in high schools, is that the cirriculum is very standardized. The APCSP and APCSA courses are what a majority of high school students are taking for computer science, and GitHub has not taken any effort to optimize for these cirriculums. If GitLab could figure out how to integrate with the College Board cirriculum, it would make a lot more sense for GitLab to be the standard in high schools.
Why It Matters
I completely if GitLab wants to be an enterprise-oriented tool. However, I think that if they do not appeal to individual users, they will loose the enterprise customers. A quote from Ford's Software Processes and Tools Supervisor said in a GitHub customer testimonial:
The teams evaluated a handful of solutions, and GitHub came out on top. Its strong following among new and experienced developers was also key. “It’s taught in school,” said Carmean. “GitHub is the largest provider of open source repositories in the industry. And people graduating from college know how to use it — which was one of the most important reasons we brought it in.”
GitLab is Positioned to Loose the Version Control War
I am going to be blunt, GitHub is much better positioned for dominating the enterprise version control despite it having a fraction of the features. I see parallels of GitLab now to BlackBerry just before 2011.
2011 was arguably the turning point for RIM in the smartphone wars. The BlackBerry 9900 was a great phone at the time that was designed and optimized for enterprise. It had security features that rival modern iOS and Android, but in 2011. It was full of features, yet the 9900 was the last "great" BlackBerry phone.
In 2011, the iPhone 4S started widespread adoption of iPhones in enterprise. The problem that RIM had was that employees started using iPhones for their everyday lives, and Apple quickly adjusted to adopt the enterprise market. Here is a phone that had less features, but employees wanted to use it.
Developers are in high demand right now, and no company would want to loose talented developers because they are forced to move over to GitLab. I am not saying that it will happen, but it could happen, and no manager would want to risk it. However, if GitHub starts to build in more features designed for DevOps, people will adopt it. Employees would want one platform for work and open source code, and if GitLab doesn't start to become a hub for open source code, GitHub will be what people migrate to. Companies gave up features so that their employees could use iPhones, because hteir employees wanted to use iPhones as their one device for their work and personal life.
I believe that many people would realize how great GitLab is if they tried GitLab. It is an amazing, feature-rich tool, but right now if people want one platform for open source contributions and business work, they are going to go with GitHub, just because of the collaborative aspect.
I love GitLab. It is an amazing tool, but the company has to put more effort into the community aspect, especially in education. Their current model of constantly adding features is valuable to users, but without the open source community on GitLab, I can imagine GitLab becoming obsolete in the upcoming years because they aren't focusing on open source software.
For individual projects, I will probably use GitLab exclusively. However, for open source projects, even ones that I start, I think that the community aspect could be enough for me to use GitHub, even though it is an inferior product at the moment. I hope that GitLab figures out how to get the open source and education communities, since I want there to be a viable alternative to GitHub, but I am not feeling optimistic at the moment.
As I am writing this, GitHub just announced new features at GitHub Sattelite 2020. The two biggest ones are Codespaces and Discussions. From what I can tell, Codespaces looks like very competitive compared to WebIDE, especially since it is based on VS Code, which is already widely used. I hope that the GitLab team start trying Codespaces, and figure out how to improve WebIDE.
Discussions also looks like a very promising feature. It looks like it could be a feasible replacement for open source slack communities. Just looking at it, a thumbs up/down feature like GitLab issues has could be useful. I hope that GitLab creates a similar feature soon, because it seems like it could be very powerful in a GitLab environment.