 Yeah, so my name's Daniel Stone. I am one of the people behind free desktop.org. Free desktop's one of the harder organizations to describe, I think. You guys have got a much easier job. We're a pretty loose umbrella of core foundational open source projects all aimed at the Linux desktop in particular. So we kind of, I should probably actually be sad in the middle because we started out of between the GNOME and KDE projects which you'll hear in a sec as a way for GNOME and KDE to collaborate on common desktop technology from everything like how should drag and drop work through to network management and now as you can see from some of the projects there, a lot of our focus is on graphics and multimedia as well. Yeah, I'm one of the people behind free desktop. I've been there approximately 15 years and I spearheaded and pushed forward. I moved to GitLab which is why I'm sat here. Yeah, so can you hear me? Yeah, so I'm Carlos Soriano. I'm one of the directors in the GNOME foundation and I've been there as a director for three years and in the GNOME project for about seven years now. And I was leading the initiative to switch GNOME from what we have before to the GitLab from all the tooling that we have before to GitLab. And so the GNOME project is free software project and what we do is that we deliver, the main goal is to deliver free software desktop for the Linux. But the GNOME project is not only that, it's also a place for innovation, like we have tools that was born in the GNOME project such as Mono. Do you know Mono, for example? Can you raise your hand? Those that know Mono? Oh, yeah, that's great. So yeah, we created Mono. We also did Gstreamer and also, for example, SystemD that probably you know. And so yeah, I'm basically sitting here just because I'm representing GNOME and I led the initiative to switch to GitLab. Okay, I'm Paul Brown and I am a communications officer for KDE. We also have a flagship project which is a graphical desktop that you can see here. Again, for Linux and for other free operating systems, it works, for example, on FreeBSD and so on. But again, it's not only a desktop, it also creates lots of applications that don't initially work on Plasma but also work on GNOME, thanks to the work of the free desktop, I think, organization and also on other platforms. So some of our most popular applications like Crit and KDE Live, et cetera, work on Windows and Mac and even on Android, they're being ported to Android and stuff like that. So it's not only Linux desktop, what we're talking about, we're also talking about all the applications around that. We have a list on our website. The core applications, there are 242 applications. There are more, but these are the core ones that we distribute every three months, four months, I think, sort of that. And yeah, and the same way as, we also create stuff that works on the back end, for example, if you use any form of browser that uses WebKit or uses the descendant of WebKit, Chrome or Safari or anything like that, WebKit came from KHTML, which was developed by KDE. So we do stuff that then finds its way into other projects, even if they are not open source. Cool, thanks for the background. And I just, my first question, I'll start with you, Carlos, because you started on this journey before the other two communities. I mean, when you were evaluating new tools or new workflow, I mean, what were your requirements like tooling-wise and workflow-wise and what were some of the requirements that you were important to you? Yeah, that's a good question. And I think the foremost requirement that we have is that the tooling must be free software. So that's something that the non-fundation is very wrote on their values, the same for the non-project. So that was the first thing. And so things like GitHub, they are out of question. And so we have a lot of tooling, such as Fabrikator, Baxilla and all of that, that were part of the investigation and research on what's the best tooling for none. So I think the main factors that we had to choose for GitHub was that we were really looking towards a single workflow. So before we had like Baxilla, we had Cigit, we have a million leads, we have a lot of different tooling and that's really hard for new people. And that's something that, for example, GitHub and GitHub did very well and especially GitHub. So when we were choosing the tooling, we were looking at that and how newcomer-friendly they are if they have a powerful CI because we don't have CI either. So all of that was very important for us. And before when I said that free software, that the tool must be free software, I don't mean only to have the code available and be open source. For us, it's very important that the company and the people behind the project are very committed to that because that requires a sustainable project and that really builds trust because the non-project has been now 22 years old. So you cannot rely on something that, you know, is proprietary and can change in three years. You really need free software there. So yeah, I think that's those were the main factors that we have to choose GitHub and I think so far we are quite happy with it. Cool, thanks. Yeah, and I mean, just to add some background, I mean, we have an open source program at GitLab and so any open source projects can apply to get free access to ultimate or go licenses of GitLab and plus like a substantial discount on support but these three communities are, I mean, they're using like a true free addition with community addition. So next question, I guess I'll go to you, Daniel. I mean, you're sort of the second in the group of, you know, moving to GitLab. I mean, I think you told me last night you were asking a lot of questions to Carlos about their experience and what were some of the questions that you were asking and what were some of your key concerns? Yeah, so we came through a little bit after GNOME, probably about a year after you guys. I was actually brought in as part of the GNOME decision-making process to argue the case for Fabricator and you know, I've ended up here so it's all got a bit out of hand. Yeah, I think really though our key consideration was the same like that real commitment to not just having the source open but to having an open development process as well. You know, Freedestop, one of its strands where all the graphical side came from is it's got its roots in a failed vendor consortium and then we later sort of fled and set up home as Freedestop is a true neutral venue. So for us it was super, super important to make sure that the development process was open and transparent, something we could see and get involved in as well. So looking at some other projects, you know, either the decision-making and the roadmap was completely opaque and that wasn't something we were comfortable with in terms of having our foundational infrastructure depend on it or it was a one-person show or it was pay-for-play. So yeah, it was really important that you know, GitLab sort of properly embraced openness because that's super compatible with us as a project. All right, next question I'll throw this to you, Paul. I mean, I think your community started probably like early this year in earnest, like doing proof of concept type of things. Like what were some of the key elements that you're looking at when you're evaluating different things? Well, I could say what they said. So I'll add something to that. There was also the fact that we could host our own instance. This was very important. Everything has to be hosted on, I mean, I think it's the same with, you know, and things like that. Yeah, it has to have open source and, no, free software projects have to be able to control all the aspects of the machines they use for the servers and so on. So this sort of, this ruled out our alternatives. We have currently a bit of a mishmash because in free software projects, what happens, especially free software projects that are as old as ours, 22 years, KD is 25 or 26 this year. I think it's next week or something like that. So that's, you've got a lot of legacy frameworks and workflows and so on. So we cannot say that we're going to migrate totally to GitLab because we have to figure out how to move all that and that's gonna take some time. And some workflows rely on really old scripts and things that have to be changed over. But everybody agreed that it was a move that we had to do because it was, as it is, it's a bit, free software projects normally don't develop, they just grow, you know, like tunes and things like that. And well, it's true. So people are coming in and bringing in their scripts and bringing their workflow and something that is a temporary fix becomes permanent. And you were talking about something that you discovered a temporary fix from 1999. My boy, I have something like that. So, you know, we find the coin. This is a new temporary fix. Yeah, okay, it's, you know, 20 years later. So we have to, we were using reintroduced fabricator I think it's four years ago. And that hasn't worked out too well for us because there's very few people who are supporting that. And we need something that could be supported by a consistent company. And also the process by which new contributors can come in and submit code is difficult with fabricator because it's not familiar. Most people know how to use this fork and then submit a request to, and this is something that fabricator doesn't do. There's this series of hopes you have to jump through that kind of defeat the purpose of having a graphical interface anyway. So, I mean, if you have to use commands that are command line gate, why would you have a graphical interface at all? So fabricator was that. And we were finding one of the groups that were most pushing for a change was the outreach group, which want to grow the community. And they were finding that a lot of people who are coming in were finding big difficulties in contributing back to KD. So we looked for something that people would be familiar with and that was GitLab and we're implementing it so we can also, it's not only the technical, the continuous integration and all these interesting tools that you have, but also because it's familiar, it's usable, and so on. Yeah, cool, thanks. Yeah, I was fortunate enough to be at KD Academy a couple of weeks ago now. And I mean, there's KD Academy's annual conference where all the community members get together. And I knew there was gonna be a session on GitLab. I knew it was a popular topic, but it was actually led by a person like Paul was saying who's in charge of outreach and community growth. And I was pretty impressed. I mean, within that context, the tooling was being discussed. So next question, and this is somewhat near and dear to my heart, I've been a community manager for a couple of different projects. There are very few topics like tools that incite excitement among community members, right? I mean, if you wanna start a lively discussion at a pub, I think one of the good topics is tools. I mean, Carlos, so who are some of the stakeholders that you had to work with or talk to in terms of making a tooling decision like a few years ago? Yeah, so this is something that is really hard. It's really hard to bring consensus in a community like NOM, KD, and FreediaStop. So how we do it? So first, we contact a good lab and we want them to know how much support we can have from them because it's very important for us that we can have the support because a community, members of the community go and go and come. So you need something that is stable and so they bring support to you. And so first we talk with them. We see the possibilities that are there. And then what they did is to bring some key contributors on the community and then we were like six people but they knew they were key contributors. So they knew they have influence on the community, right? So we were discussing options and then when I started, I wanted to bring a fabricator actually, I was not a good lab fan myself. But we started the conversation and just discussing and everything and then we agreed on good lab and just to make sure I tried to bring people from outside of NOM that were not Gila fans and I broke him, I invite him like, hey, can you come to our discussion? That's back in like good lab eights, I think, eight point something. Yeah, yeah, I think so. Yeah, like two years. It looks a lot different now. Yeah, two years ago, yeah. And so I think that was very important and it was very interesting because I bring him as a fabricator fan, other people that were using Baxila or whatever at the end of the meetings that we had over a month. We all agreed that Gila was the solution not only for NOM, but for other projects. So yeah, so once we had that, what we did is we're with other people in the community to create some wiki page where we put all the considerations that we had and so we presented that to the community. We presented the investigation, we presented the research and then we tried to gather feedback and that's the most important part when you present an incentive like this is to gather feedback and make sure that you have some consensus even though it's really hard to know whether there is consensus happening. So we did that over three months. I gather feedback, I come back to GILLAB, we talk how to address that feedback and then back and forth I consult the board as well, the board from the NOM Foundation and we agreed that GILLAB is the right solution and then once I consider the type theme personally that we have an agreement, then I just move forward with that and I set a deadline that if nothing important comes, we will switch to GILLAB. And so that's how I do it. There are multiple ways to do it and I don't think someone has the right way. It's just trying your community and see what works best. So I mean, next question I'll ask you, Daniel. I mean, so one of the things I read, like you published a blog post I think when you made an announcement about switching to GILLAB, I mean, what's been the feedback from the community? I think like one of the areas that you were concerned about was like particularly like a CI capability, but I mean, good or bad, like what were some of the early feedback that you got from the community members? Yeah, I mean, we do have like actual kernel development as well as projects which are adjacent to the kernel going on. So it was a pretty drastic change given up where literally just emailing round patches and like people would shout at you if you use HTML mail or go over 72 characters. So like it was a pretty big move for us, but I think what you were saying about the outreach in KDE was pretty relevant for us. Like we've always been starved of contributors. You know, all of us are sort of doing five different things at the same time. And then yeah, we were sat round wondering why we didn't have more contributors when we had the world's most arcane contribution processes. So a big thing like CI has been really, really helpful in getting people from mildly on board to, you know, rabbit enthusiasts, but the biggest thing for us by far was just relentlessly lowering the barrier to entry. So even just things like pretty much none of the projects that we had had contributing files until we moved to GitLab. And then there was this nice prompt saying you should add a contributing.md. So yeah, that's a good idea actually. Maybe if we told people how to approach contribution to our project and you know what they could expect as well once they've done it, maybe if we did that then we wouldn't see so many people either never turn up or just leave immediately. I mean, one of the things that struck me from your blog post, I mean, I recommend people to read it. I mean, I think it's foolishbar.org. That's right. And I mean, it was very detailed and you even touched on like governance, like you're hoping that governance would improve. Like how was the tool selection like have impact on governance in the community? I guess one of the bigger things with governance is everything was blocking on us was funneled through the admin team. I use the word team loosely. It's mostly just me. As yeah, as is common in open source, right? But so things like adding new accounts and changing permissions, setting up Git hooks for people to mail out commit notifications or whatever. Like all of that had to be funneled through us because me, because there was just no way to segregate and delegate that properly. So one of the things that's been really nice is having the ability for anyone to sign up but then projects as well to decide if someone wants to have commit access, like fine, you just give it to them, we don't care anymore. So it's, I think definitely improved things in the sense that it's allowed all of the member projects because we've got around a bit over 100 member projects, I think it's allowed them to get a little bit more loose and free form, which I think has been really good for them. But then it's also given us more time to do things which aren't creating accounts in LDAP or editing Git hooks by hand. Not what I would want, LDAP man. So next question is to you, Paul. I mean, you guys are still, I mean, going through this journey of adopting GitLab as another tool in your tool chain. I mean, what have been, have been some of the challenges in the early days? Well, we're still very much in the testing phase. I mean, most of the stuff is still being, we're still using the old tools. I can foresee what problems are gonna be because as the title of this panel says, we're talking about organizations that are really massive in scale and in scope. I mean, oh, I have some fears here that I've had to look up because they're difficult to remember, but we have, for example, we have something called KDE Identity, which gives access to things like fabricator, the wiki, et cetera. And there are 68,500 accounts of that. And then of those, there are 2,646 developer accounts, which are the people who can actually send code by a fabricator or Git from the command line, or to subversion. Yes, we still use subversion. Sorry. Really? Yeah. We're sorry for you. Yeah. And there are, so I have another number here, which I was pretty, let's see if I can find it, the number of, one sec. Ah yes, we have 2,450 official Git repositories in gitkd.org, and then there are 390 personal repositories of people who are developing stuff that don't want to make it, that are not ready to sort of make them public yet. So I think the challenge is gonna be big just because of the size of moving stuff. And a lot of these people are using arcane tools, and the typical developer excuse for that is, well, it works for me. The problem is that that's not good enough because in a community you want to have more than one person working on each project because otherwise if that person gets hit by a bus then we have a problem. So we have to somehow come up with a good framework to get all these things under control. It's been, as I say, it's been pretty chaotic up until now. Yeah, I mean as these numbers like demonstrate, I mean a lot of the open source projects, like especially with the number of contributors in projects, I mean it very quickly starts looking at medium and large sized businesses. So I mean that's the title. I think we have about six minutes left. I don't want to dominate, I monopolize all the questions. Like do any of the audience members have any questions? Like if you can raise your hand, if not I can keep going. I'm curious, I think Carlos mentioned Buxilla a couple of times and I think obviously all of those projects are used in Buxilla. It's interesting because the scale of users you have is much, much more than any other project we'll usually have. Have you ever considered embracing GitLab's issue tracker for that as well? Is it feasible at all? I mean, as you know, we are using the whole GitLab, the same thing. Yeah, they show tracker, the CI, everything that we use is GitLab. Like before we have Buxilla, they give plenty of tools or something like that and with plugins to make them work and all of that. Now, at least for now, everything is GitLab. Okay. I'm not too afraid to stop. Yeah, it's the same for us. We're just waiting for, there's a couple of kernel graphics drivers that need to migrate. Everything else is on GitLab issues. And so hopefully next week I get to permanently turn Buxilla into a read-only archive and I'm so happy about that. Other questions? I'm just wondering that historically a lot of open-source info was like old and un-maintained but like how much are you going to be keeping track with like the master or the releases or like basically how often are you going to be updating your instances of GitLab? Update your instances? How regular are you going to update the instance of GitLab? Do I understand the question correctly that you said how regularly we are going to update the GitLab instance? So for now it's daily. We literally do it daily. We use open shift I think. And then we have some Chrome job that is doing it updates every day. And that's pretty good. And it's one of the calls that we had to always be updated because with Buxilla sometimes we were four years old instance with security issues. That's insane. That's insane. So yeah, not with GitLab. It's not a coincidence that when we decided to go to GitLab and then FreeList and then KD. We, I mean a lot of people seem to think that we are competing in some way but we usually, we collaborate on these things and we say okay, well okay in this case we say okay, let's see if no crashes. Crashes and burns with this but no it didn't. So then we said okay this will be fine and we were there with you and we were there with their blog post and basically we are following that. We're following their lead at the moment. Yeah, so we're on Kubernetes rather than OpenShift for expedience but yeah, where usually takes us about 12 hours to deploy a release. Most of that is just waiting for a nice quiet time to pull it down and restart. But yeah, if you ever, like you were saying, if you ever needed a bugzilla to GitLab issue migration script, G'dome had a really good one which I absolutely butchered for our bugzillas subtly different for some reason somehow. But yeah, we do share a lot of the infrastructure and some of the tooling around it as well. Any other questions from the audience? One more over here. How much pre-thinking did you do about the group setups and what was a project? What was a sort of group of projects on it from your sort of having that historic background? This is definitely gonna be different for all of us. Like G'dome's a much more coherent organization. For free desktop we've got a process to go through where people request a specific top level group. They can't create new ones, it's admin only. Once they've got the top level group they're free to do anything with that. Barring code of conduct violation or something massively illegal. But yeah, I guess for you guys it's a very different answer, right? Yeah, I personally wanted to go like to give the least permission as possible and then grab more if there is a need. So actually no, we didn't. So now we have a group which is none. Everyone has developer permissions there and we have the projects there but you cannot create new projects. So now the good thing is that we have personal repositories so people can have them and then we have another group which is like random projects that we have to request me to add a new project and I add there. And so that's how we split it. We are pretty organized in that way, like vertically organized in that way as opposed to free desktop which is more like a network of organization. In case it's a bit different, I can tell you how it's done now which I guess we'll translate it into GitLab. If you, I mean you can, anybody can apply for a KDE identity which gives you access to things like be able to work on the wiki or to work on the task boards or whatever but you cannot actually change any code for that you need a developer account. And to do that you have to request it from the system in working group, the system in work and you have to have another developer vouch for you that you are reliable, blah, blah, blah. And that's how you get to become a developer account. As for how the projects are classified, we have projects that are private, that haven't become public yet for the rest of the community then we have an incubator and then once they have been stabilized and seem to be useful and maintained, et cetera, then they become an official KDE application. I imagine that that will be the process that will be also translated to GitLab. Cool, it looks like we're out of time. Thank you audience member for your questions and thank you panelists. And we'll be around I think like the rest of the afternoon at the party as well so come talk to us if you have any questions.