Community management in open source

Dawn (00:05): One of the things that I encourage people to think about when they're thinking about open source projects and contributions to open source projects is to think about if I was releasing this as a product within a company, what would I need?

Marc (00:19): This season, Andy and Marc are back with a fantastic group of guests.

Andy (00:26): I bet the depths remain classified. And Marc keeps his head in the clouds. With our combined experience in the industry, we can go from the bare metal to the boardroom. Enjoy your time in the DevOps Sauna.

Marc (00:45): Okay, we are back in the sauna. I'm super excited to have Dr. Dawn Foster, Director of Data Science for the CHAOSS Project on the OpenUK board, and CNCF tag, contributor, strategy, co-chair. Hello, Dawn.

Dawn (01:03): Hello, thanks for having me on the podcast. 

Marc (01:06): Super cool to have you here. We've had a wonderful time warming up. I've got my cohort as usual, Mr. Andy Allred.

Andy (01:14): Hello, hello. Good to be here as always.

Marc (01:17): Excellent. We're on holiday here in Finland, and I can't wait to get this one out to you. Dr. Dawn, it was really nice to have this connection together. In the season, we've been looking a lot at the people behind open source and how they get involved. And there's something really special, I think, about people like you where you not only are able to contribute as a direct contributor, you also contribute to open source projects, you help make them greater. And you also get out there and do things like this and talk about it. So could you talk a little bit about how did you get into open source? And what kind of work is it that you're doing in all of these projects?

Dawn (01:59): Yeah, absolutely. So I have been working in open source for well over 20 years. So I've been in the space for a very long time. I started my career right out of university with my brand-new computer science degree. And I became a system administrator for a manufacturing company in Ohio, where I administered a whole bunch of Unix boxes. And then I did a few other random things at that company. And then in 2000, I ended up at Intel. And at the time, I don't know how many of you remember Intel back in 2000. But the Itanium processor was where it was at. And so that was a brand-new 64-bit processor, which meant that everybody had to rewrite all of the software to be native 64-bit, the 32-bit stuff didn't run on Itanium. So they needed to work with software companies and open source projects to rewrite their software to be 64-bit native. And they looked at me and they were like, hey, you did Unix. It's kind of like Linux. And you know what open source is, which was more than what a lot of people knew back in 2000. So they looked at me and they were like, well, we want you to figure out which open source projects specifically in the kind of Linux developer tools and open source developer tools space, which ones are likely to be strategic for Intel over time. So which compilers are going to be important, which developer tools are going to be important, and help us figure that out. So that we can work with those communities and with those companies to support this new Itanium processor that we're working on. Fast forward, Itanium went nowhere. It was not a success, but it got me started in open source. And a big part of this evaluation for which ones were going to be strategic for us over time was looking at the communities. So were they healthy? Were they vibrant? Were they cutting releases on a regular basis? And stuff going on in these communities. And I got more and more fascinated by how these open source communities operated. Because there is the sort of hidden structure in a lot of these open source communities. And this was back before we had kind of robust ways of defining governance and things like that. So it was a little bit ad hoc and informal. And I just got more and more fascinated by it. And I managed to turn that into a full-time career so that I was in various Director of Community positions at some open source companies, including Camaiore if anyone remembers them, and Jive Software, we had some open source stuff there. And I did some consulting for a few years and I ended up back at Intel and I ended up being the community manager for some mobile open source operating systems. So some open source projects like MeeGo, and then Thai Zen before shifting back to, I went to Puppet to be their director of community a few years later and so that was kind of getting me back to my sysadmin roots and so that was interesting and a lot of fun. And then I took a little break for my midlife crisis. I decided that I was going to go back to school and get a PhD. So I packed a couple of suitcases. I moved to London in 2015, got a PhD, met a boy, decided to stay. And so I got a job at Pivotal which turned into a job at VMware. And so, I most recently was Director of Open Source Community Strategy within VMware’s open source program office before just recently shifting gears and becoming the Director of Data Science for the CHAOSS project. So I get to do things that are a bit more technical, a bit more metrics focused, which I'm pretty excited about. That was a long introduction. Sorry.

Marc (05:21): That was a wonderful introduction. It's so funny. We talked about how small the circles are. And you mentioned MeeGo, the only MeeGo device that was ever released was Nokia N9, I worked on the project from beginning to end. The only reason that came out actually was because it was cancelled because Nokia kept bumbling up the thing and the partnership with Nokia and Intel, I was there at the time. So it's really cool to have this little bit kind of have you bring it back to me today. That's really neat.

Dawn (05:51): Yeah, it was a really interesting space, actually. Sorry, I'm just going to diverge for a second because yeah, Nokia, we knew that they were going to make some sort of announcement and that it was going to affect MeeGo and they wouldn't tell us what it was. And they were going to do it at like 9 a.m. Finland time. I lived in Portland at the time, it was like 3 a.m. for me. So I get up like at 2:30, sit down. I've got IRC open in one window and I've got another document, which was an Intel like internal PR document that was like, if Nokia announces this, then this is what Intel is going to do next, if Nokia announces this, this is what Intel is going to do next. And there's this gigantic flowchart because we didn't know what they were going to say. And it turns out that they were going all in on Windows, and basically effectively killing the MeeGo project. So that was a really bad night for me. I spent a lot of time talking people down on IRC for hours and hours in the middle of what should have been my nighttime.

Marc (06:47): We're going to have to go here. So one of the fun facts, the operating system that was actually the Nokia side of MeeGo, N9 that came out was actually the third intended hardware. But Nokia pushed it so badly that like I said, the only reason that N9 came out was because it was cancelled, and then the company that I founded with a few other guys just after, called Jolla, it took us six months from concept to delivery to do the next one, the Jolla phone. And we renamed it as Sailfish OS, which was mostly open source. I don't know what the lesson is here, let's see if we can find it. But Nokia had built seven or eight open source mobile devices, hardware and software, based upon that open software stack. So we got really good at keeping the software open. I had used open-source software before, but I didn't really understand. I'll use the word passion, but it's way deeper than that, that those open source guys that came to work on this stuff at Nokia had. If they smelled anything like DRM. I don't even remember what all the other things in the minefield were, they would absolutely have a fit. So we got really good at keeping this code open, upstreaming things and working within all of the legal and compliance things. And then when we went together with Intel, it was exceptionally difficult to get any code shared back. It was the legal parts, I think, because there were some kinds of things, it was really, really difficult in those days to have two way sharing of code, preferably through upstreaming patches into open source projects. I don't know if you remember any of that stuff.

Dawn (08:31): Yeah, it was a really difficult project to work on, to be honest. Technically it was a Linux Foundation project, but it was really Intel and Nokia working together on it. We never got to the point where it was quite as open as it was intended to be. It was a really difficult project to work on. But on the one hand, like yes, it was difficult, but I really loved it because I met so many really amazing people who worked on that project. And so, it was a really interesting community and just loads of really fascinating people. And it's fun to run into them again, like there are some people that I regularly run into at various conferences. And so, it's just fun to see those people again because it was just an incredible community. And it was a real shame that we weren't able to make it successful.

Marc (09:20): There's one more thing that I'd like to try here with you. So after MeeGo and Tyson project, it didn't really have a flagship device, if I remember right. And one of the things that I noticed was some of the generic professional software people went to work for some different companies in Finland here and then a bunch of the open-source people stayed with Intel. They opened the site in Tampere, Finland and stayed there, but what I noticed was the people that were pushed like crazy to get products out in the product companies seemed to be a lot happier than those that stayed behind and worked on open source and essentially had a sponsor, and were able to work on whatever they wished as long as it generally contributed. Because I know one of the things that you do is you help a lot with understanding the maintainers and contributors and how sustainable open source projects are. But like, does the link towards a product have an influence on the attractiveness or how happy the contributors and maintainers are in an open-source project?

Dawn (10:32): That's a good question. To be honest, I'm not sure if there's a link there. On the one hand, I think there are a lot of open source projects in particular areas within the ecosystem that have become successful because companies basically paid loads of employees to work on them. So I think the Linux Kernel has been more successful because loads of people have been paid to work on it. I think the CNCF ecosystem is in that space as well, where lots of the technology companies have paid people to work on open source. So from that standpoint, I think it's one of the things that's made a lot of these open source projects maybe more successful than they would have been on their own. As far as the link back to product that's kind of interesting because I've seen it go both ways. So on the one hand, some people are happier working in that space because you can really see the stuff that you've worked on, and some sense of accomplishment. I worked on this open source thing, and look, now you can see it, and it's in this device, it's in the software package, it's in this thing. But on the other hand, I've also seen people working on the product side who weren't nearly as happy as the people that are working more generally in open source because there's often this friction between what the company wants and what the community wants. And what you need to do as an individual. And it creates this tension. And especially with companies that maybe aren't as savvy around open source, and they don't really understand that they can't just push whatever feature they want into open source just because someone's written it, you just write a feature and just push it into open source and have it automatically be accepted, you need to write it in certain ways, you need to build a space for this type of thing that you want to build in this community, have people understand where it's coming from, have it be something that the community actually wants. And so, a lot of those people end up not being very happy working on the product side because there's all of this tension between the company and the community. And that individual gets smashed in the middle of that. And it creates this real tension and this real lack of job satisfaction.

Andy (12:32): You've mentioned quite a lot about the community and different aspects of community and whatnot. And then there's also the open source projects that are maintained by one guy tirelessly in Nebraska, that everything leans on is the meme. How do you actually understand when you look at an open source project, what kind of community it is? Is there any way to measure the strength of a community?

Dawn (12:57): That's the million-dollar question right there. Yes and no, it depends is the answer to that question. You can look at the community and there are certain indicators. But the important thing to realize when you start looking at these communities is that they're all different. And what works for one community won't necessarily work for another. I'm frequently in the position, especially at VMware, of looking at open source communities and trying to give product teams an idea of whether or not they should actually embrace an open source project, or maybe they should pick something else, and a few things go into that. Is it a single maintainer project? We probably shouldn't rely too heavily on that because what happens when that person wins a lottery, what happens when they get thrown in jail, which happened with an open source project not that long ago, where the sole maintainer was in jail, and no one could update the project. So those things are not good. I also tend to look at contributors and how many contributors come from different companies. So if all of the contributors come from a single company, especially a small startup company, and what happens when that company runs out of funding, goes out of business, ships in another direction, changes the license. What happens when some of that stuff happens? And it's more likely to happen in projects that are tightly controlled by a single vendor. So that's something else that I look at. And then beyond the community, there's other stuff. So running like the OSSF scorecard. Do they leave critical vulnerabilities open for months and months and months? Maybe that's not a great project to adopt. So there are this whole set of things that I would look at and is there a big pile of open issues and pull requests that nobody's dealing with? In which case, maybe they aren't doing a good job of keeping up with the project? Maybe they don't have enough maintainers or contributors? Are they cutting regular releases? So when they fix bugs or security vulnerabilities, do those land in a release that someone can pick it up relatively quickly? So these are all kinds of things that I look at that some of them are more directly related to community, some are little bit less related to community, but it depends. And then if I work for a company like VMware, and I'm looking at building a product on top of this technology, then I want something to be robust and have multiple maintainers and multiple companies working on it. On the other hand, if it's just this little library that I'm using, that I could easily replace with something else, and it's maintained by a single maintainer, maybe I don't care as much about that. So it depends on the type of project it is, the type of community it is, what I want to use it for. It's complicated, I guess, is the short answer to that.

Andy (15:33): Marc and I work as consultants, so most of the time, or basically all the time, the right answer is always it depends. And the tricky bit is knowing it depends on what. At least you've got like a list of highlighted questions that you can like, okay, let's start with this and see where it goes from there. 

Dawn (15:53): Yeah, exactly.

Marc (15:54): So as this is recorded, and as this podcast will be published, you are in transition from VMware to the Director of Data Science for the CHAOSS project, would you like to tell a little bit about the mission? And then maybe how you got involved and how the position is opened up? And these kinds of things.

Dawn (16:19): Yeah, absolutely. I've been involved in in the CHAOSS project. And so, the CHAOSS project has only been around for a few years, but some of the tools that were adopted into the CHAOSS project have been around much longer. And so, I've been working in that space for about 10 years. And I've been a heavy user of some of the CHAOSS metrics, tools. So I've been around that community for a pretty long time. And I did eventually end up on the board of the CHAOSS project. And a while ago, Matt Germonprez came up to me as a board member, just someone who does a lot of metrics and said, hey, we're thinking that maybe we need more of a data science-based approach to the CHAOSS project, and rather than just letting people use the tools and the metrics definitions, maybe we work with people and provide a bit more context and help them interpret the metrics and help them learn more about how to generate real insights from the data. And so then we spent so much time talking about like, yeah, we need like this Director of Data Science, and this is what this person should do. And this is maybe where this position should go. And we spent a bunch of time talking about it. And I was really excited, because I was like, yeah, the project really needs this. And then I woke up the next morning, and I was like, wow, I actually want to do that. It hadn't occurred to me when I was talking to him at first that there was even something I wanted to do. I was just like, yeah, we really need this. The next day, I was like, wow, maybe I could even do that. And I did start talking to him about it. And we worked out on a grant proposal. So the position that I'm in now is Director of Data Science for CHAOSS is generously funded by the Alfred P. Sloan Foundation. So we were able to get a grant to fund this for the next three years to help us move the project from what I will affectionately call counting lots of things. So numbers of commits, numbers of pull requests, things like that, to taking all of that, and using more data science-based approaches to actually generate some real interesting insights based on the data that people have. And helping people use the tools that we have within the CHAOSS project. One of the things that we haven't done a good job of, and I think it's not necessarily data science specific, but it's probably where I'll start focusing on initially as I start the job is doing a better job of positioning these two because we have two fundamentally different tools within the CHAOSS project, we have the GrimoireLab technologies, which are based on elastic search/open search and kind of a fork out of cabana. It has those types of dashboards. And then the other one is a tool called Augur, which is a Postgres database on the back end, the front end, they're just in the process of rewriting that as well. But they're very different technologies, they serve very different purposes. And we haven't done a very good job of helping people understand which tool they should pick. We're just like here have a tool without a lot of context of which tools might be better for certain people. So the GrimoireLab technology in particular is fabulous for community managers because there's loads of things, you can dig into it, you can customize your own queries right within the interface. Even if you can't write Postgres queries on the back end, like you could with Augur. Augur is a little bit different. They have network analysis, like Network Science, data sciency stuff built in. Augur lab has been also building in some more machine learning approaches. So they're both very different technologies. And so I think I need to spend more time with each of the teams and figure out how we position them against each other so that people can pick the tool that's going to work best for them. And then the other piece that I'm going to be focusing on really is working to better feed the stuff that we learn when defining the metrics. And when having discussions with people from open source program offices, things like that, feed some of that back into the software in a way that's a bit more organized because we haven't done a good job of that as well within the CHAOSS project. So doing a better job of making sure that the software meets the needs of the people who are using it and working on the metrics, and then doing all of this and using more -- 

Marc (20:28): Sounds a little like DevOps. 

Dawn (20:29): Yes. It's actually kind of a lot like DevOps, to be honest. Like DevOps, it's all about the people and understanding what's going on within these communities. So it's a pretty fascinating space. And you can tell I'm super excited about this. This is kind of my dream job; I'm not going to lie. I get to play with data all day. And I'm really, really excited.

Marc (20:52): Yeah, about this joke that I made in the middle of sounds like DevOps. Because you're doing data science in order to help people engage with open source projects, is there a difference in the kind of DevOps that you will be capable of doing? Or the DevOps that you may be enabling for other companies or people that are working in open source projects? Or is there a difference for DevOps in an open source project versus one that is proprietary or something like that? Is there something here that you could open up?

Dawn (21:26): Fair question, I hadn't really thought about all of this and the context of DevOps. I think that there are definitely some things we can learn from the DevOps movement, as it comes to doing this work. So one of the things that yes, I guess, I went to lots of DevOps days that were organized a few, I did a lot of DevOps stuff when I worked at Puppet back in 2012, through, I guess, 2014 or so. One of the things that I thought was really important out of the DevOps movement was really that at the end of the day, it was really a lot about collaboration, and putting the systems in place for people to collaborate together, to collaborate instead of throwing things over the wall at each other. And I feel like a lot of what made DevOps successful was really getting the right people talking to each other and working together in a way that wasn't just like I said, throwing things over the wall at each other. And I think that this learning, I think, is going to be really important for the CHAOSS project as a whole because we have teams of people who are just working on the software, we have other people who are running working groups talking to open source program offices about what they need. And we have people that are developing metrics definitions for things that they think are important. And we haven't done a great job of getting all of those people collaborating together in a way that we're all learning from each other, and we're feeding things back from those working groups back into the software and back into the metrics definitions. And so, I think what we learned about collaboration from DevOps, I think will be really useful in this particular position. That wasn't exactly your question, but that's my answer.

Andy (23:05): We'll take it. It's always fun. Pretty much every customer I go into at least it's like DevOps for something and it starts with well, DevOps isn't actually a thing that you can just buy and install. Well, but I have budget share for DevOps. Okay. Yes, we can give you DevOps.

Marc (23:24): How much would you like? We're happy to sell you. 

Andy (23:27): Yeah, but then it's always a question of you have all these teams, this group of humans over here is doing this. And that group of humans over there is trying to do that, can we just get them to cooperate? Sometimes it's a tool, sometimes it's a policy, sometimes it's a tweak to what they're already doing. But it's all about getting humans to work with humans, and just collaborate and cooperate. 

Dawn (23:47): Yeah, for sure. 

Andy (23:49): It's always fun for me when that comes down to a tech tool because those are easier for me to deal with than some of the other organizational issues we sometimes find. But it's always about collaboration. 

Marc (24:03): All right. Are you in Scandinavia this autumn? Well, if you're not, you ought to be because the world's greatest DevOps conference is coming to Stockholm and Copenhagen. I'll leave a link for you in the show notes. Now, back to the show.

Marc (24:25): Dawn, when you were talking about CHAOSS, you said tools for community managers, and I was one of the phrases that you used then, and I was wondering what kind of use cases can you kind of describe? I've known and loved a lot of open-source community manager yourself over the years. So what cases are there that these people could come in and come to CHAOSS to get help with?

Dawn (24:48): Yeah, absolutely. I think one of the things that's really important for community managers is to really deeply understand who is doing what within your community and where. It's really easy as a community manager to just lose track of things. So you don't necessarily see that someone is up and coming and look at all the cool stuff that they're doing because you didn't notice it. So there are loads of metrics you can use. And one of the reasons I say that some of these tools are really great for community managers is because, as a community manager, you don't necessarily know what you need to look for. But you need to be able to look across the community and see what's happening. And so, you need to be able to surface things that you didn't necessarily know you were looking for. And so this is one of the reasons that I say that, in particular, the GrimoireLab tools are particularly interesting for community managers because they have a million graphs, their dashboard is incredibly complicated in a lot of ways because it has almost everything you might want to look at. And then you can cut it in different ways, you can filter things out, you can pull things in, and it's really super flexible. So I think that's important for community managers because you can look at it that way. You can look at it based on like core contributors, regular contributors, occasional contributors, and make sure that you're growing the right types of contributors within your project, that you have enough people that you could sustain it that you're not in decline, like overall trends, I think are important for community managers to look at. But the real power and a lot of these dashboards is that you really can look at what the people are doing, which I think is really important. It's important to be able to pull people up right into leadership positions within these communities. And if you notice that all of a sudden somebody's writing a bunch of really great reviews on pull requests, maybe you start talking to them about whether or not they'd like to become a maintainer or do more reviews, or move into a leadership position within the project. And so having access to some additional data can help you make those decisions as a community manager.

Marc (26:52): You've got me thinking it's quite interesting. So if I think of open source community, the first thing that comes to mind is obviously direct contributions of code pull requests. But then we've got people, like you said, that are doing the review. We've got people that are testing and filing bugs, are there other types of contribution within open-source projects that people might not necessarily think of? Or understand that I'm a part of the community, but I'm a lurker, but maybe I still contribute like this or that?

Dawn (27:20): Yeah, there are so many of those. One of the things that I encourage people to think about when they're thinking about open source projects, and contributions to open source projects is to think about if I was releasing this as a product within a company, what would I need, you need documentation, right? You need you need marketing, or otherwise, people aren't even going to know that it exists. And marketing in whatever format, whether that's DEPRA or some other thing, you need to be able to manage the release processes. And a lot of times, that's one of those invisible thankless tasks. There are people working tirelessly to get releases out, and that it's something that people don't necessarily see or notice. Same thing with test infrastructure, you need people who manage that test infrastructure and make sure that it's all working, the right tests are being run in an automated fashion, you need people managing the communities. So you need the people looking after the other people, translation, localization, there's all of this stuff that you need around these open source projects that people don't necessarily think of. And what I see happening is that I think maintainers don't realize how much time they're spending on some of these other things. And if they can free up some of their time by bringing in somebody who can help with community management and documentation, for example, or community management and marketing, if they can bring in some people who can help them with some of these other things, that frees up more of their time to review pull requests and merge things and do other tasks that they might be more interested in doing as a maintainer.

Marc (28:56): I think it's really fantastic that you listed so many of those out there, and then you end with. Because oftentimes, the maintainer may think that all of that burden is on them, when instead of even some of these things, there are people out there who like to build and release software. I'm one of those guys. So it's like there are people out there that can help offload a huge amount of those things so that the maintainer can make sure that the quality of the releases is what they're actually looking for.

Dawn (29:23): Yeah, absolutely. People just don't realize how much of their time is spent on some of these other community manager tasks, the marketing, some of these other things, they don't necessarily think about that. 

Andy (29:34): It always comes back to that.

Dawn (29:36): You really can free up some time by pulling in some other people to help with things. 

Marc (29:40): How big does an open source project need to be in order to have a -- I'm going to say dedicated, but sometimes it's still partial, but at least a named Community Manager.

Dawn (29:51): Well, as we said earlier, like many things, it depends. It depends on a lot of things. I'm going to diverge for a minute and then come back to that question. One of the things that I have found most fascinating about being an open-source community manager, because I was a community manager for many years now I do mostly community strategy. So I mentor other community managers. But as a community manager for loads of projects, what I did in each of those projects was always completely different based on what that community needed. When I'm coming into a new community that I haven't already been participating in as a community manager hired by a company, I spend my first month or so just talking to people and figuring out what's going on. Everyone I talked to that worked at Puppet and the Puppet community was like, the biggest barrier is our contributor license agreement because that was implemented outside of GitHub in a completely different system with no tie back to GitHub IDs. So we couldn't tell when someone submitted a pull request, whether they find the contributor license agreement or not. And it was like this investigative thing that these developers were having to do. And as a result, it just took forever to merge pull requests for people because of this barrier. So I spent my first few months at Puppet and this was before we had things like CLA bots built into GitHub. I worked with a developer and we wrote a CLA bot and we migrated everything out of this old system and put it into something that we could actually use within GitHub. And that's not something you think of as a community manager, but that was the biggest barrier to getting anything done in the community. It was a stupid implementation of this Cantura license agreement. And so, I spent a whole bunch of time working on that. And then as a result of that, I found other things to work on and figured out what needed to happen within that community. When I was at Intel, I managed the community manager team. And so, I managed the community for MeeGo jointly with Kim Gel. And within my team, I had another community manager Jeffrey Ozer Mixon, who worked on the Yocto project. And day to day, we worked on the same team, we were both community managers, what we did on a day-to-day basis was wildly different. The things we worked on were completely different because what they needed in the Yocto community was different than what we needed in the MeeGo community. So coming back to your original question, when do you need a community manager? It depends on what's going on within your project. And it depends on that community manager and what their skill set is and what else they can do. So if there's a bunch of stuff that needs to happen in your community, and you have someone who could do community management and marketing and documentation, for example, then maybe you bring someone in earlier to do that because you found someone who is familiar with the community and the technology who can help with all of these things because the danger is, and I got into the situation with Jive Software, frankly, where they brought me in to be the full-time Community Manager for both an open source community. And then there was some proprietary stuff that I was also community managing. And I did that for a year, I built a brand-new community, I did a bunch of stuff for the open-source community. And then I frankly ran out of things to do. And they hired me too early, I was employee 50 at the company, so it was a startup. And with the stuff that they needed to do in the community, it just never quite materialized into something that was a full-time job. So I bootstrapped a bunch of stuff and then ran out of things to do. So the danger in bringing that Community Manager in too early, especially if it's a company and open source project is that they may not have enough to do. So yes, it depends.

Marc (33:34): So I always ask people in interviews anyway about their hobbies, and I saw a SciFi there. Anything you'd like to share about your interest in SciFi? Like, what are you reading? Or what are you into? Would love to hear.

Dawn (33:48): Yeah, absolutely. So I read probably more SciFi than I watch just because I tend to read a lot, but one of my all-time favorites is Hugh Howey, the Wool series, which is dystopian science fiction, and Apple TV just made it into a program called the Silo series. So it's Hugh Howey Wall, the book is wall. The show on Apple TV is a Silo series and it is absolutely fantastic. I absolutely love it. So that's something that I really like. I recently just went back and read all 17 books of the Dresden Files. And I really enjoyed that because he started this quirky guy that makes all kinds of mistakes since last more, I guess that's more fantasy kind of science fiction or fantasy. I really liked that. What else have I read recently? So many. It's hard to remember. One show that I did really like that I watched on television was called For all Mankind, which is sort of an alternate history of like, what happened if the Americans hadn't made it to the moon first, and that show was absolutely fascinating. I really love that alternate history. What would have happened if this one pivotal event had been different. I really enjoy that. And I've also been reading Charles Stross. He just released a new book in the Laundry Files, Season of Skulls, I think is what it's called. So that's what I'm reading right this minute. Anything by Charles Stross is generally pretty good.

Marc (35:17): Fantastic. All right. Dawn, it's been really great to have you on here. It's neat to share a little bit of history. And you even mentioned one of my favorite community managers ever Kim Gill, what a guy he was in our collaboration, it's neat that you call out your counterpart across the water. And that's what community is all about. We have two further questions that we ask everybody that comes on the podcast, just to get a little bit more on the personal side. So my question is, when's the last time you tried something new? And what was it?

Dawn (35:55): That's interesting question. This is not tech related at all, but I really like pickles. And I like pickled vegetables especially. And I recently decided to try just like doing these quick ones in the refrigerator. And what I realized is that it's crazy easy, it's like some salt and some vinegar, and you throw some cucumbers, or some snap peas or something in it, you shake them up and leave them sit for a day, and then you have like fresh pickles. I've been having fresh pickles all the time. The other thing we're doing is a sourdough starter, which we didn't do during the pandemic. We just started one. Ours is named Bob after the skull in the Dresden Files because he's this weird like spirit creature who's super helpful. So we named our sourdough starter Bob. So that's also something new. To be honest, my partner's been doing all of the work with the sourdough starter because that's a lot of work. I like easy pickles. And he's doing the real work with sourdough starter.

Marc (36:54): I'm hugely inspired by the pickles. That's great.

Andy (36:56): I always have a jar full of pickled red onions in the fridge that goes on salads and sandwiches and everything. And my family is convinced it's a whole lot of work. And I'm just slaving away to kind of have these ready for him. But it's like three minutes, slice, slice, work done, next.

Dawn (37:15): Yeah, exactly. It's so easy. And they're so delicious. It's the best.

Andy (37:20): And my last question is, what's the last thing that really excited you?

Dawn (37:25): That really excited me? So we just recently bought a new house. We moved in November. So one of the things that's been super exciting to me is, so you can't see it. But I look out from my office into our back garden. And it's always my favorite part of living in a new place is the first year it's just like, look, I have daffodils. And then a month later, look, I have forget-me-nots. And now it's like, look, I have puppies that are enormous ones. That's been pretty exciting. And we've also been really coordinating the squirrels within our backyard. So we have a little tiny squirrel sized picnic table that we put peanuts on. And the squirrels sit on this picnic table like a person. And they pick the peanuts up from the picnic table, and they sit there and eat them on the little bench. They sit on the little bench and they reach up and then they just sit there and eat the peanuts off their little picnic table. And that's super exciting. So I guess I get excited about like food and my backyard.

Andy (38:28): That's awesome. 

Marc (38:30): And I have to say, this is really great. We just bought a little farmhouse and a little farm and I'm absolutely going to try both of your suggestions, Dawn. We'll have pickles and a little picnic table for the squirrels. They're living in our belfry it seems.

Dawn (38:46): Yeah, they're super cute. Yeah, we have videos of the squirrels eating the peanuts. It's pretty adorable.

Marc (38:53): Awesome. We'll leave a link for you in the show notes. Okay. Thank you so much Dr. Dawn Foster for joining us today.

Dawn (39:03): Yeah. Thanks for having me.

Andy (39:04): Thanks. It's been great. Really glad you came, Dawn.

Dawn (39:07): Yeah. Thanks. This has been a lot of fun.

Marc (39:08): All right. And that's all for now. We'll see you next time. Before we go, let's give our guests an opportunity to introduce themselves and tell you a little bit about who we are.

Dawn (39:23): I'm Dawn Foster, director of data science for the CHAOSS project. I'm on the board of OpenUK and I'm co-chair for the CNCF tag contributor strategy.

Marc (39:34): My name is Marc Dillon. I'm a lead consultant in the transformation business at Eficode.

Andy (39:39): My name is Andy Allred and I'm doing platform engineering at Eficode.

Marc (39:43): Thank you for listening. If you enjoyed what you heard, please like and subscribe. It means the world to us. Also check out our other interesting talks and tune in for our next episode. Take care of yourself and remember what really matters is everything we do with machines is to help humans.