Open Source and the People Who Love It

Episode 77 · 49:40 · SRT · archive.org · all Tanzu Talk

Well, you know, after this recording, I got to go to the doctors for the somewhat annual-ish kind of visit. And, you know, I was thinking other than the obvious of just, like, it's inconvenient and, like, you know, U.S. health care and all that stuff. Like, man, there is just something, like, inherently frustrating and annoying about going to see the doctor. And I just don't know what it is. Do you got any ideas? What's your relationship with going to see the doctor? Yeah, last Tuesday, I had my first physical since I think I was 30. So, you know, my doctor visits have been few and far between as I stay somewhat healthy. So, you're always a little nervous, you know, stripped down. They immediately have all the control of the situation as I'm just sitting here in a weird gown. But that's fine. It's nice to get the results. So, at least you're, you know, that part's the good part of it. And I had a dentist appointment two days later. So, my body is now rejecting all doctors for the next couple of months. Yeah. Now, the dentist, that's a whole other thing. Man, that's, that's, yeah, I don't know what it is. It's just like, it's just, it's just not, it just doesn't, it's not, it's not that I'm afraid of results or anything. I mean, maybe it is just, it's annoying and inconvenient. Like, you know, it's good to, like, go get your, your, as they say, lab work done so that you don't have to do it afterwards and you can have one appointment. And, of course, I didn't do that, right? So, now I'm going to have to, I don't know. There's, there's something wrong with that. I mean, are you an eye doctor guy? Do you like the eye doctor? Oh, no, no, no, I don't go to the eye doctor. I, I, I do need to get my LASIK renewed. See, that's, I like that. That's, I'm looking forward to that. That's a good transactional thing that has clear results, so to speak. No pun intended. But, but, but it's just a lot more straightforward, whereas, like, I mean, I feel like, you know, I've never, once, once I stopped going to the, the kid doctor, what do they call that? A pediatricist? Like, I never have had, like, a relationship.

Yeah, I've never had a relationship with a doctor. You know what I mean? It's just like retail doctoring. Like, I might as well go down to the, uh, the CVS and just, like, have someone tell me to eat more fruits and vegetables and that, you know, I'm probably, you know, should be doing something different as I get older. And it's just, it's just frustrating. I don't, I don't know. It's, it's annoying. It feels like a waste of time. Well, I'm looking forward to my doctor. Looking for more intimacy. That's good. Something. Yeah. Like, you know, just go read my Twitter feed or something and figure it out. I'm sure that look on Instagram. Look at these things I'm eating and, and, uh, and blood work. I don't know. And they always tell you, like, what your blood pressure is, as if that means anything. It might as well be, like, it's sort of like, it's like, it's like if you were, like, uh, you know, you were, like, the, the VP of, you know, running a business and some, some developer came and told you, like, some error code that happened. It's just, like, I don't, I don't know what that means. What do I do about that? Error code 35A. Great. Here's a raise. Right? Like, it's just, uh, it's just, just, just. Uncomprehensible junk. So on that note, things are looking pretty good. It's like the start of this year. Yeah. It's like when a pilot tells you the wind speed on the plane. Like, I don't know what to do with any of this information. Oh, yeah. Just do your job. Doctor slash pilots. Yeah. Yeah. That's, that's fun. That's good stuff. That's, that's maybe a good analogy because, like, my relationship with the pilot talking is pretty much the volume and my proximity to the speaker that his voice is coming out of. Right? Like, all, all I really experience is, is it really loud or is it quiet so I can tune it out? I think that's a good metaphor for my relationship with doctors. It's just, like, you know, get, get me to the place. I don't really want a bunch of jibber jabber. That's right. I used to say, love doctors, the great people. That's what I'm here for in analogies. Well, in a, in a, in a completely other area, you know, I'm, I'm excited you pulled this out because I saw the headlines for it.

You know, as, as, as I'm there, as I'm sure you are scanning the headlines, seeing what's going on. And, uh, I don't know. I didn't have much to think or say about it, but it looks like Google is, is pulling more undersea cable. So what, what's the deal with that? Yeah. I mean, remember that, you know, Google's arguably one of the largest telcos in the world based on the network they own. So they're, you know, putting down some more cable, connecting more sites. They announced, I think, five new cloud expansion locations for next year. So interesting to see them kind of announcing what 2018 looks like with, which includes owning the bandwidth, which you shouldn't underrate. Is that a, that's a big deal when you own the fiber itself. Yeah. No, I think that's true. I mean, back when I, as, as I'm, I'm sure you were in this position as well. Having been, uh, at, uh, century link, but back when I was doing cloud strategy, there was a dark horse is the wrong analogy, but the, uh, maybe the, the, the iceberg under the water or the P under the mattress is always like networking. It's pretty important, man. Like, it seemed like, uh, it was an interesting asset to have. And I was just, I was just looking up, uh, uh, one of those charts that shows like cumulative, uh, CapEx at like, uh, Amazon and, um, Google and Microsoft. Just kind of like, it's, it's, it's very imprecise, but, um, uh, it's sort of a proxy of how much money you need to spend, uh, to have public cloud. And, um, yeah, I mean, building your own global network, probably part of that. Absolutely. Yeah. It's not, not cheap. Yeah. You think the benefits of being able to control the latency and not forcing people through six different ops as they go through three different providers. That's a quality of service thing that maybe other clouds can tolerate, but it seems like Google doesn't want to. Yeah. Yeah. Yeah. They need to, they need to pull some of that cable into my neighborhood here. I only get like, uh, 18 mega doodles in my house, which is crazy. It's absurd. Like I get, I get maybe like 30 on my, uh, LTE network from the same provider, which I won't name, but, uh, I don't know what the deal is. Like they could just install a cell tower here and, uh, and, and then I'd be fine.

They don't need to pull this cable. Sheesh. Yeah. I thought you knew people. Yeah. You got to cash that in. And in Austin, they only give a Google fiber to the hipsters down in South Austin. Very sad. Should move down there. I'll, uh, I'll downsize my house by a fourth and up my costs by five, just so I can get faster. And, uh, so also, you know, you pointed this out, I noticed, I, I remember running in this, uh, this guy, they hired the, uh, the Salesforce dev developer relations. They're on his head to, uh, to work for him over there at Google now. That's right. Yeah. They continue. I mean, there's, there seems to be this battle for evangelism that's going on. Microsoft's hired a strong team. Google not willing to cede any territory there continues to add smart folks. So adding Adam, who used to, as you mentioned, run dev evangelism things at a Salesforce. Now it's like VP of evangelism things at Google. So another good hire. It's good to see, uh, Google share that message. I think he, he might've been one of the people who, uh, witnessed. One of the more embarrassing, uh, epiphanies I had when I was an analyst, which is Salesforce is just a big database. And when you're talking about development, you wrap customized forms around it. And, and like, it took me a long time to understand that, like, it was just, you just got a giant database that's customized to doing this stuff. And then after that, it's pretty straightforward, all this, what all the, the, the type of development you do around it is. And I remember I was saying that to some Salesforce person and they just were kind of nodding with a confused look on their face. And I was like, yeah, didn't, didn't, didn't you know that? So. Yeah. How good about that? I mean, he seems like a patient guy. So if I, you know, just entertained you, that's fine. That's right. Yeah. Yeah. He was always very nice. And then also, you know, Ashley, who, who worked on my team for, I think maybe like nine hours or so before going to work at our friends at Microsoft, she had a pretty good write-up about what exactly, you know, developer advocates do and things like that, which is if you're interested in that kind of thing or evangelists, as they used to be called.

It's a, it's a nice write-up developer advocate is a, is a pretty, pretty descriptive phrase for that. I remember I, I was visiting with some family recently and I was telling them that, that we used to call it evangelism and they had kind of this raised eyebrow look on their face, just a little too appropriating of the usual religious things or something. But yeah, anyway, so that's, that's a nice write-up if you're interested in that. And then also, you know, I was reading through the, the speaking of Google, they have a, what is it, would you say it, is it a machine learning or just image recognition? I guess it's both, but they have a new service out that's basically like drag and drop, uh, image recognition at the very least, uh, that, that looks actually pretty handy. Yeah. And they're saying this is the first of many to come. So I think they're just trying to get to this kind of no code or not even entry level because that probably cheapens it too much, but like, I don't need to have data scientists on staff to do some basic image recognition. So, you know, maybe products in inventory or people or what have you. So I think that's pretty cool as you, you know, I hate the democratization term, but that's, what's kind of happening here is you're simplifying machine learning for people. So it seems like it's worthwhile to, uh, add your name to the list of people who want to try it out. Yeah. Yeah. And, and like I've been, uh, I still haven't found that option where I can find out what, uh, painting I look like in the Google arts and culture thing. I guess it's not available in Austin. I don't understand why. Oh yeah. I think there was something about that. Yeah. I read that that specifically, I think it was Texas or others. If there's rules about how web companies could use your data, then those apps get blocked. That makes sense. That's interesting because, you know, like, well, uh, to, to use it as a, as a foil for that, for the, uh, that thing. So I've been using Google photos for a while, which is great. Right. It has this awesome, um, I guess, I guess it's, it's probably is a good example. I I'm guessing of like machine learning and action because it somehow figures out how to cluster things. There's literally a collection of albums called things and it figures out like, here's all the common things you have and people that you have, it clusters people. And when I was looking through the, uh, that Google, uh, arts and culture or whatever app, like it kind of looks like a re-skinned Google photos with like a blog added to it.

And it is like, it's, it's a nice application. If you're into like seeing Frida Coles, like wardrobe and, uh, other things like that, it's, uh, it's fun to search through, but it, it does give you some inspiration of, of like, how would we use this kind of technology, uh, in, in whatever our own businesses may be. And I think, uh, I think the idea of having, uh, to use, to use probably a word that as, as someone on the periphery of, of technical marketing, you would never want to use to simplify, uh, and create a simplification of something as complicated as ML definitely seems good, or we could democratize it. That's fine too. There you go. No need to say it's simple, but, and there, and therefore of a lesser value for the cynical people. And then, and so the, uh, my, my wife, there's a, there's a fun, uh, crossover from normal to nerd land. She was very upset with Amazon that they haven't just named the city that they're going to have their new headquarters. And I shouldn't say upset. She was just more like, what's the deal? Like, why wouldn't they be picking? But they have narrowed it down to, uh, to 20 places. I'm not going to read all of them. Uh, but you know, so that's, that's fun. But I wanted to ask you, this comes up every now and then there's sort of like Seattle has mixed feelings about Amazon, but like, what's the deal with that? Yeah, it's funny. I mean, I work in downtown Seattle. That's where the pivotal offices and, and no doubt that I mean, I think a new high rise is going up that Amazon rented the whole thing or at least the whole thing. So, I mean, they've taken over the city, but so has Google. So have plenty of companies. I mean, downtown Seattle, I think it's the, uh, one of those, those giant cranes. It's one of the crane capitals of the world. Everyone just building new stuff. So, you know, I think there's this love, hate of, hey, it drives up housing prices because housing's crazy around here now and increases traffic and all those things. But what was interesting is once they announced that HQ2 idea, also then all the city leaders kind of descend on, oh my gosh, we're sorry if you thought that all of our hostile activities meant we didn't like you here. So it was, uh, somewhat amusing to see everyone come hat in hand back to Amazon. But I think that ship has sailed and they've got this list of cities, which, hey, you're on the list.

Congrats, Austin. That's right. So, you've, uh, I mean, I think that the funny thing is this is, I mean, pretty much a list of major U.S. cities minus Toronto. So, I mean, it's not like this is novel. They didn't throw out some weird city in New Mexico. Like this is kind of where companies do business. So I guess congrats on owning the news cycle for a couple of days. Yeah. I mean, I guess Phoenix isn't in there, right? Is that, uh, but. Sure. I mean, he missed Detroit was one of those that they missed, you know, that people were disappointed in. But I mean, for the most part, if you're going to narrow it down to 20 cities, clearly Newark's going to be on that list. Any of these cities I can make fun of, I don't know. I mean, it's a good list of cities. It's fine. It's places you would put a headquarters. Yeah. You know, up, up several layers in the conceptual stack, if you will. It's sort of like an ongoing, uh, I don't know. I would call it one of my theories in that I haven't done any sort of research. But the, you know, the theory being as, as I've been traipsing around visiting more and more people over the past three years, like there's like technical people and programmers everywhere. Like in every, every major city, they're like chock full of one, because there's always like a ton of banks and insurance companies who are like in Phoenix. Right. There's like, you wouldn't think it as, as just someone who doesn't follow this stuff, but there's a ton of insurance stuff in Phoenix and therefore IT people. And like, so yeah, there's people who can computer pretty much everywhere in, in major cities. And, and, and it is, I think, um, I think maybe in the era of, I don't know what era this was, the era of like IBM being everywhere. That was sort of not an issue, right? I mean, like they're in, they're in all sorts of places. And some of that's driven by acquisitions that they did over the past 30, 40 years, but others of it is just like, you know, you would never guess or, or whatever. Like Austin, a huge part of Austin being a tech company, not all of it by far, but it's because IBM had a huge campus here for a long time. And so, um, it's also interesting to think about like the maturity of Amazon as a company that now they're going to just have campuses everywhere, even more so than the, they do, but like major ones spread everywhere, which we'll, we'll see how people react to that as far as how it, uh, shapes things around.

It's, it's always, it's always, uh, uh, a little scary as like, you know, a well-off tech industry person to comment on, uh, changing cities around, but I don't, I don't know what to do. It helped Austin out a lot. Yeah. And sometimes, I mean, it's good to spread it out. I mean, the one thing that's almost the joke in Seattle is because Amazon doesn't really allow remote work is that you kind of have to come to Seattle. So if you've ever worked in this city in tech, you've been called by Amazon because they've either just completely drained the market up here. Like everyone who wants to work there at this point works there. And then, you know, can you keep moving people up to the Pacific Northwest? Like you just, it gets a point where you've saturated kind of what's available. So it makes sense to go pick, go put something on the East coast, go put something in Texas, go put something in the Midwest. As long as you're buying an airport, you're in great shape. Yeah. Yeah. So when some urban planners need to do some Monte Carlo stuff on like, uh, how would it affect Seattle and other cities? And because you raise an interesting point of like, well, if there's a big issue in Seattle, then maybe we can bleed some of that off. Not only we can benefit Seattle by bleeding off all the whatever badness that people might think there is, and then also help some other city out. It's weird, weird, exciting dilemma to have. So speaking of negativity, I don't think we've talked about the, uh, the specter and meltdown stuff on this podcast, right? Cause it's first, first, uh, podcast we've recorded this year. And, uh, I mean, I, I think it's, I think it's, it's pretty well covered at this point, but, but, uh, you, uh, you dug out, uh, an overview that I think is highly relevant to the, to the cloud native world. What was written up in it? Yeah, it was a good piece by Kurt who talked about kind of patching hygiene and this idea of like this thing, like this will always happen, right? There's going to be another one of these this year. There's always going to be these sorts of things. And what this continually points out is most companies just have a bad patching hygiene and it takes months, if not more. Like the joke is by the time they get the specter patch, they're just patching heart bleed, which was when like a year or two ago. So how are you thinking about, you know, if I can't patch a few hundred images, how am I also going to patch a few thousand containers?

Like there's all these different challenges of how do I deal with patching? And for the most part, it seems like it is an industry. We're just not very good at it. So the point of this piece was a bit of sometimes you need platform sort of things that can take care of some of this for you, where you're not manually rolling through servers, but the platform's doing that. So whether that's Bosch and cloud foundry or whatever sorts of tools that you've got, it seems like that's a really worthwhile investment this year because this won't go away. And you can't, I can imagine there's a few enterprises where they've had to put major projects on hold so they could get all hands on deck to go patch a few thousand machines. Like that's not going to stop. So either you get ahead of it or you're going to keep sidetracking yourself with patching exercises. Yeah, it was, it was making me think that, I mean, unless you're of a certain ilk of IT people, few things could be more boring than patching as a topic. But, but it does point to the need of, what would you call it? Is it a, is it a functional requirement? You know, probably given all the security stuff nowadays, that actually is a pretty important thing to stress out about. Like in considering what your, your projects or as we like to call them products or something, what you're, what the initiatives that you have in IT are and the new things that you're bringing in is to have a pretty thorough understanding of how do I patch this thing? And, and what do I do with it? And it, it reminds me of a, a question I got in an EBC from someone who, uh, I think, I think they were like, they were something like the VP of patching. They were the VP of infrastructure, but it sounded like they had become the VP of patching. And, and they were asking, you know, how, how Pivotal Cloud Foundry helps out with patching. And, and it felt like I was not helping them as much as possible because what they really wanted to know is like, of all of IT, how do I patch it? Like, like, how does this address it? Whereas, you know, obviously the, uh, the benefits of, of the way that Cloud Foundry does stuff works if you're running Cloud Foundry. And, you know, I guess, I guess nowadays, if you're running a Kubernetes cluster and everything, but it is, I think, I think there is a pattern to bring out of there to be, to say like the same idea of being able to very quickly patch things should probably be a very important requirement for whatever you have.

And it probably, there's probably a huge amount of business value now to like making sure you can do that. So maybe don't ship some new stuff until you solve that problem, uh, in, in the rest of the world. But that is, uh, it's, it's, it's, it's back to the old, the old, again, another theory of mine thing about security is like the way to fix security is to actually do it. Uh, which, you know, uh, that, that comes up a lot in, uh, how to improve IT. So I think we have a blog post coming out on, uh, from pivotal, just on some things of how you can kind of act forward. But I think for most, you know, if you're a listener here, the thing you can do today is every, you know, part of your sourcing contracts, when you're bringing in new software or, or hardware, one of your primary questions would be, how do I patch this thing? And can I do it through automation? And don't buy any hardware or software that you can't patch easily because it's going to cause so much heartache later. You can do that right now. So, yeah, well, just, uh, two more things you can look up in the show notes, but that I'll reference. So, uh, uh, just some, some stuff I was doing recently last week, you know, there, there's, there's a lot of, uh, a lot of consternating and hand-wringing over like how, uh, tech companies are like destroying civilization. I don't know if, if, if you were in the listeners have read that and often what they really mean is how people are upset about Facebook. They, they had often, uh, just amounts to that. Like last week, the economist had a couple of, uh, well, one that they based their, one of the leader stories off of, uh, I think, I think it was a, uh, a fun piece to read kind of summarizing it all. And, uh, we talked about it in, in, uh, in a podcast that I did last week and, and I have a little silly newsletter I do. And I found myself writing a rant about it, but I think it is like, I normally, I don't really like consumer tech stuff because I just don't, I guess. But I think it is like worthwhile kind of like, if you don't pay attention to that stuff, kind of, uh, getting, getting into, getting into it a little bit to understand it, uh, like what people are consuming. I'm concerned about when, just because these conversations come up and you don't want it to distract from, uh, talking about more interesting things like patching. But, uh, so, you know, you, you know, that, that was, that was in our, uh, software defined talk thing, uh, last week, if you want to look that up.

And then also there's been a, um, kind of a flurry of, of market sizing and spending things coming out, which I'll put links to in the show notes at pivotal.io slash podcast. But just on the whole, I think that the thing to pull from this is, is if you look at, uh, surveys that have been coming in and forecasts, it looks like people are pretty consistently saying they're going to be spending more on, uh, IT this year and in the future, which is encouraging. Cause you know, improving takes money last time I checked. So, uh, there's a lot of people who are, who are into that. So then the, uh, you, there's just the two of us here. We, we, we have a guest that we'll get back on to, uh, to talk about, uh, it was actually going to be about, uh, talking about Azure stack and things like that, but she'll be on, uh, she had to, I think she had to like go to Singapore or something, but, uh, we'll have her on to talk about that, uh, in a future episode. But in the meantime, I think, I think one of our, uh, one of your evergreen topics based on the age of the primary content you sent me is, uh, was basically discussing like the idea of, uh, to put it in my, my summary, like what's the deal with open source as a business nowadays? And, and to add, to add a bit of my spin to it, which I think, uh, watching this over the decades, which is interesting is there's always this standing question of what, what does software companies owe the open source world, uh, operating in them. And, um, you know, you, you pulled a good, a good piece from, uh, Matt assay. He's one of the few people probably like myself who would write the word stupid in a tech news article. So that's fun. And, uh, there's several other pieces, like there's always the, um, like you have one of these from, uh, James governor or over at red monk, there's kind of surveying, uh, based on GitHub. It used to be on source forge or whatever, but whatever public records of repositories, the involvement of various companies in open source, which is interesting. But, you know, so that's my setup of the topic, but like, what, what were you thinking in this area of like, uh, what's the deal with commercialized open source and how it sort of relates to a good way of operating a software?

company nowadays. Yeah. So it'd be fun to get with you about this. As you mentioned, I mean, there's been a number of pieces about this topic for a long time, not just over the last few months, but, you know, as I look at Pivotal, we do a lot of open source here. And that's things like data, Greenplum and Gemfire or Cloud Foundry, of course, Spring, RabbitMQ, now Kubernetes making some contributions there. And so, you know, we get recognized that we, Pivotal does a lot for our size, but just makes me think about what is the role of the open source? Are you doing it because you're nice to people? Are you doing it because you want to make money off it? I think Matt's piece was, hey, Amazon doesn't owe us anything, that they're making open source easier to use by delivering it as a service. Who cares if their contribution back is a little spotty? And still, they contribute a lot, but given their size, probably not as much as you see from Google and others. So, it was just this conversation of kind of why do you open source? Why do companies participate in this? And what's interesting is if you look at, I think, most open source at this point has a corporate sponsor. So, as much as we like to think of it as people toiling around on some mission to change the world, it seems like most major open source projects are funded by people's salaries being paid for by corporations and hope to have some benefit as a result of that. I don't think that's a bad thing. It just seems like we don't talk about that a lot. Yeah, yeah, yeah. I mean, I think that the last part you mentioned is, I mean, that's the way, man, I don't know since how long, but the way I generally think of open source is, or I should say, the last point that you made is a good result of how I've tended to view open source and observe people using it, which is just like, it's a good means of production, right? Like, if you want to write software, it's, I mean, there's almost three cases. I'll see if I remember them. But the first case working backwards is like, and is this true? I mean, a lot of what Pivotal does fits into this category and Red Hat and all sorts of other people, IBM and Facebook and Google and Microsoft,

is if you're going to do software, it's probably a good idea to start with the assumption that it's going to be open source and then come up with the case why it should be closed source if you're not going to do it. Just because there's not a huge amount of tactical money that you lose and strategy that you lose by open sourcing something. It's not necessarily a recipe for killing your business. I think most people are over that idea of it. And the benefits that you get of one internal facing is, and I don't know if this is true, but it feels like it's true, is most developers would like to work on open source things. And so you have a good morale boost and motivation for your employees to do things well. And I think there's a bit of like positive shame in action. And you would see this a lot in the late 2000s when companies would want to open source things. And one, they would have to sort out like IP they had licensed and if they could open source that. And, you know, this is always like comically for me, like Java would be like, I don't know, we have some fonts that we license so we can't open source stuff. It was probably more complicated than that, but it's kind of a farcical way of putting it. But, you know, they do worry about the quality of their code and making sure that it's presentable rather than just sort of hidden stuff. And then, you know, finally, I think just for the internal production, it is genuinely helpful to like have people contribute back to it. So, you know, we have in the Cloud Foundry world, there's instances of enterprises or organizations who are not software companies. They come up with something and they contribute it back and it gets folded into the broader Cloud Foundry thing, which is incredibly useful. It's better than just filing some tickets somewhere. And then I think, you know, the other bucket that I see people having is, I don't know, a more positive word than like, well, let's call it, you know, yesterday's success. Which, you know, in our realm of the world, like we have the Spring Framework, which started maybe in the early, the first half of the 2000s, if I remember.

And as was the style at the time, you would do that as open source and it's just continued to be open source. And probably if we started it today, it would be open source as well, but it's just lingered from that era. And that's a good demonstration of how things transitioned, I think, from the first thing, which is sort of like, I don't know what you would call it. It's just philosophically open source, just like, and I don't, I think this is the thing that least exists nowadays than it used to is just like this notion of everything should be open source. Like, it should just be, and if it's not, it's evil and it's bad. And I don't think that happens that much anymore. You see it kind of, you see echoes of it in sort of like the mission statements of like the Apache Software Foundation and, you know, when GPL things come up and stuff like that. But it's not an extremely prominent way of thinking about it. So, I mean, I think, I think in summary, it's just like, it's proven to be a good way of doing software. And I don't think it's that much of a hamper to monetizing it. So, it's, might as well be a good choice of how you go about doing things. Yeah, interesting. I'm going to want to gab with you in the, I think I mostly agree with that. I think the monetization has proven trickier, but we'll talk about that in a second. I think that, as I like your reasons there on why people open source their own stuff. I've seen examples and worked with examples where sometimes you do it on purpose to almost set the market, right? That I want to freeze out any of the competitive options. So, let me open source this thing because there's another thing out there that is commercial. But let's say Kubernetes. Yeah, yeah. Did Google just open source that because they were nice people or because they also saw a chance to dominate a market? I think it's the latter. So, sometimes you do that to purposely freeze out competitors. Yeah, and to interrupt you on that note, I should remind them that I sent this to them a long time ago. But I wrote some column for the register about what's the deal. I keep saying what's the deal, but I don't know how else to phrase it.

But like, why did Google open source Kubernetes? And not only so much, why is a retroactive thing, but it's why do they keep caring about it? How does it fit in strategically? And I think that's, if I remember, that's the conclusion that I came to is it's basically a, there's a certain type of, I'm sure this happens outside of the software world. But in the software world, exactly, I'm just repeating what you said. With open source and to a limited extent free stuff like back in the VMware Hyper-V days, there is a very real strategy of basically negating someone else's advantage by giving up a little bit of your own, right? It's sort of the, you know, if none of us can have this EBIT, if I can't have this EBIT, then none of us can have it. So you just, you just totally neutralize it out. And I think in the case of, to generalize of platform things, if you're worried about someone getting a, as we used to say, control point, somewhere where they can extract a lot of value because they have the one unique closed source thing, there's something to be said for neutralizing the monetary value of that by open sourcing it. So you can focus on other areas that are more, you're more capable of monetizing. And I don't know, it's, I never reached this conclusion in the article, but I guess that's what's up with Kubernetes. It's hard to say. There's a lot of virtuousness wrapped up in it as well. Yeah, and that's, you know, sometimes you also see kind of related to that, that you are trying to solve someone else's problem or demonstrate thought leadership. I mean, is there another reason that Lyft, a car company created Envoy and that kind of complements Istio and these other things that it's demonstrating that, hey, smart people work here and we're solving problems. And maybe we can help you solve some of these problems too. So there is a bit of a altruistic approach to that. I buy that. And that's why individuals who don't work for big companies also create open source projects and slog through issues and accept pull requests on weekends.

Like that is a thankless job for plenty of people, but they do it because they feel like they're solving a legit problem. And that's awesome. And some of those corporations seem to do that as recruiting. I remember almost the end of every Netflix post about one of their cool open source projects is, hey, if you want to work on this stuff, we're hiring. So you're doing it because it shows that this is a cool place to work. Therefore, we want talented people. So let's open source stuff. I think Adrian Cockroft even admitted that at some point. Much of this is almost a recruiting technique as much as anything. And then the final one that I see, I don't know if you see this too, Coté, is the cynical side. Sometimes you open source stuff that you don't want to deal with anymore. Like, hey, let's open source this database or let's open source this thing. By the way, we're not going to be primary on this anymore because we want to work on other stuff. So it's not we're gifting this to the community. It's like, hey, you guys now take this. And so, and again, that's fine. But it seems like that's another reason people do open source their software. Yeah, yeah. Yeah. You know, and it's notable. So looking at the chart that James Governor pulled out of the top contributors to GitHub and, you know, never mind the fine print of how it's generated. I'm sure it's great and fine. But if you look at it to kind of to what you're saying, there are, well, let's just throw out Apache.org because it's sort of like, that's like saying a number one contributor to open source is open source. But anyways, if you look at there actually are not that many companies on here. Or let me rephrase that. There are a lot of companies on here that don't actually sell software, right? Or don't actually sell software traditionally. They might, in the case of Amazon, they might sell running software for you, right? Since it's public cloud. But you look at someone like Facebook, like, you know, I was writing in that rant I was mentioning earlier in my newsletter. Like, I guess you could argue that Facebook sells advertising management as a service. So you could kind of think of them as a software, as a service in that respect. But, you know, someone, and then Alibaba, like, does, you know, it does retail and also, like, public cloud stuff and all manner of things.

But it's interesting to think that a lot of the companies that contribute a lot to open source, they don't care about monetizing the software. Like, they don't need to. Like, their interests, it kind of like with Netflix, and to read a little bit into it, I think part of, I would theorize that part of why Netflix open source stuff is that genuine old rainbow and sandal stuff of, like, well, because the quality is going to be better, right? Like, there is, Netflix is, you know, this is, maybe I'm the only one in the world who thinks this, but, like, I don't know. I wouldn't really call them a technology company. They're like a TV and movie company, right? They heavily use, this is the topic to be more grandstanding of my register column this month, but they use technology, like, wickedly and, like, deeply. But they don't, like, send you DVDs, right? Like, they don't sell you software. And so, if you are one of those companies, as we used to say, an enterprise, like, to a large extent, like, open sourcing your stuff is probably a great idea. Now, maybe not if you're doing some sort of, like, you know, customized insurance book analysis or things like that. Like, there are proprietary things that maybe you don't want to open source. But, like, for the most part, if it's just about, like, we're going to have a bunch of services and we need an efficient way for various pieces of code we have to look up how to talk to a service, like, just open source your registry thing. Who cares? Like, so, you know, that might be another. That's a good point. You know, it's interesting. It would be interesting to kind of filter all this based on we actually do have a lot of enterprise involvement in open source. And we just think of those enterprise companies as, like, tech companies nowadays when really, like, they're enterprise companies. So, I guess if you're going to be predictive to test this theory out, you would say over the next 10 years, you would expect someone like Ford to be a big contributor or other enterprises that write a lot of software or are setting themselves up to write a lot of software. And be curious to see if they open source that stuff. No, that's a great point. You know, and to your point on monetization, I mean, I don't think Facebook ever will make money on React, the web framework that everyone seems to use now.

And that seems fine to them. And so, I mean, I guess that question of monetization, I guess, question was, do you care? And for plenty of folks, folks don't care to monetize. But when I look at who seems to have purposely wanted to make money on this, let's assume that group of people, people who want to earn money on software, you know, historically, it's been like, well, just do support. Like, hey, you use Redis, you use this database, you use this backup software, whatever, pay us to help support it. That seems okay. I just haven't seen a whole lot of companies make a giant business on support, especially because a successful open source project seems to have a good community around it. And so, yes, you get maybe, you know, one hour response time SLA or things like that. But you can find tools, you can find expertise. It's not proprietary knowledge. It's public knowledge. So I haven't seen a ton of success with support. Some companies clearly make something on it. The one that seems more compelling to me is the packaging and updating. We just talked about patching. You know, my boss, Ian Andrews, has mentioned that we could almost continue to sell Cloud Foundry if all we did was just package it for people and update it. Like, that alone is worth so much for people compared to CI-ing it yourself and integrating it and testing it and deploying it and rolling out. Like, that is a giant pain point for any sort of complex software. Packaging is a big deal. Red Hat does that with Red Hat Enterprise Linux and others. So it seems like the packaging story sometimes gets underrated. But that is a super valuable reason people actually would pay for software. Yeah, yeah. Yeah, I mean, not to damage my own foot by trying to trivialize it, right? But the curation of your enterprise IT stack is incredibly valuable. And not only updating it, but like, you know, we like to say we have an opinion aid stack and all of that. But just the whole idea of this is the stuff that fits together. And these are the choices that you should have. And here's how you should run it. And then to your point, like, as updates come out, like, here's updates for it and new features added to it.

I remember in the 2000s, there was, to use the passive voice purposely, there was this idea of, like, patronage to make sure that open source was this common good around enterprises and you should just pay for it. Which I think a lot of the purely open source people, like, they were kind of, like, hoping this would be the case. But there is something to be said for, you know, you do need to have someone who curates this stuff together and builds on top of it and helps keep it updated and adds new features to it. And, you know, I think, you know, there's several companies. Like, you highlighted that WSO2, like, actually came out with some public figures, which is fun. It's always good to peer into that. By my read there, last year, they should have had a 2% profit margin, which is good. It's good to eke that out on selling supposedly free things. And their trajectory looked nice and all that. But, you know, I think this gets to kind of, like, drag along to the next point. On the other hand, like, there is closed source stuff you can still sell, right? And I think when you look at the bulk of open source, especially, like, in the space we operate in, right? So if you have someone to bring them up again, like Netflix or Lyft or whatever, open sourcing all these separate, I don't even know what to call them anymore, middleware thingies and services, like, there is something to be said for, like, a unified package of that stuff that you can easily install and have operational stuff written around it and taking it and packaging it up to be run. And I think, I think, I think, what is this? I'm always thinking if I should say five or 10 years, but over the last significant amount of years, I think there's a huge market acceptance of, like, buyers saying, I don't want to cobble all that stuff together. Someone else just do that. And you can even have closed source things wrapped around it and just sell that to me, right?

Like, I know I should be doing all these things, but just help me get it up and running and be the people that we basically outsource product management of this stack to. And that seems to be a viable business model that buyers tolerate. Yeah, you just described public cloud, right? I mean, that's the as a service delivery model is I'm going to deliver this open source, whether that's a Postgres database or it's a messaging engine or whatever, I'm going to deliver it as a service. I'll take care of packaging and updating. I might even add some proprietary extensions, which companies do for regular software, too, right? Pivotal or Confluent with Kafka or others is you add some other value or you have professional services. But as a service seems to be the way that many companies, especially in the cloud, have said, this is our contribution to open source. We're going to actually make it easier to use. So you don't need to assemble this stuff yourself, maintain it, update it. And that, again, seems to be fairly successful, at least for the mega vendors. I don't know how much a small money they're making their MongoDB as a service somewhere, their Rabbit as a service, their Kafka as a service. Are they actually making money? I don't know. But that seems like yet another way you could monetize and simplify a bit. So then maybe to kind of start to wrap up, I think being at vendors, we're obsessed with the vendor strategy and all that kind of stuff. But I always – I think the obvious other side of it is so if you're, as I was saying, a buyer or you're a regular organization, I think it is – it's always worth spending time thinking about, like, so if I use this open source stuff, like, what – I don't even know what – I'm not going to suggest what the answers are. But, like, what are the questions I should have when I'm sourcing this stuff? Like, as a historic example, dating my knowledge of programming, you know, maybe when struts 0.8 came out, it was worth wondering how long is this thing going to be around? Like, if I'm going to – as you can decode from URLs that you can still see, there's a fair amount of that still running around.

So it's proven to be, like, a long-term, strategically valuable thing for people to choose to use. But there probably is, like, a good list of questions to ask around open source things beyond the usual ones that we would care about. Like, is there a commercial company behind it? Like, I mean, that's sort of, like, sure, that's a good question to ask. And then – but then that just begs the question of, like, what's the long-term viability and quality of that commercial company, which is back to the regular thing that you would ask about software acquisition. But in your experience, beyond the obvious one of the commercial company backing it, like, what do you think people should look at when they're figuring out which open source things to use? Yeah, I mean, I would probably – I don't know. Two things jump out. I would look at the market. Is the market starved for skills? Like, if I can't find people who know this thing. That's a good one. I don't care how good the tech is. I'm going to – 10 years from now, it's going to be even worse. So if I can't find people who know it, it doesn't matter how brilliant the tech is. I probably should pass on it. And then second one, I think, is look at the extensibility of it. Is this thing – do I have to go into the guts of the source code to make a small change? Or does it have a sort of extensibility model that says, yeah, let's say, again, example, Cloud Foundry. I want to bring Haskell as a programming language. Do I have to actually change Cloud Foundry? Or is there a way that that just bolts onto an architecture like we do with BuildPack? So the answer is yes. So is this thing built to purposely let myself extend it so that it has a longer life and I don't have to fundamentally recompile the software every time I want to make incremental changes? Or is it just one big kind of monolithic ball of mud that if I had to take ownership of because that company went out of business or something, I would have to literally know everything to function with this thing. So if I look at extensibility, I would look at skills. If I can't feel comfortable with those two things, I would pass. Yeah, yeah. I think the skills is a good point. It's interesting in the open source conversation that's always about the role of individuals comes up over and over again, right? Like we started off with that it's a good morale booster and people want to work on open source things.

And the point you raise is good is like, well, you're going to have to have programmers that you hire using and working on this stuff. So you should make sure there's ones you can hire that know it. So the role of people and skills, obviously, always very critical in these things. Yeah, I mean, I think back when I used to talk to people about this and advise them, like the one thing I was always trying to build heuristics around was the, I don't know, I guess like as I was alluding to in my leading questions, like the long-term viability and stability of it, which is sort of a chicken and an egg problem, right? Like the open source project will have long-term viability if a lot of people use it. And a lot of people will use it if it has long-term viability. So at some point, I mean, and in the history of various open source things, that's why there are important moments, for example, with Linux, when IBM and Oracle in the early 2000s were like, yeah, we're doing it. We're going to run our stuff on top of it. And then later SAP. And so sometimes you just have to invent the egg or the chicken or whichever one on your own, like in some Jurassic Park lab, I guess. But there, I think, I think there's probably more organic things. And if I followed, I bet an interesting thing to follow would be like the last five or 10 years of JavaScript frameworks, because there's probably a good, like, we should assign the Red Monk people to go do this. This seems like their bag. But it would be interesting to see, like, what are three things you would describe about the five or so JavaScript frameworks that came and went and, like, what caused their rise and then their plateau of productivity and then their fall for each of them. And it would be an interesting thought exercise of, like, and therefore, when you're selecting open source things to use, here's how you initially select things. And when you start to end of life your use of some open source thing. And I don't know what those characteristics are. But it definitely, I think, and this goes back to my joke about, like, the way that I've noticed that you fix most all IT problems is to actually fix them or actually do them is, that seems like another thing that's particularly important with open source, because there are so many options and you don't have money to use as leverage.

But it's good to actively manage the portfolio they're using and pay attention to the viability and the capability of the product. So it's good to kind of keep an eye on how our, is this cheese smelling, to use a very old metaphor for it. And now, that may seem like some sort of gloom and doom thing, but I think having more options and having the ability to accurately ask that question and having all these public sources, whether it's GitHub or other things, to kind of get a sense of how popular and vibrant an open source community is. I think, on the whole, open source wins that sort of, I don't know, capability that you need over closed source things. Yeah, I mean, your JavaScript example is both great but awful because those frameworks seem to change every six months. Yeah. Right? Now, you almost wonder if we do a callback to what the very beginning of this podcast was, we talked about dev evangelism or advocacy. And you almost wonder, again, you'd have to research and see, do the companies who sponsor open source and have good dev advocacy programs help to build out that community up front so you don't have the same chicken and egg as, hey, this is really cool tech. No one's using it yet. We need to do proper advocacy for it. That's what builds the community, keeps it healthy. But, again, I have to fund those advocates. So, you know, do some of those projects have a better life because advocates are actually building a community out? Not sure. But those are all things I'd probably keep an eye on when I'm picking an open source tech to bet on. Yeah. Yeah, for sure. Well, all right. I think that's a good check-in on the way of open source things. I mean, if I were to summarize it, just to go back to what I was saying, is, like, open source is pretty awesome. It's pretty much impossible to argue that it's a bad idea and isn't beneficial and, indeed, should be, like, top of the list of things you think about when you're figuring out how to manage your IT and select things and criteria that you have. Which isn't to say that it doesn't win 100% of the time, so to speak, but it's normal. It's sort of like, you know, at least here in Austin.

I don't know how it is in Seattle, but you can drink the tap water. It's fine. We don't need to speculate about the health of it. That's true. That's a weird analogy, I guess. I thought you were going with a raw water analogy, which would have been more exciting to talk about. There you go. There you go. But, as always, this has been Pivotal Conversations. If you want to get all the most recent episodes and find the RSS feed, I mean, you can search around wherever you listen to this stuff. But if you go to SoundCloud.com slash Pivotal Conversations, you can find all those episodes and other information. And about every Thursday, we post the show notes, and there'll be those links that I was alluding to over at Pivotal.io slash podcast. And you can find our other podcasts there, Pivotal Insights, and also That Moment, which is a higher level podcast about how people have encountered moments where they need to change and things like that. And I saw we were nominated for some podcast award over at the Shorties for that moment. Yeah, it's a big deal. So, you know, if you like that podcast, you should go vote for it. I think you can vote once a day or something crazy, some sort of internet democracy. I don't know how that works out. But I went over there and voted for it because it's a good podcast. I remember one that I liked a lot. They had someone from Domino's talking about, you know, how you can order from your wrist and things like that. And equally, there's been a lot of good episodes at Pivotal Insights recently. If you've been frustrated at the lack of hearing Richard and I's voice, there's plenty of good voices to hear over there. So you should check that one out as well. And I don't know. I'm Coté, C-O-T-E, in Pivotal, I mean, in Twitter. Who are you over on Twitter? Yeah, you can find me at rseroter, R-S-E-R-O-T-E-R. See, there you go. We'll start the new year out with some shameless self-promotion, and then we can just not do it for the rest of the year. So we feel less sullied, as it were. So with that, we'll see everyone next time. Bye-bye.

Tanzu Talk · 🍕 Get more pizza.