Matt Asay: You're ultimately talking about people. And that for me is the strength of the open source community. You talked about the permeability of these different projects and the maintainers of the projects and contributors too, like how accessible people and these systems are. If you want to identify the strength, that's it.

Sam Ramji: Matt Asay is a deep thinker and a writer he's written for InfoWorld, TechRepublic, CNET, ReadWrite, other tech media. But I think more importantly, he's been a practitioner, he's held a range of roles from working at companies like Alfresco to MongoDB. Right now he's the head of open source strategy and marketing at Amazon Web Services, which has a unique and challenging job. And I met Matt over a decade ago when I was responsible for open source and Linux strategy and marketing at Microsoft in the 2000s, when Matt was at Alfresco. He's always been a gentleman, a deeply principled person. We've had amazing debates. And now I find myself on the other side of the coin, because he's at AWS and I'm at an upstart open source company. So Matt, welcome. Thank you so much for taking the time to be on the show.

Matt Asay: Oh, thank you for having me.

Sam Ramji: So, we'll probably end up with a lot of things that people didn't know about you and that you thought. So this'll be fun. Let's just hop into it. What is your first memory of when tech kind of peaked your interest? How did you get into computers?

Matt Asay: First of all, I have to say I'm not a developer. So unfortunately, I can't say that I hacked my Atari 2600 as a child and it was writing code. I guess that was even pre-Basic. That's not me, the earliest memory was kind of time shifted by a year or two. The earliest memory that I have of really finding something interesting, but not knowing what it was, was I was at Cobalt Microsystems. I was working for a Japanese company, we were an investor in Cobalt, and on the cubicle, if you can remember, we used to work in offices and there were cubicles there, there was this vulgar spin on Linux and the Volkswagen. I remember looking at it and saying, "Linux f'ing grooving," or something like that, "What's Linux?" And lo and behold, a summer later, I was an intern at an embedded Linux company. But it was that first sign of the door that somebody, it was like a tattoo that they were wearing proudly. And I didn't know what it was, but I remember wanting to know what it was.

Sam Ramji: Yeah, I remember that. The word was not far for Newgen. But there was a certain thing on that, wasn't it? That was kind of fun. So, and you're kind of an adventurer, I think, right? There's a model that Simon Wardley has, explorers, pioneers and town planners. You've moved from place to place learning a lot and you've been very transparent in what you've learned. You've always published that. What are some of the more standout memories you have around things that you tried to do, things that worked out the way that you expected, maybe that worked out in a way that you really, really didn't expect?

Matt Asay: First of all, I say, and this was pre-open source, and I was in tech, but not in software. I distinctly remember presenting to some executives from a large Japanese company that shall remain nameless, but it was Toshiba. And as part of that, I had to talk about semiconductor, silicon wafer manufacturing, and I was way out of my depth. And I decided that I was going to kind of wing it. And I thought I was doing pretty well. It got to the end, and my boss pulled me aside privately, was very, very good man and a good boss. And he said, "Matt-san, never pretend to know what you don't know." And that more than anything else has guided me in open source, because there's so, everybody around me is a developer or feels like that. And they all seem extraordinarily smart, they have productive lives. Whereas I just write words and do other things like that. That principle of not pretending to know what I don't know has been hugely valuable.

Matt Asay: And so, in terms of going into open source, that's one of the reasons that I write, I write to learn. If you read a blog post that I write, sometimes it might sound like I've got it all figured out, but usually I'm writing, because I'm putting it out there. And I might assert it, make an assertion that feels pretty bold and I really believe it. More often than not, I'm making that assertion to see if it feels right, to see if it holds up to scrutiny. And if it does, I'll keep writing it and keep trying out that idea, then I bake it into my day-to-day. But it's served me well over the years with... I know open source seems to most as kind of an established fact now, but you know, we've been involved in this for years and it's been anything but on the business side and on the development side, it's been a learning process.

Matt Asay: And because of that ability to not pretend to know what I don't know, it's made it so much easier to experiment, to experiment even out in the open with revenue models for open source or combinations of companies in terms of partnerships. And I think it's been good, because the reason that we're at the place that we're at in the industry now where open source has become a primary default for how engineers build and manage software. It's because a lot of people have been willing to be wrong over the years and experiment. And you, I think about the work that you did at Microsoft, taking bullets, fighting the good fight of trying to help Microsoft chart these waters, where now Microsoft is a fantastic contributor to open source projects. But in part that was you getting out there and experimenting. And I always admire the work that you were doing there.

Sam Ramji: I really appreciate that. They were not easy days, but there are meaningful days. I think we had a certain West Wing feeling as we walked from meeting to meeting and place to place on campus. There's nowhere we'd rather be, because the work we were doing was so important. I think you said something really kind of beautifully succinct about what it is to be open source, which is to be willing to try your ideas out in the open where many people are nervous to share unformed ideas and whether that's as code, whether that's as a blog, whether that's as documentation, it's the same kind of native courage required to do good quality science. So for me, there's a lot of connection between sort of the enlightenment as a movement and human intellectual history.

Sam Ramji: And then what we're seeing in open source and how that influences those of us, even if we're not writing open source code, there's a certain ethos that kind of pulls us in to try to do better I think through honesty and honest mistakes, the willing to make mistakes in the open, be contradicted by someone who knows more and can show us something different, that's kind of the power of open source and community, I think.

Matt Asay: Yeah. And you know, there's one thing when you said that it reminded me of this series that I wrote recently profiling different open source maintainers. Often the-

Sam Ramji: That was a really cool series.

Matt Asay: The cool thing was being able to interview these people, because they're all like, I mean, they could be your neighbor, but they also built this system that billions of people use, like cURL is an example of Daniel Stenberg. But one thing that came out of those, I loved doing those interviews, because I just felt like, again, these are ordinary, but profoundly interesting and accomplished people that my parents have never heard of. And yet they use their technology all the time. One thing that came out of that, that I found really interesting and it kind of goes to your question about failures and strengths. One thing that seems to work for these different open source projects and I'll use cURL Daniel Stenberg again, because he talked about, actually, they all did, talked about how ultimately they started this project. Sometimes they were scratching an itch. They had something that they were trying to do. But the reason that they've stuck with it in some cases over for over 20 years is that it's fun. And it's personally satisfying for them.

Matt Asay: One of the things in the debates that we've had over the last, and I mean, when I say we, the industry has had over the last few years about open source and sustainability. One of the key things that I've learned or had reinforced with me during these interviews with these maintainers was part of the sustainability question has to be about that fun aspect or how these developers feel replenished or rejuvenated by contributing. For in the case of cURL, Daniel now has a job, he's able to make a living from it. But for years and years and years, he was doing it on the side in his spare time and he was doing it, because it was fun. And you say, well, is that sustainable? In the case of several of these maintainers that I talked to it's sustainable, because the joy of writing that code never left.

Sam Ramji: Yeah. Some people produce music for creativity that will never see the light of day, right? Some people tell stories. There's also kind of the flip-side of that, right? Salvatore Sanfilippo, the much loved leader for Redis, took an extraordinarily counter-cultural step down as seen from an industry and a corporate sort of classical success lens, but he realized it was not sparking his creativity anymore to be a maintainer of an extremely popular open source project. He executed a really graceful transition. And I think he taught all of us a lot in that process, there's kind of the 10 cent advice, right? Follow your heart, understanding what that means and making the changes. That's kind of the challenge to live through.

Matt Asay: Agreed.

Sam Ramji: So, one of the things that you've done a great job of over the last, what is it? 15 years or so I think that I've been paying attention to you, and maybe 14 years that I've known you, is you've talked about the patterns and anti-patterns, right? The advantages, disadvantages, risks, how to overcome the risks in open source. You ran the open source business conference for a while, which itself was a counter-cultural move, because open source technologists didn't want to acknowledge that there was a business component to it. So, thinking about sustainability advantages, disadvantages, risks, what do you see that should be top of mind in a cloud-native world, for our practitioners who are Kubernetes-based two pizza teams.

Sam Ramji: So I'm building a microservice along with a team of eight or 10 other people, trying to make sure that I've got a great API, I've got all the things that my managers want, I probably got to do some maintenance on the last project I was working on as well, and I'm thinking about open source project X, I ran across this on Twitter, right? What do I need to have at the sort of the top of my mind is I think about an open source project?

Matt Asay: Important for that developer, that team, just as much for the developer sitting at some Fortune 500 company, it can be easy to believe that your voice doesn't matter in whether we're talking about cloud-native computing or just in general and open source that your voice you're just a single developer, you don't matter. One of the things that I've learned over the years is that even the voice does matter. And maybe in, I was going to say, even for that individual developer, that small team that's toiling away in Des Moines, Iowa, contributing back is important. Those contributions might be code, but more often than not, they might also be answers on stack overflow or in other ways that they contribute to the documentation around that project that might not have been the answer that you were you expected or were looking for. But for me thinking about sustainability, thinking about how this code functions, it's easy to look at Kubernetes for example, and say, "You know what? Google's got it Red Hat's got it, VMware, AWS, they're all, they'll take care of it."

Matt Asay: And to a certain extent for like the major functionality, maybe that's true, but understanding how to make that big system, that big project work for the individual developer or the small team of developers, that's incredibly important. And if not you, then who? Get involved, make your voice heard again, it can feel daunting in a world that's where some of that cloud-native computing-related tech, whether it's Envoy or Prometheus', or name your different Linux foundation/cloud-native computing foundation projects. It can feel daunting that your voice doesn't matter, but it does. And that I can guarantee the developers of those projects want to and need to hear from the average user like me, like you, probably like the people that are listening to this, your voice matters.

Sam Ramji: Really profound point about the difference between open source and not open source software is that the community is transparent. If you had to find the developer who is responsible for a particular feature that you want to change in an Oracle database, you would probably hit the great protective firewall right around that company. If you want to find the maintainer for Redis, you can, you can go on Twitter, you can search Google, you can get into GitHub, you can then file a ticket at some point that'll be responded to, right? You can go and enter and engage, and that engagement will be reflected. To answer the corollary to that, I often find the biggest risk is people don't think they can talk to the open source developers or often they're bound by some sense of corporate secrecy about the use that they're putting this to.

Sam Ramji: And it's kind of like, I would just like everybody, who's building cloud-native code to know there's so much code being written, yours feels very special, it feels very secret, but it's really not. There are so many millions of people building these things at the same time, you have if nothing else, security through obscurity, it would be hard to find it. But to just go and say, "Here's the use-case I've got, it's not quite working for me, can you help me with it?" Is so much more powerful than trying to flail away on Google Search, for a week losing productivity, while you try to figure out this` super-obscure, YAML file attributes setting. And you've done a lot of work to advance the community. I mean, there's many people, a community by definition has many leaders, right? So, there's a lot of different parts of it. But when you think about the strength of the open source community or communities, how do you define that and how do you think about that resilience, the sustainability?

Matt Asay: I like that you self-corrected on that. It is communities. Sometimes we talk about the open source community as if it's like one big monolithic thing. But the community behind who SolveSpace, a 3D modeling for CAD, or Linux. They're all different communities, and ultimately with people, I don't want to make this all squishy... I mean, I was an English major, so I'm very comfortable with squishy concepts that have no relation to reality. But in this case, I think it does matter. You're ultimately talking about people and that for me is the strength of the open source community. You talked about the permeability of these different projects and the maintainers of the projects and contributors to how accessible people and these systems are. That's if you want to identify the strength, that's it more than anything else. The other thing that I would say, and it's related to that, is the relationships that form, usually when somebody has a hard time getting into a project or becoming a contributor, they have a desire to contribute to a given project and they find it difficult.

Matt Asay: That can be, either because they don't try, but more often than not, I think it's because projects aren't welcoming enough, don't privilege that newbie, because I mean, frankly, it can be tedious to take on new users. Talking with Jim Bailey, who's the founder and maintainer of OBS, Open. I think he said after the fact that he made up the acronym after the fact, but it's I think, Open Broadcasting System or Studio.

Sam Ramji: I was hoping that it would stand for OBS Broadcasting System.

Matt Asay: Thank you, Richard.

Sam Ramji: I'm sorry, I couldn't help it.

Matt Asay: He said it's a huge priority for him to make it a welcoming community. And he says, to go out of his way to teach newbie developers or would be contributors to OBS how to do it. And if they make a mistake or if they dump code in there that's not formatted correctly or it's just not the OBS way, he said, "You know what? It's so much easier for me just to either reject the code or to take the code and redo it myself." But it's better for the long-term health of the community to enable that person to contribute in the right way. And the right way just means the way that the OBS community does it. So people like Jim Bailey, who by the way, is an amazing human being. I was almost in tears interviewing the guy. It was just like, this is a beautiful human being. I love this person and this story.

Matt Asay: But it's that welcoming new people in. And frankly, I think that can be one of the biggest challenges. The Linux community, for example, has a reputation for being a sort of toxic community at times. Whereas the Kubernetes community, I talked with Lili Cosic the other day, who's a contributor or a maintainer there. And she said, it's the exact opposite there. It's a super-welcoming community where the first impulse is to embrace and to welcome newcomers rather than to say, "I don't have time for this," and push them out.

Sam Ramji: And maybe that's good guidance for people assessing open source projects, it's kind of take a look at the maintainers, what's the mood of the community, right? Because there's a direct correlation between the amount of energy people are willing to put into welcome newcomers and the lifetime sustainability of the project. The anti-pattern right. Look at OpenOffice in the 2000s, right? It was a notoriously closed community. And that project ended up hitting an iceberg. Had to get refactored, had to get relicensed many, many changes. And part of the new compact is to be friendly to newcomers. So I think that's something that is worth assessing for yourself as a user.

Sam Ramji: One thing that you mentioned was, it's communities and not community, which reminds me of a funny, short story that Danese Cooper told me not so long ago, which is at some point, a government agency in the U.S. summoned her and Tim O'Reilly for a meeting. And some military three letter agency, and started berating them about Linux and what this person wanted to see in Linux, because they thought that they had got the leaders of open source in their office and they can tell them what to do. So, needless to say, Danese has been a big influence on me as other open source leaders. Tim has been a big influence. Who are the biggest influences in your life from an open source standpoint?

Matt Asay: You're not going to like this answer, quite honestly, you're one of them, Jason Matusow, Bill Hilf, the maybe I'll categorize you as three people. And for those who don't know, so you know who Sam is, and Sam as part of his introduction or as part of this conversation, mentioned that he used to be at Microsoft. It's a great place to be today. If you're in open source, it wasn't that great of a place to be back in the day, if you were trying to be the open source guy. Jason Matusow was the first, I think Sam, you came after, and then Bill, if I remember right, got to play cleanup-

Sam Ramji: Bill actually was the icebreaker for me, right? Because Jason Mat was in the legal group and he was trying to create some Microsoft-compatible license, which is like a shared source license, some kind of licensing. And then Bill was hired, because he was a Linux expert from IBM. And so, they brought him in and he was doing some work directly with Bill Gates among others. And he was super-brave and bold, right? He was demonstrating SELinux to Bill Gates and telling him why it had better security than Windows. I mean, you just imagine the chutzpah there, he's now the CEO of Vulcan, which was Paul Allen's company. But Bill created the room for me. And God bless Bill. He told me one thing really clearly. He said, Sam, "If I am not getting at least one strenuous complaint about you and your team every week, you are not doing your job. I've got your back."

Matt Asay: Well, it's what you just described is why I say that. And I'm not trying to flatter you or anything like that, but I grew up in open source. I didn't love this, but Tim at OSCON, 2006, I'm trying to remember which year it was, but he set up this debate or this discussion between Matt Asay the open source zealot and I think it was Mike Olsen as the open source I don't know, like some nice word. And I took real exception to that. But that I was pretty hardcore, it's got to be open source or and GPL rules and all this stuff. And one of the things that I loved about the Microsoft folks starting with Jason, then Bill, then you was this diplomatic sometimes contrarian and sometimes you're sure internally, you were trying to turn the ship. Externally, you had to put a brave face on sometimes stuff that looked like crap to the community. Jason, I remember showed up, and he had protesters at the first open source conference he went to, and I think a bodyguard maybe.

Matt Asay: It was just different times, but that ability to challenge, not just internally what Microsoft was doing, but challenge the open source community and say, "Sometimes you're wrong on this point." And you in particular, I thought did such a good job of engendering a community conversation. You made it so much easier to have that conversation about what's ideal, what's not in open source, whether from a business perspective, from a licensing perspective. And I think it helped the industry to grow up. And yes, there were some, and I won't name names, but I'm thinking of a name that has three letters of somebody who's still around today, fighting the good fight or not so good fight against Microsoft. He changed the conversation for the industry. And that to me is that willingness, because open source should be just like science, it shouldn't be about personalities, or it should just be about what works, here's the data, here's what works. And I think that's ultimately what helped Microsoft, it's what's helping Amazon today. It helps companies figure out what's good for their customers.

Matt Asay: It's not the crusading waving a flag for open source that can only get you so far. It's ultimately about what kind of a Jamesian pragmatism, "Does it work? And if so, let's do more of it." And I thought you and the others that preceded you were just great on that.

Sam Ramji: Thank you. Yeah. Pragmatism was definitely the watch word. And I think to many in open source at the time that was a synonym for compromise, and compromise was a synonym for deceit. So that was kind of a tough place to be. But the pragmatism was key. And I think apart from Denise made an example of welcoming a new developer to a community, she made it an analogy of like, "Hey, let's help Sam and his team at Microsoft into the community." Because it's probably going to be good, but they're going to be really clumsy at first. The other person who was tremendously impactful was Alison Randall. And she offered me and my team, an intellectual model that let us do our job.

Sam Ramji: And she said, "What you need to be," and this is probably true for you and your team at AWS, "You need to be culture brokers," and I think you personally are ahead of the game on this, but she said, "A culture broker is a particular thing where there's culture A and there's culture B and you understand culture A so well that you could show up as a native, you understand culture B so well, you show up as a native. And you can explain them to each other. But you really belong to culture C, which is this bringer between this culture brokering group," which was a super-powerful construction. She was enormous, a generous in her time and energy and thoughtfulness. And I think part of Microsoft's success can be laid at the guidance that she gave us.

Sam Ramji: Kind of to conclude our thoughts, I wonder if you have any predictions on where open source software might be in the next 10 years, as some people have said, including Bill Gates, "We often overestimate what we can achieve in five years, but we vastly underestimate the progress we'll make in 10." I'm wondering if you've given this any thought recently?

Matt Asay: Here's where I think we're going, and it's also the thing simultaneously that I worry a lot about. Tim O'Reilly, Tim's always ahead of the curve on things. So he said, I think in 2008, he was talking about this cloud thing, which was just barely new. And he talked about cloud perfecting some of the advantages of open source. Back in the day you downloaded the software, you didn't have to ask legal, you didn't have to ask purchasing, you could just download and get started and go. Well now, think about cloud. It makes it in some ways, even easier. You don't even have to download anything. You can just start using the software. And I had this conversation with the founder of FaunaDB the other day. And I asked, I just take it as rote or take it as a given now that everything's going to be open source. And he said, "We don't think developers care. So Fauna's NAPI, and developers will access the API. It runs behind the scenes. It's a cloud service and no one wants to mess with the code.

Matt Asay: Anyway, he's probably right, so here's where I think we go with open source and this is leading into the threat. Where I think we go is basically everything. There's not really much reason to write, especially on the infrastructure side, there's not much reason for it to be proprietary, because you can always make money operating it as a cloud service. And I think different companies asre figuring this out now. The concern that I have is that 10 years from now, opensource will be everywhere and yet nowhere, because no one will be thinking about the underlying code that's being operated for them. And I say this as an employee of AWS, we do a good job of operating open source code for people. And in general, I think they like it. Where I don't think we want to get as to as an industry, is a point where we don't care about the code.

Matt Asay: It's never been the case that a JP Morgan Chase or a Nike really wanted to futz with the code. It's never been the case that their engineers are spending a lot of time or any time looking at that code. But the fact that you have that opportunity, the fact that think of the old analogy of the car mechanic. The hood is not bolted shut in an open source world. I worry that we're going to get to the point where all we care about is the service, the resulting services of that code and not about the code itself. So, 10 years from now, I think open source, we already feel like it's everywhere, but if you look at the cloud-native computing foundation and in other open source projects that fit into that mold, we're really just scratching the surface in terms of what code is out there. I think that's going to grow 10x or more, but our interest in touching the code is probably going to be 10x less. And that I think is a problem.

Sam Ramji: So we're going to need a lot better tools, maybe some augmented intelligence to help us find the archeological layers that we need to dig around in and understand. So to sort of conclude, in the spirit of this podcast, what information would you impart to a developer to help them succeed in cloud-native software?

Matt Asay: Again, here's the literature person in me. I don't have anything to impart in terms of technical advice. One of the best sources of advice is not going to come from me, but it's going to come from your peers on stack overflow. That's not new. No one needs me to tell them that. Hopefully everyone already knows where to get those answers. I will say, in seeking out those answers, and here's the literature major in me, be kind, you've actually always been really good about this Sam, but ultimately those communities and the value of how much information you can get from these different communities in cloud-native and elsewhere is going to directly correlate to how much of a jerk or how nice of a person you are. I don't mean like milk toast nice, but I just mean, be kind. You're looking for information, be humble. And if people are come to you seeking information, be generous, as generous as you can afford to be with your time. So it's that, be a person. You interact with computers all day long, but really you're interacting with other people, especially in open source land.

Sam Ramji: Matt, it's great wisdom. It's great spiritual guidance. And I think we will close with that. Thank you so much for being on the show and as always thank you for your friendship over the decades.

Matt Asay: Of course, anytime I can spend with Sam as good time.

Jeff Carpenter: Hi, this is Jeff Carpenter with the developer learning team here at DataStax, and I really enjoyed this episode that Sam was able to do with Matt. Really love the new theme of this series of open source data. And there's a couple of really fun play on words that are embedded in this here. We're being open source, we're talking about open source projects, but we're also talking openly and sharing about experiences and going behind the scenes on some things. And I think this episode is a really classic example of that. So I've always appreciated Matt's voice as a columnist, enjoyed his columns for years and his commentary on the open source community. He's always had a lot of great insight and I've also appreciated him telling it like it is. And I know that that's generally well appreciated across the industry. I think that there have been a number of us that have been on the receiving end of some criticisms or maybe some questions in the past. But then obviously, having the reception that he's had at multiple different companies where he's worked at his day job, in addition to the columnist aspect on the side, and he's very well respected and it's great to have him on the show.

Jeff Carpenter: So, my number one takeaway from this episode was that the open source community, open source data, really the most important part of it is people, it's us. It's not just about data and ones and zeros. It's about us and our relationships and the beautiful software that we create together. So there are a number of really great things that I felt were just great action items, even for myself and learnings for myself in how I practice going forward. So some of the things that were highlights for me, reaching out to maintainers of software projects as a consumer, as a user of an open source project - what is my relationship to the person that is producing that? How am I reaching out to interact with them, to encourage them, to provide them feedback?

Jeff Carpenter: And looking at it from the other side as a producer of open source software, how am I providing a better path for new developers? This is one of the hardest things I found is to provide that context and setting the stage for somebody that is new. You don't know exactly what they will or won't know. What are the little breadcrumbs that you can provide them to give them an on ramp into the community, into learning the technology? If you don't do that, how many people are you going to leave behind?

Jeff Carpenter: Finally, the last real big takeaway for me from this episode was the emphasis on kindness and humility. And I think there are any number of virtues that one could choose to highlight in terms of how should the community interact, what are the rules and principles by which we should govern our interactions with each other? But I think you can't go wrong with highlighting those attributes of kindness and humility. And kindness, always treating other person as the way that you would want to be treated, considering the tone and the content of your words, as you're interacting with other people, putting yourself into their shoes. Kindness is absolutely key. And then of course, humility, not thinking of yourself more highly than you should, having a proper perspective. Realizing and valuing the other person's contribution to a project, to an effort that can be really, really hard, because we invest so much of ourselves into these projects, into these communities, into our daily work, or into the work that we do on nights and weekends because it's a labor of love. And it's really easy for our ego to get so tied up in these things, and it can be super-hard to let go of. So humility is a super-valuable commodity and it's a rare commodity, unfortunately, sometimes. But I hope that through podcasts like this and just this wonderful conversation that we're having together, that we will begin to see more and more of this and that will embody it more and more in the way that we interact with each other.

Jeff Carpenter: There was one point in the conversation where I wished that I was actually in the room or in the virtual room with Sam and Matt talking. And that was that question that they posed at the end, will care about open source software in 10 years? And I wanted to stand up and say, "Yes, I believe that those developers all of us in 10 years, we will still be talking about open source software."

Jeff Carpenter: Now I think that the nature of the projects that we're talking about might change over time, maybe the world of data infrastructure to just take one aspect, maybe that world of data infrastructure will be so commoditized and taken for granted that it won't be the kind of thing that we think about anymore. And we'll all be consuming it as a service. And there will be some new set of capabilities that we will be talking about, some form of plugin or extension for artificial intelligence and machine learning. Maybe we will all be innovating in that space instead of the spaces that we're currently innovating it. So I think open source software is here to stay. I think the nature and size of the project that we ended up working on is what the open question will be. And I can't wait to see where it goes. It's been a pleasure having you with us on the Open||Source||Data Podcast, and we hope that you will join us for each new show as we roll them out to you.

Josh McKenzie: Thank you so much for tuning in to today's episode of the Open||Source||Data Podcast, hosted by DataStax's Chief Strategy Officer, Sam Ramji. We're privileged and excited to feature many more guests who will share their perspectives on the future of software. So please stay tuned.

Josh McKenzie: If you haven't already done so, subscribe to the series to be notified when a new conversation is released, and feel free to drop us any questions or feedback at opensourcedata@datastax.com.