Open Communities with Andrew Zigler

Andrew: [00:00:00] 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.

Matty: 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 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, 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 at arresteddevops.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 2-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 codebase, the edits sync between the 2 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 arresteddevops.com/gitbook to find out more. So Uffizzi is a platform for platform teams. You can stand up your developer platform in minutes, not months. What I like about Uffizzi 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, Uffizi combines a great dev experience, secure multi-tenancy, and cost efficiency. But try it out for yourself at uffizzi.com. Download their CLI and you can spin up your first sandbox cluster in under a minute on their free starter tier. That’s uffizzi.com, U-F-F-I-Z-Z-I dot 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, 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.

Andrew: [00:03:33] 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 part of the Mattermost platform. But really just excited to kick it here with Matty, 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.

Matty: 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 kind of think about products and communities especially, you know, we work in the community side of the house, And when we’re talking about having a developer community that is open first, and it’s, 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. You know, cause everyone says we want a really open community. We want all this stuff, but then when the rubber hits the road, when we’re actually doing it, it turns out it’s not so easy. What’s, what’s, what’s the myth of the open-first developer community?

Andrew: [00:05:02] A big part of it is 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 closed communications out in the wilds 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 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 measurement. And if you’re going into a default open, open source kind of community 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 working internally. 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 interior, the inner workings of the project and what they’re pushing the cart towards, you know. So definitely the biggest challenge I think is getting over that echo chamber feeling, really feeling solid about what you’re saying, not always just talking to try to get validation, but offering resources and support. And also listening. 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.

Matty: [00:06:56] And I was going to say, I think that’s— it’s very laudable to say, hey, we want to, you know, our main product, if you will, or project, whatever the thing is, the reason our company exists is fully open source. We do everything in the open. And you can But you alluded to like the echo chamber. I think there’s also like a gravity around 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, 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, Squidcast, you know, whatever kind of bullshit thing that we came up with 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 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 meeting, 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 that’s— 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?

Andrew: [00:09:07] You just have more folks being the ones focused on it all day long. I think that’s totally the phenomenon that happens a lot of times in open source projects is, 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 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 for you, like of ways for people to kind of dive in and still feel like they have a piece of ownership about what they’re doing or what they’re contributing to. Obviously, it’s unlikely, 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. But that said, you can still set up really great kind of like pathways for them in the community to validate their experience, to reward them. 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 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 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 getting celebrated and uplifted. Or perhaps they’re only seeing a small select audience of people that do a very specific thing and they don’t know 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, and with what they want to do.

Matty: [00:11:02] 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.

Andrew: No one plans for it to go bad.

Matty: 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 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 one that, again, I’m gonna do a compare contrast with Chef and Pulumi just from 2 places I was that 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. But I was always a member of the Chef community. I used to tell, when I was in SalesEng, and I would, you know, tell customers because I would work with them in presales and then they would, you know, once they were customers, I didn’t work with them anymore. And I would, 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 a, you know, Chef Community Summit. We, you know, 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 like Pulumi, at least when I was there, it was really hard to get a lot of people to understand that just that people who worked at Pulumi were also part of the Pulumi community. And I don’t think it was because, again, of anything malicious or anything, but a good example was we said, okay, we’re gonna do like a community summit. We said we wanted to do a community event for the Pulumi community. And it was really hard to get Pulumi 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 hard.

Andrew: [00:13:01] It’s so hard. You’re sitting here describing this. I’m like, wait, this happens in other places? Like, you know, exactly. I think this is a ubiquitous experience in open source. Like, absolutely what you’re describing. You got to bring the people in that are paid to be there to really pull up the people who are trying to volunteer to be there.

Matty: And it’s not a reflection on the individual contributors. This is definitely a thing that leadership has to reinforce, right? And to say like, no, you know what, we allocate for this, we assume— because that’s, 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 throughout the DNA of the, the organization. You know, and it can be really powerful and not just for your contributors, 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, 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. So it’s like, cool, we’ll take your pull request, but like all the build is— because again, doing stuff really in the open is a lot harder because you can’t control things as much, right? Like if we can say this is— 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 like all kinds of weird edges. So You know, absolutely.

Andrew: [00:14:43] 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 like 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, that open sourceness is really firm in our DNA and engineers and staff, they, 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 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 touchpoints. 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, and it, you know, it being really deep in that company DNA, like you said.

Matty: [00:16:15] 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, 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, right?

Andrew: Exactly.

Matty: Or look at it this way, like what takes a lot of trust, and 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, 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, you know. And that’s right, it’s a weird balance, right?

Andrew: [00:17:16] Yeah, totally. And it’s also, maybe in that regard, if there’s a feature that’s really important to your enterprise audience and you’re in, 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 does need to get worked on maybe in a closed capacity, especially if you’re worried about that capacity. You 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 a, 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 organization at scale has things that happen behind closed doors. But it’s also about communicating that really clearly. That way you don’t lose trust. And that when, you know, if you’re going to have a project that open source people are contributing to, and it’s part of like an enterprise motion, then it’s like you need to be kind of sharing or explaining that. And also too, like it kind of goes without saying that if your open source 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 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.

Matty: [00:18:52] 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 what 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.

Andrew: But yes, the DevRel flywheel.

Matty: Yeah. So I wonder, because 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 Technically, like tactically, how would you make an engineering blog exist? Or probably he was like, well, a little bit of both. I’m like, okay, well, whatever we can talk about. Yeah. ’Cause then you get into things like engineers don’t wanna use WordPress. They wanna 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 your people whose job it is to write things, is they do it when they can, which is why you will have a blog that has no posts for 3 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 at the— 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, like kind of what are some of the ways to build up that open advocacy, you know, that enablement, but then still be able to like have, you know, cause it’s kind of hard. You can’t really go back to your boss and be like, you’d be like, well, why didn’t we get any? We’re like, well, nobody in the community gave any talks this month, you know, and be like, well, what are you going to do about that?

Andrew: [00:20:58] So, well, first off the whole conundrum of the engineering blog and like, is it their full job? Is it not their job? Is you recited it so well, it’s scary as to how we’re 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 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 said, I think there’s an opportunity for teamwork between those 2 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’re 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. Number one is being the multiplier effect you will— that you mentioned is, is huge. 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? 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 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, 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 a few talks and I make content that people engage with pretty publicly 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 in, something they’re working on, their contributions to the open source, and Mattermost is a part of that story, what’s great is when they ask for feedback. That’s happened for me before. 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.

Matty: [00:25:03] You’re—

Andrew: 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 in 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 want to give it like a shout out, for example, to GitLab. I think the GitLab DevRel community does an amazing job at this, maybe one of the best jobs, because GitLab, as you know, is a default open community. 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. 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. You really get a sense of the impact 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 in 3 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 plan it 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 touchpoint. 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, is really really important for having an impactful DevRel, in my opinion.

Matty: [00:27:12] That’s a really interesting idea. 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 and 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. You’re like, well, I mean, you didn’t say that yet. But one of the things too, when we think about that empowerment of— and that when you think about first and third-order levers that we can pull, to, to help boost our members of our community and, you know, 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 gonna be this great idea to be like, we’ll do this, and you are signing up for like I’m not going to name names of some companies that I’ve talked to 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, and now times 1,000. 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, 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. Oh, please. 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. Like they get all the juice, all that good stuff. And like, 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 2 years ago. I don’t even use the thing anymore. You’re like, cool. But you still, but it’s still, it’s a good blog.

Andrew: [00:29:54] It’s still a good blog.

Matty: Yeah. Like, can we just put it on the website? 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 confluence, anything like that. So I’m like, okay, I needed to write this down. I just put it on my own personal blog and then sent it to my team. I’m like, here’s how you do it. And then it, I mean, I get hundreds of, 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. Forward.

Andrew: Right, right. That’s your legacy now.

Matty: [00:30:56] 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?

Andrew: Oh, that has not happened to me yet.

Matty: Oh yeah, I forgot when I had that problem.

Andrew: 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.

Matty: You’re like, that doesn’t help me.

Andrew: That doesn’t help me. Oh man. But man, what you’re— what you’re saying about the community writing program, so true. We used to run a community writing program at Mattermost. It’s a lot of work. It’s really rewarding for you and the contributors. If you get a really good momentum, you establish really good boundaries about what you’re looking for. I mean, 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, you know, 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. And so that, that creates a lot of balance. It’s definitely a huge challenge. I also think that what you’re saying about people making content and sharing it and just being like, oh, whatever, and it’s something that’s out there, you can’t even get a hold of them, they probably didn’t even give it that much of a second thought. It’s something that I’ve noticed is in open source communities, the community members get sometimes in their head, they get a feeling that 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 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. So helping them kind of get over their own internal feelings about like, oh, it doesn’t matter, and telling them it does matter, like we want to hear, is definitely a challenge at building up that confidence.

Matty: [00:33:21] 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’s show notes. We might have links in there. We might not. But there’s only one way to find out. Go to arresteddevops.com/opencommunities. If you go to arresteddevops.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’m 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 5. And there are 38 people out there who Arrested DevOps is their number 1 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 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 gonna, we’re gonna think about some other reason to have you come on sometime for sure.

Andrew: [00:34:50] And it’s been a blast. Thanks for having me.

Matty: Yeah, absolutely. This is Arrested DevOps, and remember, there is always DevOps in the banana stand.