Interview Intro

‍

Richard Rodger:  [0:00:00] Welcome to the Voxgig Podcast. We talk to people in the developer community about developer relations, public speaking and community events. For more details, visit voxgig.com/podcast. All right, let's get started. 

‍

We all talk about developer relations, but have we forgotten about dev ops? In this podcast, I talk to Marino Wigay about operator relations and how that focus has been central to the success of the Kubernetes community, and its high impact when it comes to developer relations. [0:00:36]

‍

Main Interview

Marino Wigay

‍

Richard Rodger:  [0:00:37] Marino, hey.  it is cool to have you here today on the Fireside with Voxgig podcast. And you are dressed for this podcast, I see – Kubernetes T-shirt for the win? [0:00:47] 

‍

Marino Wigay:  [0:00:49] Absolutely. Thank you so much for having me, Richard. [0:00:51] 

‍

Richard Rodger:  [0:00:52] Okay, so I’m going to – I don’t even know where to start with you, because you – do you sleep? [0:00:57] 

‍

Marino Wigay:  [0:00:59] I do. 

‍

Richard Rodger:  [0:01:01] You do a bunch of stuff. Let’s do the really easy question first. Who do you work for and what do they do? And how does that fit into dev rel? [0:01:09] 

‍

Marino Wigay:  [0:01:11] I work for a company called Solo.io as a developer advocate. And they’re a company that focuses in on API management and application networking, mostly in the cloud native and Kubernetes ecosystem. To simplify, you run a bunch of containers and they all need some fancy networking; that’s where Solo comes in. 

‍

And what I do is help talk about that message throughout communities and at conferences. But to pair that with how that’s interactive or how that works with developers, for example, developers write code. They write these microservices; they’re the ones that create them. And we want to remove that responsibility and onus of them having to manage the logic behind how their applications run, and just let them do their thing. [0:01:59] 

‍

Richard Rodger:  [0:02:00] Where does the API park? [0:02:01] 

‍

Marino Wigay:  [0:02:03] A long time ago, when Solo first launched, they got into the management of APIs. They got into that business of managing APIs, in the sense of, they’ll present you with an API gateway and you’ll be able to control all of your APIs wherever they might exist, whatever they might come in the flavor of. 

‍

Now over the years, that API pattern moved directly towards microservices, because Kubernetes started becoming a thing. And through that initial launch of an API gateway solution, they gravitated towards a service mesh, which is a bunch of API gateways all over the place. And they took the same foundation of what they call – or what they at that time called Gloo Edge, and turned this into something called Gloo Gateway. And that fits the whole application networking story and paradigm. [0:02:53]

‍

Richard Rodger:  [0:02:55] Yeah, it sounds like I could have used you guys a couple of years ago. The system I built pre-COVID had 100 microservices on Kubernetes and on Google Coud and a lot of interservice comms, our own gateway, all built by hand. It was fun. [0:03:17] 

‍

Marino Wigay:  [0:03:18] That’s the way things were before Solo came along. [0:03:22] 

‍

Richard Rodger:  [0:03:24] Did taking the job in Solo drive your interest in Kubernetes and running Kubernetes communities and doing open source? Or did that come prior to the job? [0:03:34] 

‍

Marino Wigay:  [0:03:36] A bit of that came from Solo and some of that came from before. The previous role that I was in – I was at a company called VMWare; I’m sure you’ve heard of them. [0:03:46] 

‍

Richard Rodger:  [0:03:46] Yeah, Who are they? Small company. [0:03:47] 

‍

Marino Wigay:  [0:03:48] Yeah. But they at the time, when I was working there, they had gotten into the business of containerization. They already had a business; they acquired a sister company that they had spun out a long time ago called Pivotal. And brought it in-house, and wanted to complete their portfolio by offering up container services, and this whole notion of, you can achieve dev sec ops. 

‍

While there, it was great to immerse myself in what they were doing in Kubernetes, not only in the enterprise space, but also in the ecosystem of open source. And at that time, I started to realize, oh my gosh, there’s all these amazing open-source players. Solo happened to be one of them. And there’s more to that story, but it just so happened that they were very well aligned to my career in terms of what I wanted to do and where I wanted to go. 

‍

So, I joined them. I didn’t join them as a field engineer – sorry, as a developer advocate though. I joined them initially as a field engineer. And this is where the community part came in. Solo wanted to enhance their community; they wanted to have more conversations, more direct conversations that are authentic. 

‍

And they weren’t actively doing that yet, so I decided to champion a lot of that effort, and I became their first developer advocate, that took on a lot of the community work, to engage with folks at conferences that participate in these communities, and just to be able to answer their questions and not come across as someone that sells them. I’ll educate you; I’ll answer your questions. If you decide that there is something that aligns with your problems, you know who to call. [0:05:26] 

‍

Richard Rodger:  [0:05:29] There’s something I want to zero in on here, because this goes to the heart of some of the challenges developer advocates have these days with management. You said Solo decided they wanted to improve their community engagement, but who specifically in the leadership team – where did that come from? 

‍

I’ve worked at companies and I know companies where it has literally come from the CEO, because they know intuitively – this is going to work for us. And then other companies where that’s been driven by the investors, because the investors know that it works. And other companies maybe where it’s come in at a lower level and it’s happened organically.  So, how did it happen in Solo? Was it a direct leadership initiative from the highest levels or was it a calculated move? [0:06:22] 

‍

Marino Wigay:  [0:06:24] Initially, it wasn’t even probably top of radar. They had it in there, their backburner of something to address. And I was the one that said, “Let’s actually kick this off. You can experiment with me. I’ll be the first.” And my CTO as well as the CEO was completely on board with it. 

‍

Because I felt – they felt that they needed to try something a little bit different outside of their regular marketing campaigns and their – the process that they take for sales and how long those sales cycles would be. So, they experimented with me. And because of the things that I’ve tried, whatever I’ve executed on, they grew the team. And now we’re a team of three, and we’re able to get out globally. [0:07:04] 

‍

Richard Rodger:  [0:07:06] So, you infected the organization with developer advocacy. [0:07:09]

‍

Marino Wigay:  [0:07:09] Exactly. 

‍

Richard Rodger:  [0:07:12] Okay, yeah. It was – the idea was there, but then you provided the execution- [0:07:19] 

‍

Marino Wigay:  [0:07:19] The catalyst, I’m the catalyst. [0:07:20] 

‍

Richard Rodger:  [0:07:21] Okay, so that generates another question, which is, clearly at that point in time, developers – they fitted into the sales process somewhere. But maybe it was – maybe it wasn’t that well defined. For Solo, is it the case that you sell to developers, and then they bring you to senior management of your customers. Or do you have a more traditional sales setup where you’re selling to senior management and the developers say yay or nay? [0:07:52] 

‍

Marino Wigay:  [0:07:55] It’s a combination of both, and that’s all entirely hinged on Solo’s growth, right?  There was an inflection point where they realized, having more long-term relationships with enterprise execs is going to keep growing the business; it’s going to sustain the business overall. 

‍

But the conversations still need to be had with the engineers, the ones that ae actually making the technical decisions around how an application is deployed and built and supported and scaled etc. So, developers initially was the original audience, and that’s primarily because of the way they consumed and built their APIs. Now there’s still a little bit of that, but the focus now is more around platform teams, teams that focus in on managing Kubernetes and associated orchestrated systems, but also the observability, the networking, the identity and authorization, the pieces around automation. 

‍

All of that falls under – used to fall under so many different buckets, but now falls under the platform teams. And so, Solo’s motion is, let’s work with the platform teams and tie this all in under a single pain, make this easier for them to consume. In turn they can give their developers a platform to start consuming various services inside of a mesh or inside of a network, a global network. [0:09:19] 

‍

Richard Rodger:  [0:09:23] So, if you were in VMWare, and I’m guessing around – just looking at the time you were there. You must have had a window seat to Docker emerging, getting popular. [0:09:36] 

‍

Marino Wigay:  [0:09:36] Yes, exactly. 

‍

Richard Rodger:  [0:09:38] What was that like? What did she think of it at the time? When you saw it first, were you like, oh my God, or were you like, ‘Ahhh, it just another jail. Go on, BST jails, whatever.” [0:09:47] 

‍

Marino Wigay:  [0:09:49] Back in 2017 the whole movement of containerization was starting to take off, but VMWare was in this awkward place, and I was along with them in that awkward place where they still had this audience of infrastructure builders that they sold to and they worked with. And to allow them to allow their developers to leverage containers, they had their own little answer, which was vSphere integrated containers. At the same time, if something elaborate was much needed – by the way, we’ve got a company over there called Pivotal that can help you with that. 

‍

So, for a while, it was a situation where you had conversation with developers, and they were either using Docker or you were trying to convince them to use our vSphere container solution, which didn’t scale well. And then you had Kubernetes at the side that started growing. VMware decided to pivot a little bit, and they built an internal organization that focused primarily on Kubernetes, so a very small organization. 

‍

And then they decided, “Let’s acquire a company called Heptio. Heptio was their first take at let’s offer up Kubernetes through our ecosystem, through our builds, and support it and life cycle it etc. They couldn’t stop there, because as we know it, it’s not – the story doesn’t stop with just Kubernetes. 

‍

You need an observability platform on top; you need a way to lifecycle it. You need a way to check for vulnerabilities, so many different things. And this is where they doubled down and realized, Docker’s not going to massively succeed at the orchestration game. Because we have to offer up a platform for a platform. They’re only offering up a platform. 

‍

When you think about that, a platform for developers, but we’re offering up a platform for both developers and operators; that’s going to be widely attractive to the market. You see companies like Google, AWS, Microsoft, all doing the same thing as well. They offer their own platform and they give you a platform on top of that as well. 

‍

And it comes down to the experience of it. You have a bunch of organizations highly leveraging Docker, trying to productionize it, take it to production. That’s not entirely possible. That’s not to say Docker can’t do it, or that technologies in Docker can’t do it. But it’s to say that there are better systems that have won that do it so much better, Kubernetes. [0:12:16]

‍

Richard Rodger:  [0:12:17] Yeah. There’s a narrative in my head that I want to sense check with you. And then you made a very insightful comment that I’ll come back to, which informs maybe a bit more perspective. It looks like what was done with Docker was a classic example of using developer relations to gain early adoption. Something was packaged up so that it was friendly for developers, in the same way that Stripe packaged up payment APIs. 

‍

And then you get this massive adoption. And you would think, based on the back of that, that Docker or Docker Swarm is going to win, because it’s super friendly for developers. And even now, I would say Docker’s still friendlier than Kubernetes for developers. I don’t think anyone would argue with that too much. [0:13:14] 

‍

Marino Wigay:  [0:13:14] Very much so. You’re correct, yes. [0:13:16] 

‍

Richard Rodger:  [0:13:18] I would have been making bets on Docker Swarm back in the day. Then out of nowhere, Kubernetes comes along. And it turns out that we have to use Kubernetes to deploy this stuff, and yet Docker still seems friendlier to developers. So, it was always a bit mysterious in my head. 

‍

But you just said the thing Kubernetes did was, worried about operator relations, which is the other part of the puzzle. That explains a lot. I was confused about it when it happened at the time. And I didn’t mind Kubernetes and it’s pretty cool. But I never understood why it won. Was it operator relations? Can I use that term? Is that a term? [0:14:15] 

‍

Marino Wigay:  [0:14:15] That’s an interesting term. and the way you bring it up is overall fascinating, because that is just it. Docker wasn’t built for the operators in mind; it was built for the developers in mind, to run apps at speed. But when it came down to taking things to production, making things a little bit more enterprise-y, Kubernetes won, not only because of the fact that it was massively adopted, but you start looking at the organizations behind it that massively contribute to the project: Google, IBM, VMWare, RedHat. And a whole bunch of other companies out there, AWS even. 

‍

They jump in and they’re effectively contributing to the project, but influencing the direction to make it more enterprise-like. So, who gravitates towards this? The exec. They see something very enterprise-like backed by all these massive vendors – here we go. Let’s go down that path. and then Docker’s off to the side, not heavily backed, as much as Kubernetes is, but still does the job. [0:15:18] 

‍

Richard Rodger:  [0:15:19] They got a lot of VC money, right? [0:15:21] 

‍

Marino Wigay:  [0:15:21] They got money; they got money. But it comes down to the adoption and the amount of folks that have much more consumed Kubernetes, but also made it much more developer friendly. So, when you take that approach now you’ve got a massive community behind it, not only using it and consuming it, but building it on top of it, extending the ecosystem, pointing out the flaws and the fallacies of the technology, to make sure that the next iteration becomes better. Because the next iteration’s not going to be Kubernetes; it’s going to be something else. We just don’t know what it is yet. [0:15:54] 

‍

Richard Rodger:  [0:15:55] We’ll come back in 10 years. I’m too exhausted. Gives a break. We were still learning Kubernetes. Let’s talk about observability, because if you don’t know how important it is – if you’ve been on the front-end side of things and your developer relations work has focused on more that end of the developer world, you might understand how that term is critical to running large systems. Maybe, Marino, that’s a big ask, but maybe take it from the top, and why it matters so much. 

‍

Observability is a very critical theme that – it spanned many decades. The way we’ve decided to build apps has garnered a much larger need for observability at the most micro-level possible. And it comes down to the performance, the availability, the capability of an application and the results after the fact, the outputs that we see. 

‍

Let’s take for example, I want to build a simple web application that you throw in a few characters and it’s going to autogenerate a password for you. It’s going to have those three extra characters for you. The things you don’t know about what that app is doing behind the scenes is how it’s calculating or randomly generating that password for you. Maybe the developer knows and has pulled an algorithm from outside. 

‍

Now there’s a few key problems here. Because that developer pulled an algorithm from the outside world or from some public repository, they don’t know any known vulnerabilities that might exist in that code base, so they might be using it unknowingly. Maybe those passwords, because they’re not salted or hashed in some way, are now being sent somewhere else, and we don’t know about it. We haven’t paid attention to that. 

‍

That’s another observability point. We’re not knowing; we don’t have the insights to know where this data might be exfiltrated to. There’s a hand in hand combination; your security goes with observability. But then it doesn’t stop there. What happens when our app breaks, when it stop responding? 

‍

We don’t have the true picture of why; we can’t tell why; we can’t understand why, because there was no observability tool to discern what could be going wrong. There could be outside log systems that we can tap into, but if we haven’t instrumented it correctly, we’re not going to be able to sift through that data, that log data, and truly know what’s going on. It’ll take a while, but it’s possible, but it’s just it’s going to take a long time. 

‍

Observability becomes extremely key, not only in cloud native, but any operating environment that you run in, because you’re using it to be able to be preventative, to know how things can go wrong, when it can go wrong and be proactive about it. But also, to gain insights and feedback as to how you can improve upon something. 

‍

Let’s say you have this one application that is receiving so many requests that it’s always hitting 100% CP utilization on the back end. And because of that, requests cannot be fulfilled in a timely manner. So, there’s latency; there’s a delay; the user experience becomes poor. So, what do you do? Do you scale it? But if you want to scale it, how do you know that you need to scale it? 

‍

You have to have an observability system behind the scenes to be able to tell you and alert you that you’re starting to hit that CPU threshold; it’s time to autoscale. The issues might not be just there, but the things that we want to be looking for is latency, any sort of errors towards our requests. All the traffic that’s coming in and all the saturation, LETS, that’s the acronym. The four golden signals is the key to observability. [0:19:57] 

‍

Richard Rodger:  [0:19:59] And that’s where Docker fell down; they didn’t – they should have put those VC dollars into observability maybe. It’s an awesome tool, but I’ve suffered that, and that’s eventually why I ended up using Kubernetes in the end. The other interesting question I had for you, given your background, is how – you ended up in – you were working initially pretty strait-laced in big enterprises – operations, engineering, that type of stuff. 

‍

How do you end up running communities, Kubernetes communities and open-source communities, and changing the DNA of a company to be – to have customer relations. When I guess you started out your career with Cat 5 cables and moving racks around the place, that sort of stuff, and replacing fans. [0:21:00] 

‍

Marino Wigay:  [0:21:01] That’s exactly – I’m glad you bring this up, because it’s all cumulative; it’s additive. It’s constant growth and you build upon everything that you developed in terms of experience. Let’s talk about the enterprise for a second. The enterprise is a safe space for a lot of people to grow, but not feel the pressures of – oh my Gosh, we have to do this now; we have to do that now – of a startup. 

‍

In those kinds of organizations, there are a lot of programs that are established to help you grow individually, to help you grow technically, to help you grow professionally, in a lot of different ways. And also, a lot of these organizations at the same time have the capital to be able to establish new programs. 

‍

So, they’ll follow the trends and they’ll see the fact that there’s developer relations as an activity, as an organization, as a function, that we probably need to take on – let’s experiment. And we have the money; we can do it.  You have a team that focuses in on a community that’s already been established. 

‍

In fact, the Java community has been established for a very long time; there are plenty of advocates that exist. And it all started with them when you think about it. VMWare, as an example, plays on that. They take on a little bit of the persona of what Pivotal did for that community and they execute at scale. 

‍

Meanwhile, I’m here at the side and I see that, and I’m like, “I like this, but I don’t want to see myself doing this at VMWare. Let’s go try something elsewhere, outside.” Going to the startup side of things, you have a lot of flexibility, a lot of agility and momentum; you could do a lot of different things here. And today, I decide at the end of the day I don’t want to work in advocacy any more and I want to move back in the field. That can happen within a couple of the weeks pretty easily. 

‍

But the idea is that, when you look at a massive organization like VMWare, they can offer up all the necessary foundation you need to go succeed elsewhere. And that’s pretty much why it was perfect to work there for a while; learn all the things, get immersed into Kubernetes. And then find my path elsewhere, come to a startup. And I continually found my path here. 

‍

But building those communities is like, I have this opportunity to share my story, and maybe through sharing my story, there will be 20-30% of those folks that can heavily relate to what I’m talking about is relatable in their day job, and they’re looking for a way to transform. Let’s attach ourself to that story and we’ll keep watching to see what this guy does. 

‍

A year and a half later in the advocacy role and people still ask for this stuff. They want to know more about some of the basics of networking, because they’ve never understood it. If you show up with Kubernetes cluster and everything works, but how does the packet move around?

‍

And the fact that they want more and more of this means that what I’ve been doing has been affected. You grow the community organically by focusing in on a niche area that no-one wants to talk about. They might think it’s boring or it’s – they don’t have to share about it, but people have to care about it. Because it’s the fabric that ties us all together. [0:24:16] 

‍

Richard Rodger:  0:24:19] By starting in enterprise, it gave a bit of personal space to build the skillsets. It’s a question people often ask; should you start your career in a startup or should you start in a big company? We’ve – we took completely opposite pathways into this game. I often think maybe I should have done the enterprise thing; life might have been a little bit calmer. 

‍

Speaking of enterprises, what I think you said is that a lot of them are seeing that developer relations is now a standardized activity, something they need to do. And they have budgets, so they set up a developer relations team; I don’t know do they set up an office, do they put it under CTO, CMO. But my concern is, is that just ticking a box? 

‍

Because the most effective uses of developer relations, the times that I’ve seen it move the needle, is when there’s endorsement and support right from the top of the organization, when it’s seen as – it may not be seen as critical to sales, but it’s seen as important to close the deal, because you get the constituency of developers over the line. 

‍

And also for recruiting, because it brings people in; gets people excited about their organization. I’d have a concern that in an enterprise, it would be ticking another box. And there’s no there, there. Do you think that’s what’s going to happen, or do you think the value of developer relations will ultimately trump that? [0:26:14] 

‍

Marino Wigay:  [0:26:16] For large organizations, they’re going to look at that developer relations and look for some value; they’re going to look for impact. They’re trying something they have been trying for a while. And I’ll call in a few examples of successful developer advocacy in relations programs. AWS has one that’s been working phenomenally for them.  RedHat has had a developer relations program for a very long time, and it continues to thrive. 

‍

But you have to think about why you would want to start a developer advocate or a developer relations program. You want to provide some outreach; you want to relate to these developers or practitioners and you want to enhance your community. There is the subtlety of, I want to turn some of this into actual sales, but the reality is that advocacy, that relationship, is more about building the top of funnel through that community building. 

‍

You have this top of funnel. We’re not going to actively take and cherry pick from that funnel and turn that into an actual deal or opportunity. That funnel was there for us to nurture, educate, continue to engage with. And it becomes the responsibility of turning those dev rel qualified leads, what I consider top of funnel, into marketing qualified leads, into sales qualified leads. And then turn them into actual opportunities. 

‍

But we stopped at that level where the funnel is developed, and it’s the organic funnel. Not the, I’m going to scan your badge at a conference – more like, “I’ve developed a Slack channel and I now have 100 years. Last month I only had 50 and the month before, I had five. And now I have organic users that care about this.” 

‍

And that’s the top of funnel where you have to look at other teams to go and execute on if they decide to. Maybe some of these don’t ever convert and that’s okay too. It’s not an overnight thing; developer relations, developer advocacy, is a very long game. Leadership teams need to sit there and realize this, so it goes all the way to the top. 

‍

If they’re not sponsoring it, if they’re not providing enough time for an advocacy or a relations program to properly execute – it’s not a six-month thing; we’re talking about a year plus – then you’re not going to see the results, the longer-term results. And I have clear cut examples of things I’ve done well over a year ago that are only now starting to be fruitful. [0:28:41] 

‍

Richard Rodger:  [0:28:41] Yes. And that’s a common experience in developer relations. Easily takes 18 months, two years, three years, for things to germinate. Which is why we have so much angst about measurement, quarterly measurement, because it’s hard to demonstrate value. Marino, can I ask you a controversial question? [0:29:04] 

‍

Marino Wigay:  [0:29:05] Absolutely. 

‍

Richard Rodger:  [0:29:08] We know the value of open source, and Kubernetes has benefited from its really friendly attitude to open source and support by a lot of the community members, corporate and individual people. Do you think Terraform made a mistake? What do you think’s going to happen? You don’t have to answer. [0:29:32] 

‍

Marino Wigay:  [0:29:35] I’m very neutral about this, because there’s two sides to that conversation. There’s a business that needs to make money and then there are consumers that have used this technology for a very long time and are just realizing the effects of a company deciding, “We need to make more money off of this.”

‍

In the grand scheme of things, what I end up seeing is, this will continue to happen; Terraform and HashiCorp will continue to do their thing. Open TF or open Terraform, that initiative that was struck up or that was forked over right after this announcement, is probably going to continue to be a thing. Because there’s a lot of consumers and there are a lot of companies out there that have backed themselves into using Terraform as part of their larger offering. 

‍

None of that’s going away; the experience doesn’t truly change. The legalities of it become more apparent as to how you use, sell, consume the software. And I’m not a lawyer, so I don’t know the real legalities behind what could go wrong here. What I do see though is that if HashiCorp was able to pull something like this and make a move like so, I’m certain that there are other companies out there that have leveraged the community to develop their open-source software that can easily do the same thing. It doesn’t come down to a business decision, right?  [0:30:58]

‍

Richard Rodger:  [0:30:59] Yeah, and you can sympathize with them, because you’ve put all this effort into the community and building the software, and then other organizations can deploy it. Look at Elasticsearch. So, you can certainly sympathize with it. Do we need to think collectively about a slightly different approach?  I know you have people who are – a very pure idea of what open source should be. And I’m not even talking about the GPL side of things; I’m just talking about open source in general, even if it’s MIT or BSD or whatever. 

‍

But maybe there’s another middle ground between pure commercial and traditional full open source. Maybe we collectively need to get more sophisticated about this. Because it’s nice to have open-source communities, but our bread and butter – who pays for the flights to the conferences? Who pays for the laptops? Who pays for the time to write open source? [0:32:08] 

‍

Marino Wigay:  [0:32:10] It’s-

‍

Richard Rodger:  [0:32:11] Yeah, I don’t know; I don’t know the answer .I don’t know the answer. [0:32:14] 

‍

Marino Wigay:  [0:32:15] I don’t know; I don’t now the answer either, to e honest, but it can go in one of two directions.  We could continually go on the same path and have outside contributors that aren’t compensated, so we’re going to have to fight to make sure that they’re compensated. Because they’re not associated with any organization; they’re doing free work. 

‍

We have to find a way to pool funds to make sure that they’re paid for. But on the other hand, this could go in a different direction and everyone can lock up everything. Everything has to be licensed; there can be no more open source. There won’t be flexibility in the way we do things, and there will only be a single way to do everything. And we don’t want that; we want to be able to foster the innovation and collaboration, so we’ll never go down that path. 

‍

That middle ground though, what you’re describing, the collective minds of the folks that not only drive cloud native, but outside in other open-source areas, need to come together and sit down and establish how do we present another HashiCorp from happening? And it’s not a knock against HashiCorp either, but how do we prevent this so it doesn’t have a massive, profound, radiating impact, on both the community and the way open source is consumed. [0:33:23] 

‍

Richard Rodger:  [0:33:26] There are always difficult, narrow pathways to navigate with this stuff. I’ve certainly had interesting discussions with investors and even clients over the years about – the classic dev rel one when you’re working with a client, especially when they’re not software-aware, is, your SDK has to be open source, has to be on GitHub. I’m not open sourcing my software. You have to make your SDK open source. It leads to some interesting conversations. 

‍

Let’s wrap that up. A lot of really interesting insights, and really like this idea of Kubernetes focused on operator relations; that answers a question I’ve been – I’ve never understood. I’m a developer; I’ve compiled Apache and installed it and all that sort of stuff. But I’ve never been the guy that gets called at 4am on a Sunday morning. It explains a lot. Marino, thank you so much. This has been, for me anyway, slightly revelatory. Thank you so much. [0:34:53] 

‍

Marino Wigay:  [0:34:55] It’s been a pleasure, Richard, honestly. It’s been a pleasure to talk about some of this stuff, and talk about what’s been going on and transpiring in the ecosystem. At the end of the day, things are pretty much the same. Things throughout the decades will stay the same. 

‍

It’s how we look at things and how we perceive it and the optics behind it is Kubernetes today. Like you said, 10 years, we’ll have this conversation; it’ll be something else doing the exact same thing that we’ve been trying to attain. But no, I really appreciate you having this conversation with me, Richard. [0:35:29] 

‍

Richard Rodger:  [0:35:30] Awesome. Take care, good luck. 

‍

Marino Wigay:  [0:35:33] Thank you so much. 

‍

Endnote

‍

Richard Rodger:  [0:35:35] You can find the transcript of this podcast and any links mentioned on our podcast page at Voxgig.com/podcast. Subscribe for weekly editions, where we talk to the people who make the developer community work. For even more, read our newsletter. You can subscribe at voxgig.com/newsletter, or follow our Twitter @voxgig. Thanks for listening. Catch you next time. [0:36:03]