Season 4 — Episode 4

Puppet has been open source since day one and our success has largely been built on community contributions. One could even say that it's part of our DNA. Now the question is where do we take it from here? Puppet CTO Abby Kearns and Chief Architect Chip Childers have a long and storied history with open source. Join us to hear their thoughts on how Puppet will map out the open source roadmap ahead.

 

DISCOVER OPEN SOURCE PUPPET PROJECTS

 

Learn more: 

Transcript

Ben FordHello and welcome to today's episode of the Pulling the Strings podcast, as always powered by Puppet. My name is Ben Ford. I am the ecosystem product manager here at Puppet and I'm really active in the community as @binford2k. We may have talked before, and if so, that's great, I'm glad to have you back here listening to us. So today we're here to talk about Puppet's open source roots, how that's evolved over time and then what the future of open source at Puppet looks like. So as many of you know, Puppet Foundation is built on open source. Luke was selling services on open source Puppet before open source Puppet was even a thing. This was before we had a company and we didn't have a commercial products for years after that. And a lot of the early announcements at Puppet were contributed by people using it. I remember Felix got annoyed that he couldn't distribute files using a simple web server, so he added an HTTP source support to the file resource type and you probably all use it now. And Bryce improved the SSL subsystem. And there's probably lots of other examples like that. And many of our early employees came directly from the Puppet community, where they were used to building things to scratch your own edges with and for Puppet. Even today, most of the contributions to our supported modules come from the community and thank you. Thank you all so much for that. But over the years, open source has changed a lot. Now, instead of open source being the only way we did business, it's instead become kind of foundational to the way we do business. The difference is subtle, but it's really important. I'm joined here today by our CTO, Abbey Kearns and our Chief Architect, Chip Childers, both of whom have long and storied history with open source. Walk us through how important open sourcing means to us here at Puppet and how were you evolving to keep up with open source changes across the whole industry? So Abby and Chip, you both recently worked at the Cloud Foundry Foundation. That's an open source project within the Linux Foundation. So could you share a little bit of your background at open source and kind of your guiding philosophies here?

Abby KearnsI'll go first and then Chip can chime in, although Chip's experience is more relevant than mine because I joined Puppet about two years ago. So prior to joining Puppet, I was the CEO and executive director of Cloud Foundry Foundation, the open source home of Cloud Foundry, and has been pointed out it is the part of the Linux Foundation umbrella. And, you know, I was part of Cloud Foundry for nearly five years, Chip quite a bit longer and it was a really good experience for me as someone that didn't have a ton of experience in pure open source to get the opportunity to really go all the way in with open source.  Being part of and running a foundation, you're really immersed deeply in not just the technology of the project, but also everything that goes around that in terms of ecosystem, community, the products people built based off your project. And it really taught me a lot of both the dynamics of open source and the push pull with commercial downstream products, but also the role community can play in a project in its evolution. And I learned so much being part of Cloud Foundry Foundation, and I have actually applied a lot of those learnings even to the way that I work today, in the way that we work. I skew towards transparency and openness and democratization of access to both the data and the contacts, but also how we participate in the development efforts. And I do think there's a lot of learnings there for everyone. And Chip, I don't want to steal all your thunder.

Chip ChildersWell, I wouldn't necessarily say I have a lot of thunder and, Abby, in all fairness, I was only at the CFF for a little over a year longer than you. And that was simply because there was a little bit of a front end when we helped, you know, get the thing up and running, and then I helped get it to a point of sustainability before heading out. So just for context, everyone, I took took the executive director role on when Abby moved on. And so, yeah, now it's in this great sustaining situation. So but if I rewind to talk about just generally open source youth's contribution and kind of its impacts, you know, across my career trajectory, I'd have to rewind quite a number of years. We've all been using, or many people in technology, if not everyone at this point, has been using open source for a long time. Frankly, I think, you know, most people are using open source if they even have a phone, right? So it's had this massive impact across the technology industry. And you know, my personal experience, not just as a passive consumer really started, you know, ways back. I got involved in a couple of projects at the Apache Software Founation. You know, I'm now a member of the ASF. You know, I still kind of pay attention to what's happening in that organization. I then got employed by the Linux Foundation at the time, the CFF was being bootstrapped. So kind of a long history, going back a bunch of years dealing with not just the hands-on collaboration aspect, which certainly has been a big part of that journey. But I would say, similar to Abby, kind of dealing with the macro challenges and opportunities that are presented in an open source development model, right? So that's really something that I've always found to be both interesting in terms of the, you know, commercial applications, right? If you're a person out there who's managing infrastructure on behalf of a company, that's a commercial application. If you're a team member here at Puppet, where we repackage this open source software and we add additional value to it and we offer it to our customers, that's a commercial use of the open source software. So to me, the intersection in the Venn diagram between commercial value and open source community value has always been a fascinating topic.

Ben FordAgreed and like balancing those two is always it's a hard balancing act. So thanks for giving us that window into how you all approach open source. And honestly, I'm really fascinated to see where the conversation is going to lead us. So let's jump right into it, Abby, you mentioned you use the phrase pure open source, and I'd kind of like to dig into that just a little bit. There are a lot of different models for open source engagement out there. There's like traditional open source, which I think is probably what you mean by pure open source, maybe not, versus like open core was like proprietary extensions to an open source core versus open ecosystem or some people call it closed core, where the engagement focuses on content and tooling around the core product and lots of others. But what I'm curious about is like, what are your thoughts about these different approaches to open source?

Abby KearnsI think they're, you know, as you pointed out, there's a lot of variations of open source under the, you know, we're doing a podcast, but I'm doing air quotes. You know, we talk about open source. There are a lot of different ways open source can be handled, done and managed, and it's entirely dependent on what you want to get out of it. You know, there's everything from a, you know, I've got a single company open source project to a foundation led open source project to to your point, is it open core? Is it, you know, some of it's open, some of it's not. I think there's a lot of different flavors at the end of the day. You know, when I speak to other companies that are considering open source something or have open source part of their product, you know, the question I always ask is what do you want to get out of it? Is it you want more people to contribute to the code? Is it you want to just open up some of the code for people to have access to? Is it to build community? Is it to build ecosystem? Because depending on what you're trying to accomplish, the way you structure both the open source project, the governance around that project, the community, the engagement with that community, even down to the licensing are highly variable depending on what you want your outcome to be. But you have to be intentional about that outcome because open source is a very complicated endeavor. If you want community, you really have to also engage with your community. You have to spend time and you have to be clear on what your expectation is of that community. Community doesn't spring up on its own, and it doesn't sustain itself on its own. And the same with open source. In terms of the project, open core has been obviously gotten a lot of legs. A lot of companies have open core projects and products over the last decade. We're seeing this another shift as more companies are doing less open core and more managed services are managed hosting or SaaS based hosting of open source projects. And I think it's entirely dependent on what the expectation is is there's no right answer for open source, nor is it ever straightforward or easy. And I think those are the expectations you should enter into any open source engagement with, what do I want to get out of it and what am I going to contribute to it?

Ben FordAs somebody who's been involved with a lot of the open source conversations throughout my time here at Puppet, I cannot agree more with what you're saying. One thing that I do think that that's kind of interesting is this like along with what you said about communicating your expectations of community, we also have to be real explicit about like what our commitments to that community are. It's almost like a societal contract in which, you know, there's give and take and you help me out. I'll help you out. And we kind of have to hold up our end of that bargain as well,

Abby KearnsFor sure, and I think that's something we have to constantly relook at. I think that for most companies and this is true here at Puppet is our expectations of open source are evolving. You know, as you pointed out, Puppet really began with open source and 12 years later, we're looking at it again to say, what role does open source play in our future as we think about the innovations and the shifts we're going to make in our technology stack and our product portfolio? What role does open source play in that? And let's get real intentional about that because otherwise what we end up with is kind of a mixed bag of investments that aren't really necessarily good for a community, nor are they necessarily good for the projects.

Chip ChildersOne of the ways that I think it's worth, you know, looking at this subject is to kind of turn it on its head, right? A practitioner who is engaging with us in a particular way. You know that's adopting a project or giving us feedback on a project, you know, their view of the world. And I'm kind of speaking to the audience, right? And maybe, maybe I'm wrong. But, you know, leave a comment. Ben can follow up, right? I think a practitioner is looking for software that's easily accessible, potentially modifiable, and is going to solve a particular practical problem that they have. And, you know, Puppet was fundamentally founded on software that delivered on those three goals. When we look into the future, while while certainly we need to make really thoughtful decisions that ensure that you know, Puppet continues to grow, continues to be really successful with our commercial customers, we also need to be really thoughtful about making sure that we're continuing to deliver on those three promises for the practitioners and that as we offer new software to the open source community, that new software similarly delivers against those three promises, right? Like that it solves practical problems, that it's freely available and that it's, you know, we're open to collaboration with anyone that might choose to take that step. And, you know, in collaboration is everything from raising an issue, sending in a code contribution, participating in helping other users learn how to adopt a tool. So I'm just a big fan of looking at our position as a company with regard to open source through both the lens of our company, but also flipping it around and looking at it through the eyes of an individual in our community and what they're trying to achieve.

Ben FordI'm really glad that you brought up the point about such a broad definition of collaboration because I feel like a lot of people don't really. They have a little bit of imposter syndrome as to where it comes to collaboration, and they don't really understand that just by showing up and just by participating in conversations, helping answer questions, or even just helping clarify or help other people ask questions to to get the help that they need. All of these are ways of collaborating, and we want to support all of those.

Chip ChildersYeah. You know, historically, open source contribution has been measured in, you know, code lines of codes that are that are being contributed to a project, right? In fact, there's this whole kind of open source Project Health metric phenomenon that's occurring where, you know, the number of lines of code is being measured and companies are trying to stack rank, you know, on top of each other. That is all fundamentally nonsense. The main reason that I say it's nonsense is that while the code itself is incredibly important, the pure number of lines of code isn't particularly useful in looking at, you know, in measuring value. And it's also exclusionary when you consider all of the other incredibly important components of a successful, you know, open source adoption, growing in use and growing in value. And so, you know, both Abby and I have spent a lot of time with global 2000 organizations, whether it's in the context of a particular technology that we're working with them on, or whether it's just in the context of helping the reason about what it means to contribute back to the community. And one of the most important things that I've always said is your opinions are the first place you can start, right? But you're using something. And if it works well, congratulating the people who wrote that software is always really useful, giving them constructive feedback. Super useful, right? And then you can continue to increase the contributions and the depth of that contribution towards code based contribution or towards helping with documentation or towards helping with evangelism for a project. There's just so many ways you can actually help in these collaborative environments.

Ben FordYeah, you can't see me right now, but I was nodding my head very, very vigorously for, like the last two minutes straight. So glad to hear all of this. One thing that I find interesting is that as the product manager for Ecosystem, I said a few minutes ago, that most of our contributions are actually coming from the community, like most of the code that goes into the supported modules, most of the ideas. And I think that that's really the important thing right there is that like we're really good authors of Puppet code, we can write really good Puppet code, but the subject matter expertise that says what kind of things you do with a particular module or with a particular technology, those experts are the people actually using it. And so just getting your ideas, just getting back from you to say this is the thing that you really ought to implement or this is how people do it in the field. Those are things that we may not ever know unless you tell us. Chip, a little bit ago you talked about sustainability, and I'm a little bit interested in that and sort of like how we continue to get sort of sustainable benefits from open source. I think there's a little bit of defining what that benefit is and then like, how do we build the process and like build the muscle that keeps that going? So I'm sure that most people are familiar with the societal value of open source. I happen to think and I think both of you do as well, that there's a lot of business value in open source. So let's just kind of throw it out there. What sort of thoughts you have about that?

Abby KearnsI'll go first, I know Chip has some thoughts as well. I would say from a business standpoint, open source can be very valuable, both as a way to accelerate development efforts. It's a great way to accelerate an ecosystem beyond where you exist today. It's a great way to build, particularly if you're early company. It's a great way to build early engagement with a user group and a community. And it's, you know, it's a fantastic way to potentially accelerate the evolution of your product far beyond where you can exist today. There's a lot of great outcomes that open source can deliver to a business. Now, the flip side of that is you've really got to be very specific about what outcomes you would like to obtain, because with every positive, there's obviously a negative that goes with each one of those, those things I just outlined. And I think that for businesses, you have to get very clear on the expectation because there isn't a magic bullet with an open source, it doesn't magically generate a top of funnel. It doesn't magically go viral. It doesn't magically bring along a community, and it doesn't magically build out an ecosystem for you. And you have to really be thoughtful about how you want to build and leverage the experience around open source, both within the company but also externally with your customers, your partners and the broader market as a whole.

Chip ChildersYeah. So +1 to all that right.The question's interesting, Ben, because when we talk about open source, we mean actually about, you know, an incredibly wide variety of actual things, right? And that really spans from code that is written by and shared by an individual person because they wanted to completely disassociated with their employment, could be a hobby project could be, you know, anything, right? Just kind of learning how to code. And GitHub has become kind of the nexus of this just sharing world. Right? I don't even want to call it an economy because a lot of this is just sharing of what you're working on, you know, and trying to get some feedback or just putting it out there because you're putting it out there, right? And I think that that's kind of one end of the spectrum. On the other end of the spectrum, we can go all the way to the extreme of, let's say, the Linux kernel, right? Fundamentally, that is a critical technology that underpins the global economy. And it's because it's everywhere, right? The kernel, the Linux kernel is embedded all throughout devices that we touch, services that we use. And it's also very large. It's very complex with a massive economic ecosystem wrapped around it with commercialization. And you know, all the hardware vendors need to be involved in it. So when we think about this question of sustainability, we're really talking about somewhere in the middle of that spectrum to the extreme of something like at the scale of the Linux kernel, because that's where people begin to rely on that software. You know, I as an individual might publish a library that I found to be particularly interesting. If nobody's using it, it didn't really matter if I sustain it, maintain it, you know, deal with upstream dependencies that I've added to it that may become vulnerable in time or, you know, vulnerabilities may be discovered. But as a project grows in use, it begins to mean something more to the community that uses it than just simply like a point solution that you know, no big deal if it never changes. It starts to underpin things that are being built on top of it. And so the question of sustainability is really complex when you even just look at that, you know, kind of the middle to the large scale of the spectrum because there's also so much variation in how those projects and communities are constructed. Right. So there there's the whole, you know, collaboration of individuals just acting as individuals model where they're just, you know, they're just agreeing to share their collective code under a shared open source license. You've got projects that are stewarded by a, you know, a single vendor. A lot of the Puppet code that we offer to the world essentially follows that model. You've got the charity based foundation model like the Apache Software Foundation and, you know, the Python Software Foundation and a bunch of others, right? And then you have the more trade group style organizations that do a similar thing, right? They'll help support that open collaboration, but they'll also do it by looking at the commercial activity and how do they support the commercial activity around it. So sustainability really matters, and you have to kind of scale the question of sustainability to the type of project that you're talking about.

Ben FordMaybe we could get a little bit more concrete, too. We've talked a lot about community and just benefits as a whole and in a very abstract way. But maybe what does Puppet get out of open source specifically and why do we choose to invest in it? And corollary to that is like, how have those investments shifted over time as the open source ecosystem has grown and evolved?

Abby KearnsI think from my perspective, the open source of Puppet has very much evolved and I've only been here a couple of years. But I do recognize that Puppet has had a long history with open source, but also the engagement around the open source project has changed over time and that's only natural. One of the things we talked a lot about when Chip and I were in an open source software foundation is what are the evolutions of a project? And every project has this same evolution. It goes, it spikes up, there is a lot of engagement, a lot of either community or even contributors and maintainers working on the project, and then as it matures, the technology matures over time, those numbers start to decrease as the project matures, the technology matures and the community around it matures. And then you start to see a decline in in those numbers and that engagement and that happens to every single open source project. And so as I think about that for Puppet, you know, we've seen the same evolution as Puppet Enterprise, particularly a lot of the core open source facets of open source Puppet. We've seen the technology grow and change over time and then mature over time, which is only natural. But as we look towards the future, we've got new open source projects like Bolt and investment in other open source areas that we're going to see a different type of community emerge, a different type of engagement model. And we're going to need to balance that with the investments we make as a company into proprietary projects that go specifically into our new commercial products. And for us, as a company, it's going to be about balancing those concerns. What do we want to invest in open source and why? And what do we want to invest in the proprietary code and why? And how do we want to balance those two from both a product and a technology strategy, but also from a business strategy as a company? And that's something we've, you know, as you know, Ben, we've been talking a lot about internally is what does that look like over time? What is the expectation? What are our investments going to look like and how do we really align those to the investments we want to make as a company, as we look towards the future for what Puppet is going to be going forward.

Chip ChildersYeah. And I'd also, you know, I'd also say it's really important, right? If you're a listener and you're a member of the Puppet community through the use of any of the projects that we publish today. You know our commitment is to is to be explicit, right? So if there's code that's out there that is, you know, in active use that, you know, a lot of people rely on, we want to make sure that it remains available. We also, you know, are looking very carefully at how do we continue to follow that pattern of these really valuable practitioner level tools that will allow us to frankly get feedback and to evolve our approach, you know, our approach commercially. But we're going to be very clear and we want to make sure that we're very clear about our commitment to projects and when we may choose, if we choose, you know, to kind of move on from a project, we want to help the community continue it if it wants to continue it. You know, I want to be clear, though, I'm not projecting that any critical project that the community relies on is something that we're we're looking to back away from. What we're actually saying is there's probably a lot of open source that we've published that maybe isn't being maintained as well and also frankly hasn't been adopted. And we just want to clean that up, right? So we're very clear about the projects that we publish, the projects where we engage with the community. These are things that we care about, we care about that community, we want to see that community be healthy and we just want to be very, very clear about all that.

Ben FordYeah, it's all about communications and setting expectations. I heard somebody say the other day that ambiguity is worse than closed source projects or dead projects or anything. So it's just like communicating what we plan on doing with it. I do want to drop a real quick plug for the Puppet toy chest. It's still early in its evolution, but we are working on a way for people to sort of add projects that we're no longer working on and clearly communicate that so that people in the community can look at these. And if anything strikes their fancy, or if it's something that they feel very passionate about, facilitate the process of adopting it so that even if we're not specifically investing in it, the project itself can continue to live on. And I'll drop a note to that down in the show notes. And maybe we'll even talk about it a little bit more later on. I'll kind of put you on the spot just a little bit here, Abby. There was a Twitter question just a few weeks ago, it was asking very specifically pointed question whether we are considering closing the Puppet source, and Chip kind of talked a little bit about that, but this is very specifically are we considering closing the Puppet source? And I know you answered that thread, but is that something maybe you want to comment here?

Abby KearnsYeah, I was going to give a little bit of a sarcastic answer because I think that once you've opened source something, there really is no such thing as closing that door. Once you open that barn door, it's open and any hopes to do otherwise are usually fraught with challenges, both perception, but also code and contribution wise.

Ben FordIt would be a nightmare to close it, honestly, I'm not even sure it's legally possible at this point.

Abby KearnsI mean, legally, yes. Yes, you can. You can change licensing, but there's just a whole host of other issues. So I'd say, you know, we're not going to close source anything that's open source. And I think that's an avenue I don't personally want to go down. But I'd say the better question is, are we going to continue to invest in open source? And I think Chip really answered it quite nicely, which is absolutely we're going to continue to invest in the open source projects that remain active and in use by our user community and also those many open source projects that remain in use by our products today, but also going in the future. So we'll absolutely continue to invest in those open source projects and support our community around them. But we're going to, as Chip said, be a lot more intentional and explicit about what that looks like. And because things are changing and things are evolving and the onus is going to be on us as a team to really be clear about what our investment is going to look like, what our user community and our community can expect out of that. And then internally, also, what does that look like from an engineering investment standpoint? How do we invest in it as an engineering team? How do we prioritize those investments? And frankly, that's a conversation we should always be having because our projects, the technologies are constantly evolving and we should always be reassessing what we're investing and why and making sure that it makes sense for us as a company, but also balancing that with our needs of our community.

Ben FordYeah, absolutely. And the the question itself was attached to an open source survey that we just put out a little bit ago. And so kind of maybe along those lines, maybe we could talk about that. What, like how is this indicative of how we want to reach our Puppet community and understand their needs and how we can best address them? And I know we don't actually have any data back from it yet, but maybe a little bit about what we were hoping to accomplish with this survey and where we're going from it.

Abby KearnsGreat question. I'm excited about that survey. We're going to have the data next week, so stay tuned. I'm sure we'll publish some blogs about it as well. But I, for me, I really want to get more data on our user community, what our users do, what do they care about? How are they using our projects and our technologies? We have a lot of anecdotes here, but we didn't really have a lot of hard and fast data on what that user community look like. This is something Chip and I know quite well. We've done this. We did this every year when we were at Cloud Foundry. Just to get a sense of who are user community is, what type of companies and industries, but also how they use the technology and the role it played in their organization and what they cared about going forward. And I wanted to apply the same learnings here at Puppet so that we can all have a rich set of data. I mean, if you look at our deployment of Puppet, Puppet has been around for over 12 years and it's in over 80 percent of the global 5000. So 80 percent of the world's largest companies use Puppet in some way. And so for us, it's really about quantifying that and figuring out what people care about and why and being able to say, OK, how do we take this information? Do we invest in different ways in our open source projects and technologies? Do we invest and engage with our community in new and different ways? Are there opportunities for us to show up differently and take feedback and really evolve over time? And so when I look at the research that's really around to largely help us have an informed path forward to engage with our community in the projects better.

Ben FordAs one of the people who regularly brought that anecdotal data back that you mentioned, anecdotal data from the community, I'm really, really excited to hear about this data centric approach to quantifying what our community needs are. Is that something that we're intending on doing regularly? You mentioned that was something you did yearly before, will we continue doing that here?

Abby KearnsYeah, I'd love to first do it annually because, you know, these things change because, you know, our user community changes, what they care about changes every year. They're using our technology in different ways than they were even a couple of years ago. And so I think it would be great if this is something we could do on an annual basis and really use it as an opportunity to connect more deeply with our user community and understand what they care about. Feedback for us. You know, it's always a good time to get feedback and say, Hey, what are we doing? Can we do things differently, better? What do you think? And just give us an honest data set. I think anecdotes are great, Ben, and I love the stories you bring back. But I think it's also great to be able to quantify and say, you know what, 90 percent of our user community care about this thing, or 75 percent of our user community really think this way about our projects. And so I think having a bit more data behind it allows us to make more informed decisions.

Chip ChildersYeah, I think I would add two things. One, we talk a lot about the positives of open source, but there's a negative and the negative is that the creators of that open source, they don't have to be employed by Puppet in our example, right, they could be the people that are contributing to it, you know, along with us. The creators of that project frankly have no idea how it's being used beyond the individual examples of people collaborating with them, giving them feedback. And so the process of using a survey instrument is kind of the best way that you can get a sense of what that user community who is largely anonymous to you, you know, feels, wants, etcetera, so you know, my call to action, I guess for any member of any of our of the project communities that you know, that we we support would be the next time we do that survey, please, please, please respond to it. Because frankly, it's really the most important thing we can do to understand what your consumption looks like, what your usage looks like, what your pain points look like, and that's what helps us invest appropriately in these projects.

Ben FordI had another very pointed question that somebody in the community kind of fed me here and another one of those anecdotal bits, right? Some vendors in our space, they kind of seem to deliberately like impoverish or hobble their open source platform or their ecosystems to make sure that the open source offerings or things that other people build or tooling, etcetera, etcetera, they don't conflict or compete with our own commercial products. And I guess I kind of conflated that a little bit there. But what are your personal thoughts about that practice and how would you describe Puppet's stance on that itself?

Chip ChildersSo I'm going to roll in with a personal opinion first and then maybe Abby can smooth it out with the appropriate Puppet response here. I find that there's a few things. So first, this concept of an open core model where there's some open source code and then you wrap proprietary software around it is really hard to get right and where there's that whole issue of, you know, the community kind of arguing with the company that's sponsoring the project or that's publishing the project. That is to me, it's a failure mode. One of the things that a lot of companies that attempt to do an open core approach to open source run into is the unstoppable process. When a project is adopted and a community is built around it, that community will continue to extend that software. And so if you're a company who's trying to build a business around it and the success of that business is what sustains most of the, you know, most of the engineering effort that's going into that code, you have really two choices. Your first choice is to get upset and try to block things. That never works. But your second choice is to understand that inevitable dynamic and think about commercialization in a different way. Practitioners aren't going to come in and extend software in a way that's going to serve the needs of all the, I don't know, chief information security officers out there right? No, they're building practitioner level tooling. So artificially hobbling software, you know, based on this idea that this like tactical feature is something that you're going to monetize. It's just bad strategy. It's bad community relationship management and it's bad product management. The right approach is to think about what are the incredibly valuable things that you can build that are more solution oriented that make things easier for an enterprise organization. So I've got a very strong opinion about that. You know, I actually love to hear if Abby's got any slightly different opinion there.

Abby KearnsI have the same opinion. I think as a commercial company, we really have one big objective, which is develop products that customers want to buy. Full stop. Now along the way, is there opportunity to build a deeper and richer engagement with the surrounding community and ecosystem? Absolutely. And usually that's part of the journey on driving that revenue growth. But if you're going to use open source to do that, you really have to be thoughtful about what does that look like for you? And taking pieces off and moving things around aren't necessarily great long term strategies or good long term product strategy to think about the way you think about your product, but also your customer. What does your customer want to buy or what do they want to pay for? And so it really becomes this game of chase, even with open core. Open core, I think is a really incredibly hard thing to do well over time, because what works year one for your product, what customers are willing to pay for that is, you know, whether it be a UI or natively integrated service that sits on top of that open source, the value to customers changes really, really quickly. What customers are willing to pay for changes every year. And so open core becomes this race to say, OK, here's what we want to open source. And here's the value in that, but here's what we deliver as a commercial product, and here's the value in that. And OK, we're going to innovate really, really quickly on both fronts in order to deliver value to both constituents, and that becomes a really, really hard, complicated thing to do well. And so companies tend to slide one way or another. And I think you really have to think this through and say, OK, intentionally, what are we trying to accomplish? What is our goal? And let's be very, very dogmatic in that goal, but also very explicit, both with our internal company, our engineers and our product teams, but externally with our community and our customers. And without that transparency and that clarity, it just ends up kind of looking a little bit like, OK, some things are open, some are not. We don't really know. Sometimes we open source things, sometimes we don't. There's just no clarity. And so how you deliver value and how you drive innovation becomes increasingly complex as years pile on and time goes on. And so one of the challenges for any company that has open core is what does that innovation loop look like? What is that value and what is the value open source provides to that? And so I think I tend to even get a little more dogmatic about that than even Chip, because I think it's really, really hard thing to do really, really well. And more companies fail than not.

Ben FordMaybe that's a good segway into a couple of like more tactical practitioner to practitioner sort of ideas and thoughts here. As one of our core members of our own internal open source stewards group, we've had sort of a spotty history about our open source engagement. We've had a lot of our projects had like very excellent engagement and some kind of didn't really seem to get a whole lot of attention and some sort of like wavered in between. And there were some projects that we weren't super great at communicating clearly where they all stood, and that's one of the things that you just brought up now. So the stewards are working on some plans for improving that. But I was wondering if you all had like some thoughts. Maybe we can just like livT recommend some things so that we could do to improve

Chip ChildersSo the first thing that I think we owe our community is to clean up anything that we're not actually actively supporting and they're probably not using. So the things that nobody's using, that we're not actively supporting need to move somewhere so that, you know, maybe it's the toy chest, Ben, but we need to do that so there's no confusion. No, no mixed expectations, right? So let's just let's clean them out. The projects that maybe we're not actively supporting, but they actually do have an active user community. Maybe they even have pending contributions that somebody would like to make. Look, we need to figure out how we just do right by the people that were willing to try our code, use our code, contribute to our code, even if we're not actively using it anymore. So we'll figure out the right path for each one of those, you know, in a collaborative way with those users with that community. And then I think that the other thing. Coming in like, I'm a little over 90 days here at Puppet, right, when I go to the GitHub repos, I know that a lot of effort has been put into trying to help like navigate all of these repositories that we have. But I still think there continues to be room for improvement there, right? Because for those projects where we really do very much want to continue to foster, you know, active community engagement and to find ways to elevate members of the community that might not be employed by Puppet, we need to give really good signposts, right? Like what's the map to go find where the valuable stuff is? And I know so much work has gone into that. It's just I think there's still opportunity to continue to just get even better at it.

Ben FordThat mirrors some of the conversations that we had and I think maybe like the sound bite form of what you said might be just to focus engagement on where contributions are and then just clean up all the rest. Just to be clear about what we're doing.

Abby KearnsI was just going to say one other thing, and I would add in what we're not going to do. And I think that's something we also have to really be clear on so that we don't have these things just lingering out there either.

Chip ChildersYeah, one hundred percent. And you know, I think the other area that's really important to think about is this kind of like the practitioner toolchain related projects. But then, you know, I know Ben very near and dear to your heart rate, there's all that content. There's the Puppet content, some of which we host, some of which community members have created and put out there in their own GitHub repos. You know, we try to bring that together in the Forge. And I know that a lot of work is going into continuing to evolve the Forge as a discovery mechanism for that really rich ecosystem of content. And we can do even more there, right? We can find ways to improve discoverability in the Forge. We can find ways to improve the author experience engaging with the Forge. We can find ways to improve the, you know, the browser. You know, if you downloaded Module X, you might be interested in Modules Y and Z, right? So open source for Puppet isn't just around the practitioner tools, but it's also some of the content that we offer, and it's the content that the community itself offers to the rest of the community.

Ben FordThat seems like a really good place to kind of close this conversation, and I'm curious to know if there like if there are any ways that you'd like to suggest or recommend listeners to get involved or to participate in our open source effort.

Abby KearnsI would say get more involved, take the survey, give us feedback, engage on Slack.

Chip ChildersContribute pull requests, contribute issues. Tell us if you're not getting a response, pop on Slack. I'm there. If you've got an issue or pull requests that sitting there, that just because nobody's noticed it, because maybe it's in one of those repositories that we intend to clean up and, you know, be more explicit about our support on, reach out.

Ben FordAnd I'd also like to go back to that point about like contribution isn't necessarily always about code, but it's like ideas and other kinds of content. If you want to, like, publish a blog or something, there are avenues open for you if you don't have your own personal blog. There's some kind of content that we'll put up on the Puppet.com blog, and we've got a Dev.to engineering blog that we can share, and I'll put the links to all of those in the show notes.

Abby KearnsAnd docs feedback, too, Ben. Docs feedback is a great way, and it's also one of the most crucial pieces of any open source project.

Ben FordAnd I think especially with regards to docs, we get a lot of like very tactical feedback about a particular page, but sometimes helpful feedback is more holistic. Like, I'm trying to learn this particular topic and the way that it flowed didn't make a whole lot of sense. And I don't have feedback about a specific page, but I don't understand what this like trajectory is trying to teach me. All of these are valid and super, super valuable feedback. And I'll throw something else out there kind of put you both on the spot. I don't know if I've mentioned this to to either of you yet, but I'm advocating to do like an AMA style, like a live question and answer for community members with both of you sometime in the new year. So I'm really kind of excited and hoping that I can push that through and make it happen

Abby KearnsLet's do it. Let's make it happen. Ben, let's do it.

Ben FordChip, you mentioned that you are in the Slack and I'm assuming you're you're pretty easily findable as Chip Childers. Do you have like Twitter or anything or any other ways for people to engage with you or just hop into the Slack and look for your name?

Chip ChildersI mean, hop into the Slack. I mean, sure, you can find me on Twitter, but I'm usually just rambling about things there, so you know your mileage may vary. Puppet related stuff hit me up on Slack.

Ben FordI've seen Abby engage with quite a few community members on Twitter. Is that your preferred preferred engagement or do you have other ideas?

Abby KearnsTwitter or Slack, I'm open, or email whatever works for you. I'm available.

Ben FordMaybe I'll even put links to like your Medium blog posts or anything and get some links to all of the Twitter feeds and whatnot in the show notes. Well, I think that's a wrap for today. Thank you both for coming and sharing all your ideas. This is a really great conversation. And honestly, like personally, I'm super engaged and excited and like, reinvigorated even for the future of where we're going with Puppet and our open source engagement here. So let's call that a wrap for today and everybody once again, thank you so much for being here and participating in our in our community here on Pulling the Strings podcasts, powered by Puppet.