We know that we can iterate faster when we innovate together. We want to highlight how you make GitLab better every day by contributing to our open DevOps platform, by suggesting improvements, submitting bug fixes, and contributing features.
You contribute around 300 merge requests to GitLab each month. Just look at last month's release for a multitude of examples – a reminder that everyone can contribute.
Achievement unlocked: having NASA contribute directly to your codebase. Open core ftw. https://t.co/qcnu8jhQuR— Brendan O’Leary (@olearycrew) February 22, 2021
Roger Meier, principal key expert and service owner of code.siemens.com from Siemens IT explains, “If we want to have new features, we contribute them to GitLab.”
An open DevOps platform gives you visibility into security and beyond
Working in the open presents unique security challenges (you can read about how we prevent security fixes from leaking into our public repositories), but we’re proud of how taking an open approach to security serves our community, customers, and us.
Community member Ethan Reesor is working on improving and simplifying how we do authorization in our package managers and added some great test coverage around that in gitlab-org/gitlab!50729.
Security issues are often reported to us directly in GitLab, but Dominic Couture, senior security engineer, Application Security at GitLab, explains that even security bugs reported through our HackerOne bug bounty program are often made public 30 days after they’re fixed: everyone can see the old security issues. “This creates a positive feedback loop where external security researchers can look into old issues to help them find and disclose new ones to us.” You can read more reflections on security and open source here.
Our customers regularly collaborate with us to debug problems. In this example, a customer helped our backend engineers to resolve an S1 bug, and even gave us access to part of their system to test the fix – showing that we’re most successful when everyone’s committed to iteration.
Small fixes and improvements to our documentation often arise out of customer interactions with our support engineers – you can see all the merge requests from 2021 captured here.
For some customers, contributing to GitLab is even an official part of their job. Learn about how one of our contributors at CERN here helps make GitLab’s open DevOps platform better.
Getting to the root of performance problems
Working in public by default is a little uncomfortable at first – especially when it comes to troubleshooting performance issues – but the advantage of this visibility is that we can crowdsource solutions.
In July 2019, our site reliability engineers noticed a significant increase in errors and site slowdown on GitLab.com. In the course of investigation, community member Andrew Armstrong commented on the public issue with a suggestion: The Redis instance might be approaching its self-imposed memory limit, which can overwhelm the instance quickly even if plenty of physical memory is available. This inspired a review of the time to live (TTL) we apply to Redis keys.
Living our values through open DevOps
We're proud to partner with groups who foster our values in their communities. The Last Mile is opening doors for aspiring software engineers at correctional facilities across the US. GNOME moved to GitLab in 2018, and together with Endless they launched the Coding Education Challenge to inspire a new generation to "take control of their digital worlds, not be controlled by them." Read more about intitiatives from our friends in open source.
These are just a few examples of the improvements you make to GitLab and the wider community, and we want to keep celebrating how you iterate and innovate using our open DevOps platform. Got a story of your own to share? We’re accepting proposals for our virtual user conference, GitLab Commit (Aug. 10-11, 2021) and would love to hear from you.