It's been a little over two years since the GNOME project moved to GitLab. We wanted to check in to see what’s happening at GNOME these days and see if they had noticed an impact from their migration on their community and their software development lifecycle. To find out the latest, we spoke with Carlos Soriano and Sri Ramkrishna from GNOME and combined their responses.
How are you using GitLab at GNOME?
GNOME is using GitLab’s Community Edition, which is entirely open source.
All teams at GNOME have been using GitLab for over a year, including non-coding teams like engagement and design, and the board of directors. The GNOME Foundation’s staff is also using GitLab for things like grant writing and running the foundation.
GNOME is using most features that GitLab has to offer, such as CI/CD for testing, issue tracking, kanban boards, and labels. Labels and CI/CD are two of the most important features being used across the entire organization.
In addition to this, GNOME is using GitLab Pages for some of the landing pages for projects, and also to host documentation.
The only team that hasn’t fully been able to use GitLab is the GNOME translation team since they need a different set of permissions and roles than GitLab provides. For them, Bugzilla was more flexible, and so some of their workflow is still there and in other tools. However, they are using GitLab for issue tracking and coordination.
Here's how GNOME has set up its GitLab instance.
What are some of the changes that you’ve noticed in your community?
The perception at GNOME is that the move to GitLab has made it easier for people to contribute to GNOME.
One noticeable difference is that a lot of people are now using the GNOME GitLab instance to host their own projects that are somehow related to GNOME but aren’t part of the core software produced by GNOME. This has increased GNOME’s developer community.
Another noticeable difference in the community is that, since moving to GitLab, there is more awareness around what CI/CD is and how important it is to the development process. CI/CD is being used extensively throughout the project.
There is now also more transparency at GNOME, which is both a blessing and a curse. More people from the wider community are able to see what’s happening in the development cycle, and are chiming in on issues and merge requests. This has caused friction at times when things like designs were picked up by the wider community that weren’t ready for comments.
Unfortunately, GNOME does not currently have metrics to share about the changes they’ve seen within their community; however, the overall sentiment has been positive towards the move to GitLab. GNOME is on the path to being a more data-driven organization than it has been in the past, and hopes to share more concrete data in the future.
What are some of the changes in GNOME’s software development lifecycle?
The biggest change in GNOME's software development lifecycle is that they can now build images for testing pipelines, something that couldn't be done before moving to GitLab. In the future, they hope to allow people to preview upcoming releases.
Despite the positive changes in testing practices due to the move to GitLab, QA and wider community testing are still challenges for GNOME. (To be fair, GitLab's Global 2020 DevSecOps Survey found QA/test remain challenging for everyone.) Coordinating teams and members within a large free software project like GNOME is similar to doing so at a large commercial organization -- mostly around coordinating milestones and features spanning multiple teams. This means that GNOME has to hack around the limits of the GitLab Community Edition with homegrown tools.
Another big change to GNOME’s software development lifecycle is that there is now a closer relationship between designers and maintainers because there is more transparency on what the design team is doing.
The move to GitLab has also shortened the cycle for developing Flatpak, a software deployment and package management technology created by members of the GNOME community. The community can now automatically build Flatpak bundles and test changes against those instead of committing things to code. This shortens the feedback for QA, design, and releasing the software.
What do you think GitLab is doing well in supporting open source communities and what else would you like to see?
One of the things that GNOME appreciates most about GitLab is its transparency. It helps to know the roadmap and see what is being worked on in order to form proper expectations and plan ahead.
GNOME is also happy that GitLab is continuing to grow its Developer Relations team and has invested in hiring an open source program manager. They are encouraged that GitLab now has a dedicated resource to understand the specific needs of open source communities on GitLab and craft a strategy to enable growth in this segment.
Using the Community Edition adds some challenges for open source communities since they often have to ask for features to be ported down. There are common features that are important to a lot of open source projects and communities and it is important to identify those and port them down. Having someone who can start conversations around these features is important.
Another area of opportunity for GitLab is to foster a closer relationship between the GitLab team and the community. GNOME would find it especially helpful to get to know GitLab engineers and product managers, in order to feel more comfortable collaborating with them.
While there is more work to be done on this, GitLab is actively taking this feedback into account and is rolling out changes to the GitLab forum. Instead of being just a place to ask technical questions and find answers, there will soon be more of a social component as well.
What kind of organizations would you recommend GitLab for?
Large open source organizations that require coordination among various contributors will benefit from using GitLab. The project or organization doesn’t have to be super big, but when you have 20-40 people, or if your project is something that the industry depends on, GitLab is a great choice due to its features that enable project management, issue tracking, and CI for testing.
Also, if you’re into open source software, then GitLab is your best option from a feature to feature comparison.
What’s new at GNOME and what are some of the new things on the horizon?
GNOME is continuing to invest in expanding its contributor base. Not only are they working on initiatives to improve and scale newcomer onboarding, but they are also hosting a Community Engagement Challenge, along with Endless, to get a younger generation into open source. The Challenge has multiple stages and includes over $65,000 USD in cash and prizes. Phase One winners were recently announced at this year’s GUADEC, GNOME’s annual core conference.
This year’s GUADEC was done remotely due to the pandemic and was a huge success! If you missed it, be sure to check out the GUADEC YouTube channel for videos of the talks. Coming soon will be the annual GNOME.Asia Summit, and the Linux App Summit, which will be co-hosted again with KDE. GNOME also hopes to hold a first-ever Pan African GNOME Summit (PAGS) in the upcoming year.
From a technical standpoint, GNOME is trying to remove their over-reliance on mailing lists by using GitLab projects instead. The release team now makes “freeze break” requests in a GitLab project, and the security team uses a web form that opens a confidential issue in a GitLab project through the GitLab Service Desk feature.
After enthusiastically adopting CI pipelines, GNOME projects are now trying to optimize their workflows to minimise time spent, bandwidth, and energy consumption.
Last but not least, some GNOME members are working on implementing community health metrics in order to evolve into a more data-driven organization. The App Ecosystem working group at CHAOSS was founded earlier this year as a result, and includes members from GNOME and KDE, among others. New members are encouraged to join!
