Podcast

Who the Vox Pupuli Are and How They Work with Puppet

Great things – tools, spaces, companies, brands – are supported by great communities. The Vox Pupuli are perhaps the most prominent, active group in the Puppet community. Here’s what they're up to lately, what it’s like being one of them, and what Puppet (the community) means to Puppet (the company).

The Vox Pupuli are 200+ strong; they maintain dozens of modules on the Forge; even executive leadership knows their name. On this episode of Pulling the Strings, join Puppet community members Gene Liverman, Tim Meusel, and Ben Ford for a casual discussion on what what Vox Pupuli actually do, the role of community in shaping a company like Puppet, what Vox Pupuli is focused on now, and what drives the highly engaged group. As Tim puts it, “There is no excuse to not participate.”

JOIN THE PUPPET COMMUNITY ON SLACK

Highlights:

  • How Vox Pupuli works
  • The relationship of Puppet (the company) to the Vox Pupuli
  • The power of independence
  • The time Vox Pupuli helped Puppet avoid disaster in a new release
  • What Vox Pupuli is working on now

Links:

Gene Liverman [0:19] Hello and welcome to today's episode of the Pulling the Strings podcast, as always powered by Puppet. My name is Gene Liverman, and I am a community member of Puppet, who previously worked for Puppet the company. I'll be hosting this and a few more community-centric episodes of Pulling the Strings going forward. If you have ideas, or want to connect, I'm genebean in the Puppet Community Slack, and on the Fosstodon.org, Mastodon instance. And there'll be links to both of those in the show notes. Today, I am excited to talk to two awesome people who are involved in the community in very different capacities. Tim Meusel is a Vox Pupuli PMC community member, and Ben Ford, who is on the product team at Puppet, and oversees Forge and the Ecosystem team. Today, we're going to talk about Vox Pupuli, what it is, its importance to the community, how it came about, and how the group works and interacts with folks like Ben and the rest of the public community. So let's get started. Tim, can you give us a bit of an intro to yourself and help the rest of us understand the right way to say your name and the organization name?

Tim Meusel [1:30] Hi, Gene. Thanks for having me. The correct German pronunciation for my last name is Meusel. And in Germany, we pronounce Vox Pupuli as “VOCKS poo-POO-lee”, but I learned at various conferences that every person with a different background has a different pronunciation for Vox Pupuli, and I would say there is no right or wrong about it. To my personal background, as you might hear from my accent, I am living in Germany. I started in the Puppet Ecosystem roughly 10 years ago at a big internet service provider, managing internal systems. And got into the community, because I was using some of the software from it. And some years later, I ended up in the project management committee, and I'm kind of in a steering board and manage a bit about the whole organization.

Gene Liverman [2:35] Very cool. And Ben, I know you've, obviously, been on this podcast many times before, but since you're taking kind of a guest role this time, can you give us a bit of a introduction to yourself and your history with public, and anything that just really jumps out that you want people to know?  

Ben Ford [2:52] Yeah. I'd be happy to, Gene. But first, I would just want to take a side and say we can't really let Tim downplay himself and his role in the community so much. He says that he's one of the PMC members, but reality is that Tim is kind of the lifeblood of what makes Vox Pupuli work, and he has been for many years. So I just want to highlight that and point out what a wonderful person we have here with us today.  

Tim Meusel [3:16] Thank you.

Gene Liverman [3:17] Yeah, a hundred percent agree with that.

Ben Ford [3:19] So my story here with Puppet is kind of weird and long and takes a couple of strange sides. But quite some time ago, I started out in university, I was setting up a, I'll just call it a test lab to kind of simplify the story a little bit. And I didn't really want to run around and poke at machines and SSH and sit at keyboards and all of that stuff, so I looked for tools that could help me. And no surprise, I found this fancy new tool called Puppet that automated a lot of that for me and let me sort of describe what I needed. It took me a while to understand that whole model and everything, but it was so helpful to help me get things done and not worry about making sure that I did everything exactly the same everywhere and in the right order and all of those things. So I became a fan real early. And then I came to work for Puppet, because why not? You become a fan of the thing, and that's what you want to get involved with.

Gene Liverman [4:21] That sounds kind of familiar.

Ben Ford [4:25] Yeah, I think that a lot of us have very, very similar starting stories right there. But yeah. So I started out doing professional services, and one of the things that I felt was kind of unique about how we did that is that Pro Services also did trainings back in the day. And that was pretty cool, because it let people get very hands-on and let people in trainings. They didn't have a trainer that was talking to them, they had a practitioner or somebody who knew what was going on, and then somebody who had used the tool to solve real problems. And no surprise, I'm a very opinionated person, and I got kind of cranky and upset with the fact that engineers were also writing the content though. And that meant that Hunter would go out to do a training and realize that we needed a section to talk about higher data management, for example. Or somebody else would go out and do a training and go, "Oh, we don't have anything on EXT lookup, and if you recognize that word, then I'm so sorry, that's not really a thing anymore and that's a good thing. But I got cranky about this, so I sort of grouched and ranted to our director, and he listened to me for a little bit. And eventually, he says, "Well, thank you for volunteering for your new role." So that's when I started in Puppet Education, and I built out our education team and a lot of our content. So I did fundamentals and practitioner and all of that, which many of you probably recognize. And the thing about that was I focused on the learner's journey, the arc from being introduced to something to becoming proficient with something and how you picked up pieces along the way and the different things that people would struggle with and how we can have answers as people started hitting those problems. But that all kind of relied on the fact that I had spent so much time with Puppet and I had spent so much time solving problems with Puppet. And as I kind of came off the road and focused more on building the content in the team, I realized that I was losing touch with the people who were actually sort of using the product, not just academically, this is how a thing works, but using the product to solve real problems. So I started getting more involved with the community, talking with people, and helping people through some of the things that they were working on, and I realized how much community mattered to me. It's funny, because I'd been doing that my whole life. It's like back in university, I ran the Linux users group, and my partner is a roller derby skater, and I was always involved in helping plan and coordinate some of the things that they did and whatnot. But coming to realize that that was a central part of the things that I value was kind of how I got so deep ingrained within the Puppet Community. And then I did different things at Puppet, and eventually, came and talked with Kara, who was the community manager at the time, and I was like, "Hey, Kara, you know what? This community thing is really great, but it'd be even greater is if we had a technical person whose job was actually to help work with the community." So we built out a new role for me that was our first developer advocate role. So now, I'm deeply ingrained with community. I work with community every day, and it's my job now. I lead the community and Ecosystems team. So it's like the people who build our puppet content, to the people who build the tools for that, and the people who run the Forge to share the content, and the people in the community who are actually using that content to solve real problems. It's like this ecosystem is where my job is right now. And as you might guess, that means that I work with Vox Pupuli pretty much every day these days.

Gene Liverman [8:01] That’s pretty cool. Tim, I want to kick it back to you for just a second and say, can you tell us a little more about what Vox Pupuli is? I'm not sure that everybody actually knows what this organization is.

Tim Meusel [8:14] Yes. So let me explain a bit how all of this started roughly 10 years ago. Back then, Puppet was already a thing and widely used, at least among many Linux administrators. And people were quite happy with it, but there wasn't a place to exchange Puppet code. That came a bit later, which is now known as the Puppet Forge, or forge.puppet.com. And people took a look at it and tried to figure out, "What are actually Puppet modules? How do we write our Puppet code? And how do we define what actually is a module? When do we split it up into multiple modules?" Stuff like this. "How do we structure our code?" During this process, many Puppet users, developers, or administrators talked to each other and figured out, it doesn't make sense that every organization writes their own code to manage their DNS server, or to distribute SSH keys, or to write your NTP configuration, or manage your DNS configuration, for example. So those were the most common use cases. And people had the idea to form a collective of developers to write together Puppet code and to use it together. And that's how the loose group or loose term Puppet Community was invented was a bunch of Puppet users, basically. And this grew over time. And it happens a lot that there is a system administrator at a company, and he uses Puppet to manage a bunch of Linux servers. And he needs Puppet modules for it, and he doesn't want to write all of them on his own and takes a look online and finds the community and starts to interact with Vox Pupuli and notices that there are already people out there that already went the hard path and wrote modules and that they are reusable and many of them are maintained by Vox Pupuli. I think two years after the collective gave itself the name Puppet Community, I joined, because I was a user as well. I had to use Puppet back then and had to maintain many, many Linux systems with all the kind of different software on it. And I didn't want to write Puppet modules on my own. But the Linux system that I had to use was a bit proprietary, and it wasn't supported out of the box by most modules. So I had two options, write the Puppet code myself, or take the existing Puppet modules and just write a small patch. And that's how I got into the open source community. Basically, I had to patch roughly a hundred, 120 Puppet modules. That took a bit of time. But in this process, I got to know all the different people. And Vox Pupuli grew over time, and now, it's a big and working community of roughly 210 people, I think, at the moment. And altogether, we are maintaining a huge set of Puppet modules and Puppet related tooling.

Ben Ford [12:00] That story about patching 120 modules, it kind of makes things like module sync make more sense now, right?

Tim Meusel [12:06] Yes, absolutely.

Gene Liverman [12:08] Yeah, patching the modules for adding operating systems support, I think, is a way that a lot of people end up getting into the community, either adding one additional operating system or something equally as trivial compared to writing the entire module from scratch. I know it's certainly how I got pulled in on some of the things too. So Tim, how do you decide what to work on within Vox? And also, besides just what you decide to work on, how do individuals within Vox in general decide what to work on? Because like you said, there's a lot of different things being maintained by the group.

Tim Meusel [12:43] I think the cool thing about Vox Pupuli is that we are not a company. There is no manager that dictates what you have to do. And we have enough work of different kinds available for everybody, so there is no excuse to not participate, basically. At the moment, I focus on streamlining our CI pipeline, so ensuring that we have a good test coverage on all of the modules and all of the tooling and that the CI pipelines as identical as possible across all the different Git repositories. Because we learned in the past that makes it way, way easier for people to contribute, because they only need to understand a certain pipeline or a certain coding style once. And if they understand the pattern, they're able to contribute to all the repositories. And that brings me to my second point I'm working on, that's our style guide, which is a bit more detailed than the official Puppets style guide on the Puppet website, because, again, it's just helpful when the style guide is quite strict and easy to understand because newcomers can read it and are able to understand how code should look, how it should be formatted, and that makes it easy for newcomers to review pull requests on modules.

Gene Liverman [14:28] I totally agree that that is one place a very opinionated document is actually quite helpful. Because when you're new, it's easier to just have somebody say, "This is what you do," as opposed to giving you 75 different choices that all theoretically could be okay.

Tim Meusel [14:43] Yeah, absolutely. So onboarding a new person to Vox Pupuli is like five minutes of work compared to multiple days at the usual company. We can give the person right access to the Git repositories, if that's required. We have a link to the Git Repository and to the style guide, and that's it, basically. We have the people where they can find us, which is usually on the Puppet Community Slack, or on the Libera IC channel, or the Libera IRC network in the Vox Pupuli room. And if somebody has questions, there's always someone around to reach out to. But the style guide should always be the entry point and should answer most of the questions for newcomers. And GitHub is quite helpful to list all the open pull requests that we have. And if you are interested in any of our modules, you can check through the open pull requests or through the open issues and, yeah, start contributing, basically.

Gene Liverman [15:52] Very cool. So both you as an individual in Vox as the community, how do you work with Puppet, the company, and people like Ben? And then for whichever one of you want to answer, or both of you, how does that help the larger ecosystem? What benefits does this collaborative approach bring?

Ben Ford [16:18] It is incredibly valuable to be able to talk with people who are so steeped in the community and so steeped in using Puppet to solve real world problems. It's one of the ways that we do product research for what Puppet ought to do in the future. It's one of the ways that we keep ourselves held accountable to the decisions that we make. Real good example of that is when we pulled out the core modules out of Puppet, I think that was 6.0 when we did that. And we thought we had planned everything out, we thought it was going to be a seamless transition, and it was just going to work. And Vox Pupuli immediately came to us and said, "Hey, here's a problem. We need to fix this right now. This is what's happening." In retrospect, we should have caught, but we didn't think about it, because our testing pipelines ran a little bit differently. But because Vox was so, they were so on top of the regular testing and because they already had these connections with us and they were able to bring that feedback immediately, we were able to get working on that and resolve that problem far, far sooner than it would've been if we had just relied on support tickets coming in from customers going, "Hey, what's going on?" So it's incredibly valuable that we have these tech connections.

Gene Liverman [17:31] Very cool. I can totally see where that would make for a much better feedback loop than something like just relying on customers, whether they be paid or open source to chime back in eventually via a ticket or something.

Ben Ford [17:45] And to be very clear too, that's only the business value part of it. The community value is just immense. It's engaging with each other and helping each other, there's so many more things that come out of this rich ecosystem, because we have this group that holds it all together.

Gene Liverman [18:01] So Tim, from your side, how does Vox work with the Puppet team?

Tim Meusel [18:05] When Vox Pupuli started almost a decade ago, I would say half of Vox Pupuli were Puppet Labs employees. So there was always a very, very close connection, and even some of the people started in the community and then moved to an official job at Puppet, or the other way around and moved from Puppet to the community and are still tightly connected to the whole ecosystem. So we talk to each other on a daily basis, and that started when the community was founded basically. And that's still continuous. And yeah, we talk to Puppet probably on a daily basis sometimes about bugs that we discovered. And my impression is that Puppet listens to Vox Pupuli, because when we identify bugs and report them, we are usually quite confident that it's an actual bug somewhere in the software and not related to our CI system. Because we spend a huge amount of time making it rock solid, and we are basically continuously working on this CI setup and are now quite good at identifying bugs. And that's a big value, so Puppet listens to us. On the other side, we talk often to the different employees that maintain Puppet tooling and also the Puppet modules, and we try to align how we test things and how we roll out things. There are some differences, because Puppet is a big company and has paying customers, so not everything can be identical. But our testing is now quite similar, and I think that's a big benefit for everybody, because like I mentioned earlier, it's good when you have a very, very strict style guide and just one way to do things. And we are almost there with how we test stuff, not only within the Vox Pupuli community, but within the old Puppet ecosystem.

Gene Liverman [20:27] Yeah. That consistency certainly makes it easier to interact, because then you don't have to worry so much about whether the module is owned by the company side or by the community side. The process is pretty much the same with both.

Tim Meusel [20:43] Absolutely, yes.

Ben Ford [20:44] And I do want to say something else, and that is that yes, absolutely Vox is known, not just throughout engineering, engineering knows that reports that come in from Vox, they get special attention because of who you are and the reputation that you've built. But it also goes up, all the way up to the company, and it's like not only... We're acquired, so now our CEO is one layer above. But not only the Puppet business unit now, but all the way up to the CEO of Perforce itself. They know the name Vox Pupuli, and many, if not most, also know your name specifically. So it's like you are known inside Puppet.

Tim Meusel [21:24] I am not sure if that's good or bad, but I'll take it.

Gene Liverman [21:30] So we don't have a ton of time left, but I was curious, is there anything you've created recently that you think is either particularly exciting or that you think to be really good for the people listening to know about?

Ben Ford [21:44] Tell me that it's tasks, Tim. That's the thing I'm excited about.

Tim Meusel [21:50] I would say there are a few things. The first one, which is what Ben mentioned is software. We are calling Vox Pupuli Tasks, which is currently under development. It's not finished yet. But the idea is that this is a Ruby on Rails application, and it listens to events from GitHub.com. And it turns out GitHub is quite verbal and sends out a lot of notifications if you ask it.

Gene Liverman [22:19] No kidding.

Tim Meusel [22:20] Yeah. Yeah, my email inbox is just overflowed. But yeah, one of the goals of our Vox Pupuli Tasks application is to fix this. For example, it gets notifications about new comments in a pull request, and it can automatically check if there are new merge conflicts, or if there were merge conflicts in the past and they're not resolved. And based on this, the application can attach a label to the pull request, for example, has merge conflicts, needs rebates, stuff like this, or also remove the labels. And based on this, we can filter through all of the open pull requests. And we always have like 400 to maybe 650 open pull requests in the whole organization, which is quite a lot. And it's impossible to review all of them every week. And that doesn't make sense, because most of them don't change that often, and many of them require attention from the person that opened the pull request, and not from us as maintainers. Because they might need to add tests, or they provided code that broke the existing tests and they need to review their own code, or they introduced a merge conflict, or another pull request most merged, and they need to rebase their own code. All of this is stuff that we should not care about, because it's the job of the pull request author to review their code. And it doesn't make sense for us to check the pull request and just pinging them. And this is stuff that we would like to automate with our Ruby on Rails application. We started it one and a half years ago, maybe a bit longer. And this is on a good path, and we hope to finish this or make it production ready within the next month.

Gene Liverman [24:30] Oh, nice.

Tim Meusel [24:30] Yes. So that's our big goal. No pressure.

Ben Ford [24:33] I think what I'm hearing from you, Tim, is maybe like a request for contributions, or people participating and helping out.

Tim Meusel [24:38] Absolutely. So if you love Ruby on Rails, or Ruby in general, or you love working and poking the GitHub API, let us know. We are always happy to get more help and to get more ICE on our own code. That would help a lot. And one thing that I would like to mention is that this application is not specific for Vox Pupuli. As long as you are using GitHub or GitHub Enterprise for your organization, you are able to use our Vox Pupuli Tasks application. So your own company, if you're listening, might benefit from this, if you set this up for your own. If you have a bunch of repositories or a bunch of pull requests, this could be helpful.

Ben Ford [25:27] You’re using it for things that are not just Puppet modules too, right? You're using it for all your gems and other tools.

Tim Meusel [25:32] Yes, that's correct. It's also not specific for Puppet modules.

Gene Liverman [25:37] That sounds pretty awesome. It's exciting to hear that that's nearing such a close timeframe to being out for kind of general use.

Tim Meusel [25:46] Yes. I'm really looking forward when this is finished and rolled out. That will take a lot of burden from us about just reviewing for requests. Yeah. And lets us focus on more important stuff.

Gene Liverman [25:59] On the other end of the spectrum, is there anything that Tim, you and Ben are looking forward to working together on in the near term?

Tim Meusel [26:08] I have something on my mind. I'm not sure if Ben has it as well. I would like to see some improvements on the Puppet Forge about scanning uploaded content and doing quality ratings.

Ben Ford [26:27] Yes.

Tim Meusel [26:29] We already do a bunch of this within our own CI pipeline, and I think it would make sense to have this on the Puppet Forge as well, so that not only we as the maintainer of a module can see how good we think it is, but also everybody that's looking for a new Puppet model. I think that would be a big benefit for everybody.

Ben Ford [26:49] Yeah. And we're not at a place that I can talk real publicly about some of the things that we have planned. But yes, that is absolutely on our roadmap in the relatively short timeframe. So we will talk more. And you should expect to see some neat things happening soon, both on the developer tool side, like the PDK and whatnot, and from the front end on the Forge. So you'll be able to use some of more of the quality tools as you're developing things, and they'll also be reflected in what you see on the Forge. Stay tuned. More information coming.  

Gene Liverman [27:26] That sounds exciting. To close us out, wanted to just reiterate that Vox is a very open community. I myself have been welcomed into it several years ago and can speak to that personally. And Tim, is VoxPupuli.org still the best place for people to go to find out how to get in touch and to learn more?

Tim Meusel [27:49] Yes, absolutely. That's where we document everything. And at the bottom of the webpage is a link to our Slack channel and mailing list and IRC channel.

Gene Liverman [28:00] Very cool. And if somebody's not already part of the Puppet Community Slack, slack.puppet.com is a quick and easy way to join the community and get engaged.

Ben Ford [28:11] And I will point out too, one thing that the people sometimes get intimidated with Vox is that it's not super clear. There's no application process or something, and people are like, "How do I get involved?" And the answer is you just do. You sit down and you look and you see there's a module that has a thing that needs to be fixed, so you fix it. And you hop into the Slack channel or the IRC and you say, "Hey, can somebody help me with this thing?" And you just start participating. And once you've been there long enough working with it and helping out enough, you think, "Hey, maybe we can make this official." And you talk to one of the members, and they help get you onboarded into the GitHub.org. But really, it's just a matter of jumping in and starting to help out, like so many other open source stories. Just help out.

Gene Liverman [29:02] And to that end, I'll also say that there's a lot of non code ways to become a very, very productive and helpful member of the community. There's a lot of questions that get asked that simply participating in the Slack channels, or in the IRC channels could be hugely helpful for. And then there's always documentation and related things that can be helped with. So it's not just coding on Puppet modules, or on RubyGems or the like.

Ben Ford [29:29] Yeah, I've wanted to try to find somebody who is a good docs writer, like a tech docs writer, or maybe visual design or whatnot to help revamp and improve some of the content that's up on the Vox Pupuli webpage, just make it more discoverable and make it easier for people to navigate around and understand how they can get involved. I'm sure that Tim has a lot of other ideas and other things that he wants help with too.

Tim Meusel [29:57] Yes. If anybody's listening and is a web designer, or knows stuff about style sheets, it's like, please ping us. So there is lots of room for improvement on our website. And yes, you don't need to be a Puppet developer to contribute to Vox Pupuli, as Gene and Ben said. There's a lot of documentation stuff that could also be improved, or just reread by others and just see if it's still up-to-date, if it's understandable. Because, again, as you can hear from my pronunciation, I'm not a native speaker. But every other documentations written in English, and sometimes it's not perfect.

Ben Ford [30:41] Oh, it's far better than my German is. And also, there are so many other ways to get involved. One of the other things that we need in this community is just the ability to help talk about what Vox is doing. Maybe it's like help run the social channels, or do tweets, or write blog posts, or things like that. So it doesn't necessarily have to be directly code or documentation or whatnot. It's just like if you look at this, and you're like, "Hey, this is a fun kind of thing to get involved with," just come get involved. And then help write stuff, help do stuff. And Vox is now, maybe Tim wants to talk about this for one second, but Vox is now actually a registered nonprofit. And they have a budget, and they've got money coming in and out. And if you want to help with that, I'm sure that Tim would love to have that kind of help.

Tim Meusel [31:38] Absolutely. Thanks, Ben. Yes. Since the beginning of this year, we are part of the Open Collective, and you can sponsor us directly on opencollective.com, I think, but also, via GitHub sponsors. That's also possible. And one thing that I would like to mention is sometimes it looks a bit intimidating that we are now a GitHub organization with 50 RubyGems, something like that, and 180, 190 Puppet modules roughly, which is more maintained Puppet modules than even Puppet the company has. And yes, that sometimes looks a bit intimidating for new people. So if you maintain a RubyGem, or any open source project, basically, or a Puppet module, you can ping us. You can become part of Vox Pupuli and keep maintaining your software, but within the Vox Pupuli namespace, which enables all of our existing contributors to also take a look at your code base. And you have the ability to use our existing CI infrastructure and CI pipelines that we have for Puppet modules and RubyGems, so you do not need to care about those anymore. Point A. Point B. We also have sponsors for our pipelines. One of them, for example, is CERN from Europe, but also GitHub itself, who are sponsoring us, mostly our CI runners. And yeah, that's a big benefit of maintaining your module with Vox Pupuli. Your CI just runs way, way faster, and it's totally fine to just take a look at your own project. Nobody's required to review all the pull requests for all the 50 RubyGems, for example, that we have. Nobody does that. That would be insane. That's way too much. It's totally fine to just focus on the project or projects you care about. You don't need to review pull requests for all projects that we have.

Gene Liverman [33:54] And that really is a helpful thing. It makes it much easier to keep a module up to date that way.

Tim Meusel [34:00] Yeah, absolutely.

Gene Liverman [34:02] If people would like to reach out to you, Tim, what would be the place you would prefer them to do that?

Tim Meusel [34:09] For quick responses, our Slack channel or IRC channel are probably the best entry point, and they both are linked via a Slack bot, so it's fine to just join the Slack channel or the IRC channel. And if you would like to start a bigger discussion, we also have a mailing list, which is also linked at the bottom of our website, voxpupuli@groups.io, where you can just send an email too. And yeah, those are the main entry points, I would say.

Gene Liverman [34:44] And Ben, how should people reach out if they would like to chat more with you?

Ben Ford [34:48] I’m pretty easy to find in all the places. I'm just benford2k on Mastodon, or the Community Slack, or various other places. So if you just look for that, you'll find me.

Gene Liverman [35:03] And we'll be sure to put links in the show notes to all the different places we've talked about throughout this episode for both the website and some of the sub links off of it, and for all of our different social handles. Thanks, everybody, for listening and for being here on the Pulling the Strings podcast, Ben and Tim. And as always, this is powered by Puppet. Thank y'all.