 So glad to be here. I guess we'll do a round of introductions. My name is Ray Paik, and I manage the code contributor program here at GitLab. And I've had a great fortune in the past 18 months or so of people that have been contributing code through MRs to GitLab. And what I learned pretty quickly was that a lot of them are actually customers, or even resellers, which I find out to my pleasant surprise. So without further ado, I'll start with you, Pierre. I'll let you introduce yourself, tell us where you're from, and how long you've been a customer at GitLab. Yeah. So hi, this is Pierre. So I'm a continuous integration specialist in Group Rono. Basically, we were hired by Rono like three years ago. Tried to make the company evolve into a software-oriented company, a company being able to build software by themselves. Because before, they were just using contractors to do that. And we had to choose in the beginning what we wanted to use as a source control system. And we choose GitLab at the time. And so that's three years ago. And so we have been investing a lot in this. We have been doing a lot of tooling around it. And yeah, cool, right? James, sorry. I'm James Starp. I'm a principal software developer at T-Mobile. I work on a team that helps develop the software that our call centers run to manage our customer accounts. My primary focus right now is on reducing duplicate effort and improving the T-Mobile culture within development, specifically through inner-source. And GitLab has been a huge part of that. Cool. All right, thanks, last but not least, JB. My name is JB. I work with CreationLine, who is the primary reseller for GitLab in Japan. My role is I work as an agile coach. So I support teams and organizations to be able to adapt agile methodologies and mindset so they can be more impactful on what they do. And as you can guess, it eventually comes to how do we get to adopt DevOps. And I also support teams and organizations to adopt DevOps and also adopt GitLab in their organizations. Right, thanks. So it's good to have a representative from three different continents, which is great. And then I just want to show, I only have one slide besides our Facebook page, basically. So this is a dashboard that we have. Hopefully the URL is easy enough to remember. Go to contributors.gitlab.com. And you can see the, this is where people like Sid got their stats on how many merge requests are coming in and how many are making contributions. And if you look at sort of at the bottom right of the slide, it even shows if people are using their work email address to make contributions, you'll see organizations like CERN and Siemens and others that have been making contributions to GitLab. So I know this is an eye chart, but I encourage you to take a look at the amount of contributions that we're getting from different geographies and different organizations. So that was my one and only slide. And I'll start with a few questions. And I think I'll start with you, James, if you don't mind. I mean, tell me about your first MR. And what's your motivation for getting started? And then what was your experience like? Yeah, so my first merge request for GitLab was actually to improve the documentation around NPM repository hosting. T-Mobile's only had GitLab in place for about six months or so. And I've been one of the early adopters trying to lead the way. And to scale out GitLab adoption, good documentation is very important. So I was essentially one of the first to use that feature of GitLab within the company. I found some. I ran into some snags along the way. And I just thought, gosh, they could use some better documentation. There was the edit button at the bottom of the page. I clicked it, and the rest was history, I guess. The experience was really great. Just very easy to do. There was actually good documentation on the process. And the GitLab team jumped right on it. And my request only took a day or two to get in place, which was really nice. And then it was also something that was great, because I learned a lot from the experience as trying to promote inner-source within T-Mobile, seeing in action, working with a group of essentially strangers on making something better. I was able to take that knowledge, bring it back to T-Mobile, and share it as a good example of working collaboratively. So it was a really nice experience. Right. I'm Pierre. I guess I'll ask the same question to you. When was your first MR, and what do you remember about it? So the first MR was two years ago. Actually, when we started using GitLab, we missed some features and mostly some real-time features that we wanted to implement on multi-project. And we actually built a bot that is connected to the event, the webhooks from GitLab. And so basically, we needed a new information on, I don't remember exactly what was the information that we needed, but we needed the information. And so we just downloaded GDK and tried to start hacking on it. And we find quite easily the code that was managing those hooks. And we looked at the tests. And they were very nice and well done. And you can just easily understand it and add one test for your use case. And that's it. You send that merge request. And mine was a little bit longer to be approved because the owner didn't understand well what was my use case. So I had to work a little bit more to make the owner of the code understand the use case and so on. But in the end, we managed to make the code merged. And since that, we have merged other merge requests on similar code for our bot. OK, great. Thanks. And next question I'll ask you, JB. And I mean, I was familiar with your colleagues, Hato-san, who has been very active in our community. And I didn't realize until one of my GitLab team members pointed out he works for a creation line, which is a reseller. So I want to ask you about, how do they get started at creation line? I mean, I don't think I see a lot of resellers do that. So tell me about how they started and how you decide to submit MRs and the process that you go through internally. Right, so I'm located in Tokyo, in Japan. And back three years ago, I wanted to join GitLab. There was no job position open for the type of role I was looking for at the time, especially in Japan. So I ended up working with creation line and get creation line to become a reseller. Because at the time, there was a very active reseller program. And I think it's still in place now. And I thought that was the best way at the moment for me to be able to work with GitLab. So we became reseller. And as a reseller, we go and consult our customers so that they can get the maximum benefit out of GitLab. And at one point, I think it was back two years ago, I was supporting a customer, quite a big firm. And they were developing their own DevOps solution, mostly based on GitLab, where they could use it internally for all their development teams. It had to be separated into multiple instances. And when they were doing this, they were trying to automate most of the work that they were doing. And they were missing an API endpoint at some point where they wanted to do some integration configuration automatically. And I told them, why don't you make a merge request? I was saying, OK, we are too scared about having these discussions in English. We are not very comfortable. They are Japanese speakers. They are not really comfortable in English. So then I told myself, OK, what do I want to try? I like writing code. Doesn't sound like too much of a challenge. And I did take my chance to get started writing a merge request for GitLab. And within a couple of hours, I got everything up and ready. And I got a lot of feedback from the developers from GitLab community, giving me opportunities to do some refactoring later on. Everything was looking fine. But they say, OK, why don't we do some refactoring? So it's like we have some candidates for that, which helped me to learn even more about how to write clean code on GitLab source repository. And after a couple of days, it got merged. And that's how I started to really think, oh, that's probably something I want to keep doing. OK, great. So I mean, when you work with your customers in Japan, is this something that you talk about, the ability to make contributions and some of the track record of your past contributions? I don't know if that's something that you discuss with your potential customers or current customers. I'm sorry. I mean, so I mean, I think this is pretty unique for a reseller to make contributions to an open source community. Is this something that you talk about with your customers in Japan or? Right, usually we're not supposed to be committed into pushing some code as a reseller, but it's just as we love writing code as individual contributors. So we don't do this as a reseller, we just do this as like individual contributors. And we just do this for passion of code. As you mentioned, another colleague of mine who's being MVP for GitLab, I think three times now, is just spending half of his time contributing to open source and GitLab, of course. And that is something that inside CreationLine we have been changing a lot. And we've been pushing as many developers as we can to spend some of their time contributing to open source. Because it's really important for us. OK, great. Thanks. And then I think I forgot to mention this in the beginning. Like in about 10 minutes, I'm going to open up questions to the audience members as well. So I don't ask all the questions of, I mean, if you think of any questions, you'll be given an opportunity. I think we'll have a mic that we should be able to carry over to you. So next question I'll ask this to you, Pierre. Like I mean, I think you've been most, if not all, of your contributions have been our runner project. You may have had MRs in like other areas of GitLab. But how do you sort of figure out like what kind of contributions you want to make? Do you look at our issue boards? Or is it mostly like way to enhance our product or features? So as I mean, a big enterprise, basically, I cannot commit sometimes to just go into issues to find out the issues that I would like to work on. I contribute when I have a task that my company really needs and we already look at the issues and the issue is not moving forward because it's so specific to our company. And then we say, OK, it's specific to us. We think we can do it without too much maintenance burden. So let's try to make a design and make a proposal for this particular topic issue. So that's basically how we decide on which topic we are working on. And basically, the last major question I was working on is on the support of Docker on Windows, which we have a lot of Windows tools and we want to actually run Windows containers. And this is really a very niche topic. There is not many people doing that. So at some point, we have to work on it and try to push it. So that's basically it. OK, great. Thanks. I think next couple of questions, I'll start with you, James. I mean, you've obviously, beyond that documentation, MR for documentation you made, you made other contributions like recently. And so I mean, what has you sort of have you coming back to make contributions to GitLab and what kind of, I mean, what have you been doing right, I guess, to encourage you to come back and continue to make contributions? Yeah, so my main focus actually has been on documentation, because like I said, in order for us to scale GitLab out quickly within our organization, we want to remove as many impediments as possible from within the team. But as far as code contributions, I actually have two that are active right now. So they haven't been merged yet. But along the lines of documentation, one of the things we need for adoption is really good examples. So I have two projects that I'm looking to get added to the GitLab templates feature. One is an example of an NPM package, including the publishing and consuming the package from within GitLab CI using GitLab's NPM repository. There are a lot of little gotchas along the way. So having a fully functioning example, I think, is really going to help smooth out the experience for our teams. The other is a Gatsby-based template for static website or React application generator. So I think that'll be really handy as well. It publishes to GitLab pages. And Gatsby is just in general a very nice framework for generating React-based applications. OK, cool. And I think I asked you this question like last night. I mean, in general, like a T-Mobile, is it pretty straightforward to make contributions to any open source projects? Or do you need to go through a lot of review processes or compliance issues? Yeah, actually, our process is really straightforward. So there's essentially two paths. One is you can contribute to an existing project. The overhead there is very low. Pretty much as long as you promise not to betray any of our secrets or intellectual property or security-related issues, we have a very wide lane we can travel through to make contributions. If we want to open source something that is currently internal to the company, it's also pretty easy. Our process is still developing. But right now, it's essentially, there are a few emails that have to go back and forth. We have a meeting with some technical folks, usually the senior level ICs, our principal level, and our MTS level engineers, just to give it a review. And then we also have a meeting with the legal team to kind of go over what is this thing that we're releasing, what intellectual property might be involved before we release it so we can make sure we're not at risk. But it doesn't take long, actually. It's a really easy process to go through. One of the reasons I like working there. All right, great. So, I mean, JB, I think you mentioned not just GitLab. I mean, you and your colleagues contribute to a lot of different open source projects. So what are your motivations of participating in open source communities? And what do you get out of it personally or professionally? Well, I think mainly because we just love writing code. And being able to interact in a open source community is the best way for, especially for people who get started in development, to get to learn fast, to get to read some code, somebody else's code, understand design pattern, coding patterns, participating to open source community is definitely a way that will get you faster to a higher level. So there is definitely something that we recommend. Yeah, basically, we do like writing code. And that's probably the main motivation. And in the previous example that I mentioned before, if this is also enabling us to help our customers achieve things, then there's no reason for us to stop. Okay, great. And I guess, I mean, it's somewhat similar question to you, Pierre. I mean, do you have other colleagues that ever know a system that are contributing to GitLab? And if so, do you coordinate a lot of your contributions or how do you sort of organize your work internally? Not really. At some point, we wanted to coordinate a list of issues. We wanted to push from the company because we have some issues that are created by our colleagues. But eventually, we didn't do that because it just works. We don't have to really have an enterprise and one voice. And it just works. So I have some colleagues that also send some small patches. It's never like a thousand lines of code. It's just adding a very small feature and it's a little bit like JB. It allows us to improve our software culture because we are mainly a Python shop in my team. And so looking at the Ruby on-rails code is quite good and it's, you know, as GitLab is open source code, you know, it's public. So you take a large amount of work to make it very polished. So it's very nice and it's really interesting to look how the Ruby community just solves the problem that Python is not doing the same at all. So it's, yeah, so we spend some time learning about, so learning from the culture of this project and we also spend some time making our own requirements fixed into the product. So that's the kind of thing you cannot do with proprietary software. With, I don't know, with other software, you have to beg to the commercial, to the sales people, I really need this feature and they say, okay, we will think about it, we call you later and eventually you have nothing or you have to wait a lot of time here. You can just do your small change and then it's implemented, you can even patch in production while waiting for the next release and that's just working fine for us. Okay, right. And I mean, in open source communities in general, I think a lot of focus right or wrong tend to be on code contributions but I think there are other areas where people can help us build great communities and I think, JB, you've been doing a lot of that through like workshops and like a meetups that you've been participating, so tell us a little bit about that and what kind of things that you do for meetups and workshops. There's a big community in Japan, especially in Tokyo around GitLab and every time we organize some meetups, as during the week it's after work, we still get more than 100 participants coming and participating, doing lightning talks, sharing about their experience, sharing about what kind of improvement we could bring to GitLab, which is very valuable. And that is something where CreationLine is also really committed to support, both financially by providing drinks or also organizing specific events involving the community. One of them that we frequently organize is a CI workshop where we help a lot of people who have never used GitLab CI before. We help them to get started writing their first CI pipeline so that they can build a container, push it to a container image, push it to the registry and then be able to pull it on their local machine and run their website. That is something that we organize once every quarter also. Great. Looks like we have about seven minutes left. I want to make sure that if there are any questions in the audience, I mean feel free to raise your hand and then William's got the microphone. Are there any questions from the audience? If not, I'll be happy to keep going. Looks like we have a question over there. Hey there. Just curious, it seems like a lot of you are contributing as part of your kind of professional roles. What can we do to keep you involved in the GitLab community? Should things change professionally? How do we keep people that start contributing to GitLab as part of their jobs in the community when they're changing jobs and things? I couldn't hear the question. Go ahead. You could. Yeah, I couldn't hear the question. I think. So I think like if I heard correctly, I mean how can we just make it easier in general for people to make contributions that right, John? And then or allow, give them more opportunities to contribute to GitLab as part of their job. Can you hear me now? Yeah, it's better. Okay, so my question was, you know, a lot of you are contributing as part of your kind of professional role right now. What can we do to keep you in the GitLab community should you change jobs in the future? Like what are the things that are gonna keep you engaged with the GitLab community over the long term? Yeah, so like I guess for example, even if you were to change jobs, you know, what are the things that we can do to like encourage you to keep contributing? I'd love to answer that one. Yeah, go ahead. So if I were to change jobs, you know, I don't necessarily know what I'm going into from, you know, source code management perspective, right? Certainly I'd like if my, you know, my next job, I'd love it if they use GitLab, but I don't know that that's going to be the case. So to stay involved, I'd really like to see GitLab be at the forefront of open source. I'm an active community member in open source in general. I contribute to a lot of small projects on my own time and, you know, I would certainly see GitLab being one of them. There's a network effect, though, that GitHub has, that GitLab just doesn't quite have yet. And I really, I believe that GitLab's approach that having that open source core and that an incredibly transparent way of operating, I think they will eventually become, you know, the place for open source. But I don't think they are yet. Once they are, I can guarantee I'll never leave it. Yeah, it's interesting to see that. So I don't remember what I was willing to say. Yeah, so I don't... Sorry, JB, do you have anything you want to add there? If I am to change my job someday, I'd love to join GitLab. I was still okay three years ago, I was still okay today. So I just hope GitLab is able to, you know, get a lot of people involved in different communities in different companies, but also make it easier to people in Japan to work for GitLab. That'd be great. Yeah, I mean, I think we, like around lunch, we had a first of us feather session on community. And I think we use like Kubernetes as an example, because it's sort of the guiding light these days. I mean, within Kubernetes, like people change jobs, while you still see them like contributing, right? I think that's sort of what we want to see. And hopefully, like you said, James, like GitLab is an open source project of choice where people keep on contributing no matter who their employers are. So any other questions? And thanks for repeating the question, so can I? Yeah, I'll add one comment that the interesting bit is that GitHub is actually closed source software. You cannot contribute to GitHub, but they host the most open source software. GitLab is open source software, but we actually host the most closed source software because of our prevalence with an enterprise. So, yeah, we'd love additional questions for our panel. Get out there and kick their butts. The thing is, we see a lot of open source projects that are actually using GitLab on premise to actually run their code because they don't want to have their own infrastructure. We see, like, we have Debian, Gnome, and very big projects. And so the thing is, it's not on GitLab.com, so it doesn't benefit from the network effect. And so that's interesting, and it's a little bit a problem for you because you don't have the network effect from the huge project that are actually using GitLab. And so this is interesting, I think. Yeah, I mean, we, I don't know if you know, like we, speaking of jobs at GitLab, one of the hires that we want to make is somebody who manages the open source program. We sort of been reacting to requests that have been coming in, but we'd love to have somebody with a strong open source background to work with other open source communities, like the big ones that you mentioned, on a more proactive basis. But a couple of minutes left, so I'm gonna ask like one last parting question before, oh. Ray, we do have just one more here, and I think we have enough time, we can jump into these ones. Thanks for this great panel. One question I have is, your contributions, do you coordinate them within your company, maybe with other people? Do you build missing features, or is it more? I'm sorry, you have to, I think you'll have to repeat the question, if you don't mind. Yeah, your contributions, do you coordinate those with other people inside your company, in the context of building larger features that you need, that GitLab doesn't have, or is it just your scratch on edge, and you do it for yourself? So like if I heard your question correctly, is it the discretion of individuals who make contributions, or is it like a more following like a corporate plan or strategy, is that correct? More than other people inside the company. Yeah, I think it's similar to, you know, there's a reason why I asked a question to you, James, about like how is it done at like a T-Mobile as an example, but you know, maybe like from Runeau's standpoint, like if you want to decide to make contributions to, I mean, let's say Kubernetes, like how do you need to get expressive permission from somebody to be able to do that, or is it like, it's a pretty easy, like it is at T-Mobile? Yeah, so in our company, we don't have an ancient software culture, so it's just building up. So for now, we don't have a strict process, we are currently building it. So we just let people that have open source background just do as they think it's right. So we want to have a better process than that. And so basically people who are contributing are just already like open source fans doing that for a long time, so we don't have to teach them the rules. And you know, not all the people that you have in the industry, they are willing to, it's not really easy for everybody to contribute because you know, they are shy, they don't know exactly how it will work. So people will judge my work, I don't know them. And so it's not quite easy to start and send your code, it puts you on the public. So that's why not that many people inside the company are doing it, this is always the same people. And we are trying to educate people on that and you know, inner source is also part of this culture. Once you start teaching people inner source and maybe when you have the inner source program, then people are starting to understand how it's good to collaborate and then they want to do that on the public. And then they want to start doing more open source contribution in the public. I don't know if you have some opinion on that. Well, I know a lot of our inner source talks kind of start with, well, what would GitLab do? Oh, okay. I didn't hear the full answer though, it's hard to. Oh yeah, my question was in your idea, the inner source program does that help people to contribute more on open source in the public? Yeah, there's certainly a huge spirit of encouragement for sure. There's a lot of kudos that go around if you do something either inner source or open source. We're very big on it in general. We actually have a formal recognition program that folks use, it's not purely for inner and open source but I know when folks make contributions that formal recognition program gets used a lot. Oh, thank you so much for doing this and whether it's getting the T-Mobile name out there or clearing some roadblock for some team, having a clear path for recognition has really I think helped spread adoption and encourage people to try. And I think I've seen wide range of spectrum. I mean, there are companies that are, especially in the heavily regulated industry, it's like you need multiple layers of permission to make contributions and you need to be on a specific list to be able to contribute to projects like X, Y and Z. But there are other companies that have, they not only have inner sourcing but they would have open source program office internally and they do a really good job of onboarding people on like etiquettes on how a process of contributing to open source projects in general. So I think like the mileage is very, I mean it's sort of like a hand wavy type of answer but I don't think it's, so it's interesting to hear perspective from even these panelists and how their experiences are internally. So I think we're like out of time. So thank you panelists and then thank you audience members for your questions and I think all of us will be around like the rest of the day so come feel free to grab us if you have any other questions. Thank you. Thank you. Thank you. Thank you.