Open Communities With Andrew Zigler

Speaker A: You know, being default open doesn't mean you have to sacrifice standards or sacrifice productivity or what you're aiming for as a company. It just means that you have to do the work to align people to it.

Speaker B: It's time for Arrested DevOps, the podcast that helps you achieve understanding, develop good practices and operate your team and organization for maximum DevOps awesomeness. I'm Matty Stratton. I am really excited to kick into today's show. Longtime, uh, listeners are probably like, Matty, you're always excited. Has there ever been an episode where I say this episode is mid? Actually, maybe this episode will be mid. We'll see what happens. But before we get into the meat of the episode, if you will the Chewy center, let's hear a word from our sponsors. Is your database the bottleneck for page load times? Is your AWS database bill skyrocketing? Are you tired of spending hours chasing down and optimizing slow queries? Solve these problems in the click of a button with ReadySet Cloud. ReadySet Cloud is a database scalability platform that uses transparent event driven caches to boost the performance and uptime of your database while driving down costs. It's wire compatible with Postgres and MySQL so it works out of the box with all of your favorite database tools and ORMS. ReadySet Cloud is available as a fully managed cloud offering and is open source. Try it out today@arrestadevops.com ReadySet let's face it, no one likes writing or maintaining documentation. But when you start a technical project or pick up a new task, missing information can cost you valuable time. Gitbook is a technical knowledge platform that fills that information gap, making it easy for your team to capture, maintain, and find information from a single source of truth. For example, with Git Sync, you can set up a two way sync between your repository and Gitbook so you can turn markdown files into awesome user friendly docs. And if you make a change in your code base, the edits sync between the two automatically. Or what about when you need to find something in that knowledge base? Forget about searching, just ask Gitbook AI. You'll get a neat summarized answer that is sourced directly from your docs. These are a few examples of what Gitbook can do, so why not give it a try? Head to areestadevops.com gitbook to find out more. So Eufizi is a platform for platform teams. You can stand up your developer platform in minutes, not months. What I like about Eufizi is that it gives platform teams control and dev teams autonomy. It's kubernetes native and extensible, so you can customize it with tooling that meets your team's evolving requirements. And these clusters, they spin up fast. Like super fast out of the box. Eufizi combines a great dev experience, secure, multi tenancy and cost efficiency. But try it out for yourself@, uh, eufizi.com, download their CLI and you can spin up your first sandbox cluster in under a minute on their free starter tier. That's ufizi.com U F F I Z Z I.com I am going to tell you right now, I don't know what we're going to talk about in this episode, which are some of the fun ones. You as a listener have an advantage because you will be able to see the title of this episode. So you're ahead of us. But I am joined by my friend Andrew here and we're going to figure out something devopsy to talk about. We got a couple ideas, but before we get into that, Andrew, why don't you introduce yourself to the ADO audience. Hello.

Speaker A: Hello, my name is Andrew. I'm the developer advocate at Mattermost and I work in open source. I'm really excited to talk about DevOps. DevOps is a huge, uh, part of the Mattermost platform, but really just excited to kick it here with Matti, my good friend, and talk through some great topics today as we explore the big scary DevOps jungle and figure out what we'd like to talk about.

Speaker B: I think one of the things that might be cool to jump into a little bit, you talked about Mattermost being open source and open source in general is a big, juicy topic and we ain't got time to dig into all of it. But when we think about products and communities especially we work in the community side of the and when we're talking about having a developer community that is open first. And I think about historically, when I was at PagerDuty, I was like, man, Devrel is hard when it's a closed source thing. And then you're like, well, you know what, it's also hard when everything's really open, right? You know, so the point is it's hard, but not so much even thinking about like the trials and tribulations of your neighborhood developer advocate. There's other podcasts for that, like Community Pulse and such, but just thinking about all the different ways that we're part of a developer community, whether it's we're helping run that community, we're participating. What are some of the things about that? Right, because everyone says we want a really open community, we want all this stuff. But then when uh, the rubber hits the road, when we're actually doing it, it turns out it's not so easy. What's the myth of the Open first developer community?

Speaker A: A big part of it is uh, getting over the echo chamber feeling when you're working Default Open and you're putting everything out there and you're trying to gather feedback or you know, really just kind of share things that you would regularly just put in channels or close communications out in the, out in the wild where people can see it, appreciate it, have feedback or whatnot. A lot of times you end up in kind of an echo chamber where maybe you get the same folks participating or maybe you really don't get anybody and you're just kind of on a particular topic, kind of just talking into the uh, Internet. And so that can kind of be its own challenge too. Of, you know, is my message landing? Does this make sense to people? Are people getting engaged? Are they passively reading it? And I just can't tell that there's lots of people that are actually engaging with this. So there's lots of levels of, you know, measurement. And if you're going into a uh, default Open, open source kind of community from, from our side, from the Devrel side and expecting everything to be just like this big celebratory thing and everything you post is just like, you know, goes viral within your little mini community. That's not really how it works because you have to work for a while to build that trust and you have to get people on the same page and then at the same time you're, you're, you're working. You know, every company is constantly internally trying to get on the same page. So oftentimes Devrel ends up being this counterbalancing force between what the community perceives about the company or the project and then the actual inter, the inner workings of the project and what they're the draw, what they're pushing the cart towards, you know. So definitely the biggest challenge I think is getting over that echo chamber feeling really, really feeling solid about what you're saying. Not always just talking to try to get validation, but offering resources and, and also listening. Uh, the biggest part with Default Open is if you're going to be posting things out there for people to have feedback on, you need to listen to that feedback and incorporate it because if you don't, you lose their trust.

Speaker B: And I was going to say, I think it's very laudable to say, hey, we want to. Our main product, if you will, or project, whatever the thing. The reason our company exists is fully open source. We do everything in the open. And you can. But, uh, you alluded to like the echo chamber. I think there's also like a gravity around, uh, the company. Right. So if I think about, and I will, to be very clear, I've worked for several different places that are open source first and everything. And all of these are supposed to be very positive of what I'm saying. And this is not like me sitting and saying like, these people did it bad because these are the challenges and I might get some of the detail slightly wrong, but deal with it, right? It'll be fine. But I think about like at, uh, say it was like something like Pulumi or Chef, where I was. Where we're like, hey, our product, our thing is open source. And we absolutely. And I think Chef always did a really great job of saying, like, we really run this, like a big community project. And we just happen to have a bunch of people that their main job is working on. Chef. But that's the key. Their main job is working on that. So number one, you can have, let's say we have whatever made up, you know, squid cast, whatever kind of bullshit thing that we came up as our open source project. Now we have a company around it. You and me, Zig. Well, okay, we are sitting and we spend all our time doing this. But then a lot of people working in open source are doing it. They don't have the luxury of either working for the actual company or even working at an OSPO in another company where their job is to sit and contribute to open source. Some people have that job. It's great. There should be more of that. But there's also plenty of people that are like, I just do it some. I do it in addition. And it's hard to have like to be of an equal. You don't really have an equal seat at that table. Right. Because you're not able to. Because the same thing. If it's my main job, then you better believe I'm going to every single roadmap. All these open meetings, I can go to them all. But maybe I'm like, I can only look at this project every now and again. And so I'm either a behind my voice isn't as loud and maybe I get caught. And this is hard. That's why you end up with these things where the main company always, no matter how much you try inherently, I think has more gravity just by virtue of the people. Right.

Speaker A: You just have more being the ones focused on it all day long. I think that's totally the phenomenon that happens a lot of times in an open source project is uh, of course, you know, it's open source, it's default open, everyone can contribute to it. But the loudest and most contributory voices are going to be the, obviously your staff that are paid to be there and that are there driving the vehicle. And really it's about I think having like gradients of engagement. You know, ooh, there's a term for you like of ways for people to kind of dive in and, and still feel like they have a piece of ownership about what they're doing, um, or what they're contributing to. Obviously, uh, it's, it's unlikely, it's, it's unrealistic to expect to have an open source, purely open source contributor who's contributing on the same level as your paid internal staff. Um, but that said, you can still set up really great kind of like pathways for them in the community, uh, to validate their experience, to reward them. Um, a lot of times this reward can be something as, you know, we all talk about like the swag and stuff like that and some people are really big on that. But sometimes the reward is just thought leadership, sharing this, the stage, giving them a platform. Sometimes it's about making them feel heard as well. And so, you know, I think that you make a really good point in that there's like different levels of engagement and you have to learn how to talk to all of those levels of engagement. And if you don't then those people that, who are on the periphery and they don't know how to get into the mix, they never do because they don't see other open source contributors like them that are, that are getting celebrated and uplifted or perhaps they're only seeing a small select audience of people that are, that do a very specific thing and they don't know how to, how to build their own little specific thing. So it's also about training and teaching people how to contribute where they're at and with what they want to do.

Speaker B: You know, almost all these things happen unintentionally. The negatives, the hard things. Right. They don't really necessarily come out of this like, hey, we want to just say we're open, but really we control everything or whatever. I mean there's a little bit of that.

Speaker A: No one plans for it to go bad.

Speaker B: And I Think about a couple things where things that seem like good ideas that maybe have unintended consequences where within a project, identifying people who work for the company within their thing. Right? Because that kind of is like, uh, an inherent, you know, even a little bit of flair on your discord or whatever. It's like, wait a minute, there's a whole company mindset that has to happen too. And this is. This is one that again, I'm going to do a compare contrast with Chef and Pulumi just from two places.

Speaker A: I was.

Speaker B: They were in a similar situation and why one thing worked a little bit better than the other. I used to say, I work at Chef because I believe in Chef, not the other way around. It was like I was a member of the Chef community that then got to go work. There's. But I was always a member of the Chef community. I used to tell when I was in sales Eng and I would tell customers because I would work with them in pre sales and then they would. Once they were customers, I didn't work with them anymore. And they'd be like, oh, that's a bummer. I said, hey, we're all part of the Chef community together. Even though I'm not your account person, we're all part of the community. And that worked really well at Chef. That's why you would have it at Chef Community Summit. You'd have a lot of people there that worked at Chef, but a lot of community members. But everybody really was sitting on an equal footing at that point. Then if I look at Pulumi, at least when I was there, it was really hard to get a lot of people to understand that people who worked at Pulumi were also part of the Pulumi community. I don't think it was because again, of anything malicious or anything. But a good example was we said, okay, we're going to do a community summit. We said we wanted to do a, uh, community event for the Pulumi community. And it was really hard to get Pulumi M employees to participate in it because they're like, yeah, but I have my work to do. And like, yeah, but you're part of the community. Like, you need to come and be part of this the same way as people who don't work here. And we're all part of this thing. And like, some folks got it and it's. It's hard.

Speaker A: It's so hard. You're sitting here describing this, I'm like, wait, this happens in other places. Like, you know, exact. Exactly. I think, I think this is a ubiquitous experience. And open source, like absolutely what you're describing, you uh, gotta, you gotta bring the people in that are, that are paid to be there to really pull up the people who are trying to volunteer to be there.

Speaker B: And it's not a reflection on the individual contributors. This is definitely a thing that leads leadership has to reinforce, right? And to say like no, you know what? We allocate for this we assume because that was the thing when we said we wanted to do this. Most of the engineers and stuff were not like oh, community, I hate that. But they're just like I have other stuff I have to do. Like I can't take a day to be part of this event and this, this thing or part of these groups because I've got deliverables, I have a bunch of, you know, all these things. So it needs to be uh, throughout the DNA of the organization, you know. And it can be really powerful and not just for your contributor, not just your engineers, but if you have your sales, you know, as long as they can know how to switch their hat. Because engaging with that community and being part of it is actually what makes you really effective. But that context switching is very hard and I think if you don't, the more that like uh, again, how many, how many places have you thought of or know about that again are open? But it's like all of the builds all go through an internal system. It's like cool, we'll take your pull request. But all the build is because again doing stuff really in the open is a lot harder because you can't control things as much. If we can say we use this Jenkins server configured this way and I know what our developer machines look like and all this, then you get great efficiencies. And when you want to say we do it all in the open man, you have to cover all kinds of weird edges, you know.

Speaker A: Absolutely. And in fact you hit on a great point of giving them the tools, right. To meet you where you're at. If you have a dev work environment that all your staff are using, maybe find a way to share it. Right. You could use a cloud workspaces to kind of more democratize the access to how people build your software in the way that you want it to. You know, being default open doesn't mean you have to sacrifice standards or sacrifice productivity or what you're aiming for as a company. It just means that you have to do the work to align people to it. And I will say, you know, at mattermost I'm really Grateful that that open source ness is really firm in our DNA and engineers and staff, everyone across the board really understands the importance of the open source community and wants to help them. It's just that like you said, balancing that with actual deliverables and things you have to do to succeed at your job is difficult. And so, um, you have to kind of understand where they're coming from, the staff at least, and provide reasons for them to engage and also, like you're saying, from a leadership level, create that environment for them to do so. Because, you know, leadership has to also instill in its staff that, you know, open source is important. If it means taking a pause on something that we're pushing ahead on to do an open source movement or plan or something that we're talking about, then that's what we need to do. Because those are limited touch points, points that the community gets. And all of the stuff that you're doing, you know, happens 365. So it's about balancing those priorities and you know, it being really deep in that company DNA like you said.

Speaker B: I think another thing that can be really challenging again, if you're trying to run this all very open, having an open roadmap, what you're going to run into is you have your product folks, right? And they're, yes, they're doing in the open, but especially as your company grows up a little bit more, maybe wants to get into some of that, you know, fatter enterprise money and stuff like that. There are priorities that have to do with customers that you can't talk about necessarily or whatever. And so you can say, hey, we need this feature done because the fruit stand wants it. Well, you can't put that in something open because nobody's allowed to say that that company uses anybody.

Speaker A: Right, exactly.

Speaker B: Or look at it this way, like what takes a lot of trust, I think almost no company would allow this to happen, is that the company who's the steward of the project gets the same say as anybody else because they're like, wait a minute, I'm trying to make money here. So the community might say we don't need that, we deprioritize this feature. But they're like, but that feature is worth a million dollars to IBM as a customer. So we need to do it. It's a weird balance, right?

Speaker A: Yeah, totally. And it's also maybe in that regard, uh, if there's a feature that's really important to your enterprise audience, or rather a particular enterprise customer, or if it's going to be part of your enterprise offering, then that sounds like something that is, should, that doesn't need to get worked on maybe in a closed capacity, especially if you're worried about that capacity. You, um, know, being default open doesn't mean that everything has to be open. It just means that you have to default to being open. But you can ask the question at the very beginning, does this need to be open? No. Then it's not open. And I think it's perfectly fine for, you know, a default open or an open source project or a company or community to have those things that aren't open. I think that any kind of successful uh, organization at scale has things that happen behind closed doors. But it's also about, uh, communicating that really clearly that way you don't lose trust and that when if you're going to have a project that uh, open source people are contributing to and it's part of an enterprise motion, then it's like you need to be kind of sharing or explaining that. And also too, it kind of goes without saying that if your open source community, community is building really successful features for your product that is accepted, loved and celebrated by enterprise, that makes you sticky there. Then the reciprocation of what you get from that enterprise should also trickle down into the community because the community got you there. And so you should, you know, you should prop them up and maybe use some of that to do some meetups or some uh, lightning talks or you know, send out some swag or, you know, whatever the case may be. That's how you build that trust, I would say by sharing the spoils.

Speaker B: How do you open source your advocacy? Because I think that's actually the thing at the core of doing Devrel at any kind of scale is you can't just have the people that work there doing it. Right. You know, I mean, first of all, you can't just have the people whose title is Developer Advocate doing the advocacy. It just doesn't work. You know, it needs to scale within your company. And we all want to build our advocates and basically be force multipliers to create this flywheel that gets everybody in the community doing it.

Speaker A: Yes, the Devrel flywheel.

Speaker B: Yeah. So I wonder because, uh, there's sort of different microcosms of this problem and they just continue to get bigger. So bear with me as I go through this thing. I had a friend of mine a while ago, we were having dinner and he's an engineering manager and he said, how do engineering blogs work? I said, well, I have a question. I was like, are you talking about technically, like tactically, how would you make an engineering blog exist? Or he was like, well, a little bit of both. I'm like, okay, well, whatever we can talk about. Yeah, because then you get into things like engineers don't want to use WordPress, they want to do markdown and blah, blah, blah. And how do you connect that to your blog? That's a whole other thing. But then I said, the problem that you run into with an engineering blog, as in the blog is written by your engineers, not your marketing, not, uh, your people whose job it is to write things is, uh, they do it when they can. Which is why you will have a blog that has no posts for three months and then 12 in a day. Right. And the reason is because if it's not your main job, you do it when you can and if you don't have deliverables or measurement against it. And so you have the same problem when you're. Because we're trying as a business, you know, we have strategy around how our advocacy works and all of this stuff. And we can't call on our community members to be like, well, we need to make sure that we're having stuff, that they kind of do it when they can. We can do everything we can to enable them. But. So I'm interested to know, in your experience, what are some of the ways to build up that open advocacy, that enablement, but then still be able to have. Because it's kind of hard. You can't really go back to your boss and be like, well, why didn't we get any blah, blah. Well, nobody in the community gave any talks this month and be like, well, what are you going to do about that?

Speaker A: Well, first off, the whole conundrum, uh, of the engineering blog and is it their full job? Is it not their job? You recited it so well. It's scary as to how relatable that story is. And it's something that I love. An engineering blog run by engineers. I think it creates really fascinating thought content. It just doesn't do it at a, uh, pace that. And in some cases it might leave something to be wanting in terms of tying back to an overall company strategy, because that's what a marketing professional would be doing. But that's it. I think there's an opportunity for teamwork between those two teams. And I also think it's really important to give engineers that platform to share their ideas to, to go out there and, and to kind of be a part of something bigger, to do a thought leadership piece or to Just talk about a cool internal code project they've been working on because you know your open source community, they love that kind of stuff. They want to be down in the weeds. They, they don't really want to read the marketing content about like the high level solutions and feature stuff from the executives of the company. They want to like hear from the react developer how they are like adding this cool new like design library or you know, wherever the case may be. And so scaling open, you know, devrel and doing it default open and open source is something that's really important to me and it has a lot of challenges. Uh, number one is being the multiplier effect you will, that you mentioned is, is huge. Uh, the biggest thing that you can do as a developer advocate is to create more developer advocates, create other people who maybe don't necessarily have that, that title that you do, but they still are invested in what you're doing and they have opportunities to engage themselves. And you're right that, you know, sometimes in that, in that kind of setting there's, there's some months that are, you know, really slow. There's not much going on. It's like how do you, how do you fix that? Uh, how do you be responsible for that, how do you kind of rectify that? But then there's other months where it's like a whole bunch is happening all at once. And I think that kind of goes to just the nature of open source communities in general. They tend to be very seasonal and based upon when people have free time to engage in stuff like that. It's, it's very, very rare that you get a year round, really steady contributor. A lot of times someone will pop up for very specific windows of time and you see them during that window of time and you know, community management tools help you identify those windows and who those people are and help you take advantage of the times of the year when maybe you have the most eyes on yourself. So it's about being strategic, about, you know, the waves of the community as they ebb and flow. You can't control the waves, but you can control what the waves do when they wash up on the shore and what's there for them. And so definitely, I think in terms of being default open. As a developer advocate, that means sharing your strategy, it means sharing your plans, but it also means retrospecting on the things that you do if you make a really cool developer demo or project, or if you go to a really impactful conference, or if you attend a really interesting talk, or if you go on a really wild podcast called Arrested DevOps, then you should write about it or you should tell other people and you should share that experience and get them excited. And then when they say, oh, I want to do that too, or I want to, you know, that sounds really interesting. Then when you go out there and you find that next thing that you're doing along those same lines, you can share it with that same audience and you can get them engaged. Maybe they come with you, maybe they, maybe they want to do something similar along their own lines. I've actually been fortunate enough in my own company just because, in my own open source community because I give, you know, a, uh, few talks and, and I, and I make, and I make content that people engage with pretty publicly, uh, representing the community and the project that when there are folks in our contributor community who want to maybe go to a meetup or to a conference or whatever and they're talking about something they're passionate and something they're working on, their contributions to the open source and mattermost as a part of that story, what's great is when they ask like for feedback. That's happened for me before, like, oh, would you look at my presentation? Oh, like, what do you think of this? And, and that's amazing because that means one, that you've earned their trust and that your opinion matters to them. But two, it means that your advocacy is working because you've now created another advocate. You're, this is somebody who wants to go to an audience that you don't have any awareness of, that you didn't have any opportunity to influence. And now here you are being able to kind of help them convey the message of you and what you're doing and what they're doing. You're helping them find the words to explain their contributions to open source because you have the big old book with all of the terms and all of the wonderful connections and the dots and we and Devrel sit up on this wonderful huge high perch where we can see a ton of stuff in the community, but they're way down there in the valley and they need you to help guide them to the right message, to the highest impact because those opportunities are limited. And so yeah, I definitely think being default open sharing your strategy, I, uh, want to give like a shout out for example to GitLab. I think the GitLab, um, Devrel community community does an amazing job at this, maybe one of the best jobs because GitLab, as you know, is a default open community. Um, and you can go right onto their GitLab and you can see all of their epics and their milestones and their planning around Devrel events and where they're going to. And after they go there, they do a retro, they make little slides of. Here are the pictures, here are the talks, here are the contributors, here are the things we did and you really get a sense of the impact of that's measured. But more importantly, if I'm a contributor for GitLab, I can go on that roadmap and say, oh cool, look, they're going to Brussels. I live in Brussels, I can just go meet up with them there uh, in three months and that'd be great. Let me hop onto this issue and let them know that I'm interested. Hey, it's Me, open source contributor 84 coming to tell you that I love you in Brussels. Like, you know, like doing that and making it easy for them is key because if you kind of just planet in the background a lot of times this is something that defaults to being closed because we're talking money, we're talking sponsorships, we're talking collateral, we're talking developer demos for maybe cutting edge stuff that you haven't even really released or talked about yet in an extensive way or that doesn't have a community touch point. So all those conversations, they happen on, you know, they happen on Slack, they happen on Discord, they happen on Asana, they don't happen where the community can see them, so they're invisible. So fixing that invisibility is really, really important for having an impactful dev rel in my opinion.

Speaker B: That's a really interesting idea. And again I think a lot of times we default because also the tools that we have and the way that we do that, like you said, sometimes because it's connected to money and we can't really have it out there be like here's all the places we're thinking about going. Because then the conference is like oh cool, we can get some money from Zig. And you're like well you didn't say that. But one of the things too, when we think about that empowerment of and that when you kind of think about first and third order levers that we can pull to help boost our members of our community and force multiply them or even sometimes it's just a signal boost and occasionally, more than occasionally within an organization, we over engineer things. Right? So a contributor program, like a writing contributor program in your organization is oh my dear Lord, so much work. It's like everybody thinks it's Going to be this great idea to be like, we'll do this. And you are signing up for like, I not going to name names of some companies that I've talked because we thought about doing one at Pulumi and then I connected to a couple folks that I knew at a couple big orgs who did one and almost all of them said, okay, I've been doing this and I wish we didn't because what you're taking on by opening that fire hose and now you have to, you know, all the things we already have to deal with in content production within our company now times a thousand. But you don't have to do that in order to like have members of your community contributing to the things that you do. It doesn't have to be a full fledged big program that anybody contributes to and you earn a status and we give you swag. Like, it can just be a matter of, hey, I see this person wrote a blog post about our stuff. That's cool. The minimum we can do is just like signal, boost it a little bit, right? You know, and says, hey, cool, we saw this, we can do something. Maybe we invite them to collaborate. Right? You know, because also sometimes you, uh, you know, it's the same idea that happens internally. My solution to the engineering blog is you have your people whose job it is to create the content regularly. They can work with those subject matter experts and do that. But we do that in our bigger community as well. And then now I will tell you this as people listening to this, as those community members, please, please, please, please, if you have a blog, have there be a way to get ahold of you on that blog. Because I cannot tell you how many times because I did this with Pulumi, we would say, cool. We would see people in the community write awesome blog posts and we wanted to syndicate them onto our blog with all the proper canonical tag. They get all the juice, all that good stuff. And I don't even know how to get ahold of you because it's on your medium and you have no contact. So I don't even know how to find you to say, would you want to do this? And also what's interesting is that occasionally you run into the person that's like, I wrote that blog two years ago. I don't even use the thing anymore. You're like, cool, but still, it's a good blog.

Speaker A: Still a good blog.

Speaker B: Yeah, put it on the website. But, but you know, people do make awesome stuff. And again, you never know. I can tell you back in My personal blogging days, there were things I would write that were just random, throwaway, whatever. To this day, most of my traffic to my personal website is this blog post I wrote over a decade ago about configuring SharePoint in a one way trust situation. And the only reason I wrote the blog post was it was a problem I had and I actually wrote it to document it for the rest of my team. I was like, I just. Because we internally did not have a wiki or a convo, anything like that. So I'm like, okay, I needed to write this down. I just put on my own personal blog and then sent it to my team. Like, here's how you do it. And then it, I mean, I get hundreds. Uh, it's actually upsetting to me that I still get traffic to this because I'm like, who is having this problem still? That is. I am sad for you that SharePoint 2010 is still part of your life. But it was like an upvoted answer on MSDN for a while. And all this. I'm like, also, again, I'm like, this is not what I want to be known for, for.

Speaker A: Right, right. That's your legacy now.

Speaker B: Have you ever had the one when you find it, you're googling for an answer and you find you wrote the answer years ago.

Speaker A: Oh, that has not happened to me yet.

Speaker B: Uh, oh yeah, I forgot when I had that problem.

Speaker A: Sometimes I'll go try to look up something related to what I'm talking about and then Google throws one of my sources back at me.

Speaker B: You're like, that doesn't help me.

Speaker A: That doesn't help me. Oh, uh, man. But man, what you're saying about the community writing program. So true. We, we used to run a community writing program at Mattermost. It's a lot of work. It's really rewarding, uh, for you and the contributors. Uh, if you get a really good momentum, you establish really good, uh, boundaries about what you're looking for and it aligns with the strategy and that takes a lot of time. It's also a huge opportunity for contributors, especially from places where they don't have great access to tech hubs or they're in emerging tech hubs. Community writing programs and technical writing programs are amazing ways for them to elevate their expertise for them to get their foot in the door. And so it's a really rewarding and uplifting experience for the community. But it's very draining for the staff to maintain and to keep going. And that vehicle is very hard to Keep related back to the company message, the company story. So sometimes it ends up almost being like a side project that doesn't very closely or well relate back to maybe the original goals you set up for. Um, and so that of kind, it creates a lot of balance, you know, it's definitely a huge challenge. Um, and I also think that, you know, what you're saying about people making content and sharing it and kind of just being like, oh, whatever, and it's like it's something that's out there. You can't even get a hold of them. Like they probably didn't even give it that much of a second thought. Is something that I've noticed is in open source communities, the community members get sometimes in their head they get a feeling that like there's a whole bunch of people that are making a whole bunch of stuff that's way more interesting than anything they'll ever do. And, and so like, they don't really want to share, they don't really want to talk about, they don't really want to put it out there because they just assume, oh, the company's not even going to see that, or, oh, the project won't even notice that or whatever. But then here's us on the other side of it and the second anything comes across the line, you know, from the community about something they've made or they're proud of, we're right on top of it. We're really excited to see it. We want to elevate it. Um, so helping them kind of get over their own internal, uh, feelings about like, oh, it doesn't matter, um, and telling them it does matter, like we want to hear, uh, is definitely a challenge, uh, building up that confidence.

Speaker B: This has been incredibly awesome and has always gone by well too fast. So we'll have to do this again. But in the meantime, you listeners, if you go to arresteddevops.com opencommunities, you can find out this episode show notes. We might have links in there. Uh, we might not, but, but there's only one way to find out. Go to arrestdevops.comopencommunities if, uh, you go to arrestedevops.com iTunes and leave us a review in the itunes store, allegedly that helps people find the podcast. We might even read it on air at some point. You can also find us on Spotify. We're finding lots of people have been finding us on Spotify. In fact, I am going to tell you what our Spotify wrapped results were that I thought were so interesting. So in 2023 for 323 people. We were one of their top 10 podcasts on Spotify. For 216 people, we were in their top five. And there are 38 people out there who arrested DevOps is their number one podcast on Spotify. And I'm sitting here going, people listen to podcasts on Spotify. So awesome. That was amazing. I didn't realize we had so many. And we have many more listeners than just the ones who put us in the top top 10. So love for you to listen to us on Spotify. If Spotify is a thing you're into, if iheartradio is what you like, find us there. We're on audible. We're everywhere that fine and less fine podcasts can be found. So, Andrew, this has been amazing. Thanks for being on the show. We're going to think about some other reason to have you come on sometime. For sure.

Speaker A: Yeah, it's been a blast. Thanks for having me.

Speaker B: Yeah, absolutely. This is arrested DevOps. And remember, there is always DevOps in the banana stand.