What if there was a way to redefine the significance of non-code contributions in open source projects? That's exactly what our guest, Bryan Behrenshausen of GitLab, is here to explore with us. OSPea, Felicity Brand, and Bryan journey together through the evolving landscape of open source projects and discuss the value of non-code contributions. Bryan shares his insights into the creation of contributor pathways, the optimization of recognition systems, and the importance of fostering an environment of effective communication.
Felicity and Bryan discuss remote work and how asynchronous communication can revolutionize your work culture. We unwrap GitLab's unique model that's setting industry benchmarks, discussing their tools, policies, and practices that cultivate a healthy work environment. Bryan explains GitLab's innovative Team Ops model, which champions a distributed, asynchronous work approach, ensuring everyone feels connected and valued.
Bryan and Felicity dive into GitLab's Open Source Programs and Partnerships, discussing the exciting opportunities these programs bring to the table and how they play a vital role in nurturing a thriving open source ecosystem.
Show notes
Welcome to the Open Strategy Partners podcast, "Communicate, Connect, Grow!" At Open Strategy Partners, we specialize in strategic product communication. We help you communicate the value of what you do, connect you with the people who need to know about it, and grow.
To get in touch with us, follow what we’re doing, or learn about our Writer Enablement Workshops, you can:
What if there was a way to redefine the significance of non-code contributions in open source projects? That's exactly what our guest, Bryan Behrenshausen of GitLab, is here to explore with us. OSPea, Felicity Brand, and Bryan journey together through the evolving landscape of open source projects and discuss the value of non-code contributions. Bryan shares his insights into the creation of contributor pathways, the optimization of recognition systems, and the importance of fostering an environment of effective communication.
Felicity and Bryan discuss remote work and how asynchronous communication can revolutionize your work culture. We unwrap GitLab's unique model that's setting industry benchmarks, discussing their tools, policies, and practices that cultivate a healthy work environment. Bryan explains GitLab's innovative Team Ops model, which champions a distributed, asynchronous work approach, ensuring everyone feels connected and valued.
Bryan and Felicity dive into GitLab's Open Source Programs and Partnerships, discussing the exciting opportunities these programs bring to the table and how they play a vital role in nurturing a thriving open source ecosystem.
Show notes
Welcome to the Open Strategy Partners podcast, "Communicate, Connect, Grow!" At Open Strategy Partners, we specialize in strategic product communication. We help you communicate the value of what you do, connect you with the people who need to know about it, and grow.
To get in touch with us, follow what we’re doing, or learn about our Writer Enablement Workshops, you can:
Hi, I'm Carl from OSP and this is Communicate Connect Grow, the OSP podcast. At OSP, we do a lot of thinking about what makes for effective, consistent communication. In this podcast, we want to show you how we translate between technical complexity and business value to create strategic product communication at OSP and we want to learn more from you and our guests. This episode is part of our Connect series on the podcast. Connect episodes are in-depth conversations with interesting, smart people about who they are, what they do and how they approach their life and work as communicators, technologists and leaders. Today, OSPea Felicity Brand sits down with from GitLab. These two discover they are kindred spirits with a shared love of writing and editing. They chat about the importance of non-code contributions in open source, best practices when you're all remote and how fun it can be to work asynchronously. Please enjoy this conversation with Felicity and Bryan.
Felicity Brand:Hello everyone. I am Felicity Brand, a communications consultant at Open Strategy Partners, and today I'm joined by , senior Open Source Program Manager at GitLab. Welcome, Bryan.
Bryan Behrenshausen:Thanks so much. You got my last name in one. That's really impressive. Thanks for having me on the podcast. Just thanks for doing the podcast. I have to say, since you invited me, I've gone through the back catalog, I've been plowing through and it's just a delight. To be honest, it's a podcast I've been looking for for a long time. I'm just delighted that it exists. Thank you.
Felicity Brand:I'm glad to hear that they say write the book you want to read and, I think, make the podcast you want to hear.
Bryan Behrenshausen:I wanted to hear it too. Thank you very much. It's really been a pleasure. I had a long car ride a couple of weeks ago. Just queued up a bunch and have been enjoying them, thanks.
Felicity Brand:Fantastic to hear. This is the first time we've spoken in person. We met recently through The Good Docs Project which is an open source project I'm involved with that is creating best practice documentation, templates for software and communities. The Good Docs was recently invited to become a GitLab open source partner, which is a major milestone for the project. We were delighted with that. Bryan, I'm really happy to chat with you today. I suspect that we are kindred spirits. We both like writing, editing and open source. Can you tell us briefly about your role at GitLab?
Bryan Behrenshausen:Sure Happy to. I am Senior Open Source Program Manager at GitLab. That is a role that's on our developer relations team, which itself is embedded in the marketing organization. All the various members of my team operate at that interface between GitLab, the company and the wider GitLab community. Naturally, because we're an open core product, we're supremely interested in the health and well-being of the GitLab developer community. My role, however, isn't necessarily to look after open source contributions to GitLab. I have teammates wonderful teammates in contributor success who do that work Not contributions to GitLab, but it's more focused on open source contributions on GitLab. My role is focused on really assisting and empowering the open source projects that choose to develop on and with GitLab. Make sure they have what they need in order to succeed to shine a spotlight on the great open source work that occurs on and with GitLab. I run a few programs as part of that remit, but it seems to me that we're going to probably get into those a little bit later. I'll withhold my elaboration to them, but that's my role at GitLab.
Felicity Brand:That sounds like a many and varied role. Very interesting. I'm sure that keeps you on your toes.
Bryan Behrenshausen:Yes, it does.
Felicity Brand:I'm curious to hear about your journey to open source, but first I wanted to share my story. I came to open source as recently as four years ago. Two things happened at the same time. I did the Google season of docs their inaugural program in 2019, and I joined Open Strategy Partners. Around the same time. I was involved at the co-founding of The Good Docs Project. There was this confluence of events. Prior to that, I had spent my career as a tech writer in working for software companies. What I discovered, or what I working with open source helped me discover in my adult life, is that I am intrinsically motivated. I would always come to work in my traditional companies, assuming that everyone else had the same motivation as me. I was always surprised when I found out that actually no, they were coming to work because they needed a pay check, they needed to pay the bills.
Felicity Brand:I was always interested in the success of building the thing or getting something off the ground. Open source was a real eye-opener for me because what I found was people were coming to a project to build something. Everyone was interested in seeing it succeed. We're all volunteering our time, so you're kind of rubbing shoulders with people who are good at what they do. They're interested in the success of a thing and that's the way I love to work. Obviously that is a bit rosy Like I'm sure there are horror stories out there in open source, but that's why I feel so privileged today to work in open source with open strategy partners. We have a lot of open source clients. I spend my time in other open source projects. TYPO 3 is a large open source CMS and obviously The Good Docs Project. So that's my happy story.
Felicity Brand:But, Bryan, I know you've been involved with open source a lot longer than that, so please tell me what was your first interaction with open source.
Bryan Behrenshausen:Yeah, well, I'm happy to. But first I just want to comment on that and say welcome and second say you know, I know we're going to talk about contributions to open source that are not development focused in a little while at least, I believe we will. I just want to say, you know, that's why recognizing those contributions is important, because there are many you know felicities in the world who have this intrinsic sense of motivation, a strong orientation toward community, and they are the stuff that open source projects are made of. Right, they might not do the specific kind of work that you know we have historically recognized in open source, but they are the type of people that not only thrive in open source work but also make open source projects thrive. This is why I'm glad that we're, you know, we're having this conversation about, about those practices. But anyway, I just wanted to remark on that as a prelude to, perhaps you know, what we'll discuss later.
Bryan Behrenshausen:So I'm happy to tell you about my history in open source, and that is starts in 2007, late 2007, when I purchased what at the time was my first netbook. Do you have one of these, one of these netbook computers? It was like a very small, the low spec notebook computers that were focused on portability, right, it was a product category that was super hot for a burn a star that burned super bright, super quickly. They don't make them much anymore. They were low, these kind of low spec notebook computers, and I had what was widely considered the first model, the EEPC or the EPC 701. And that was running a Linux distribution called Zandross, a custom Linux distribution called Zandross Linux, which was based on Debian, and that was my first exposure to mainstream desktop consumer facing open source software in general. I mean, of course, you know, like like most people, I've been using open source software for years because I've been using the internet and the internet is built on open source software, so I've been using open source software.
Bryan Behrenshausen:But I mean my first exposure to, you know, desktop consumer facing open source software. It was in 2007. And of course, you know, soon enough I ran up against the limitations of that machine and started poking around with it. And because it's it's open source and because it's Linux, you can poke around a lot further than you can with other tools and I learned how to access the command line, and then I learned how to run apt and app get, and then the rest is sort of history, right. So all that, though I will say I never learned how to develop software. You know, from the very beginning of my history with my history with computers, you know, sitting up in my grandfather's study playing around on his Commodore 64 and learning how to make it work, you know, I never. I never had an interest in programming. But since that initial encounter with Zandross I've come to care really deeply about issues surrounding free and open source software, digital rights etc. And like so many people, I guess I came for the technology but I stayed for the philosophy, you know, when it comes to open source and free software. So I've been into open source software as a user and an advocate for a long time.
Bryan Behrenshausen:But I got my first internship in open source at Red Hat in 2011, when I was also doing my PhD in communication studies in North Carolina, and it's experience you know about which I think I'm still pinching myself to this day really like an analogy for those of us here in the States, I guess, would be you know, it's like saying you got into baseball and then you got drafted by the Yankees right out of you know, as soon as you got into baseball, like it's just you know, it's like you go. I worked at Red Hat for 12 years and it was like you know, playing at the epicenter of open source work, working with the best of the best in the field, from day one, like it was just a magical experience, right. So in that 12 years at Red Hat, I was an intern, I worked and then was hired full time after I finished my degree, but I worked on the brand team and in corporate marketing and in public relations and in the open source program office and a bunch of different roles there, but in all those roles I essentially wrote and edited and served as a community manager in some way or another. So Kindred Spirits, felicity, yes, as you said. Yeah in 2021, I joined GitLab to help grow open source programs as part of developer relations. And now I'm talking to you.
Felicity Brand:Wow, that sounds like a dream.
Bryan Behrenshausen:It has been.
Felicity Brand:Well, so let's talk about non code contributions. Like you, I am not a software developer. I've worked developer adjacent for my career as a technical writer.
Felicity Brand:I recognized that I had something to offer open source communities, I suppose because I know that software projects are so much more than just the code. Sure, you can open source your code, but there has to be kind of an ecosystem around that, and so wherever there is code, there is going to need to be a tech writer in my view. So that's why I kind of thought, well, of course there's a space for me here, of course I have something to offer, and what I've seen in my time. So over those four years, I've seen more and more technical writers, ux designers, product owners, people kind of flocking to open source projects and products, looking to either give back or just to get experience for their portfolio, something like that. So let's talk about the importance of non code contributions.
Bryan Behrenshausen:Yeah, the subject that's near and dear to my heart because it's as I said previously, it's where I sit and where I've always sat. When I started getting involved in open source as more than just a user, I volunteered with documentation projects, worked on the Ubuntu manual project at the time because I knew that. I knew that I couldn't contribute a lick of code, but I knew I could help brush up some documentation. I could write a user manual and things like that. So I've always felt like a valued and important member of the open source ecosystem without contributing a line of code. I think it did make my first code contribution a year or two ago when I changed the text on a button. I think that counts right. Like I'm pretty sure that I was digging around in somebody's like Python file, so I'm pretty sure you know that counts.
Felicity Brand:Yeah, I think so, and have you noticed so in your time? From 2007, have you noticed a shift or a change in terms of valuing contributions? That are code.
Bryan Behrenshausen:I really have, yeah, and it's been a welcome and refreshing change. And the first thing I'll say is that what I'm seeing is something that I welcome, which is the erosion or sort of the erasure of the code non-code distinction right applied to the field of open source contributions. Right, that's really yeah, it only really serves to reify code contributions as a kind of a privileged site or a privileged class of contribution by marking it, you know, linguistically, as the dominant and then everything else is not that right. But like. So what you're saying is essentially there's code and non-code contributions and the other codes are. The other contributions are just as you know. But I prefer to just talk about open source contributions, you know, and development is one and documentation is one, and so I try to avoid the code non-code distinction as a way of reifying the code as dominant form of contribution.
Felicity Brand:But I like that idea and I think it is reflected in projects contribution guidelines. So often projects will have a document which outlines how they want people to contribute to their project, and sometimes you will see kind of a split. This is how you do a code contribution, but it's great if you can bring them all together in one.
Bryan Behrenshausen:I think that projects that are really mature and thoughtful about these things work on various contributor pathways. So they start with the user or the contributor, rather, and they start with that contributor's passion and that contributor's skill set and they build contributor pathways that optimize for that contributor's particular background and skills and channel them into aspects of the project that would benefit from those skills and passions. So along with that, another thing that I'm seeing that I think is really encouraging is the gradual, I think, inclusion of more I don't know a heterogeneous variety of open-source related activities in a project's reward mechanisms. The projects have a point system or a leaderboard. They're increasingly including more types of contribution activities in their formal recognition systems. So they're tracking. The top contributor to this X project this month is counting more than just lines of code contributed. It's other things.
Bryan Behrenshausen:So, including those things in their reward mechanisms show how they value those contributions but also incentivize for them, so welcome to your talk.
Felicity Brand:Yeah, I'm really interested in that as a non-code contributor. So I work in the content team of Type-O3 and I'm always recognized for content that we publish. I'll get a little shout out on those. I've also seen talk of projects trying to implement like a Kudo system or a point system to, as you say, recognize things that aren't necessarily an approved merge request into the code base. That does contribute to the overall health of the community and the project.
Felicity Brand:I've seen some really good contributor guidelines out there. One that comes to mind that I really enjoy is Symphony. What I really like about a particular page I'm thinking of in their guideline is they give examples for how to write in terms of the language they want people to use in their issue requests, in their merge requests. So I'm not talking about a template like a merge request template. I'm talking about if you're doing a review of a pool request. They give examples of the language to use when giving feedback and basically it's about respect. So they're trying to build a respectful community and contributor guidelines, you get bonus points. You can just say we want everyone to be respectful, but if you give examples for the language for people, to use.
Felicity Brand:It just goes so much further. So have you seen some good examples in your time?
Bryan Behrenshausen:I mean, I'm sure I have, but of course I can't think of anything off the top. My head is specific, I know. But I know exactly what you're talking about and I'll just say a general comment on that. I will say, first, I agree with you and I think it's great to bring that up. And second of all, I will say this is why I hesitate a little bit at folks who say, like all you need for a code of conduct is a statement that says be kind to each other or be excellent to one another.
Bryan Behrenshausen:I think that's a nice sentiment and I really do truly believe folks that put those things in their codes of conduct are coming from the right place. But I believe it's not enough. I mean, what does that look like? What does that feel like for our community? Likewise, where folks are saying things like we need to be more thoughtful about bringing in how we treat newcomers and how we engage, great, show me what that feels like. And it's the same way with remote working practices, which we may talk about at some point too, where folks are saying we need to be thoughtful with each other and hold each other accountable, they like to say, for following these practices.
Bryan Behrenshausen:But what does that sound like? Give me a sense of what that looks and sounds like so that I understand that I can bring something up, raise something, say something in a way that's almost kind of sanctioned by the community, so that I don't feel like I'm new and I'm sticking my nose in and I'm going to ruffle any feathers. It's okay to say that's not how we talk to each other here, right, and put that in your documentation, right? Or something like sanction your interjections. I guess you know what I mean. So I know I totally get what you're saying. I wish I had a great example of a project that did like you do, but there are plenty out there.
Felicity Brand:Yeah, I really you're such a professional, Bryan, because that was a great segue into talking about remote work, so I know.
Bryan Behrenshausen:Oh, great Sorry.
Felicity Brand:So GitLab are a remote first company, the true to say yes, and we are famously all remote, I should say.
Bryan Behrenshausen:And I can start to talk. It's hard to track these things, but we do believe we're the world's largest all remote organization, at around 2,000 people headcount.
Felicity Brand:Open strategy partners are also all remote. We do have headquarters in Cologne, germany, but let's talk about remote work. So over 2,000 employees. Does it work, and what sort of practices and processes do you have in place to help set you up for success?
Bryan Behrenshausen:Yeah.
Bryan Behrenshausen:So I think whether it works is a practical matter that's different for everyone.
Bryan Behrenshausen:I will say that our success as an organization like Lee speaks for itself and the success of our model, our operating model which we'll get to in a second, I'll talk about more in a second and we have a lot of practices that I think have set industry benchmarks in terms of remote work, our handbook being one of them, is probably one of the most famous or most easily observable artifacts of our culture, which is our, the GitLab handbook, which is notoriously open Open by default.
Bryan Behrenshausen:I can say that whether or not that works I don't know, but it works for me because I find working at GitLab is infinitely easier when that is the case, when the handbook is open, and I can say that it makes working with the GitLab community a lot easier. Infinitely easier as well, because when I need to explain why something is the case or due to a GitLab policy or procedure, I can simply link to it. If a community member says oh well, it's our policy and here's the policy, the same document that everybody at GitLab is using. So that's why we talk about GitLab team members and the wider GitLab community. We try to erode that distinction as possible. We also don't ignore the distinction Like yes, there are folks who are GitLab team members and there are folks that are part of the community. But we try to embrace all.
Bryan Behrenshausen:And also, I'll just say as an aside, the handbook made interviewing at GitLab so much easier and less stressful because I could read the entire interview process, even some potential interview questions, in the handbook. That included, by the way, accessing the salary calculator to begin getting a sense of what my salary range would be if GitLab made me an offer for a job. So that is open and transparent.
Bryan Behrenshausen:It gets labbed to as much as possible, to the greatest extent possible so again, these are some of the benefits that I've seen, not to say nothing of the day in and day out work a day benefits of working according to our operating model, which we call T-Maps.
Felicity Brand:Yeah, so give me a sense of your, as you say, your day to day, like what sort of tools are you using to interact with people and get on with it?
Bryan Behrenshausen:Yeah, so we are a GitLab-first organization. So the policy and the spirit is use GitLab first whenever possible. Even maybe when it's not quite possible, make it possible, because that's what pushes GitLab forward. So I'm on GitLab, I would say, 90% of my day. That's especially true working in the particular role that I have where I'm interacting with open source communities on GitLab. I just need to be on the platform. But one of the reasons I wanted to work at GitLab is just because I love the tool and I wanted to not only help make it better but use it more. So I certainly use it now and I love it. So most of my days is spent on GitLab. But of course, we have our tool chain, like everybody else. We have a messenger, we use Slack. But some interesting things about Slack is we have some policies around using private messages. I don't know where this is tracked, but I believe that administrators are able to see the percentage of messages that go to channels and messages that go to DMs and raise some warnings if there's too much private communication.
Felicity Brand:Right, so that's folding into your open ethos Approach. I imagine that, right. Yeah, channel communication channel by default.
Bryan Behrenshausen:Yeah, channel by default and EMS as a last resort, or private message as a last resort or if it's something sensitive. You know it's a people issue. Where there's a you know you have to share a private you know bit of information or something. Obviously you know there are always cases, but the more often than not you don't need to do that. Somebody could benefit from what you're saying and what you're doing if you posted in your team's channel, so the ideas you go there. We also delete our slack history after 90 days. So, yeah, things don't live in slack after 90 days and that's Deliberately disincentive eyes. Using slack as a source of truth for anything, yes, yes, I love that.
Felicity Brand:Yeah, what if you want to blow off steam or just have some leisure time?
Bryan Behrenshausen:I imagine you have channels for jokes and there's gif channels, there's an all caps channel, there's a. You know, I'm in Legos, I'm in the all caps, I'm in the yeah yeah, yeah.
Bryan Behrenshausen:That's, that's to go in, and just you know. And there are channels for different localities. Again, we're all remote, but get lab team members love getting together in person. So there are remote. There are location based channels where if something's going on in your, your town or your neighborhood or city or your region, you can post and talk in there and people meet up and post pictures in there of their work, co-working days and stuff. So All those channels exist as well.
Felicity Brand:Sure, absolutely do you have an onboarding process to teach new employees, the remote first?
Bryan Behrenshausen:approach. Yes, it's quite intimidating, to be honest. It's voluminous because it involves a lot of self directed work. It takes up the onboarding process at get lab. Takes about a month to complete. That's by recommendation, is about a month, takes about four weeks.
Bryan Behrenshausen:When you join get lab, your assigned an issue, that is your onboarding issue. That has several. I think it's now about a hundred and thirty seven thing.
Bryan Behrenshausen:Don't quote me on that because I spent a while since I looked at it, but when I lasted it it was over a hundred items that you must complete and those are everything from you know day one Lockdown your security stuff, make sure your info, sex stuff is is is tight. So you do that first, all the way up to hey, look, here's your tutorial on, if you're unfamiliar with it. Here's how to make, here's how to Make a get commit and here's how to do a merger quest on get lab right, which are survival skills right? So it takes about a month, it's several, you know it's over a hundred, more than a hundred items long and it's mostly self directed work because everything at get lab Is more than thoroughly documented and if it's not documented to get lab likely doesn't exist. So means you gotta be ready to do a lot of reading and a lot of asynchronous video tutorials and things like that during your first four weeks of work.
Felicity Brand:I'm asynchronous to.
Bryan Behrenshausen:I'm in Melbourne, australia, but most of my team are in the northern hemisphere, so the cobblers elf, as they say yeah, I think it's the perfect, which I think it's the perfect story, because I would say that that is also one of my very favorite benefits of working for a distributed organization in asynchronous way is that sort of Cross hemisphere, cross time zone, but on pass of the day, right, and just the idea that you know the work is like this 24 hour continuous stream and your work day is sort of where you choose to plug into that stream, ride it and then pull out at the end, like you jack into the matrix when you need to. Then you like do your and you pull out. You know it could be, it could be any, you know any, any moment in your day or whatever. But Working in an asynchronous way with a distributed team makes all kinds of things that weren't formally possible. Again, I understand it's not for everybody, but for me it just clicks with how I live and how I think and how I work. So yeah.
Bryan Behrenshausen:I cross the time zones that I can hand stuff off to and then likewise wake up and see all this cool stuff they've done and take the baton from them and push it along while they're spending time with their family and having dinner and go, you know, sleeping, and Go to the gym or whatever. That is a thrill for me to yeah, I totally hear what you're saying.
Felicity Brand:Just another aspect in which we are kindred spirits. So I want to ask you about Team ops, your distributed asynchronous operating model yeah yeah, I just wanted to add on to that.
Felicity Brand:I also feel that joy of being asynchronous, and when I started at open strategy partners, it took a little while for us to work out, but Once we realize we could use it to our advantage, my colleagues would write something. It would come into my queue. I'd wake up, I would review it, mark it up with feedback, send it back. That wake up. Oh, you know, it's just the next day and how. Now I can give it to the client. So that is as you say. It's. It's a. You get a thrill when you know that you are Adding value, like you're helping someone. Yes, move a piece along.
Bryan Behrenshausen:Kindred spirits, again. That is what that's. What motivates me to do my work is when I know I'm being of use to someone, or helpful to someone, or or in live in their work or enriching their work, and likewise when people do that for me. Right, that's why I like open source and that's why I like working in this highly collaborative, distributed way, right, yeah, for sure?
Felicity Brand:so tell us about team ops. What is that all about?
Bryan Behrenshausen:Yeah, so. So team ops is an organizational operating model that is really, I think, the crystal crystalization of Get labs way of working. The get lab way of working that we've sort of refined over the years are best practices. Working all remote are things that people often ask us about. They often ask our CEO about, they often ask lots of get lab employees about, and so they're documented.
Bryan Behrenshausen:But team ops is our way to sort of operationalize those things right to build to program ties them in a way that Makes them not only like graspable and noble and repeatable for other organizations, but also possible right that actually holds us accountable to say like no, really, what are you doing?
Bryan Behrenshausen:And like, if you had to explain this is somebody, how would you do it? And so it's our way of sharing best practices for working in a distributed way, high distributed way, asynchronous way with the world at get lab. Another hat that I hold is I'm a certified team ops trainer, so I train other get lab team members, new folks, on the kind of the tenants of team ops, and also we work with external customers as well who Again wanna bring team ops to their team or understand that the way that their team is working needs to change or maybe has been forced to change by events like I don't know, like a global pandemic or something like on fat mobile, like that, where the things like change radically and you have to Adapt your way of working. You know we have a tool set, you know, culture and value based tool set that helps your organization operationalize these sort of more abstract principles about the heart of this remote work model one of the downsides of being a sink is you can feel a bit lonely.
Felicity Brand:Well, I can. I'm lucky at certain times of the year. The time zones shift, you know, we have daylight savings, and so I do get some crossover in the early morning and in the evening, and so that is just a part of my job, that I'll take meetings after dinner. Yeah, I really enjoy getting face time. I just wanted to tell you about one thing that we have at OSP that helps us feel stay connected as a team. So we have a weekly team meeting that gets recorded and I watch it the next day because it happens at my 2am. After a while I realized well, every I get to see everyone, but people don't get to see me, and so what we do now is before the meeting in my daytime. I will join the meeting. It's a Google Meet and I can press record. I'll record a two-minute update and then, when the rest of the team join the meeting, they play my update, so everyone gets to see me.
Bryan Behrenshausen:That's great, yes, perfect.
Felicity Brand:And then when I view the meeting I see everyone in the team watching me. Yeah, it gets a bit better, but that has gone a long way to help us feel together and just getting that FaceTime is really beneficial.
Bryan Behrenshausen:Absolutely, absolutely. That's a lovely practice and makes you feel included and helps the rest of the team not only feel your presence as a team member, but also appreciate your contributions more because you're there talking about it and telling them about it.
Felicity Brand:That's right, that's right. So yeah, it is, but, as you say, it's not for everyone. Some people may really struggle. If they didn't have you can still be distributed. But if you're at least synchronous, that goes a long way to helping you feel connected.
Bryan Behrenshausen:So yeah, yeah, and I would say that things like operational models like team ops are optimized for asynchronous, but they don't preclude synchronous interactions.
Bryan Behrenshausen:In fact, what they do is they also optimize those synchronous opportunities as well.
Bryan Behrenshausen:So, for example, at GitLab, it's sort of taboo to have a meeting where you're reading out without any discussion for 40 minutes or even five minutes. Five minutes is probably the max, but the idea is, if you're going to have a meeting that and you're going to have it synchronously, you want the benefits that come with having a synchronous interactional possibilities. So if I'm going to read out slides for 45 minutes, I'll record that, send them before the meeting, everybody watch that and then I spend my 30 minutes with everybody, not going over it again, but having a discussion about that. I mean, because that's what that's the benefit of having everybody there right Is that they can get their feedback, not so they can sit and listen to me in a time zone of my choosing at a time of day of my choosing, so that I can get their feedback. So again, models like team ops don't preclude synchronous interactions, but they do optimize for them in ways that for some might feel like they're downplaying synchronous, but not really.
Felicity Brand:Yes, Well, everyone's time is important and we should all value each other's time. Let's talk about oh OK, We've got two topics I can't choose, so I was going to ask you about the GitLab Open Source Partners program and we should talk about that, but then I also do want to talk to you about the Open Organization Project.
Felicity Brand:So, Bryan, our paths crossed because the Open Source Project I'm involved with, The Good Docs Project, was recently invited to be a GitLab Open Source Partner. Can you tell us a bit more about that program and what it's all about?
Bryan Behrenshausen:Absolutely can. So I'll back up a little bit and just say that there are two programs that are relevant here that I manage at GitLab. They're related but they're distinct. The first is the GitLab for Open Source program. That's a program under which qualifying Open Source projects receive GitLab Ultimate Subscriptions. And I say qualifying because projects need to meet certain criteria to get that. They need to be publicly accessible and open to collaboration on GitLab. They need to carry an OSI-approved Open Source license where you follow the OSI, the Open Source initiatives definition of what constitutes an Open Source project, and they need to be not for profit. They need to be community-driven or foundation-backed projects in some way. And if projects meet these criteria then they can apply and will review their eligibility according to those criteria and if they qualify, we will send them a subscription for the year and they can renew again if they'd like. So that's our way of ensuring a healthy Open Source ecosystem on GitLab but also giving back to the Open Source community. That, of course, is the bedrock of our success as an open core product and an Open Source
Bryan Behrenshausen:motivated company. Now, the program you're asking after is related to that, but it's a little bit more exclusive the GitLab Open Source Partners Program. This consists of about, I'd say, 25 high-profile, large-scale Open Source communities that have set up shop on GitLab and are advancing the state of the Open Source art using GitLab. So partners you can think of as kind of like our marquee Open Source projects, these are the projects that represent what's possible for Open Source development at the cutting edge of GitLab and at Open Source in general. So examples of these include major Linux distributions. Partners include Debian, arch, fedora and major derivatives of those like Mandaro and Kali. Major desktop environments in the Linux desktop ecosystem are partners. Gnomes, kde, xfce are all partners, but not just computing projects like that, but also scientific projects like the sqa observatory, the square kilometer observatory, of scientific projects that are partners, and of course, the good docs project, which is a documentation focus project and we're not interested in just having, you know, your kind of open source stalwarts the Linux distributions and the desktop environments, but of course they are still and always functioning at the cutting edge of open source development but Trying to bring in partners with different aims and purposes in the open source ecosystems. So it's a partnership program in so far as there's a great deal of reciprocity inherent to it.
Bryan Behrenshausen:Partners receive certain benefits for being partners, like extended license you know, gratis subscription licenses, a private service desk where they can send issues that they might be having a special space on get lab where they can raise issues and open and then bug reports and issue feature. You know, requests that I can pass along to our team at get lab. Also opportunities to partner with us on some storytelling opportunities or presentations, things like that. So we hope that helps raise their profiles a bit and keeps them thriving. And in return, you know what we ask is that they help us shine a spotlight on their work by letting us interview them for our YouTube channel, maybe co writing tutorials with us or case studies with us About things they're doing with get lab. You know, again, they're pushing the boundaries of what's possible with get lab. So we learn from them. You know, not only via the feedback of the open source development cycle. You know we learn from them when they're developing on get lab and coming up against boundaries that then we can help help them overcome. But Others can learn from them and hopefully, hopefully emulate them. You know they can ask them what's it like to be a A large scale, successful open source project and community on this platform, and how can we emulate your success? You know, and again, partners we hope Can help each other by forming a partner community. Partners can help one another and learn from each other.
Bryan Behrenshausen:You know, managing a large scale open source project like a Linux distribution is difficult work, often thankless. So it's nice to have allies that can assist you or share their solutions or best practices or, again, even just commiserate. You know if they're having spam ish, spam woes or, you know, difficult code of conduct situations in their communities. Whatever it might be To have a community of partners in your space, in your sphere, for that kind of support is important too. So that's what the partners program is all about.
Bryan Behrenshausen:Of course, the good docs project was Recently invited and graciously accepted the invitation and it just been a pleasure to work with and a really great partner in helping demonstrate what's possible with get lab as a project management tool.
Bryan Behrenshausen:I mean the way that you all use get lab to manage your releases, and this is the article I'm working on now with members of your community is an explanation of how you just released your first major Set of documentation using the project management tools on get lab.
Bryan Behrenshausen:It's just astounding, I mean, you know again marquee project, shining example of what's possible with the platform, and so I could talk all day In you know, fifty blog posts about how great get lab is and why everybody should use it, and what the great, what the best features are, etc. Etc. But I'd much rather help the good docs project tell their story about how they were successful, because one people are more likely to listen to them than they are to me and to their story is much more real than anything I could invent for a blog post. I mean, here's a, here's a story of how you all actually did it right, and so that's what that's where I get joy out of running that program is helping, you know, raise the profile of folks that are using get lab and showing some real life examples of how folks have been successful using the tools.
Felicity Brand:Yes, and it certainly has incentivized us to start to push the boundaries of how we can use the platform and even conversations we've had internally, you know, we might normally do this a certain way and then we think, well, hang on, we should actually be using get lab for this. So let's, you know, let's try and work this out using this tool and then if we run into problems, we know that we can speak with people, you know, raise an issue, whatever and work with you to see. If you know we want to do this, can we do that? That's the interesting part. We don't. We don't have all day to talk. Let's, let's wrap up. We do have some standard questions, Bryan.
Bryan Behrenshausen:Okay, oh, yes, okay, this is the Okay all right, I'm ready, I'm ready, I'm ready for your, I'm ready for the rapid fire. Yeah, what's one kind of communication you wish you could do better. Oh, visual communication. For sure I can't draw my own breath. I've always wished that I was better at depicting things visually. It's just, I've never had that skill.
Felicity Brand:That is a good one. Have you seen X Cali draw? No, yeah, I'll send. I'll show you the link. It's a browser based graphics tool. It's quite easy to use and sometimes it can make what you draw look amazing. So Fantastic.
Bryan Behrenshausen:Yeah, I often think that I can. I'm thinking that way, especially mapping ideas and showing relationships between things, but it's just difficult. It's always been difficult for me to translate that stuff into A visual medium. You know, I see what people do with charts and infographics and All sorts of things like that. I just I'm very envious, yeah.
Felicity Brand:Who is a communicator who inspires you?
Bryan Behrenshausen:Oh, I would say Isaac Asimov is my favorite writer. He was not only a prolific writer wrote something like 500 books in his life or something like that but he's just a master explainer who writes in, especially in his nonfiction work on science. Science writing Writes with this kind of clarity and concision that I will always envy.
Felicity Brand:Wow, you've inspired me. I'll just go to the library and grab one of these books. You won't have trouble finding him.
Bryan Behrenshausen:I think he's the only author that has one book in every section of the Dewey Decimal System.
Felicity Brand:Go to any spot in the library. Yep Wow, that is a claim to fame.
Bryan Behrenshausen:I will look that up, though, to be sure, but I'm pretty sure that's correct, still correct, yeah. We'll get our fact check it yeah right, right with your busy staff and your busy time, that you know you're all the extra time you have, sure, yeah.
Felicity Brand:What is one thing you wish you knew about open source when you were getting started?
Bryan Behrenshausen:I think that people are more willing to help than I initially realized. Right at first I was very timid about asking for help and reaching out to community members on various channels, even just to say thank you, because I sort of felt like an imposter. I sort of felt like I wasn't sure if I was doing it right or if that would be welcome or if I had the chops to do this or that or say this or that. But I think what I would tell myself I could go back now was, hey, people are more willing to help and listen. Then then you realize, so just speak up.
Felicity Brand:Yeah, I would agree with that. Something I've noticed and I should like to get your take on this don't ask for someone to tell you what to do. We get a lot of kind of newcomers who come in and say I'm here, I'm interested. Now what, what should? I do and I'm thinking well, I mean, there's a list of issues. Tell me which one excites you, you know.
Bryan Behrenshausen:Yeah, yeah, yeah, I see that as well and I think it cuts both ways. It definitely cuts both ways because I think I've seen that and it's it's very empowering to invite someone in and allow them to do what they want to do right off the bat. I also think it can be intimidating for newcomers.
Felicity Brand:Especially if they're coming from a traditional management structure.
Bryan Behrenshausen:That's right, that's right, yep, yep. And it can be intimidating. They come in and they say I want to, I want to help you by writing something Okay, great, here you go, here's a blank sheet of paper, right, whatever you want. And sometimes you know you're doing them a favor by not over optimizing their experience, but by giving them some scaffolding, whether it's in the form of you know, good first time, you know.
Bryan Behrenshausen:Label good, good, first time you know contribute your label on your issues, or having them contribute to something like a template for their first contribution. So they're reading the template and improving it and then improving the first time experience for others, you know, giving them something a little bit more concrete. Now, if somebody wants to leapfrog over that and has a clear way to make a contribution, sure you welcome that. But you know also, you know as a, as a maintainer and a community manager, being aware that you know sometimes people want to help and they don't mind having their hand held because that's how they're going to learn, yes, to get involved, right.
Felicity Brand:so yeah, yeah, indeed. Now you work remote, as do I. I think you've even recently relocated. So what is an important piece of a concrete, what is an important piece of equipment you need for your home office?
Bryan Behrenshausen:Oh man, well, that was that. That's probably it. I guess I would go by the order in which I set things up in my office, right? So one of the first things I set up was you can see behind me, my, my, my, probably my most important piece of equipment is my vintage a chi cassette deck where I play my collection of about 400 cassette tapes, because that's what I need to do my work. But if the, if the music's not going, my brain's not going. So you know, if I'm here and I'm working, something's coming out of those, those speakers. So without any music, I think my days would feel a lot longer, and I think that if I had to pick one piece of equipment that I couldn't do without working remotely, it'd be my stereo.
Felicity Brand:Yeah, Wow, that is fantastic. You know, I would imagine most people just have Spotify running through the computer. But you are old school and I have music subscription services.
Bryan Behrenshausen:I listen to a lot of digital music, but I like to buy my own music and maintain a collection instead of renting music, which you know I understand works for some people. It's just not my style.
Felicity Brand:This has been a fantastic conversation, Bryan. Is there anything else that we that you wanted to cover today have we have. We done it all.
Bryan Behrenshausen:Oh well, I think. Well, now I understand. We could probably talk for hours, felicity, but let's just leave it at. I'll come back anytime, you'll have me.
Felicity Brand:Yeah, well, we'll have you back. I'd love to hear more about the open organization project. So yeah, let's try and tee that up. So I guess nothing else remains but for me to say thank you very much. I've thoroughly enjoyed our conversation. I'll see you around. Open Source.
Bryan Behrenshausen:You bet I hope our paths cross again. Thanks so much for the interview and thanks so much for having me on your great show.
Carl Richards:We hope you enjoyed listening to Felicity's Conversation with Bryan. If you have questions, head on over to the show notes, where you'll find all of Bryan's information, and feel free to reach out to us as well via Twitter at openunderscorestrategy, or email hello at openstrategypartnerscom. This was one of the editorial codes we use at OSP. We'll be sharing more of them as we go. If you'd like to learn more in the meantime, come over to openstrategypartnerscom, have a look at our writer enablement, workshops, case study offering or get in touch to talk about your strategy or product communication needs. Thanks to everyone who contributed to this podcast all the P's at OSP. Thanks to our clients who believe in us. Shout out to Patrick Gaumont for our high energy maple syrup flavored theme music and to Mike Snow for additional horn arrangements. Thank you for listening and subscribing, and our three themes on the podcast. You'll hear from different members of the OSP team hosting episodes over time.
Carl Richards:Communicate all things communication we share how we tackle writing, editing, word choices, formats, processes and more. Connect in depth conversations with interesting, smart people about who they are, what they do and how they approach their life and work as communicators, technologists and leaders. Grow. We cover strategic approaches to understanding and expressing the value of what you do, including tools, templates and practical applications. We also feel strongly about building a mindful, positive, human first culture at work. That's bound to pop up from time to time, too. This podcast is us figuring out communication, connection and growing together. Subscribe now on YouTube, apple Podcast or the podcast channel of your choice. Follow us, suggest guests and topics, ask us questions. On social media, we are at Open Underscore Strategy on Twitter. Until next time. Thanks for listening to Communicate, connect, grow. See you next time.
Felicity Brand:I'm going to go off script. Okay, I just thought of something that I wanted to talk about.
Bryan Behrenshausen:Do I need to do the interstitial for you Like, don't you like it? Are you going to change that, isn't that? You get your little. You can splice that in if you want. Do a clean take and then you switch topics.
Felicity Brand:Yeah, no, I don't think I can. I'm not that smooth, Bryan, I'm not that smooth.