Adam Jacob: When I said that I wasn't the only person who wrote Chef, that's very true. Part of the reason I say that is that there's all these people who own Chef. In a very real way, as soon as they put that software in Chef, they own Chef, and it bonds to you in a way that isn't the same as just being a passive consumer of the software. Eric Anderson: This is Contributor, a podcast telling the stories behind the best open source projects and the communities that make them. I'm Eric Anderson. Eric Anderson: All right, we are kicking this off. I am live today with Adam Jacob, of Chef, he's the project creator, and I guess he would be the historical principal contributor. Is that the way to phrase it? Adam Jacob: I've never heard it phrased that way. But yeah, historical principle contributor means I started it in the first place, but then thousands of people have written the code over time. But, yes. Eric Anderson: We hate to not give everybody appropriate credit. Adam Jacob: Yeah, for sure. There was a blank screen and there was me. And that's very real. But yeah, plenty of other people. But yes, I'm the original author of Chef and Habitat too. Eric Anderson: And what's awesome about this show, if we want to call it that, is that we adhere, Adam, about that blank screen. So let's start with that. Take us through the beginning of Chef, how did it all get started? Adam Jacob: Yeah, well, I think in order to understand how Chef got started, I have to tell you a little bit more about me. So I'm, was, I'm really, honestly a systems administrator. That's what my career has been. I came up in that era of ISPs, when there were lots of small ISPs in dentists' offices and all kinds of random locations, that then got consolidated over time. And then as the ISPs consolidated, as the US market became more stable, what you saw was a lot of the folks who ran those ISPs wound up then running the internet companies in that first generation of internet companies. Adam Jacob: And so that whole time I was a systems administrator. And I had worked for the same series of folks for a long time. And to make a long story short, there was a very clear minute where it was obvious that the work that I had done for them over the bulk of a decade just wasn't particularly appreciated as much as I had hoped that it was. And so it was a very pretty day in Seattle. And I called my best friend and former coworker, Nathen Haneysmith and co-founder of Chef as well, and said, "Hey, you know what we should do? We should quit our jobs and go be consultants." He was working for IBM at the time. And he was like, "Yeah, you're right. We should." And I was like, "Great. I will find us someone who pay our bills." And did. Adam Jacob: And so we started a consulting company, it was called HJK. And what we did was sell automated infrastructure to startups. So you pay us a fixed upfront fee and then we would automate everything from provisioning to configuration management, monitoring, trending, identity management, application deployment, all of this stuff, we would automate for you for a fixed fee. And then we would take a retainer to maintain it over time. And the plan was that we would become these hyper efficient consultants and that we would make a bunch of cash on the upfront fees, because we would charge you a lot and we would be really efficient at doing it. That turned out to be true. So the fastest we turned one around was 24 hours from signed contracts to we automated someone's entire business, which was rad. Eric Anderson: And you're reusing code across projects, I guess. Adam Jacob: Well, this we were trying to, yeah. Eric Anderson: Right. Adam Jacob: What happened was, as we got bigger, and we're more successful, and we were, and that was awesome. It turned out that the ongoing maintenance of those customers was a pain. I mean, there were a couple of things. So one was any given person only really cares about their problem. So the way to think about that is if you run a database, and your application works, because you tweak a particular setting on the database, if I can automate the database for you, but I can't tweak that setting, you don't care. You know what I mean? It wasn't useful. Doesn't matter how cool it was, just doesn't have any value. Adam Jacob: And so, every individual customer was quite happy with their automation. Because it was all working for them. But when it came to try to maintain it, or update it or refactor it, they had very little appetite for that because obviously, it didn't necessarily show them a lot of upside. Until we found ourselves in a place where we just weren't getting the economy of scale we needed out of the technology we had built initially, using Puppet and a couple of other things to make that stuff work. And we'd also had just some... There was a moment in that early era of when we were building the systems that like it was a hard minute for the industry. It was the beginning of EC2, we saw the first of the second wave of web companies and the first, like Facebook apps really hit and have massive scales instantaneously. And so there was just a lot going on in the market at that minute. Adam Jacob: And so our decision as a consultant company, and as co-founders was, "Hey, either we can basically wind this thing down, because it's not as much fun as we wanted it to be. Or we could see if we could write something that would be better at solving this problem of being able to maintain all of these different customers' environments from a single place." And my co-founders and friends were like, "Hey, you know what? We'll pay your bills, and take care of all these customers. You go see if you can solve this problem." And so I did. Eric Anderson: Interesting. Adam Jacob: And from there, that's what Chef became. Eric Anderson: So you're still, yeah, I mean, you operated as a group. But you were no longer doing client work. You were doing this project on the side? Adam Jacob: Yeah, that's right. They basically took me off all the client work, and stuck me in just doing nothing but trying to see if I could build a system that would let us manage the, what? Probably 20 or 25 customers that we had better than we had before. And the results of that work was Chef. Eric Anderson: Got it. And was their ambition at that point that this could be bigger than solving your client work? Adam Jacob: Well, sort of. So we'd had a moment where we had met Jesse Robbins, who is the founding CEO of Chef, would become the founding CEO of Chef. Where he had been doing some work with O'Reilly. He'd worked at Amazon for a long time and he was, the master of disaster was his title. And Jesse is a force of nature. For those of you who might not know Jesse, Jesse is an incredibly smart and capable human, who, when we tried to recruit him to our consulting company, he was like, "Man, get out of here. I can be my own consultant. I don't need to hitch my wagon to you guys. But if you come up with a product give me a call." Adam Jacob: And so we came up with this product, I called Jesse, and was like, "Hey, do you want to see this thing I've been building?" And he said, "Yes." And we showed it to him, and he's like, "This is awesome. There's a company here, we should start a company that does this. This should be a software company. And we should go raise venture capital." And I was like, "That sounds great. We should absolutely go and do that. I have no idea how to do that. But let's do that." And also nobody, you're in venture capital, how many systems administrators have you invested in? Who's last title was systems administrator? Eric Anderson: None come to mind. Adam Jacob: One, me. Eric Anderson: Right. There you go. Adam Jacob: Me, I'm it. But that's because of Jesse Robbins. All of that comes together because of those relationships. So it was really Jesse that saw that what we could be is be a software project and that we could really be a company. And it was also Jesse who brought some other really incredible talent to Chef that I think without which, Chef wouldn't be what it was. So Chris Brown, who was one of the original engineers on EC2 and was a very, Chef employee number one, basically number two, maybe, if you don't count every... Number one if you count nobody else who worked at HJK at the time, who had an incredible impact on the technology. So Jesse also opened a lot of doors, not only to venture capital, but also to resources and talent. Eric Anderson: And we should acknowledge here, nothing is open source yet at this point, is that right? Adam Jacob: Well, so we knew that it was going to be. So I'm an open source person. And I was trying to decide if I was going to use the word zealot, or [inaudible 00:08:27]. But we'll just go with an open source person. I believe in open source, not only as a development model, but I'm a free software person. I believe in the idea that software, it's an important thing that software be free and be open. And in particular, I think in infrastructure software, I think it's important that it be free and be open. And so we always knew that we were going to open source it. Adam Jacob: We also knew that there was software in the market already that did similar things to what we did. So there was some barrier to entry there, that just, how good would it be and what would it be? And so our original business model was that we were going to open source all of Chef and then we would run a hosted configuration management service called Hosted Chef cleverly enough. And that would be what people would pay for. We were just way too early. This was 10 years ago, the market was just not at all ready for a hosted configuration management business. They were very ready for Chef, they just weren't ready for a hosted configuration management service. Adam Jacob: Now, I get a lot of shenanigans, where people are like, "Dude, this should be a hosted service that I don't have to pay for." And I'm just like, "God, you jerks. I did this for you, and you just didn't care." Eric Anderson: Where do we go from, so Jesse gets involved, talking to VCs. Take us through the launch. Adam Jacob: Yeah. So I mean, we raised money at a very dark period in the economy. So it was, the market had just crashed and it was pretty bleak. We got turned down a lot. And then we met the folks at DFJ, Bill Bryant, who saw what we were building and believed in us and believed in the idea. So we also found, through the Velocity Conference, that Jesse was co chairing through O'Reilly, we had made some pretty great connections to folks. And so one of the folks that I showed it to was Ezra Zygmuntowicz, who was at Engine Yard at the time, and Ezra was busily building the Engine Yard Cloud. I don't know if anybody remembers the Engine Yard Cloud. But Engine Yard Cloud was a big deal, especially for deploying Ruby on Rails applications to AWS in the early days. Adam Jacob: And he was also thinking in a very similar way to me about what kind of configuration management system they should use to build it. And so I showed him an early Chef demo, and he liked it. And so we spent a week or two with Ezra, building the Engine Yard Cloud to use Chef and what was called chef-solo. So we had some vision of having a Chef server, Ezra didn't need that, because he had a system that already knew how to do it. And so he and I just hung out together and ported the Engine Yard Cloud to Chef before they had launched Engine Yard Cloud and before we had launched Chef. Adam Jacob: And so we had some pretty strong validation that we were onto something before we had ever launched the product. But then we did announce both the company's existence and the product, at the same time. And it was all open source the day we launched, there was no hosted service the day we launched. We launched with an open source product. Eric Anderson: So launched the open source, announced the company funding all on the same day? Adam Jacob: Yep. Eric Anderson: And you had a lot of validation. You had your own clients internally. This was working for you, it's all you need, or at least the consulting firms you need. And then you had sold this one person. Adam Jacob: It was Engine... I mean, Engine Yard's need was pretty big. They bet the whole firm on it. And that was a huge benefit early on when we launched. Certainly I had made a lot of friends in the configuration management community over the years. And so I had showed it to a lot of those folks, and many of them liked it. Some of them didn't. But a lot of them did. And Ezra and Engine Yard's endorsement went a long way into making it real for people. And was also, it didn't hurt that it was written in Ruby, and that the DSL was just Ruby, which, at the time, this was near peak Rails. So that made a big difference too, that community was very open and welcoming to us. Eric Anderson: And then, how does the open source aspects of the project grow at this point? It's largely, you've written most if not all the code, and it's now on GitHub or something similar? Adam Jacob: Yeah. So we posted it to GitHub. It was always on GitHub, and it grew massively. Hundreds of contributors in months, thousands in years. A lot of that early development happened on IRC and was very open. So the whole of the company was on IRC plus every single person that was using the product basically, and all of the people who were doing development. And so that was a fun era, of really a lot of building, a lot of collaboration, a lot of accepting people's new work. And the community itself really formed up around that collaboration. And around, it became this very welcoming place where a good story from that early era of open source development was people would just wander into the IRC channel, because it was called Chef, thinking that it was talking about food. Adam Jacob: We had a kid who showed up and was going to cook dinner for a first date and he was looking for recommendations about what to cook. And so this 300 or 400 person IRC channel, crowd sourced, what the right thing to cook was, if you'd never cooked before, and you're going on a date, what's a good hard to mess up, but still slightly impressive thing to cook? And I think we landed on carbonara or something. Eric Anderson: Yeah, it's amazing. So you served, I mean, you rolled with it and- Adam Jacob: Yeah. Eric Anderson: [crosstalk 00:14:13]. Adam Jacob: And that's a very Chef thing, to just solve whatever the thing is that's in front of you, rather than get too pedantic about whether it's supposed to be done that way or not. Eric Anderson: Before we get too far, tell us about the name, the analogy. How'd you happen into the concept of basing it around Chef? Adam Jacob: Yeah. So like I said, at the very beginning, and in passing, I had been a pretty large Puppet user. And at the time, when I first started, I was just building prototypes for myself, and I called the prototype marionette. Because it was a kind of Puppet. But I don't know if you've ever typed to the word marionette, but it sucks. The short answer is it's awful to type the word marionette, much less to type it over and over and over and over again, which is what you do when you name a piece of software. Adam Jacob: And so I very quickly wanted something that was as short as possible. Can I come up with just a four letter word that would work? And Chef fit. Puppet had already had a minute where they had talked about Puppet manifests as recipes and people... I think that's mostly a forgotten dint of history, but there was a minute when manifests were talked about as recipes. And so I'm sure that was part of what was in my mind when that particular word came up. Adam Jacob: But then the analogy just took off from there. You call it Chef, you have recipes, recipes fit in cookbooks, they include their ingredients, which the metaphor broke down, I should have just called everything ingredients, I should have just kept going. But in the end, the truth of the metaphor is that the metaphor came a deep second to the fact that it was a four letter word. Eric Anderson: Great. Where does governance emerge, if ever in the Chef project? Is that from the outset? Is that something that happens organically? Adam Jacob: Yeah. So I mean, we had a couple of different eras. So in the very beginning, the governance was pretty loose. So no, it was clearly maintained by the contributors, and by maintainers. But essentially, all the major decisions were made by me. And then it was just people sending pull requests and doing code review, and there was a very informal governance. As we grew the project, and especially as our commercial monetization ramped up, we've gone through a couple of different cycles of exactly how we monetize the product. So initially, it was a hosted service, then we sold on prem software that was a version of the hosted service, but that was slightly different than the open source software. And then eventually, the open source software was the same as the software that we were selling, but then... Anyway, there was a lot of movement in terms of precisely what we sell. Adam Jacob: And so as the company got bigger, our need for governance got stronger. And so we moved from a model that was very ad hoc to one that was much more formalized where there was an RFC process that you go through for the community to make large breaking changes. There was a formal contributor process, there was maintainers, who signed themselves up to maintain different subsystems with the software, there was a way that those maintainers then could become lieutenants over those subsystems and have veto power. And then all the way up to the top of the project. Adam Jacob: But it definitely evolved over time. It didn't start with a lot of governance, it just ended with it now has quite a bit of governance. And I think that's a pretty good way to think about those sorts of problems. I think you want to have an approach early, that allows people to contribute easily and with very little friction. And you need to have a path for those people to then gain more prestige and gain more ability to make decisions about where the software goes. And even if in the beginning that's very ad hoc, like it was in Chef's era, we had people that were maintaining like the Debian subsystems, for example. And they weren't official lieutenants. But all the code that dealt with that subsystem went through them, and they weren't my employees. So they were basically lieutenants. And I think it's okay to have that governance change and evolve over time, but I think it's important to have. Eric Anderson: And did you more or less invent the governance systems yourself through evolution? Or do you have a source of inspiration? Adam Jacob: Yeah. Certainly in the beginning, my source of inspiration has always been the Apache Foundation, and the way that Apache runs their projects. I just have a deep respect both for the license and for the Apache way. I think, as we grew, the current governance model of Chef actually was modeled a lot on Docker's early model where Docker did a really good job of being clear about how do you become a contributor and where do you send the pull request to think about being a contributor. Those sorts of things. So later on, I think that system became much more formal. And it was actually pretty inspired by Docker's specific formalization. Eric Anderson: Yeah, going on to contributors, was that an objective for you with building the project? Like, "We need outside contributions?" And why? And what level of importance does that have? Adam Jacob: Yeah. I mean, it certainly was a goal for me. I think, as an engineer, and as somebody who builds software and believes in open source, when you have other people who are contributing to the software and making it better, that is the dream. On a bunch of different levels, it's the social dream, it's the dream that says that people should and can take the software and have it do what they need it to do because that's their right to do. And when they exercise that right, it's great validation that what you've done matters because somebody cared enough to improve it. Adam Jacob: I think it also gives you quite a bit of, I'm trying to think of a good word for it, but if you think about it, as somebody who commits software, who actually updates your code, who changes the software itself, they're much more invested in that software. I mean, earlier on when I said that I wasn't the only person who wrote Chef, that's very true. Part of the reason I say that is that there's all these people who own Chef, in a very real way, as soon as they put that software in Chef, they own Chef. They own this piece of what it is. And I own the trademark, but certainly, that software is theirs now. Adam Jacob: And it bonds to you, in a way that isn't the same as just being a passive consumer of the software. We're using some software to record this podcast right now. And it seems like really great software. But I don't care about this software. Do you know what I mean? Eric Anderson: Yeah. Adam Jacob: It's not a part of who I am. I don't know if they'll ever be a conference about this software. But the people who contributed to Chef early on, they loved Chef. And they loved it then and they love it now. And they may have moved on with their lives and they may have decided that they're on different trajectories or with different software or whatever. But they're Chef people for life. Just like I'm a Perl person for life. It doesn't matter that I haven't written Perl in a while, the mark that the Perl community left on me, and I hope that I left on it, that's a permanent thing. And it's a part of my identity in a way that I don't think proprietary software can match. I know that it cannot. You can be a user of the software, but it's never yours, not like that. And I think it's really powerful. Adam Jacob: And for me, it's the thing that I most love, and I'm most proud of in building Chef. I'm certainly proud of the business we've built, which is great. And don't get me wrong, and I'm super proud of how it's gone to market and all of those things. And of everyone who's ever worked at the company. Our ability to build a community that has taken the software to its own heart is deeply meaningful to me. Eric Anderson: So you got these two things, the open source project is going great, the business as you mentioned was going well. You're proud of them both. Were they ever in conflict? Were there tension? And it sounds like you've got this... You're an open source person, as you mentioned. And so maybe you had less conflict than others who use open source as a means to facilitate business. Adam Jacob: I mean, there was a lot of conflict. Eric Anderson: Yeah. All right. There we go. Adam Jacob: I think, look, there's always tension. We've gotten an email where we've spent months of sales resources and marketing resources and technical resources to win a deal, which we then win. And then we just get an email from procurement that's like, "Hey this is great. You guys are it, good job. We're never going to buy this from you. Because you gave it all away for free and your business model is bullshit." And if you've ever had an enterprise sales rep on your payroll, who gets that email, it's hard to keep them on your payroll. You know what I mean? Eric Anderson: Yeah. Adam Jacob: That's not good. And that's because there's a lot of different open source business models, I think. By my count there's probably nine. But without going into all of them, Chef's model over time has become one that is called loose open core. And what that means is that we have this core of the software, that's very useful on its own. You can take it and build an entire billion dollar business on top of it, and you can never pay me a dime. I also build proprietary software around that software that I think you should buy because it will make that experience better for you. It provides better insights into the software and how it's working, it provides better governance, it provides all kinds of other things. And if I get that slider right, then people will pay me. But if I get the slider wrong, then people will just use the software I buy but they won't pay me any money at which point I've taken venture capital, if I don't grow, I die. Adam Jacob: So I think the tension there is very, very real because in your community, the things that you decide to make proprietary, if you make things proprietary that are incredibly burdensome. So a good example here is like Elasticsearch makes authentication proprietary. So you can use Elasticsearch for free, but you can't log into your database unless you pay them money. Adam Jacob: Now certainly there's ways around that. But the point is, that's a very intensely hostile moment of a consumer. If you're like, "Oh, you want to log into your database? Well, dollar bills, you all." Whereas Chef's model is like, "Hey, go ahead, build all the infrastructure you want in the world. But if you want to do monitoring, if you want to see what's happening, if you want to be able to do those things, then you pay me money." Adam Jacob: And I think getting that slider right is where the tension lives. Because the community, there's always someone in the community who's like, "Well, that's a stupid place to put it like, I want that feature. I want that integration with that other piece of software. I need this proprietary thing, and that should be free." And then there's on the other side, you have the commercial folks who are like, "There's not enough commercial stuff in my back. I don't want to pay you as much as you demand or whatever, because what I value is this other piece of the software and you set the value of that thing at zero." Adam Jacob: And I think that tension, that is the key tension in building open source companies, is you have to decide what your model is and why your model exists. And I think early on in Chef's life, we decided that our business model involves having a huge tent at the top of the funnel. So at the top of the business you just need as many people as possible using the software. Over time our business model has evolved. It's very clear that the people who pay money for Chef are the large enterprises. It's the global 3000 that pay me money. It's not every person in the world. Adam Jacob: So what features I decide to build and how I think about what's free and what's proprietary has changed over time. Because my vision of who my customer is has gotten more clear over time. But that's the core tension. There's always a huge amount of tension between what's proprietary and what's free and where do you draw the line. And it has a huge impact on your ability to build a community. Because while there's a lot of Elasticsearch users in the world, I don't think that the Elasticsearch community is as thriving as say, the Chef community is. If that makes sense. Adam Jacob: It's not because there isn't one or it's bad software or they're bad community stewards. I don't mean to talk shit about Elasticsearch. I'm just saying that the more proprietary it is, obviously, the less what you're going to see is a thriving community building the software. You may have a thriving user community, but you don't have a thriving developer community in the same way. Eric Anderson: And what does that look like? Or what are the measures of a strong community? I see a lot of people taunt GitHub stars and a number of contributors and these metrics, but on the other hand, some projects look like it's half dozen people, the creators largely develop the software, then there's everyone else who uses it. Adam Jacob: Yep. Yeah. I mean, it's hard to tell. So I think it also varies project to project. So if you look at Chef and Ansible, Ansible has a huge amount of the content that Chef pushes into third party places in the main repository for Ansible. So if you look at the number of Ansible committers, it's massive, whereas the number of Chef contributors look smaller. However, and I don't know the actual counts, I'm just saying, that Chef, we split their repositories up differently, therefore, the counts are different. Adam Jacob: So it's very difficult to get a, when you're talking about business metrics, you can be like, "Talk to me about ARR." And we know what ARR means. And if you try to calculate ARR in some funny way, we'll all be like, "Get out of here with that. That's not ARR man. You're talking total contract value instead of annual recurring revenue," or whatever. Or very common, someone talks about revenue, what they mean is run rate. They're not talking about their actual revenue, they're talking about projected revenue. Adam Jacob: So I think in open source, it's very difficult to talk about community health in a very metrics driven way. You can certainly talk about how many people are showing up, you can talk about contributors, counts and GitHub, you could talk about stars. I think stars are a vanity metric. But for sure, the thing that you can do is when that community gathers itself together, so either wherever that is, if it's in Slack, or it's an IRC, or it's on mailing lists, or it's in-person, at a conference or any of those things, you can feel the difference between the community that's thriving and helping each other and one that's not. There's an electricity that comes with the give and take of a community that is a true community. And I know that that's not a metric, but it's real. Eric Anderson: Yeah. And I imagine it's very valuable. And as you said, it's I know it's hard to measure, but it's hard to create. There's no definite process in order to create it. It's a bit of- Adam Jacob: Yeah. I think that's right. It's a reflection of, I mean, like all communities, how do you choose your friends? How do you choose who you want to hang out with? How do you choose where do you want to spend your time? And that's what community is. Community isn't just folks on GitHub or those sorts of things, it's the human beings and it's, who do you want to talk to? Who do you want to be around? Who do you look up to? Who do you emulate? Who do you want to be like? What can you become? Is there opportunity for you to grow? Those are the things that make true communities, communities. Adam Jacob: We like to talk about them as if contributors are about lines of code that they write. They're not. I mean, they are, but they're not. It's about whether or not those human beings are invested in the community that is the software itself. That's what makes open source special. That's what the Commons is. When you boil it down to just lines of code and like, well, I don't get very many features from those people. Well, sure, you're right. No one's going to care as much as me about Chef or about Habitat or about any of that. Because this is my software. You know what I mean? It came out of my brain, and I pay a bunch of people to write it. Adam Jacob: So at no moment, are you going to look at the number of contributors and say that the community dwarfs the corporation. The corporation dwarfs the community, for sure, especially if you're looking at lines of code, because I pay them all day to do it. But that human connection, the part where the community itself cares about itself and cares about each other, that's the magic. Adam Jacob: A good example is Chef has an RFC for hugging. I don't remember exactly how it began. But I am a huggy person, just as a human being, if you ever meet me and you want to hug you can ask and I'm happy to hug you. But over time that hugginess, became a thing that exists in a community and not everybody is a hugger. That's not attractive to everyone. It can actually be a real reason not to participate if you don't like hugs. Adam Jacob: So we have an RFC that outlines all the different, the exact protocol for initiating hugging, and what are good responses if you don't want to hug. So for example, the reverse head nod is a good move. You can cross your arms, which is no hugging, but also still, you can think of it as a hug. Lots of that stuff. Those things, those are the things that make community. It's not arguing about a patch. It's those moments, it's the things in between. It's the times where we get together at ChefConf and we have incredible friends of the company. Darek Mazzone, who's a world DJ at KEXP. Darek finds incredible music acts that are local to the place we hold the conference and puts together an incredible show for everybody. It's those things. That's what makes community. Yes, where they are around the software. But that's what community is. Eric Anderson: You mentioned something interesting, this idea, going back to the tension and the salesperson, whose deals last, because they're going open source. Is that ever also a backwards win for the open source project? Does part of you think, "We need to have a few stalwart companies who are betting on the software, even if they're not paying us- Adam Jacob: Yeah. Eric Anderson: ... and so let's make this work even if they're not customers."? Adam Jacob: I mean, certainly that's true in the beginning. Eric Anderson: Yeah, yeah. Adam Jacob: When you just need users. Because you need the validation, and you need the market to know that you're for real. 10 years in, with a whole lot of customers, it would be very rare for me to decide that what I should do is engage deeply with someone who isn't willing to understand that if they don't pay for the software, the software doesn't get made. Certainly it doesn't get made for them. Eric Anderson: Right, yeah. Adam Jacob: Which doesn't mean that I don't care about people who don't pay for the software, I do. In particular, human beings who are going to use Chef to solve their problems I care about quite deeply. But if you're a billion dollar company, and you decide that, or a multi billion dollar company, and you decided that you're going to use the open source software to run your company, God bless you. I want you to do that. I just don't want you to come to me to help you do it unless you want to pay me money. Because I pay a bunch of people to do that. And you've decided that you don't want to be a part of that cycle, which is okay, by me. It just means that what I have to do is put my attention elsewhere. Adam Jacob: And that is also an interesting point of tension. Because if you're a person who's just trying to solve your problem, and you're using Chef and you work at one of those companies, and you don't have that relationship with me, what happens to your sense of community when you try to engage? Because what you get is a little bit of a stiff arm from me or from the company. And that feels gross. That feels less welcoming and less good than you would like it to feel. But the cold truth of it is that it has to be that way. Otherwise there'd be no business at all, and therefore there'd be no software. Adam Jacob: So I think it is tough. In the early days, sure, we certainly invested in folks who we knew weren't going to pay us just for the win. But I very quickly got to a place where in order to have those relationships, they needed to pay me something. So even if it wasn't going to be as much as I wanted, or as much as I knew it was worth, they needed to have some relationship with me so that that would be easy. And we don't do that really at all anymore, because we don't need to. Eric Anderson: So let's wrap up the story on Chef, where is it today? It's a fairly mature project. Are there still things you're doing to advance the project in certain directions? Adam Jacob: Yeah, absolutely. I mean, I think the big thing for Chef, and look, the product's 10 years old. So anytime you have software that's lived 10 years, that's good software in some way. And certainly it continues to evolve. I think one of the things that's different is that 10 year old software tends to be stable software. You have a lot of users, you don't actually want this software to change all that much, not in dramatic ways. Because if you did, that would be painful for things that have now become pillars of your use. Adam Jacob: What I think is changing though, is the industry is starting to figure out where we want to think about the different layers in the stack. So what's the relationship between the application and my operating system? And what tooling do I want to run different layers of that stack? And I think for Chef being so focused, historically at the infrastructure layer, Chef's big value in addition to that, was that it can go anywhere. It's a programming language so you can just write whatever you want that solves whatever your problem is. Adam Jacob: I think the evolution of Chef as we go forward in time is going to really be about thinking about how can it be the best possible thing, at that infrastructure layer? A little bit going back to its roots and saying, "Hey as we expanded and grew to manage so many different kinds of applications, and so many different kinds of things, maybe we lost sight of how to make it as easy as possible to just manage the infrastructure that needs to run those applications." And so I think the future of Chef's development is to really think about what can Chef do to really rethink what that initial experience is of running infrastructure? And how can we make that better? Eric Anderson: Awesome. Maybe as a final topic for us as we wrap up, you've highlighted in a way that I don't take many do very well, the value of a community and the social benefits for lack of a better phrase, of open source project community. For listeners who maybe aren't experiencing, who want to experience that, how do they engage with the community? Or maybe a related question would be, should they seek that relationship with every piece of software they're using? Or do you pick and choose your communities? Adam Jacob: Yeah. I mean, I think that's a great question. For my part, I think that I want that relationship to my software, if I can get it. Look, I don't have it to all the software that I use. So I'm using Chrome to do this right now. I don't have much of a relationship with Chrome, other than as a user, do you know what I mean? Eric Anderson: Yep, yep. Adam Jacob: I'm not a part of some Chrome community. I'm sure one exists, but I'm not there. It's on a Windows box. And I'm also not a part of the Windows community. But through the course of my career there have been communities that have supported me and moved me forward. The Perl community is one, the Ruby community is another, the Rust community is another. Certainly the Chef community, the Ansible community, the Habitat community, the ones we've created, have made that impact. Adam Jacob: And I think as somebody thinking about open source, when you're choosing where to put your time and your effort, I think you should think about and invest in the communities that are places you want to be. That are populated with people that you want to be around. And yes, it's about the software solving your problem, of course. But it's not just that. Do you know what I mean? Because there's a lot of problems you could solve in the world. And so you do have to decide, "Are these the people I want to be with? Is this the place I want to be around?" And if so, why? "What are they doing to help me as a person or to help each other? And how are they behaving toward each other? Do they lighten my load? Do they brighten my day?" Adam Jacob: And I think that's incredibly important. It's a thing that you don't get to do when it's just consuming software. For a lot of us, we go to work, we consume the software we're told to consume and we build the software we're told to build. But when you're in an open source community, it's not that way. We get to choose to be in these places. We get to choose to be with these people and to do this work and that choice is a powerful one and I think you should vote with your feet a little bit about wanting to be a part of communities that are diverse and inclusive and kind and care about the human beings that are involved in the software that you're helping to build. Adam Jacob: If you want to build a community like that, I think it starts by just saying that you want to do that, you know what I mean? Setting the intention in the world and saying to people, that that's the community you want to create, and you value it. And this is why, that's the first thing. And then you need to give those communities places to gather and you need to be present inside them and you need to try to live your values. And you won't always get it right, and when you get it wrong, you can apologize and hopefully you'll have built up enough goodwill that people will go along with you anyway. But that's, I hate to trivialize it, but that's all there is to it. Eric Anderson: Yeah. This has been fantastic, Adam. I tend to look at open source from a business lens. And it's been wonderful and inspirational to reflect during this conversation on societal and social benefits of these communities. Thank you very much. Thank you for your contributions to and creation of Chef. Adam Jacob: That's my pleasure. Eric Anderson: And your time today. Adam Jacob: Yeah, thanks. It's been fun. Eric Anderson: You can find today's show notes and past episodes at contributor.fyi. Until next time, I'm Eric Anderson, and this has been Contributor.