Topic on Talk:GitLab/2020 consultation

One thing that is not super clear to me is what the longer term viability of Gerrit is compared to GitLab.

Looking at merged patches to Gerrit you can see there's a lot of activity, and quite a bit more if you look at unmerged patches. Looking at the GitHub mirror of Gerrit (ha) to see contributor information, it looks like most commits in the last two years are coming from fewer than 10 people, and of the top ten contributors, half stopped contributing in 2018/2019. GitHub says there has been a total of 285 contributors in the 12 year history. On the plus side, there is a roadmap and it looks to have been updated recently with plans for a 3.4 release in Q2 of 2021.

Whereas GitLab is a mega project by comparison, with 3,395 contributors (excluding GitLab employees; with GitLab employees included then there are 6,534 contributors). The GitLab company is comprised of 1,279 people. Of the contributions to GitLab, 82.75% come from GitLab so there is at least for now an ecosystem around their products that is accepting of contributions from outside.

So just looking at the scale of the ecosystems around the two different products, if I had to say which code review system is going to be more mature and include more features that would make developer lives easier in, say, the next 3-5 years, then GitLab seems like a more certain bet. (Of course this doesn't erase the concerns about open core / enterprise editions, or that the company could decide to move things in a direction that cause issues for us, etc)

Having written the above, personally I would favor investing resources in improving our current setup and working on the various social issues around code review, then reassessing the viability of open core GitLab in the future. The open core edition of GitLab is limited enough that I'm not sure I see the overall benefit of switching to it in comparison to the tools and features we have in our current setup.

Came here to ask/say this as well as add another wrinkle: by standardizing on a well maintained, large ecosystem, we lower our cost of maintenance. Lowering our cost of maintenance means we *should* be able to free up more people to work on things that are core to where we add value. The less we maintain one-off solutions that don't add value to our mission as a movement, the more we have to focus on the things we do care about: creating an awesome platform for open knowledge. We don't need to innovate (or even glue) in the Continuous Integration/Continuous Delivery/Code Review space. Let's pick "industry standards" so that we don't have to train and maintain individuals on non standard things. This goes way beyond onboarding of new devs or attracting new talent and is as much about the experienced devs who have to regularly help onboard new folks, update the documentation, etc.