Welcome to the Cloud Native in 15 Minutes podcast. If you haven't listened before, the goal of this podcast is simple, to explain some complex but increasingly important and even strategic technologies and about the time it takes for a coffee break or a walk in the park or a short commute, whatever it is you do in 15 to 20 minutes. I'm your host, Derek Harris from Pivotal, and the topic today is open source, specifically how enterprises should think about open source software. Joining me to discuss that topic is Stephen O'Grady, co-founder and principal analyst of Redmonk, an analyst firm. We dive into a wide number of topics involving open source, including everything from, you know, the actual cost of open source, whether it's worth doing it yourself with upstream code or buying something from a vendor, whether it's worth contributing to open source projects versus just consuming them, how concerned enterprises need to be about some of these new open source licenses that have been sprouting up from companies the past couple of years. So really, really insightful conversation. Stephen's really informed on these topics and offers, I think, some good advice and good ways of thinking about it. And before we get into the interview, just a quick reminder, if you listen to this podcast on Apple Podcasts, especially, please give a review and a rating. It's really helpful. And also, if you like what you're hearing on the podcast and want to read write-ups of these podcasts and want to read more about digital transformation and some of the underlying technologies and cultural changes and just everything like that, you can follow the Intersect blog. That's at pivotal.io slash intersect. We're also on Twitter at at intersect IT. And with that, here's Stephen O'Grady and me talking about open source. All right, Steve. So to start, can you talk about, like, as a general rule, how much weight companies should give to whether or not software they're considering using is open source? Honestly, I think it depends on the company. If I'm making the decisions, if it's a company that I'm running, open source certainly affords
2:02some advantages, you know, in the sense that it's sort of most obviously, you can, you know, potentially mitigate, you know, sort of the threat of lock-in. This is assuming, of course, relying on an open source project that enjoys support from multiple parties. In some cases, there are cost advantages. In other cases, you know, there are advantages in terms of being able to see the source code and, you know, sort of understand sort of what it's doing in sort of rarer cases, you know, sort of making fixes or contributions yourself. But the net is, is that, you know, there's no hard and fast rule that open source is better in every case. But, you know, sort of the landscape today is that the majority of infrastructure software tends to be open source, and there's a reason for that. All right. Yeah, you mentioned infrastructure software. Does it matter what layer we're talking about? Because there's, you know, there's obviously a difference between maybe an infrastructure software like Kubernetes, and you move up to the database layer where you're going to mix the stuff. And then like at the application layer, there's not a whole lot of open source, frankly. So it seems like. Yeah, for a whole variety of reasons, you know, typically when we talk about open source within the enterprise, you know, we're typically talking about infrastructure, right? And, you know, while functionally, obviously, something like Kubernetes is very different, you know, than a database, in big picture terms, from an enterprise standpoint, there's not a lot of distinctions, you know, between them from an open source standpoint, again, with the exception that, you know, there are, I don't know, databases, for example, that are sort of backed by single entity rather than, you know, sort of a sort of wider community, you know, so that's something you have to take into account. But by and large, like I said, if you're going to be using infrastructure software, the odds are pretty good that you're going to be using something that at a minimum is based on open source software, if not open source software outright. All right. Is there, I mean, is there a reason that, do you think there's a reason why the infrastructure layer is so open source?
4:02Is it just a matter of like, you know, low, like less value add, I guess, or? Well, you know, I think there's, I think there's any number of reasons for that. You know, there are, you know, there have been sort of competitive drivers, you know, for people to contribute in this fashion for, for a long time, right? So in other words, if you, for example, if you want to go back to the rise of Linux, right? You know, Linux was, you know, sort of a combination of, you know, developer led in the early days, you know, where developers wanted to get their hands on essentially an operating system, you know, without having to pay for a commercial version, you know, something like Windows. And that was complimented sort of ultimately by companies, you know, that wanted to sort of decrease the, the stranglehold that Microsoft's enjoyed, you know, via Windows on customers, right? So, you know, that sort of ushered in an era in which, again, driven by different motivations, you know, sometimes it was primarily developer led, sometimes it was more commercially led, you know, many times it was a combination of both. You know, we've, we've had an era where open source software has been infrastructure, open source software, I should say, has essentially become the default. And as I said, there's no single reason for that, but, you know, over time, it also becomes a self-fulfilling prophecy in the sense that, you know, if you, if you have open source software, say at an operating system level and a database level, then the question becomes, okay, why wouldn't I have that for my orchestration, my container orchestration layer, right? Why would that sort of uniquely be proprietary? So, you know, basically what we've, what we've seen over time is, you know, sort of a mix of factors that led to it. And then, you know, as I said, it just became a, essentially a self-reinforcing cycle, you know, over time, you know, it has led us to where we are today. All right. You mentioned earlier the, that data, some database projects, for example, are ran by maybe a single entity or a company rather than, let's say a foundation.
6:04Do you see a difference or should companies think about a difference between something managed by a foundation versus managed by a single entity? I guess I can think of reasons. Yeah. I can think of examples, I guess, where foundations, you know, are, you know, are better sometimes where it's like, well, you know, that's not a very active foundation or that's not a very active community. So how do you weigh that element of it? Well, you know, I think, you know, very much like open source versus proprietary software, there's no sort of one size fits all, right? You know, so there are situations in which, you know, sort of you will be perfectly adequately served, you know, by a, an open source project that is backed by a single entity. You know, and the nature of open source is such that, you know, even in cases where, you know, for example, MySQL was primarily developed strictly by MySQL for years, right? And, you know, without getting into the minutia of the licensing and the dual licensing model, there were many sort of external changes available. But as if you're talking about vanilla MySQL, that was, you know, sort of a project that was developed almost entirely by MySQL, the company, at least in the, in the early days, it's, it's changed, you know, somewhat since then versus Linux, right? Linux was very much the sort of confluence and collaboration between lots and lots of different sort of commercial third parties. Both of those were, you know, very successful projects, you know, sort of in their own right. So there's no, there's no sort of, you know, sort of hard and fast, you must do one or you must do the other. Sort of the, the sort of one thing that does tend to, you know, point people towards foundation led projects is that you are theoretically at a decreased risk of being locked in, right? Because, you know, if you are sort of primarily oriented on a project that, you know, comes from one provider, then, you know, by, you know, sort of by virtue of being the sole provider, they're able, they're in a position to sort of more easily dictate terms to you, you know, versus, hey, I can theoretically get this open source project from any one of multiple players.
8:05In practice, you know, how does that really work is sort of an interesting question. But yeah, there's no, there's no one way to do this. All right. And you mentioned, so we've talked about, you mentioned locking a couple of times. The one thing we haven't talked about is cost. And I wonder, you know, I think this might just be, you know, element of maturation in terms of both buyers and, and the open source community. But I mean, what's a realistic way to think about if I'm a company or enterprise saying, hey, listen, we're, you know, we're committing to open source, you know, that, like, that doesn't mean free, right? So what, what's a realistic way to think about what, how does that cost structure shift as you make that switch? Well, a lot of it depends on the layer, right? You know, the layer that we're talking about, you know, the most important thing is exactly what you said, right, which is that open source is not, is not free as in, as in beer, right? And that has been a sort of less, much less of these days, but certainly years ago, people would sort of look at this and say, hey, I can sort of go get this off the shelf, you know, pick a category operating system database, whatever, and say, hey, I can use this for free. Well, at the end of the day, most businesses are not in the business of maintaining or developing software, and therefore, they need help with that, right? And so at some point or another, you're going to be paying for it, even if you're not paying for it in the form of an upfront license, you know, sort of as you're used to. So, yeah, in other words, that's, you know, that's the most sort of important change. Now, as I mentioned before, you know, with open source, you are, you can theoretically enjoy lesser costs in the sense that in many cases, there are multiple suppliers versus something like a Windows, you know, for example, where you can only get that from Microsoft. And even in cases where, you know, there is, you know, I mentioned MySQL earlier, which was primarily developed by MySQL, other people can pick up and support that code, right? So if you don't like the support or service that you're getting from MySQL, theoretically, you could go to some third party, you know, supplier or Percona or somebody else. So, you know, that has a, you know, sort of has the ability to, you know, sort of somewhat
10:09decrease your costs. But, you know, at the end of the day, you know, like I said, the most important sort of takeaways is that this isn't, you know, this isn't free. You're going to have to pay for software to be developed and software to be supported and serviced over time one way or another. All right. Yeah, I think, yeah, I think that the, I would ask, is there, do you censor the type of company or do you, when you're talking to clients, is there a type of company where it makes more sense maybe to do this DIY or do it yourself approach, right? Using vanilla open source, using, you know, upstream open source and investing in engineering versus saying, hey, there's an enterprise version of this product. That's probably where we should be investing. Well, I mean, you know, sort of the classic example that, you know, are some of the classic internet companies, right? In the sense that, you know, if you are in Amazon, if you're Google, if you're a Facebook or whoever, right, you're probably not, you're going to be operating at a scale in which licensing in sort of traditional, even if you're not paying sort of per license of software, if you're, if you're licensing for support and service on a sort of per machine basis, that just isn't going to work. Right. So at that point, you know, it's one of the reasons that, you know, sort of all of the above, you know, have invested heavily in, you know, developing, for example, and approving, you know, MySQL is one example, right? Google and Facebook, you know, in particular, you know, have had, you know, teams that have been very, very good at sort of building, maintaining, running that software, you know, but that's not most enterprises, right? That's not most businesses. Most businesses are not going to be anywhere near that scale. So, you know, I sort of put the sort of companies that are in the bucket of managed, you know, being in a position to sort of really invest in and manage their own open source software as a very, very small bucket. Everyone else for the most part is going to need help at least somewhere. You know, they may choose to run, you know, certain pieces. You know, if you are, for example, a small business, many small businesses rely, you know, historically rely on things like the LAMP stack, you know, to, you know, essentially to run
12:11websites and things of that nature. And that's not something where you need to go out and buy a license for, you know, say Red Hat or MySQL and so on, you know. So, you know, there are things where, okay, you know, this is not a huge area of focus. But for most businesses, you know, you're probably going to want to pay in something like a traditional enterprise fashion. Yeah. The one thing that struck me lately is looking at a project like Kubernetes, for example, right, and saying, like, this thing is being updated. You know, the new releases are coming out every quarter. Right. And the long-term support is not, you know, is whatever. It's like N minus two or whatever it is, right? And so basically, yes, if you fall behind real quick, if you're not used to, if you're trying to manage that and you're not used to that pace of change and updates and upgrades. Well, it's also, you know, is that a good area for you to invest in, right? In other words, you know, if you're part of your job, you know, is sort of building out an operating sort of infrastructure at scale. It might be. But if your focus rather is, all right, I need to develop, you know, essentially applications, you know, for my customers, whatever those are, and I don't care as much about the enterprise or the infrastructure rather, then, yeah, it's probably not going to be a good area for you to invest in. So, you know, it really comes down to, you know, sort of what are you doing? What are you providing? And what's most important to the organization? What's your focus? All right. And then how do you feel about or what's your thought process in terms of, you know, again, like if I'm in a large enterprise, you know, going with an open source product first, you know, that's coming from, even if it's an enterprise version, right? Even if I'm paying for it, that's coming from, say, a startup of which there are many or even a startup or, I mean, there are public companies, frankly, that are pretty small in this space, right? Relatively speaking, compared with an Elastic, perhaps, right? Compared with like an open source project coming out of Amazon or Google or Microsoft or one of these large vendors. Is there a trade-off there? Yeah, for sure there are. Typically, what you find is that, you know, the company, you know, taking Elastic, you know,
14:11they are going to be in many, you know, they're the ones who primarily develop the software. They employ the vast majority of the engineers in the planet qualified to develop the software. So for sure, there's going to be a, you know, sort of a technical distinction, right? In terms of sort of what they're able to offer. You know, so, you know, depending on what you need, you know, that may be sort of the right fit. In other cases, you know, it may be a case of, all right, well, the 20% or whatever the sort of actual technical delta is, you know, it's not super important to me. I just have some basic needs, in which case I'll go to a mega cloud provider, right? I'll go to one of the hyperscale folks. And yes, this is not going to be bleeding edge. And I may lack features A, B, and C, but I don't care about those, right? So again, it really comes down to what are you trying to do? And how strategic, I guess, is the asset in question? And if the asset, you know, in question is strategic, then, you know, it's pretty reasonable at least to consider the people developing that asset as your first stop, you know, versus folks that are more in the business of, you know, essentially, hey, I run this, sort of then maintain this at scale. You know, those are meaningfully different things. All right. For sure. Okay. And then the other question, I mean, and speaking of Elastic, this is like, should enterprise users care, particularly their buyers care about, there's been a kind of a spate of modified open source licenses that have come out over the past couple of years. You know, my take personally, and I could be way off, is that this is probably more, and this is definitely an anti-competitive sort of maneuver versus something trying to, you know, lock in customers. But I'm curious what your take on that is. I would agree. I tend to think that, well, put it this way. I think the behaviors, the trend towards these sort of anti-compete licenses, you know, or hybrid licenses, you know, as I have typically referred to them, I don't think are going to yield the benefits, you know, that the folks employing these licenses expect.
16:11So I think from a strategic standpoint, these efforts are misguided at best and damaging at worst. As far as the enterprise buyers, you know, should they care, you know, the folks employing these licenses will tell you no, in the sense that, you know, look, you know, in many cases, if you're engaged in a commercial relationship, very likely you're buying your way out of, you know, the sort of the complicated license. And so therefore you don't care. My take is, is that that's incorrect for a couple of reasons. One, that assumes that you are aware of all the usage within your company, which tends not to be the case in my experience. In other words, you may be aware of, you know, sort of most of the usage, but if somebody is in an area of your company and is using the license in a way that is incompatible with these new provisions, then, you know, you may end up running into difficulties as a result of that. But also at scale, you know, it presents a, it presents a challenge for businesses, right? Because basically, you know, we have evolved into a world in which open source is essentially accepted at most mainstream enterprises because the licenses themselves are standard, predictable and understood, right? So over a period of, you know, better than 20 years, you know, these licenses have been released, embedded and, you know, have really stood a, you know, withstood a fair amount of legal scrutiny, both on a market basis and within sort of individual enterprise buyers, which is why most enterprises say, okay, we have a sort of approved list of, you know, you can use, you know, these licenses, you know, if the project you want to use is one of these licenses, you're fine and you don't have to come talk to us. And the difficulty is, is that with a lot of these modified open source licenses, they, you know, aggressively and in some cases intentionally blur the lines between what is open source and what is not, right? So, you know, one of the, one of the sort of implications of a couple of these is, well, you can't offer this as a service, you know, and the intended target there is Amazon or,
18:13or, you know, Microsoft or whomever, you know, any of the hyperscale cloud providers. But what if you're in a scenario where a centralized IT, you know, runs, you know, sort of the software and then offers it up to divisions as a service, do you trigger that license or not? That's something that previously you would not have had to worry about because we, we understood the boundaries of these licenses. Now, maybe you do. And, you know, what we've seen, you know, to date is, is that, you know, each new sort of hybrid or, or sort of non-compete license seems to encourage the next. And that can lead to, you know, sort of what is called license proliferation, which is something that the OSI, you know, has, has fought for years, you know, many, many people who have tenure in this industry on the open source side have fought as well. And what that essentially means is that, you know, licenses work essentially, if we have a, a more limited set of understood licenses, if everybody starts coming up with their own license, then every sort of license consideration is a one-off, right? And that just, that just doesn't work. So in other words, if I have the GPL or the Apache license and they apply to whole swaths of products, I can evaluate a license once and then approve dozens of these things. If every, you know, if, if every sort of new vendor comes out with, here's my license and here's my license and here's my license, you know, that's not good for the vendors. It's certainly not good for the businesses who are going to be, you know, basically having to review more licenses. So yeah, I am, I am very strongly against these licenses. I have recommended against them both publicly and privately. Um, but at present they seem to be, they seem to be rowdy, uh, for better or it might be for worse. Great news for legal teams though, right? Yeah. It never stops. More work for them. And then finally, Steve, like, you know, so the other, so there's obviously the consumption side of open source, but how do you think, how do you think organizations should look at like the contributing side of open source, right? Whether it's contributing back to projects they use or whether it's, you know, actually,
20:14you know, starting their own projects and open sourcing them, is there value in doing that? Yeah, for sure. Uh, you know, the effort there is high, right? The education side is, is, uh, non-trivial, um, for sure. But in other words, like, think about it this way. If you, if you, um, you know, if you're an organization of sufficient size, you know, that you run some open source piece of infrastructure and you have a patch, you have a fix, you have a, you know, sort of whatever, something, you know, to potentially contribute back to the project, uh, you know, essentially you have two options, right? Which is, uh, you know, try to contribute that back upstream to the project, um, and have that become part of the core or, uh, essentially applying your unique patch every time a new release is, is come out. And in many cases that'll void your, your support, your warranty, right? And that doesn't seem like a terribly complicated choice, you know, to most people. Um, so that's why we're seeing sort of more, more thoughtful policies about contributing back to projects. And it can be difficult in some circumstances because, you know, what you hear from, from enterprises is, I don't want to subsidize the development of, you know, you know, this vendor's product and so on. Um, but we're, we're sort of gradually getting people to the, to the point where it's like, look, this isn't, you're not paying to develop it. You're paying not to have to repatch this thing over and over. Right. So, you know, progress I think is being made there launching their own open source projects. Um, it, that is a more complicated question. It can be a very, very good thing. Uh, you know, Capital One has done this with, you know, things like Hygieia and so on. Um, it's harder simply because, you know, basically launching a project, you know, takes a fair amount of time and effort. Uh, and that may or may not be of, of, you know, sort of benefit, you know, uh, to the parent organization. Um, but in some cases, you know, if the, if the software itself is valuable, uh, and, you know, sort of meaningfully, um, you know, received by the market, you can find, uh, you know, homes, you know, in, in the form of foundations that will take on that code for
22:15you. And therefore you get to offset some of the, oh, legal trademark IP validation, et cetera. Um, overhead, you know, of maintaining these projects. So there are benefits. That's a, that's a more complicated question though, than just sort of contributing fixes and patches back. Right. And kind of the implicit benefit too, is, is recruiting. Correct. In the sense that one, one, you look cool and two, but if, but two, if you're, if you're using this and contributing stuff, you actually, you, you're, you're a pool of talent to come work on your stuff. It's just immeasurably larger because there's the learning curve. Kind of. Yeah. The learn, the learning curve is, is, is for sure better. And you can also recruit, you know, sort of in many cases, uh, better talent because, you know, if, if, you know, like if I'm a talented engineer and I can pick between two options, you know, one in which I write a whole bunch of code, nobody ever sees it, or two, I write a whole bunch of code, uh, you know, on behalf of an enterprise and it makes its way into, um, you know, sort of these, these sort of public, uh, open source projects. I'm more marketable, you know, sort of in the second example. So, you know, yeah, it certainly, you know, it helps with recruiting. It helps with, um, you know, sort of the, the talent, uh, that you can recruit. It helps for retention in many cases. All right. It seems like a great place to stop. Thank you. Not at all. My pleasure. There you have it. I hope you learned something. For more information about Redmonk and to read the analysis from Steve and his crew, you can visit redmonk.com. That's R-E-D-M-O-N-K.com. And you can also follow Steven on Twitter at, at S-O-Grady, the letter S-O-G-R-A-D-Y. For more about Pivotal's broad suite of products and services, you can visit pivotal.io. And again, as I mentioned in the intro, for more information about, or for more content, frankly, on, on all things digital transformation and some of the next gen cloud native technologies, you can visit pivotal.io slash intersect or follow us on Twitter at, at intersect IT.