It's no secret that open source software is now commonplace, if not the norm in some layers of the enterprise technology stack. What's less understood, however, is how exactly enterprises and other large organizations should architect their open source strategies to maximize the upside. Software of any type is only as good as the teams developing it and how much users are willing to invest in making it work for them.
In this episode of Cloud Native in 15 Minutes, RedMonk co-founder and principal analyst Stephen O'Grady shares insights from his years of knowledge watching the world of open source. He dives into a number of issues, including new licensing trends; company-led vs. foundation-driven projects; when to choose a specialist and when to choose a cloud provider; and how open source really affects IT budgets. He also explains the benefits of contributing to open source projects rather than just consuming them.
Here are a few excerpts from the episode, where O'Grady gives his thoughts on the topics mentioned above.
You still pay for open source, one way or another
"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. 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 as you're used to.
". . . With open source you can theoretically enjoy lesser costs in the sense that in many cases there are multiple suppliers, versus something like a Windows, for example, where you can only get that from Microsoft. . . . I mentioned MySQL earlier, which was primarily developed by MySQL. Other people can pick up and support that code. So if you don't like the support or service that you're getting from MySQL, theoretically you could go to some third party supplier, Percona or somebody else. So that has the ability to somewhat decrease your costs.
"But at the end of the day, like I said, the most important takeaway is that 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."
Creators and cloud providers offer different things
"Typically what you find is that the company—take an Elastic—they're the ones who primarily develop the software. They employ the vast majority of engineers on the planet qualified to develop the software. So for sure there's going to be a technical distinction in terms what they're able to offer. Depending on what you need, that may be the right fit.
"In other cases, it may be a case of, 'Alright, well, the 20 percent or whatever of actual technical delta is not super important to me, I just have some basic needs. In which case I'll go to a mega cloud provider. 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.'
"It really comes down to: what are you trying to do, and how strategic is the asset in question? And if the asset in question is strategic, then it's pretty reasonable at least to consider the people developing that asset as your first stop, versus folks that are more in the business of, essentially, 'Hey, I run this and maintain this at scale.' Those are meaningfully different things."
A good open source license is a widely understood one
"What we've seen to date is that each new hybrid or, or non-compete, license seems to encourage the next. And that can lead to what is called 'license proliferation' . . . And what that essentially means is that licenses work, essentially, if we have a more limited set of understood licenses. If everybody starts coming up with their own license, then every license consideration is a one-off. And 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 new vendor comes out with, "Here's my license" and "Here's my license" and "Here's my license," that's not good for the vendors, [and] it's certainly not good for the businesses who are going to be basically having to review more licenses."
Open source contributions are a valuable exercise
"If you're an organization of sufficient size that you run some open source piece of infrastructure and you have a patch, you have a fix, you have . . . something to potentially contribute back to the project, essentially you have two options. Which is try to contribute that back upstream to the project and have that become part of the core, or, essentially, applying your unique patch every time a new release has come out. And, in many cases, that'll void your support or your warranty.
"That doesn't seem like a terribly complicated choice to most people, so that's why we're seeing more thoughtful policies about contributing back to projects. And it can be difficult in some circumstances because what you hear from enterprises is, 'I don't want to subsidize the development of this vendor's product,' and so on. But we're gradually getting people to the point where it's like, 'Look . . . you're not paying to develop it. You're paying not to have to re-patch this thing over and over.'"
. . .
"And you can also recruit, in many cases, better talent. Because if I'm a talented engineer and I can pick between two options—one in which I write a whole bunch of code and nobody ever sees it; or, two, I write a whole bunch of code on behalf of an enterprise and it makes its way into these public open source projects—I'm more marketable in the second example."
Subscribe here
Cloud Native in 15 Minutes publishes bi-weekly, and you can find it on most of your favorite apps and platforms, including:
