 Thanks, Walter. Can you hear me in the back? Good? All right. Thumbs up. Awesome. So I'm gonna talk about the fig management community. My talk, I think, is 30-ish minutes, so hopefully I'm not gonna keep you here the whole hour because I know I'm standing between you and Belgian beer, Belgian waffles, whatever's your thing, but I am at the end of the day, so I'll keep it moving if I can. So, I spent the past 20 years working in roles focused mostly on open-source software, most recently at Puppet, where I was director of community up until the beginning of 2015 when I decided to take a little break from working and go back to school to get a PhD at the University of Greenwich, and these days I'm mostly doing research focused on the Linux kernel and looking at how Linux kernel developers collaborate when many of them actually work for competing companies, which I find pretty fascinating. I'm not sure what this says about me. I'm also doing a bit of part-time community and open-source consulting with the Scale Factory in London, where we are hiring DevOps engineers, if anyone wants to come work for us. That's my one obligatory plug for the work stuff. I'm gonna talk about a couple of things, and because I'm incredibly lazy, so Walter referred to this as research, which is quite a stretch. I outsourced most of this talk to people like you, including some of the people in this room, with a highly unscientific survey of the three questions, and I asked people what's the most awesome, awful, and apathetic bits about this community. So a huge thank you to everyone who did complete my little survey since the survey responses make up the vast majority of materials for this talk. Again, because I'm lazy. The survey had 13 responses, so highly scientific again. One person sent me feedback via Twitter DMs, so that's 14 responses, and then I, of course, have done this for more years than I want to count, so I've added in a few things that I've experienced in this community. And because I like to keep things a bit positive, I'm gonna talk about the apathetic and awful things as more areas for improvement, and I'm gonna mix it up to talk about the awesome things alongside the areas for improvement, to avoid having just this gigantic section of the talk, focused about sad things that suck. In case you haven't guessed, I'm an American. We've had enough things that really sucked over the past two weeks, so I'm gonna try to go with the awesome examples, because keeping sanity, I suppose. So working with really, really awesome people was a common thread throughout all of the replies to, again, my highly unscientific survey. And being in communities where people are welcoming, friendly, smart, makes them so much more enjoyable. I became part of this community when I started working at Puppet. And it would have been really easy for me to just sort of fade out of this community and disappear when I left Puppet and sort of disappeared into academia, PhD work. But I still go to some of the conferences. I still go to FOSDEM. I went to, I go to a lot of the DevOps conferences. And I still go to some of the London meetups, things like that. I've been doing a bit of blogging in the space. But the main reason I've stayed active in this community is because I really love the people and they're fun and awesome to hang out with. So I keep coming to the conferences and they're generous enough to let me continue talking so I can sort of justify it. It's awesome. But the people, the people are what make this community so amazing. But what really stands out to me is that this is something that's true across the entire configuration management community. And not just in one project. So you see this in the examples here on this slide and you'll see it on the next one as well. And it comes from people participating in all of the various config management communities, Chef, Juju, Ansible, Puppet. So in any community, there are always those tasks that we should all take time to do. But for whatever reason, many of us just kind of don't get around to them. Things like documentation, answering questions on the mailing list and IRC, organizing things. And it's important to think about how many community members are doing work that tends to sort of fall between the cracks and not get noticed. Much of this work just isn't really noticed or appreciated. So don't forget to thank those people who are actually picking up those tasks that everyone should be doing but not quite getting around to. And you can see this comment from Spencer. So he says that the people are what make it worthwhile to participate in these communities. And I wholeheartedly agree with that. He specifically called out Igor. So I do think someone should start an Igor fan club. I've said this before, I would totally join it. Anybody who's worked with them can attest to that. I've always said that one of the things that I love about this community is working with really great people who happen to work for competing companies. One of the best things about helping to organize the first couple of config management camps, and I used to help organize this config management dev room here at Fosdown, is that I get to work with some of my favorite competitors once a year to do something really amazing together, which is actually a lot of fun. So at Fosdown this mostly meant sharing bouncer responsibilities to turn people away from the room, which was full almost all the time. Just not the most fun thing to do. It's a bonding experience, I guess. It's part of the charm of Fosdown. But this close collaboration with competitors to do something that helps the entire group happens in other areas, but I think it isn't really always all that common. And many of us were working on these events in addition to our regular day jobs because it was the right thing to do. And it's nice to be at conferences and be able to go out to dinner or drinks with people who work for competing companies and actually have a really fun time, awesome time hanging out with them. Within the config management community we seem to have a bit of a love-hate relationship with containers. On the one hand I know quite a few people in the config management community who use containers on a regular basis. How many of you use containers on a regular basis? How many of you just don't like to raise your hand during talks? Just as a baseline. Okay, just curious. So a lot of people use them in test development environments, but starting to see a few people use them in more production environments. And they can certainly be handy in some situations. But there is also a lot of talk from the container side from people who think the containers are a replacement for what they often refer to as legacy approaches like configuration management, which creates a fair bit of animosity between people in this community, as you can see from the quotes on the slide. And that's not cool. We should be able to talk about other technologies while having a bit more of respect for some of the people using those technologies. And maybe some of the issues with containers are similar to the concerns about people being sort of excessively aligned to a particular group or particular tribe to the point where they really aren't willing to consider ideas from other people and can sometimes be really hostile towards those new ideas or new technologies. I like this comment about how people weren't always supportive of Ansible when they were sort of new on the configuration management scene compared to some of the other tools. And I think this is a bit of a double-edged sword, right? On the one hand, you have some people who always want to embrace sort of the latest and greatest technologies, the ones that are the most fashionable this particular week. And this can sometimes, frankly, lead to a lot of resume-driven development, which also isn't necessarily what we want to be doing. You know, selecting technologies not based on any kind of evidence, but based on what's fun or cool at the time. On the one hand, though, on the other side, some people push back so hard on these people who are just trying to, you know, adopt something a bit more modern, something a bit more interesting, and just want to stick with what works, which can lead to a bit of tribalism and resistance change. And the reality is we need to be somewhere in the middle, right? Looking more pragmatically at new technologies and being willing to embrace the ones that help us effectively get our jobs done. Peerly proprietary tools really haven't really become established as leading tools in the configuration management space, which makes us, I think, a bit different from some other segments. With open-source projects as the leading tools, we have some pretty large communities of people who are working on configuration management. And I think this is part of what makes the configuration management space so collaborative and the people so willing to work together to share technology and integrate between solutions. While many of these tools have competing functionality, the reality is that the people who use them, the customers of, you know, open-source projects, often use them together. So having integrations between these various tools is pretty important. And there's also a lot of excitement about the technology. And people are willing to share ideas and share code, which is cool. You know, you can just take a look at the Puppet Forge or Chef Supermarket or any of the other similar products or projects. And those are just two examples. You can see so many people sharing code and working together across technologies, which I think is pretty cool. Now, this problem, I don't think this is actually unique to the configuration management space. I think there always tend to be gaps between what the vendors and the developers of the software think that they should do and what different groups of users want. To some extent, this is, frankly, this is just inevitable. This is the way software development works. You just can't possibly please everyone all of the time because they have all kinds of conflicting needs. So different groups of users will want to do slightly different things. And the people developing the software, of course, will also have their own vision for where they want to take it. And this is especially true of open source projects. I think where vendors are involved, right? The reality is that companies, Puppet, for example, just because I worked there, they fund a lot of the development of the software. And they can only continue to do that if they can make enough money to sustain the business and continue to pay those developers, pay those employees. But the gaps tend to get a lot smaller and the vendor really spends a lot of time listening to the needs of the community and works hard to fund their business in ways that are supportive of the open source community. And I do think that the vendors with these stronger collaborative relationships with their open source communities will be in a better position to succeed over the longer term. With all sorts of people embracing DevOps and automation, it's become a lot more common for people from ops to end up writing at least some code outside of the shell scripts in Perl that have been sort of the mainstay of operations since even before I was a sysadmin and that was the mid-90s. It's becoming more and more common for people from operations to write or contribute to things like puppet modules, chef cookbooks. And with these being shared and reused by a lot of other people, you get feedback. And in this case, you often get a lot of positive feedback, which is pretty cool and doesn't always happen in a lot of environments. And we also see some operations people contributing back to configuration management projects themselves, which in some cases requires a bit more coding skill than maybe a module or a cookbook. And so I think we'll continue to see these lines blur between the developers and operations as more and more teams embrace more of this DevOps culture. We've all probably done this at some point in time, right? Made some nasty comment about the technical skills of someone else. I know I've been guilty of this on way more than one occasion. I'm not proud of it. But it's important to remember that you really don't always know what's going on in someone else's head, right? Or why they made the technical decisions that they did. Maybe they had a good reason at the time for doing something a certain way or maybe they know that they took a shortcut that wasn't optimal but they felt like it was the best decision giving whatever constraints they were working under at the time. And maybe it generated a little more technical debt, something like that, but they kind of ran with it. And maybe they've spent years in operations and are now just starting to do a little bit of development. Or maybe they're relatively new to a particular technology language or a certain way of doing things and are already maybe a little insecure about their abilities. Or maybe they were just having a really, really crappy day at the time. But the moral of this really is to give people the benefit of the doubt. Put yourself in their position. And I think having a bit of empathy for other people goes a long way towards understanding what people are going through. While there is some occasional talking crap from some people, I do think though that for the most part people tend to be quite helpful and supportive of each other. I've seen a lot of examples over the years of people really pitching in and working together to solve tough issues. Getting back to my earlier comment about ops people writing code, there's a lot of, I think, empathy from ops people turned devs when something they've written is causing someone else to have an issue or have an outage performance issue, something like that. They actually know what it feels like to be in that position, which tends to make them, I think, sometimes even more responsive when someone else is having an issue. Because we all know what it feels to have things just sort of on fire all around you and all you want to do is to get things back in working order so that people stop yelling at you. And I think this helps make us, this makes us more helpful and collaborative even when it's someone else's issue that needs to be solved. It's also really, really easy to fall into the trap of thinking that we know the best way to solve a problem that we can't learn from other people and projects who came before us because those projects may be different in some way or maybe we think those people aren't quite as clever as we are. But I think this is, friend Liz, this is rarely the case. We can always learn something from the successes and failures of those that came before us. Even if we just take the time to do a little bit of research. And this is an incredibly helpful community. So there really is no good reason for new tools and new projects to be making the same mistakes or running into the same issues as those that have come before. And we can talk to the people who've built similar tools about their challenges and hopefully avoid running into some of those same issues again. Now the downside to more people without a coding background and being able to write codes is that you might sometimes end up with a less than ideal solution. But we certainly can't blame this on operations people writing code, right? I think you tend to see this in most projects, not just configuration management. We want to be able to handle every situation, every edge case, every possible use which then tends to make things overly complex. Then when someone tries to use it for a relatively simple use case they need to sort it through a ton of options to figure out how to handle their situation. And because we can't possibly anticipate every use case some solutions won't be nearly complete enough for some people. And people can strive for something of a middle ground by building solutions that maybe aren't too complex but are likely to meet the needs of most people while being easy to extend and add additional functionality. However this is completely a no win situation, right? Because it can be really difficult and probably impossible to strike this balance but it's certainly something we can strive for. Part of the problem with modules, cookbooks, that sort of thing is that the quality varies tremendously from one to the next. Some of them are amazing and they're used by tons and tons of really, really happy people. And others are, well, not so amazing, right? In some cases as the top quote here suggests there isn't always great direction about best practices to follow when developing them. So people take all kinds of different approaches and some of those approaches are good, some not so much. But having better documentation and providing better direction to people about how they should be developed certainly helps but you still have the case where someone develops something and then they just don't have time for it or they move on to a new job and for whatever reason it becomes abandoned. And there are on any of these sites big chunks of what amount to module graveyards full of really sad, neglected, unloved, abandoned code. However, there are ways that you can start to solve the sad abandoned module phenomenon. I personally love what the Fox Public Group is doing that we have at least one member of the group here in the back. I love what they're doing for the puppet community and some cases they have adopted some of these poor neglected sad modules and in other cases they work with owners to proactively move their modules over to the Fox Public Community and some of the top modules now in the puppet community are actually maintained by this group. They're including quite a few of the puppet approved modules like the Archive Module, Collectee, Jera, Confluence, and a few others. And they've also recently become a bit more organized. They have a governance document and an elected project management committee and being part of this group gives module owners a bit more support from a community of people who are working across a whole collection of modules instead of some lone module owner working on their own. And everyone can work together to maintain these existing modules and then build some new ones as well. And they even accepted a poll request from me when I was doing this talk. I did this talk before in Berlin a month or so ago and there was a really annoying typo on the website which I fixed while I was doing research for the presentation. I think many, many projects struggle with how operating system vendors include their software. This, again, is certainly not a problem that is limited to configuration management tools. As users, it's really easy when the software we want is already installed by default on our favorite Linux distro. And when it's not, we too often just apt-get or yum install and anything that we're missing without really spending enough time thinking maybe about the version that we're getting. And this is one of those hard problems to solve because there are so many options. If I'm working on a config management tool, how much time do I have to collaborate with all of the various different Linux distros to help ensure that they're actually using the most up-to-date version in their package repose or shipping an up-to-date version with their distros? And if I spend time talking to them, will they even have the time to make the effort from my software when they have thousands and thousands of packages to think about? And this is, again, one of those scenarios that frankly just doesn't have a perfect solution. But I do think that working closely between the configuration management tools and the operating system vendors, maybe we can improve it a little bit, at least in some situations. So every configuration management and DevOps... Oh, I lied when I said that was my only plug. I had another one for the fact that we're hiring. Every configuration management or DevOps-related conference or meetup that I attend is full of people who are hiring for various operations roles. And the jobs for these hard-to-fill positions of people who have experience actually working within DevOps environments, people who are really awesome at operations but who also understand the value of working collaboratively with developers within these environments. And the people who can automate the crap out of everything while focusing on building a culture of sharing and collaboration with the development teams to make sure that development and operations are actually working closely together as opposed to throwing things over the wall at each other. And I know a lot of people who've been hired at companies based at least in part and based on what they've contributed to the community. So most companies I know hire out of the community. Puppet certainly does this sometimes. Many other companies do as well. I know one person in the room who was hired at a company because of a work he'd done on a puppet module. But not many people have configuration management expertise right now, so it's kind of a great time to be looking for that next gig. Okay, we all know that some upgrades will be more painful than others. Sometimes breaking changes are, frankly, just something we need to tolerate in order to make other things better. But we need to make sure that we're, first of all, correctly using semantic versioning so that our software rely on those version numbers to actually decide whether it's worth the risk of doing an upgrade and maybe how much testing they need to do to make sure that the upgrade isn't going to just wreak havoc with their entire environment. And when we do need to make those breaking changes, like the Puppet 4 example here, and there are many other similar examples, we need to think pretty carefully about how those changes impact the people who are actually using software and what we can do to make the upgrades as easy as possible. In the theme of things that cause pain, it's not uncommon for documentation to be right up there near the top of the list of things that are painful for users. How many of you prefer video, going back to this comment, how many of you prefer video over other forms of documentation? Are there any people in the room who work for vendors who do this to poor operations people? Because don't. Documentation is one of these things that no matter how much time you spend on it can almost always be better. And sadly, sadly, sadly, a lot of projects don't spend nearly enough time focused on making sure the documentation is actually correct, complete, most importantly, actually up to date. And I do think this is something that they did pretty well at Puppet during the time that I was there. But I also know that there were quite a few people devoted to doing documentation. And the docs were in a GitHub repo so anyone could contribute, so they did make it easy also to update the documentation. And it's not a small task. I mean, looking at how many people Puppet had focused on it, but it's something that projects do need to have some focus on. And so here's how I think about documentation. This is just my personal philosophy on it. If I can document something once, then when I get those repeat questions on the mailing list or wherever else, and I can just point people to the answer instead of me and countless others spending hours and hours and hours answering the exact same questions over and over and over, which frankly is dull. But documentation is really how you scale community, and I think that's important to think about. I did mention empathy quite a few times throughout this presentation because I think it's one of the keys to having an amazing community full of people who are welcoming and helpful. This quote was actually the second half of a quote from a few slides ago about maintainers breaking things for your users when abusing semantic versioning. But I wanted to spin this out into a positive since I do tend to see quite a bit of empathy within this community. I see tweets and blog posts from maintainers who are frankly just heartbroken that they made some mistake that caused really painful experiences for their users. And not all, granted, not all maintainers feel this way, but I think a lot of them are really empathetic when it comes to their users. And, you know, on the other hand we also need to be really careful as users of the software, right, to make sure that we're actually showing empathy for these maintainers, some of whom are doing this on their free time. And DevOps really is sort of all about empathy. I think that when ops and devs can actually see things from the other's perspective and work well together, then that's how we all win. This image up here is a Twitter exchange between Luke Kniece, founder of Puppet and Mark Burgess, founder of CF Engine. And this is when Luke announced that he was stepping down as the CEO of Puppet. And Mark wished him well and Luke responded with some sort of admiration for Mark. And I wanted to actually end the presentation on this note. So this is one of my favorite things about the community. While leaders in other communities sometimes tend to focus on tearing the competition down, there are so many examples like this one of the leaders within the configuration management space supporting each other and helping each other. Which I think is pretty cool because the reality is the leaders really set the tone for how people participate in your community. When you have leaders who are actually supportive and gracious towards each other, it becomes more likely that people in your community will adopt similar behaviors. And I've said before and I certainly mean it that the Puppet community is honestly really the nicest community of people that I've had the pleasure of being community manager for. And I've done this for a bunch of communities. But I think that leaders setting the example for how people should behave is really a big part of why the configuration management community is such a great place to participate. Thank you. Questions? So I know I'm between you and Bear, but there's always one question, so I will stand here and stare awkwardly into someone answers or asks one.