The Changelog: Software Development, Open Source - Open source is at a crossroads (Interview)

Episode Date: September 20, 2023

This week we're joined by Steve O'Grady, Principal Analyst & Co-founder at RedMonk. The topic today is the definition of open source, the constant pressure on the true definition of the term, and the seemingly small but vocal minority that aim to protect that definition. In Steve's post _Why Open Source Matters_, he says "open source is at a crossroads" and there are some seeking to break the definition of open source to one that is more permissive to their desires, and they are closer than ever to achieving that goal. Today's conversation goes deep on this subject.

This week on The Change Law, we're joined by Steve O'Grady, Principal Analyst and Co-Founder at RedMonk. The topic today is the definition of open source, the constant pressure on the true definition of the term, and the seemingly small but vocal minority that aim to protect that definition. In Steve's post, Why Open Source Matters, he says, quote, open source is at a crossroads, end quote. And there are some seeking to break the definition of open source to one that is more permissive to their desires.

And they're closer than ever to achieving that goal. Today's conversation goes deep on this subject. A massive thank you to our friends and our partners at Fastly and Fly. This podcast gets downloaded everywhere around the world super fast because fastly is super fast globally check them out at fastly.com and our friends at fly help us put our app in our database close to our users all over the world with no ops check them out at fly.io What's up, friends? I'm here with James Cowling, co-founder and CTO at Convex. They're one of our new sponsors,

and they're building a full-stack platform for the TypeScript era. So, James, in your main navigation, you link to a page called Convex versus Firebase. How similar is Convex to Firebase? And if someone is quickly trying to grok what Convex is, is that a good comparison? I think it's a good starting point for sure. I mean, Firebase has been very impactful. And the people we speak to who use Firebase often love it and often lament the time they

have to move off of Firebase because it's kind of failed to meet their needs as a growing company. So Firebase falls short in a few ways. One is in terms of like a fully relational document model. One is in terms of having strong type system. One is in terms of having this full end-to-end consistency story where you write functions that run on an API server on the data that you can subscribe to. And so one thing I think we see in the Firebase style development model is that you have web applications talking directly to a database in a cloud fire store. With Convex, what is different is you have your code talking to actual fully fledged TypeScript functions

running on your data that you can subscribe to. But I think the Firebase comparison is fairly apt. And if someone is a Firebase user, I think you will love Convex. And it's certainly designed to fill that niche in the market. It's people who want to build applications without having to mess with infrastructure. In what way has infrastructure failed specifically application developers? I think if one was to compare what it looked like to build an application 10 plus years ago to today, it's gotten more complex, not less complex. There's a bewildering amount of frameworks. I think Google, for all their amazing work they do, has had a bad influence on how people build systems. days they're told to like learn kubernetes or something ridiculous like that you know these infrastructure platforms really resemble the shape of the underlying implementation not the shape of the problem that the application developer is facing and so even when before we started commerce we're talking to customers people like well i just want someone to like manage my kafka cluster and i say well why do you even have kafka And like, well, I don't really know. I think the database falls over if I don't put a queue in front of it or like I need to like

buffer some data somewhere. And what became clear is that the tools just weren't serving the needs of the application developers. And I think application developers and framework, front-end framework engineers understand the problem space because they spend all day doing it. They sometimes don't have the power to fix the problem because they don't build the database themselves. And I think oftentimes infra folks don't have enough empathy for the application developer that at the end of the day,

all that matters is the application. Okay, if you're looking for a better type of backend, Convex is the full stack TypeScript development platform you've been looking for. Replace your database, server functions, and glue code. Get started at convex.dev. That's C-O-N-V-E-X dot dev.

Again, convex dot dev. so finally we have ste Steven here to talk. Big fans of RedMonk and big fans of the recent post you put out there. We're big fans of open source, as you know. We're big fans to defend what open source is and is not so that the line is clear. And we think that the line needs to be clear because it's just important. And one thing you said from the Why Open Source Matters post you put out there, you said, from the CF formally open source relicensed database,

which we're aware of, to Meta's repeated poor behavior with respect to its open source licenses, to an as yet unannounced but pending major releasing effort, to even the longtime open source standard bearer Red Hat, flirting with the limits of license compliance, the definition of open source is besieged. So let's start there.

Yeah, so obviously a lot to unpack there, right? So a couple things off the top. If you wrote code, it's your right to decide on a license for that. Now, it's worth looking at the re-license, the companies that have re-licensed, it's worth separating them into two groups. You have one group where 99.9% of the IP is a code that they wrote, in which case, they have the right to, as I said, to license that however they like. Well, it's certainly legal. I think it violates the spirit of folks

that have done this on a community basis, right? Where the code comes from a bunch of different places, it's typically permissively licensed. Developers from outside of an organization have contributed on that basis. And then that is unilaterally re-licensed by a company. Again, they have the right to do that legally. I think it's a different situation. Certainly, communities tend to react differently to that. Examples, so Mongo writes most of their software, they relicense it. Elastic sort of took contributions from a variety of places. And you saw people in that community pretty outraged when they relicensed. So those are slightly different scenarios. But at the end of the day, the license permits a re-license, then so be it. The thing to me, the sticking point in the piece that you referenced is if you're re-licensing the code to a non-open source license, just don't call it open source. It's not complicated. And that's the thing that is immensely frustrating because, to your point, Adam, we need a lot in the sand. we need a, like, hey, here's the, this is open source. This is something where the code is available,

but there's sort of some restrictions on it. And those are not the same thing. And, you know, so myself, you know, a number of other people that, you know, you're all familiar with Adam Jacob and Matt Wilson and so on, you know, I've said this sort of consistently, hey, just call it what it is. And so far, companies are having a tough time doing that. Yeah. So a few recent events, I think, help inform this conversation. We have Meta's release of Llama 2, which came out with an open source-ish license that said pretty much it's open for both research and commercial use to do as you please with this contingency,

as long as you're not, and then they put their restriction, which I think was a certain size of user base. It's basically like our competitors. So that's one. Obviously, we have the re-licensing of HashiCorp's open source projects to business source. And I think HashiCorp was clear in the way that they did that, as far as I can tell.

So fair, but a major event, right? Terraform going non-open source business source. We have the release of CodeCov by Sentry. The code base for CodeCov goes open source-ish. It goes business source, which is open source eventually. That's kind of their phrase. They called it open source in the release announcement. They then changed it and I believe apologized

for using the word flippantly or without discretion perhaps. So that happened recently. We have Red Hat doing things. So these are like, there's been a lot going on in this world. And then Matt Acy wrote a piece saying that all of this argumentation about definitions and what really is or is not open source is missing the point because developers really don't care. And they've showed they don't care for years. And he actually had some stats that he went out and gathered and

provided for that. Maybe we start right there. What do you think with that argument? Because I'm a developer. I'm in the open source world. I care. Well, I've kind of come to a place to care, mostly through this podcast, more than I used to care before I was so well informed. Because I was kind of one of the people that just was like, well, I've benefited a lot

from open source. I should open source some stuff. I went and looked at the licenses that they was like, well, I've benefited a lot from open source. I should open source some stuff. I went and looked at the licenses that they had as MIT. I put the MIT license on mine, but really what I cared about was freely available out there to be seen. Source available was important to me because I loved reading source code, hackability, like that kind of stuff. I wasn't like firmly in the camp of it must be according to the open source definition. So Matt's piece in that way identified me as a developer for many years. I've since kind of become more caring than I used to. But what do you think to

that point? Like developers don't care. So is it just a few ideologues or passionate religious folk who have open source religion that care and therefore the war is over or, you know, we're going to lose. What do you think? Certainly that's the argument. And with all due respect to Matt, who I think is a great guy, I find that argument nonsense, to be honest. An example that I use in the piece that I wrote up is, you know, it's like climate change, right? It's like arguing that because your average citizen doesn't care about climate change, that climate change doesn't matter. And I think most people, you know, who understand, you know, sort of the science and the implications of it would sort of argue, no, actually it matters quite a bit regardless of sort of what they think, right? And, you know,

so the fact that matters that developers don't care in large part because they haven't had to because of the definitions that we've had, right? And, you know, developers have been able to, you know, sort of use this huge variety of open source software, right? You know, from operating systems, you know, web servers, containers, you know, languages, framework, you them. We have this immense library of software that's been available and importantly has been available under open source terms without arbitrary use restrictions. It didn't matter how many users your company had. It didn't matter how much money your company was making. And that's the thing is that the argument from folks behind these licenses is, oh, it's not a big deal. The source is available, which great. Look, if I had a choice between a source available sort of asset and one that was totally proprietary, I'd pick the source available for sure. Because you want the right to inspect the code, you want the right to take a look at what's happening. But the problem is that when you introduce these arbitrary

restrictions, which the traditional definition of open source prohibits, all of a sudden things get complicated pretty quickly because it's not clear. But first of all, if you're using a bunch of these projects, okay, which restrictions apply to which license? In other cases, if you're a developer, you may not have access to that, right? You may not have access, for example, if you work for a startup, what your actual revenue is. You don't know that, right? So how do you ensure that you're complying with the terms of a license? So, you know, at the end of the day, it is sort of, I don't quibble with the argument that developers don't care. I just don't think it's terribly meaningful, right? They don't care because they haven't had to because of this definition. And unfortunately, you know, again, kind of like climate change, you know, sort of

that, I don't know, benign neglect that he will is not doing anybody any favors in my view at this point. Right. I agree that there's clarity around open source, the definition, but there has been cause for developers to care with regards to selecting a project based on kind of the copy left versus open source divide even inside of open source community sure because like if it's a gpl for instance some companies are just like well we can't use that or if it's gpl they say we can't use that if it's mit bsd blah blah and so there's to a certain extent i feel like even as i was in any dev so i was just making decisions based on what was best for my customers, not what my boss at a corporation said, but I still didn't want to like back them into a corner unnecessarily.

So I had to care a little bit, I guess, get into the weeds, but you think this is a different distinction than that? I think it's a different distinction, you know, for, for a couple of reasons. First of all, all, so we obviously have a spectrum of licenses, right? On the one end, we have sort of quote unquote permissive licenses. You mentioned one of them, MIT, Apache, BSD, there's a bunch of them, right? And those impose few, if any, restrictions. A lot of times it's little more than an attribution in terms of what your responsibilities are in terms of using that source code. At the other end of the spectrum,

we've had copyleft, right? Most sort of famous and notable example of this is the GPL, right? Which basically says in sort of plain terms, if you use this and make changes and you distribute those changes, then you have to make whatever changes you've made available under precisely the same terms, right?

You have to have a reciprocal relationship with the source code. You have to basically share, share and share like right and so you know obviously it's not and then you have the the mpl which sort of sits in the middle right which is okay if you make changes to certain parts you have to you know sort of change those parts right so those are you have one end spectrum the other end and then things sit in the middle that being being said, those pertain to your responsibilities regarding the source code. The difference with a lot of these arbitrary use restrictions is that they don't really have anything to do with the code. It's all about who's using it. What field are you in? How much money are you making? How many users do you have?

And those responsibilities are very different, right? Because a developer can understand sort of what your responsibilities are with respect to source code. But when we're talking about sort of arbitrary uses, they either don't know, in some cases, don't have any control of that in other cases. And just as importantly, we have a couple decades of understanding as an industry, all right, how do these models like copy left or even sort of a more aggressive copy left like AGPL? So the AGPL closes what's called the distribution loophole, right? So in other words, I could run GPL software on a network and for a website, I'm not technically not distribution. AGPL says, look, if you're using it in that fashion, you trigger the license and you have to share your changes, right? So we understand how these work. We have an industry consensus of, okay, this is sort of

how these things work. And companies have learned to respect that. And really what we've seen sort of recently is a world in which all these arbitrary sort of restrictions are coming up, right? And like I said, it could be revenue-based, it could be user-based. We saw a push a couple of years ago for ethical licenses, right? So you can't use this for sort of XYZ fields of endeavor. And those conversations with people are hard because it's like, I can support all of these, or at least most of the sort of ethical sort of impulses behind them, and yet they just don't work in practice. You're using the wrong mechanism. The licensing, in my view, is the wrong mechanism for what you're trying to achieve.

So the net of it for me is that there's a meaningful distinction between the way that open source licenses have typically worked in terms of the copyright and how they handle that and the arbitrary restrictions that are being introduced by, sort of pick the sort of LAMA license, the BSL, any of these sort of licenses that are sort of being portrayed explicitly in cases like Meta as open source and yet are not and don't adhere to that definition. I guess one piece of evidence to this point is the JS Hint project. Adam, do you recall this episode we did years ago

with Mike Panisi? I do recall this. So JS Hint was a widely used JavaScript linter and it had the MIT license, except for at the end was the phrase, the software shall be used for good, not evil, which is an ethical kind of a thing, but it was just an addendum. And that was out there.

And when Mike Panisi took the project over, there was lots of trouble where it couldn't get adoption because that added beggary or just question marks around the license, even though other than that, cause like, how do you define good and evil? Right. And so he spent, and he told us the whole story, how much work he went through in order to get that relicensed. He had to go back and find all the contributors from times past and get them all to sign a thing. And it was a huge headache. He finally got it all done. That episode was called, you can finally use JS hint for evil, which I thought was a good way of saying it. But, uh, that's, I guess that's an evidence of like, if you, if you, if you make it vague and confusing, you really are presenting a lot of challenges for a lot of people.

Yeah. Yeah. Well, and that's the thing, like one of the, one of the things that comes up, you know, frequently in these licenses and the concept, I think the first time I saw it was in the, the commons clause, right. Which is now sort of largely deprecated, you know, was this idea of like, oh, you know, this in sort of these restrictions don't against usage, don't kick in unless you compete with me. And then the obvious question is, well, who defines that, right? In what way are we talking about competition? Because that's not always as

simple as, hey, we're in exactly the same business. It's like, hey, we do things that are sort of the same. There's a little overlap. Now, does the license kick in or does it not? And, you know, I'm not a lawyer. I happen to be married to one, but I have spent enough time with lawyers decades at this point in this space to understand that basically if you, put it this way, if you have a project and you only ever want sort of individuals to use it, the good versus evil is a good example of this. If you don't care about usage, license it however you want. But I think it's difficult to make the argument at this point that usage by businesses has done anything but kick lots of money, lots of jobs into the ecosystem. And if you have a project

and you have wider ambitions for it, then one of the things you have to learn and lawyers tell you is that ambiguity just doesn't fly. No? No enterprise is going to sort of use a license that says, you know, use this for good or not evil. And a lot of enterprises won't use it if it's, as I said, hey, you know, you can use this unless you compete with me, right? You know, because I can remember when the SSPL came out, you know, from Mongo, it was, you know, basically aimed at, you know, cloud providers. But then you have corner cases like, all right, large Fortune 500 organizations will frequently have internal hosts, for lack of a better term, and they charge back to businesses. So they'll run the infrastructure for somebody

else. Does that apply there? Technically, if you read the license, probably does. So that's the thing. A lot of these licenses are ambiguous. The terms are, you know, arbitrary in that they vary, you know, from project, you know, to project and company to company. And, you know, that sort of the end state of that is sort of my concern, right? Which is any one of these things in and of itself is, all right, it's not ideal, but, you know but it's just a single project, it's just a single company. But in other words, what we have at present, as we've talked about, is this huge wealth of resources that are licensed in a way that makes them available to developers worldwide without these arbitrary restrictions. If you take the current direction of travel and project that forward, one of the potential outcomes is that we have sort of a mess of new important projects, particularly in the AI space, that now each carry some weird different license restriction that I now have to keep track of in ways that I never did before, right? And that is a world where, you know, to the, and we talked about Lama at the top, you know, when I talk to people about this, they're like, the, and we talked about Lama at the top, you know,

that when I talk to people about this, they're like, oh, it's not a big deal. It's mostly open. And I'm like, cool. But imagine a world in which Linux or Kubernetes or any of these things was usable by Facebook, but not, you know, sort of Amazon or Google or Microsoft, right? And maybe that's sort of a world that people want. But, you know, I tend to believe that we are better off as an industry when we have open source projects that are supported by the bulk of the industry. Not in every case, of course, but like I said, if we fast forward to a place where all these licenses

become more and more common and they conflict in varying ways, to me, that's a nightmare from a developer standpoint. There's an obvious advantage to calling yourself open source. And I think that's the challenge here is like the definition is becoming blurred, besieged even, as you had said, in regards to the advantage you get from being in quotes, open source. And so some will want to blur the line for their own advantage, whether intentionally or unintentionally. There's an advantage to being open source. And that's why there's a desire to be open source, even though you're not, right?

Yeah, clearly. We have this conversation all the time. I'm trying to remember who it was. I really wish I could remember anyway. But there was an exchange on Twitter and we have a conversation literally all the time, which is, hey, you know, I'm open sourcing this thing. It's like, cool, which license?

You know, like, well, it's this one that we came up with, or it's this, you know, it's an open source license, but we have these additional riders on it. Right. And they're like, okay, cool. That's not open source. And they're like, okay, but you know, the source is available. So it's open source. You're like, no, no, there's a definition that's been clearly established. It means certain things to everybody involved. And they're like, but what do I call it? We're like, Hey, there's a bunch of different been clearly established that means certain things to everybody involved and they're like but what do i call it we're like hey there's a bunch of different terms you can call it source available you can call it open-ish you can call you know you know sort of non-compete like pick a term as long as it's not open source and they come back and say something like you know that doesn't that doesn't mean open source and you know developers like open source and i'm like exactly like that's exactly that term has value for a reason.

And the reason it has value is because people have protected it for a long time. Right. This is not the first time. Yeah, this is not not even the thousandth time that we've argued about the definition of open source and sort of what it means and so on. And, you know, unfortunately, as an industry, it's a battle that we keep having to fight over and over. Well, it reminds me of what Josh Padnick said, one of the guys behind OpenTF when he was on the show a couple weeks back,

about Terraform and his involvement and the sentiment from the large group of people who decided to fork it. I asked him, because the bait and switch aspect of what HashiCorp did was a driving factor in their feelings. And I said, well, what if it would have been business source from the start? Because then you wouldn't have the bait and switch, but you would not have had an open source project. You would have had a business source project from the very beginning. And his statement was, we would have never invested like we did around a business source project.

The fact that it was open source is why they got thousands of developers and probably tens of thousands of hours of labor put into the project because of the goodwill that exists with an open source project where business source is very close. I mean, it's even open source eventually, as they say, right? But it's not the same thing. And so people see the difference. And so they really want it to be the same thing because yeah, you have your cake and you eat it too. Yeah. I'm, I tend to be very outspoken on this, but the, the open source aspect of the business source license to me is, uh, that's just a, a fop, right. Did people throw

to themselves to make themselves feel better? You know, because it was last time you talked to Valper and said, Hey, here's a project. Do you want to go use a version that's two or three or four years old? Right? No one wants to do that ever. In which case, I mean, I guess it's better than nothing, but it's not, to me, that's not a meaningful contribution, right? Because no one wants super old source code, right? That's just not the way it works. And, you know, really what we've seen, you know, from a direction of travel standpoint is that, you know, the quote, bait and switch model has just become sort of normalized, right, to a degree, right, in the sense that you use open source to get to a certain

point where you are, for lack of a better term, too big to fail. And then, you know, you sort of rug pull and switch the license to something else. And the sort of community, typically, you know, just sort of continues on because they don't have an alternative. Or in some cases, like in extreme cases, you know, sort of like OPTF, you know, they sort of band together and fork. But, you know, the difficulty with that is that the odds are against, you know, those forks, they don't tend to work most of the time. So, you know, jury's out in terms of how that works. Yeah, we'll see what happens.

Yeah. But, you know, that's the thing is that this is a pattern, right? Which has become sort of more and more common at this point. And so, yeah, a lot exclusivity or so that they prevent the sort of competition from certain specific competitors, typically cloud providers, but it could be, you know, Hashi was not pointed to cloud providers. They pointed to sort of other resellers and so on.

They changed the terms of license and they expect the communities to just kind of be okay with that. And a lot of them aren't. Well, speaking of Hashi and cloud providers providers as google just announced a big managed offering with managed terraform offering they did yeah yeah just today or yesterday so they didn't mention them in their stance but they're definitely probably feeling it from all sides i was just going to echo what you said was the goodwill aspect i think there's a big i mean you see that

in a lot of aspects this term goodwill right like if you're in a relationship marital friendship whatever it might be the goodwill between that relationship is that you're not intending harm and whenever uh and then obviously these companies are building on top of the goodwill of the community and the the goodwill essentially is not just it's kind of spear-led in some cases but it's it's as if there's no harm intended and whenever you change that definition or you want to re-license to something else that transitions from a goodwill scenario to a not goodwill scenario it's like well as long as it doesn't hurt me i'm okay with whatever happens. But it can hurt you because it restricts. In the case of, I'm thinking back to Josh Padnick and OpenTF,

I would not have invested in this thing if it were licensed as X because there was no goodwill towards me. But because it had goodwill initially, and that term goodwill I think is key because that's the clarifying factor in the whole reason why open source works and why it has its advantages and why folks want to leverage the term open source is that that goodwill is present and then in a non-open source, masquerading as open source license, like BSL for example, is not goodwill focused. It's selfish, right? If you think of it in relatable terms, in relation terms, it's not goodwill. It's selfish. selfish right if you think of it in relatable terms in relation terms it's not goodwill it's selfish it's narcissistic in a way even like if as long as it doesn't hurt me and i get it in these cases these their businesses they want to continue to

operate and thrive and they want to use a license that allows their code to be open allows contributions but back to what you said ste's like, just don't call it open source because that's not what it is. It doesn't have that goodwill nature that open source, that truly is open source, thrives upon. And so it doesn't have that. It can't be open source.

Well, and I think it's actually that sort of goodwill, and I would add into that, the trust, right, I think is sort of multi-level, right? Because in other words, we tend to think about it sort of on a purely, on a single, on a per project or per company basis, right? So, that's typically how we sort of look at this, think of this, et cetera. And it's like, oh,

hey, what does it mean in the context of this project, right? So, when we talk to vendors and every, I'm pretty sure every vendor that has re-licensed has talked to us first, you know, at least to sort of brief us and say, hey, here's what we're doing. And, you know, one of the things that we hear, you know, in to us first, at least to brief us and say, hey, here's what we're doing. One of the things that we hear in those conversations is, hey, this is not a big deal. Our community will be fine with it and so on, which that's not typically how it plays out, but some communities care more than others. But again, as we talked about earlier, it's selfish in the sense that they're looking at it purely from the perspective of their company, which look, you have shareholders to keep happy and everything else. I get it. This is kind of capitalism at work. But the reality is that in the aggregate, the behavior is extraordinarily problematic. Because basically, if one company does this, it makes it easier for the next company, easier for the next company, easier for the next company. And ultimately we end up in a world where the stack that you're going to be working with is like, okay, I can't use that piece because

we might compete with them. I can't use that piece because we have too many users, or I can't use that piece because we're at this revenue level, or I can't use it because I don't know how many people we have, or I don't know any of these. And for me, at least, RedMonk is a firm that we consider our first and foremost responsibility to be looking out for developers, frankly, even on things that they might not care about themselves to try to say, hey, look, you're in the trenches. You're building things day to day. You are concerned with what you're building day to day, right? You are not saying, hey, okay, what happens if this... That's not what you get paid for, right? And so that's kind of

our responsibility is to take a look at, all right, hey, what's happening here sort of at scale, right? And the way that we put it to developers all the time, it's like, hey, if you're sort of in traffic, right? Our job is to kind of orbit the earth like as a satellite and say, okay, we have traffic over here, we have traffic over there because we're trying to watch these larger patterns. And so, yeah, I think it's certainly a self-motivated behavior, which is, again, sort of understandable from a capitalist standpoint. But a lot of things within capitalism, I say this as a capitalist, it definitely introduces some problems sort of when you scale up, right? And just in the aggregate, it's not a great thing.

The don't care aspect that Matt Acy brought up, I've been thinking about this as we've been having this conversation. So bear with me if this analogy is not perfectly on, but this is somewhat how I feel about it. And my story is almost like coffee. You know, I've been a coffee drinker my whole life and the majority of my life, I always wanted to have good coffee, but only until later in my life did I understand what good coffee really was and began to truly care about how to make good coffee. And so for a while

there, I was drinking, and no offense to the Keurig drinkers out there, or even Nespresso, if you're drinking that, it's not truly good coffee. It is coffee, but it's not good coffee. And as a coffee drinker, sometimes you just want to have coffee, right? As a software maker, sometimes you just want to have software and you can just use it because it's open-ish or it's source available or it's truly open source and you just don't care because you can use it. Well, in comparison, but the point I'm trying to make is that I didn't truly care about good coffee until I truly understood what good coffee was. And then I began to care about just-in-time grinding and I cared about water temperature and the pH balance of the water and just different aspects. Then I began to care. Basically, when the rubber met the road of good coffee, then I cared. So I can kind of understand your sentiment where you have developers who just do their job.

And I get it. You want, like Jared in the past or Jared currently with more care, you want to have access to good software out there that you can use in ways that benefit you and those that you're trying to serve in your job. Yep. And maybe you really don't necessarily in quotes care that it's open source by definition. But when it really matters, protecting that customer, in Jared's case, or the company that you work for, protecting that company, when it truly matters, you do care and you will care. Just in that moment, it's sort of delayed care or I think you said before, I forget what the word was, but benign concern for essentially this care. You do care, but just not deeply in that moment. And my analogy really is this good coffee. You just want to talk about good coffee. Yeah, sure. Why not? Right. I'm down with that. I mean, I think honestly, you just have to remember,

I think sort of both, both ends of this, right. You have to remember what it was like to be somebody in the trenches as a developer. And then you have to sort of understand, okay. You know, and the example that I've used for people is, you know, very early in my career, I was building a medical records, you know, sort of system, right? So that doctors could sit at home, you know, pull up medical records, right? And a bunch of these MRIs and CAT scans and everything else were in some really weird, obscure, I think it was TIFF, anyway, some weird graphics format, right? Browsers could not display it natively. So we needed a plugin and hunted down, you know, hunted across the internet. I was like, there has to be one.

And found one, was like, cool. Like, hey hey this does exactly what we want like here are the images and you know and then it goes up to senior management like yeah what's the licensing for it i was like no no you don't understand like i got these images displayed you know how hard this was right like and they're like yeah yeah except we're rolling this out for a customer and so we have to know what the license is you know so that was certainly an instance for me in my career where it's like, I'm focused on the problem here. This is a super hard problem to solve. I couldn't do this. This thing does what I needed to do. But at the end of the day, from a business standpoint, there has to be somebody in place to say, yeah, no, we actually have to care about that. And we ended up having to get a different one because the licensing complication was,

but basically it was a non-starter. The client was going to be, day one, they roll it out, they're screwed legally. And so that's a, like I said, I have empathy for developers that don't care because I've been you, I've been in your shoes, but I can tell you with the benefit of a little bit of experience between now and then, and like I said, hundreds if not thousands of conversations with lawyers, as much as we might hate it, this stuff matters. And that's the problem. What's up, friends? I'm here with Vijay Raji, CEO and founder of Statsig, where they help thousands of companies from startups to Fortune 500s to ship faster and smarter with a unified platform for feature flags, experimentation, and analytics. So Vijay, what's the inception story

of Statsig? Why did you build this? Yeah, so StatSync started about two and a half years ago. And before that, I was at Facebook for 10 years where I saw firsthand the set of tools that people or engineers inside Facebook had access to. And this breadth and depth of the tools that actually led to the formation of the canonical engineering culture that Facebook is famous for. And that also got me thinking about how do you distill all of that and bring it out to everyone if every company wants to build that kind of an engineering culture of building and shipping things really fast,

using data to make data-informed decisions, and then also informed to what do you need to go invest in next. And all of that was fascinating, was really, really powerful. So, so much so that I decided to quit Facebook and start this company. Yeah. So in the last two and a half years, we've been building those tools that are helping engineers today to build and ship new features and then roll them out. And as they're rolling it out, also understand the impact of those features. Does it have bugs? Does it impact your customers in the way that you expected it? Or are there some side effects, unintended side effects? And knowing those things help you make your product better. It's somewhat common now to hear this train of thought where an engineer, developer was

at one of the big companies, Facebook, Google, Airbnb, you name it. And they get used to certain tooling on the inside. They get used to certain workflows, certain developer culture, certain ways of doing things, tooling, of course. And then they leave and they miss everything they had while at that company. And they go and they start their own company like you did. What are your thoughts on that? Your thoughts on that kind of tech being on the inside of the big companies and those of us out here, not in those companies without that tooling? In order to get the same level of sophistication of tools that companies like Facebook, Google,

Airbnb, and Uber have, you need to invest quite a bit. You need to take some of your best engineers and then go have them go build tools like this. And not every company has the luxury to go do that, right? Because it's a pretty large investment. And so the fact that the sophistication of those tools inside these companies have advanced so much and that's left behind most of the other companies and the tooling that they get access to, that's exactly the opportunity that I was like, okay, well, we need to bring those sophistication outside so everybody can be benefiting from these.

Okay. The next step is to go to statsig.com slash change while they're offering our fans free white glove onboarding, including migration support. In addition to 5 million free events per month, that's massive. Test drive Statsig today at statsig.com slash changelog. That's S-T-A-T-S-I-G.com slash changelog. The link is in the show notes. ស្រូវាប់ពីប្រូវាប់ពីប្រូវាប់ពីប្រូវាប់ពីប្រូវាប់ពីប្រូវាប់ពីប្រូវាប់ពីប្រូវាប់ពីប្រូវាប់ពីប្រូវាប់ពីប្រូវាប់ពីប្រូវាប់ពីប្រូវាប់ពីប្រូវាប់ពីប្រូវាប់ពីប្រូវាប់ពីប្រូវាប់ពីប្រូវាប់ពីប្រូវាប់ពីប្រូវាប់ពីប� So we all agree that if it's not, if it doesn't fit the open source definition, it's not open source. Stephen, what do you say to folks who say, well, the definition of open source is old and too constrained and times have changed. Back when it was written, there was no such thing as AWS. There's no such thing as LAMA or AI models. And it needs to change with the times because we're trying to be open source, but we're getting our

lunch eaten by large corporations taking our stuff and rehosting it or whatever they say. And we need to change, we need to expand what open source means so that we can have a broader tent and still have clarity, but just have more of us fitting inside of that definition. Yeah. So there's, again, there's a lot to unpack there. So, you know, looking at it from a commercial angle, right? It's been interesting that, you know, a number of times people have argued about, oh, hey, it's a, you know, this cloud stuff is sort of a brand new frontier and, you know, people can pick this up and run with it. It's like, that's happened kind of forever, right?

You know, commercial entities, I mean, how the, was it the networking stack? I think in Windows, you know, sort of famously was BSD license, right? And so companies have been picking up this stuff forever and sort of selling it. In other words, you look at sort of the IBM, for example, picked up and replaced and basically deprecated their own web server because they're like, no, Apache wasn't just as good, if not better. I see these models have been around for a long time, right? There's nothing new about that. And from a cloud standpoint, really the argument that I always make is that there are sort

of two different ways to look at it. One, which is in the early days in particular, I can't tell you how many conversations I had with particularly people in the database space. And I was like, look at the growth here from a managed database standpoint. You have to spin up your own managed database, right? Otherwise, other companies are going to do it for you, right? And it took some of them a lot longer than it should have. And sure enough, they've done that.

And guess what? The businesses took off, right? So in Mongo's case, I'll get the numbers probably a little wrong, but it was like about 10 years for them to hit a 100 million run rate for their on-prem business. They did it in like two and a half, sort of from a services standpoint, right? So, you know, sort of option number one is spin up your own services business. And oh, by the way, you can differentiate your own software in the services business by releasing adjacent feature, you know, features that maybe don't make it back to open source. You can differentiate pretty easily, you know, sort of when you do that, right? So there are easily ways to compete, you know, sort of on the cloud front.

And then, you know, sort of the sort of other piece of this is that, you know, well of when you do that, right? So, there are easily ways to compete, you know, sort of on the cloud front. And then, you know, sort of the sort of other piece of this is that, you know, well, I had a conversation with, you know, somebody a while ago, which is, you know, hey, you know, nobody wants to see their work picked up and sort of just used and sort of repurposed. And you're like, that's what the licenses permit, right? I mean, that's just how this works. Like, if you don't want that, then great, don't release a note of that license. It's pretty straightforward. And the thing that a lot of the companies really don't want to hear as well is that they want to exclusively monetize an asset, which I get. You wrote it, you want to sort of capture the maximum profits. But the interesting thing that we hear all the time is, oh, these companies can't make money

because they're competing with cloud. And it's like, yeah, they've gone public. Like they're multi-billion dollar companies in many cases, you know, sort of, you know, while competing, you know, when they change licenses, they're already multi-billion dollar companies. And it's like, okay, you know, really, what are we talking? No, they can make money. And in many cases, the sort of, I don't know, de facto anointment of these companies as market leaders, right? So in other words, if you're AWS and you pick one of these companies and you spin up your own instance, what you're telling the market is that, yeah, we've looked at all these databases, search, whatever it might be. We've looked at all of them and we think this is the best and most popular one, right? So on the one hand, that sucks if you're the company

that's being competed with. On the other hand, it is a lot worse to be one of the competitors, right? Because you're like, oh, wait, so I'm not as popular? Like, you know, AWS is, you know, I'm not the kind of opportunity that AWS is even interested in. So, that's the thing, there are ancillary benefits, you know, to the cloud companies, you know, competing with these competing with these companies. And it's like, anyway, you try to have these conversations with a lot of the vendors and they don't really go that well, perhaps not surprisingly. And if you talk to the investors, it goes even less well. Those are typically not terribly productive conversations. We'll stop in a company like that in this scenario where their database is chosen to be an AWS service that spins up and say, wow,

we're blessed by AWS, but now we have to compete. What's stopping them from literally going to AWS and saying, Hey, I know you can use this open source software we produce. Thank you so much for believing in our hard work and deciding to make it an AWS service. But what if you helped us? What if we made a business deal where you could totally go and just use that with no payment to us, no funding to us whatsoever. And you can just do it free and clear because that's how open source works. But what if you also respected that ability, but also said, what if we help fund, you know,

XYZ company that produces this phenomenal database that you clearly want to leverage for your customer's benefit? What if you helped us through a business deal if our software is open source you can totally go and never make this deal with us but what if you did so that we can continue to make this software amazing and keep the open source spirit alive like is that just a non-conversation happening out there is that is that happening and they're like nah we're not going to do that honestly it's mostly you know i think it's mostly politics it's mostly the fact that you know these companies uh and more particularly their boards in sort of aim are aiming for exclusivity right they don't want to share um the pool you know you could sort of make the argument on paper like hey look if you worked you know to your point if you worked in concert you know you can have a hundred percent

of you know i don't know make make up numbers worked in concert, you know, you can have 100% of, you know, I don't know, make up numbers, like a $50 million market, or you can have 80% of a $300 billion market, right? Like, that's not the conversation that most of them are having, right? I think that could change, you know, sort of in the sense that, you know, I think you could see, you know, some movement on the part of the cloud providers, which are looking at this and saying, all right, do we really want to maintain Forks indefinitely? Do we really want to sort of be at war? So, I mean, over the longer term, you know, there's some potential for some change dynamics there. But, you know, for better or for worse, the, you know, the reality in most cases is, you know, the dynamics of any partnership, right? Set open source and clouds and so on aside,

the dynamics of any partnership are complicated, right? And they're hard to maintain. There's a lot of moving pieces. And a lot of times, you know, it's something as simple as, hey, you know, you get to the, you know, five yard line, right? You know, with a deal and then somebody takes a new job, right? And that partnership is now sort of back to square one, right? And so, I mean, there's nothing on paper that says that that can't work as an approach, but you know, just the sort of political reality within most organizations at this point is that I think it'll be a little while before we see that playing out. One interesting side effect in AWS's case in particular is that they've kind of become

this open source villain to a certain extent. like their reputation in the community is pretty tarnished because of what is completely legal according to the license. And a lot of us just think isn't in the spirit of open source because Adam, your idea is more in the spirit of open source of like contribute back to this thing, which is, you're saying resources is money, right? Go ahead and provide your hosted offering and stuff,

but like contribute back in some sort of way. And we're going to, we're all good here. But so much, it's not wolf crying, but so much like you said, Steve, is that these large corporations set themselves up as David versus Goliath in the way they speak about it. And it's not really the case. It's like a mini Goliath versus a bigger Goliath is kind of what's going on, but we still root for the underdog and we still see what looks like injustice. And so AWS does have, at least in my opinion

and in the way I hear people talk about it, not the best reputation in open source because of what they're doing. And I wonder if that would be to the right VP or to the right C-level executive, something that would make them maybe change their approach to a certain extent. I don't know.

Yeah, I think to me, AWS is an interesting case, right? Because they're not where they need to be, right? And I think they would sort of at least privately sort of say, you know, hey, there's always work to be done and so on. I will say that the, put it this way, the conversations we have with them around open source today versus 10 years ago are 180 degrees, right?

And, you know, I think, you know, the reality for, I mean, it is for sure, but frankly, you know, Microsoft and Google to a lesser extent, they're always going to be the bad guy because they're the big guy, right? So, you know, look, it's- Sort of, but i think on the other side microsoft has repaired its reputation to a certain extent with microsoft has done quite

a bit yeah for sure but in other words you know when we when we're thinking about the you know the rallies and sort of running you know sort of some of these open source projects at scale yeah i mean i mean put it this way amazon did itself no favors nor did elastic for that matter you know sort of in the way that that whole thing went down, right? And that was, and I wrote this at the time, right? It's sort of bad for everybody involved, you know, it does damage and so on, you know, but the difficulties is that, you know, like everything else, from a reputational staffing, right? The number of people who are in and involved in contributing back to open source is, again, night and day different than it was a while ago. The difficulty is that, you know, once your reputation takes a hit, right? This is true, obviously, for people as well as businesses. Yeah. Jared, in terms of Microsoft, that was a decade plus rehab, right? Because Microsoft, old Microsoft in the Balmer era, I can't tell you how many times we talked to folks over there like, hey, we're doing all these things for open source. And I'm like, yeah, but every time Balmer opens his mouth, he sets you back like 10 steps. And you have a new leader in the Della, and they've done the right, not in every case, of course,

but they have done better than they have for an extended period of time, and their reputation's recovered, and jury's out. Will we see that from AWS? Who knows? But could it be better two or three years from now than it is today? I think potentially, yeah. And they're still fighting that fight. I mean, they haven't fully recovered.

I mean, they've recovered quite a bit, Microsoft-wise, to the dev community. But I would say the one thing they do show, which you just said that they don't always get it right, is they've shown goodwill in the relationship of Microsoft to the community of developers. They've shown that they have intentions to respect and to play fair in ways. There's ways that they don't play fair, but they've shown, I think in this change, what has come out is the idea that they intend to be good for everybody. I think what ultimately matters is that,

honestly, I guess I'd less use the word goodwill than just being smart about how and where you interact and being sort of upfront, right? So in other words, a decade or more ago, companies were coming to us and saying, I don't understand how IBM has this good reputation We're active being sort of upfront, right? So in other words, you know, a decade or more ago, right? You know, companies were coming to us and saying, I don't understand how IBM has this good reputation with open source. And it's like, you know, hey, they're doing these things that we don't agree with. And it's like, right, but they're transparent in terms of what they're doing.

They're setting expectations upfront. They're, you know, they're doing things like, hey, we're going to invest a billion dollars in Linux. And, you know, so it wasn't a, you know, there was no kumbaya, like, hey, we're going to invest a billion dollars in Linux. And so it wasn't a... There was no kumbaya. You see companies try this from time to time. It's like, oh, we love open source. And it's like trying to evoke sentiment and emotion and so on as a company. It's very difficult to do. The thing that you want to see more from companies these days is, okay, just understand where open source fits with your business model, do the right thing as much as you can, and try to respect the communities and the projects involved. And that doesn't mean

that you're going to do what the community wants every time. It doesn't mean that you're going to do what the community wants most of the time. But if you are basically consistent in your approach and like, here's how we're going to do things, and you set those expectations, more often than not, you can keep yourself not out of trouble, but at least out of major trouble. When we think about licensing with the data model world in the world of AI, it seems like it's getting more complicated and different. And I wonder if the open source definition even applies there.

I mean, we don't use it to talk about a novel or an article. Like we use different kind of licensing for that kind of stuff. I have, I do follow opensource.org RSS. I do see them talking like they're, they're having meetings about artificial intelligence. I don't really read the details there, but like, are they working on new licenses for this kind of stuff? Because it is kind of a different thing. It's there's code involved, but there's also data just there. And I don't know, what are your thoughts on that? Well, honestly, to me, you know, that's kind of the wild, wild west, you know, and I, you've actually had, um, uh, Louis V on before, like those are the people that

I, you know, the people who are at lawyers are trained, you know, I look to folks like that to try to sort of understand a lot. Um, Dan Lindenberg is another guy, you know, they pay a ton of attention to sort of in that space, you know, the AI side of things is, you know, honestly, fractally more complex because it's not just the training data. Then you get into the weight. It's like, okay, it's basically a string of numbers. Like, how do we license that? Like, is that even licensable? And, you know, that's one of the sort of fun things from an AI standpoint.

We get asked all the time, like licensing implications, right? And honestly, it's like a new question or new brain teaser every day, right? So it was trying to remember that the Supreme Court case, which came out, I should know it. But anyhow, it came out recently and it's like, now there's some question as to whether output from AI systems is copyrightable. And I was like, I hadn't thought, you know, everything, all my focus had been on the inputs, right? So in other words, is it legal, for example, to consume training data? Is it legal for companies to use these products, you know, these trained products and so on, have the additional question of like, okay,

I use one of these products and I output something, can I copyright that? Like, or is that a transformative? So all of which is to say is that AI is going to challenge the sort of assumptions and the basis for a lot of these licenses. And I don't have any idea how that's going to play out. And frankly, the market doesn't. One of our standard responses is like, hey, what's the legalities of the system? I'm like, I don't know. Look at this case. Look at that case. They're pending. We know more you know when that's resolved so yeah the data side of things is it's a brand new frontier put it that way yeah i wonder if the merging of that world with our world as software systems you know get significantly more complex and they're probably weaving in and out of them different

inferences from models here and there if like that will further muddy the water of what open source is. Well, I think it might further muddy the water of what open source is. But in other words, at a minimum, you know, we're going to have to come up with sort of new ways to do this. So there's a number of years ago, there was a business I was talking to that I probably shouldn't say which. Anyway, they had, you know, these sort of, you know, dramatically oversized, you know,

sort of memory allocation for a distributed system. And I was like, I don't, what the hell's going on? Like, you don't need this much memory. And it turned out that they had two different data sets that they were not allowed to combine, except that their lawyers had determined that when they're in memory together, they're not technically combined, they're not technically combined

because they're not on a disc. And I was just like, I don't, yeah, what? So, I guess my point is that I think what we're going to see from an AI standpoint, this is all pre sort of AI, at least the sort of more recent AI boom. I think what we're going to end up seeing is that we're going to have to see the evolution of more approaches. And I think what we'll end up seeing is, well, I think one possibility is that I think we'll end up seeing sort of the creation of a new class of licenses or licensing that applies to these sort of AI weights, models, data, training data, et cetera, because it's going to have to be its own brand, its own thing. I'm with you, Jared. I was considering the same question.

Like, does, because the AI world is almost mainstream, whereas developers still sort of niche, you know? The AI brings in a lot of people to the room, not just developers. And if the contents of the room gets bigger, and developers become a minority, or those

who care about open source and its definition and the whole reason why we're having this conversation because the three of us do care if because more people come in to the space that blur the lines of what open source means and say well you know we really need a new definition here or whatever it might be like we need a different license i just wonder if like that influx of folks won't outweigh us screaming hey it matters it matters because like they just take over numbers we come we become a minority in their majority because just so much that ai has just become so mainstream this year like almost in an instant yeah i mean my hope is ultimately that know, we leave those sorts of decisions to policymakers,

right? And I say that reluctantly, but in other words- Yeah, I'm not sure. Have you seen the questions they ask at these hearings? I mean, you just need people who are trained, right? You know, to have, you know, it's honestly why, you know, with AI, like I have, obviously, as we've hopefully demonstrated over the course of this episode, I have very strong opinions on licensing and how it should and shouldn't be done and definitions and all that. When it comes to AI, I'm still

learning. I've spent the past couple of decades understanding, all right, how does it apply to source code? What are the mechanisms? What are the levers? And all that. With AI, it is... So in other words, what I try to do as somebody who is responsible for researching and writing about the field is take a step back, like, okay, what are people who are trained in this? Like, what do they see? What are they thinking? What are their opinions?

And, you know, when it comes to your everyday average user of, you know, frankly, any degenerative systems, you know, as an example, right, whether it's, you know, chat GPT or Vigernia or what have you, my hope is that they don't try to, they don't try to be lawyers, like leave the licensing to the lawyers.

Yeah. But I don't know, maybe that'll play out about as well in AI as it does in source code, so we'll see. The output argument, though, is an interesting one. Considering the copyrightable nature of the output, I think is quite compelling because we have all been focused on the inputs and what makes up the possibility of even the generative and then not so much what

is generated because as a user of it i don't want to be restricted on what i can do with it because that's the whole point of using it in the first place right yep but at the same time i understand the inputs you know to some degree or many degrees obviously have an implication to what is output but i think yeah it is absolutely a wild west i'm just thinking like recent usages and if i had to like somehow adhere to a usage license of what i've recently generated through artificial intelligence but it's also part of my ideas too because i'm like probing it and because of its input whatever what it has available to it it's a dance in a way. It definitely is a new creation. But as a user of it on the daily, I would

be pissed and upset and sad if I had to somehow adhere to restrictions or licenses of how I use what I generated with it. So like a typical developer today says, even just John Evans recently on our show said 30% of my code is now written by copilot. And so does that mean he only has a 70% copyright on his finished product? You know, like, what does that mean? Well, I mean, and what does it mean for an individual? But what does it mean for business? Well, yeah, of course. Yeah, totally.

If you're using the, you know, for example, if you're using it to write high speed trading algorithms, right? Do you down on the copyright to that like if somebody takes that walks out the door is that fine because it's not copyrightable like i don't know so yeah the ai licensing is just like uh like i said this is fractally complex you're like i don't understand how this is gonna play out but you know fortunately i'm not a lawyer so i'm not the one who has to figure it out. At the practical level where we actually, you know, put our license in our projects, for instance, it might play out similar to how we do with creative assets. Now we're like code is licensed under this license assets are licensed under this creative commons license. Maybe it's like data models are licensed under this other thing. And so you just have multiple

licenses for like subsections of your system. I'm just thinking about how an open source maintainer might put together their project in the future world where all these things are involved in a piece of software. Maybe that's just a matter. I know there's like OpenRail

and there's a bunch of other things going on with. And I just, I just subscribed to Louis Villa's newsletter and I hope he can keep me up to date like you, Steve. That is excellent. And anybody listening,

if you want to, if the AI licensing thing is of interest to you you how to you have to subscribe what is it the open ish open ish newsletter yeah dot dot ml where we think um anyway yeah something like that we'll link to it in the show notes my only complaint with it lewis is that it does not publish enough come on man we need more we need he he has these poor guys got a day job i know he has these very long like monthly or even less than every month and i'm like that's a lot to read but i could We need more. We need, he, he, he has these. Poor guy's got a day job. I know. He has these very long, like monthly or even less than every month. And I'm like,

that's a lot to read, but I could read smaller chunks and smaller cadences. That's fair. That's a, that's me vouching for how good it is in a weird way. We should get him back on. It's been a while. Yeah.

Yeah. Yeah. Yeah. Yeah. Definitely get him on and talk, talk, talk more. I, that was a great episode.

I love that one. Thank you. I was trying to search the GitHub blog for this, but I thought I saw recently something about them defending co-pilot copyright or something like that. Does that ring a bell to either of you? Yeah. So Microsoft, I wasn't briefed, but I saw presumably the same articles. Apparently, they are in a position where they are basically going to indemnify users,

which is a big, big deal, at least from my perspective. Because it's one thing to say, hey, our lawyers have determined it's fine for you to use this. It's a different thing to basically step up and say, yeah, no, well, if somebody takes you to court, we'll indemnify you. That's a step change in terms of your level of responsibility for the output. And if nothing else, it's a signal from the company that they feel pretty good about their legal funding because what they don't want to do is run around and indemnify a ton of customers. It's not good business for them. So I won't gauge the outcomes from a legal standpoint, but I think that's certainly a pretty strong market signal

that they feel good about their chances that reminds me jared of your recent episode on js party elon musk and the licensing and you know well would you get sued for your tweets i forget the i'm paraphrasing that was hilarious headlines or headlines he guaranteed that he would uh what did he say he says so many things you can't keep up with them all. He said something along the lines of that they would pay legal fees for people whose bosses are mad at them for their tweets or something. Like something just, I think it was just a flippant thing that he said, but it was like another course made news. Yeah. Yeah.

I think like a lot of things that come out of his mouth, the lawyers somewhere were probably like, oh my God, no. Yes. Please don't hold us to this. Yeah. Microsoft, Microsoft's a different deal. Microsoft, I think, yeah, they probably had a more calculated statement. So this indemnification, was that from Microsoft

or was that from GitHub? Because I couldn't find it on the GitHub blog, so I think it was from Microsoft. I'd have to go back and look. I believe it's from Microsoft. That's my recollection. So that means that like, that's even blurring the lines between Microsoft and GitHub too, because that's a,. That's my recollection. So that means that like, that's even, you know,

blurring the lines between Microsoft and GitHub too, because that's a, Copilot is a GitHub product. It's owned by Microsoft, but it's a GitHub product. Yeah, yeah. But Copilot has also surfaced up

in, you know, Microsoft projects as well. That's true. That's, you know, going to be their brand, right? Yeah. So, you know, Copilot is, you know, frankly, it's going to be,

it's like it is for something, you know, you see, Google does this with like Duet, right? You know, Duet is their, you know, their brand for, you know, frankly, it's going to be, it's like it is for something, you know, you see Google does this with like Duet, right? You know, Duet is their, you know, their brand for, you know, their generative, I should say their conversational interface, right? And send all kinds of like workspace and GCP and, you know, some of all these other pieces. So, yeah, because in other words, you know, Microsoft, you know, if they want to leverage the technology, they have to make a decision, you know, is this legal or is it not, right? And clearly they've come to the, I mean, they have come to the conclusion that it was because otherwise, you know, release that project and invest in it what they have. But like I said, there's a difference between, hey, we're going to do this and hope where customers have said, okay, this is going way back with the SCO license issue with respect to Linux kernel. One of the questions was like, hey, will you indemnify us? And it was really difficult for, even for companies that were like,

no, hey, legally, I'm certain we're on solid footing. If you're a smaller company at that time, which most of the open source companies were, indentification is like, how are you going to, like, how would you do that? Practically speaking, you just don't have the resources. So the point is, is that from a Microsoft standpoint, yeah, when I saw that, that was a pretty big deal. This is a Changeangelog Newsbreak. PageFind looks pretty cool.

It's a fully static search library that aims to perform well on large sites while using as little of your user's bandwidth as possible and without hosting any infrastructure. It runs after your static site generator, like Hugo, Eleventy, Astro, etc. and generates a static search bundle to add to your built files. It then exposes a JavaScript search API that can be used anywhere on your site. Quote, the goal of PageFind is that websites with tens of thousands of pages should be searchable by someone in their browser while consuming as little bandwidth as possible. PageFind's search index is split into chunks so that searching in the browser only ever needs to load a small subset of the search index. PageFind can run a full-text search on a 10,000-page site with a total network payload

under 300 kilobytes, including the PageFind library itself. For most sites, this will be closer to 100 kilobytes." I'd love to see a comparison, link me up if you know of one, but my guess is that this could easily replace Algolia on lots of open source docs and websites. One less service to depend on, why not, right? You just heard one of our five top stories from Monday's Changelog News. Subscribe to the podcast to get all of the week's top stories and pop your email address in at changelog.com slash news to also receive our free companion email with even more developer news worth your attention. Once again, that's changelog.com slash news. so steve do you like to uh predict the future at all is that something you do as an industry

analyst uh yeah so so if brian cancel happens to listen to this, uh, he'll, he'll get a chuckle out of this. But, um, so for many years I did these predictions at the end of the year and I did pretty well, like, you know, it was like 60, 70%. And, you know, it was noted by, uh, Brian noted that, um, my predictions were a little safe. Uh, so then I was like, okay, like I'll take some shots. And I predicted some things in my, my accuracy, not so good. Yeah. So then the good news is that I had a kid was was like, she's going to turn eight in November. And I was like, oh, I don't have the time. I'm so tired. I'm trying to do too many things. So it's been a couple years since I did predictions.

Okay. Well, I'll allow a safe one here. What I was thinking is one of the things that you say in the post is that open source is at a crossroads. And I thought that was true. And I thought, hey, maybe you make a good title for this episode. We'll see when the minds combine between Adam and I, what we come up with. But if it's at a crossroads, you know, you're going to go one way or you're going to go the other from a crossroads. So I'm curious what you think the trend is. Like, where is open source headed? Are we going to have more munging of the term? Are we going to have more things that are open-ish claiming to be open source? Are we going to have more munging of the term? Are we going to have more things that are open-ish claiming to be open source? Are we going to have it like resolutely defended and these things will be clearly delineated that they're not open source?

What do you think is headed if you had to project a little bit? Yeah. So let me tease that apart just a bit in the sense that the direction of travel, I think from the standpoint of commercial open source licensing is pretty inarguable at this point. We're going to see more of this, right? Either, you know, sort of the quote unquote bait and switch model, right? More companies are going to sort of, you know, relicense their assets. I don't think we'll see companies start, you know, with BSL and so on as much for the reasons that we talked about earlier.

You know, I think Adam mentioned this where it's like, yeah, I wouldn't have started if it was licensed that way. But in other words, if we're having this conversation three, four, five years from now, are there going to be more of these companies who are re-licensed? The answer to me is, I don't see how you build the argument otherwise, which like I said, I don't think that's a great thing for the industry. But again, companies have the right to do what they will. The bigger question to me is, does the open source term itself get munged, to use your term, Jared? I think my hope is no. And at least I will say this, having put out the piece, having had a lot of conversations since, I've talked to people who didn't care before, and they don't care necessarily now, but they at least understand, hey, this is okay.

I can understand that there may be some issues with that. Right. And so, yeah, I mean, I've been in this industry too long to be hopeful about the sort of ethics involved in terms of people getting together and doing the right thing from a licensing standpoint. But yeah, like I said, I think we'll see more, you know, relicensed assets. And, you know, if I had to bet, I would probably bet that, you know, the term itself is pretty damaged a couple of years from now. We spent this whole conversation not mentioning the OSI though. Like, I think if anybody's going to defend it, they would step up and defend, right? Like they maintain, you know, the list. Yeah. I mean, the OSI maintains the definition. Put it this way, I think the OSI's biggest issue

for many years has just been staffing and funding, right? That is having to have the resources to do the kinds of campaigns, you know, that you need to do, right? Like, so, you know, you have individual voices out there, you know, who are basically saying, hey, this is a problem, here's why, you know, writing pieces like the one that, you know, sort of, you know, kicked off this particular conversation, but that's not enough, right? You know, we need a more systemic campaign. The OSI has done, has been more aggressive on this front recently. I was on a, I guess, a webinar with Stefano from the OSI last month, two months ago, you know, after the sort of lawmen who's broke, I think he's done a good job trying to up-level this from a

visibility standpoint. But like I said, they're just not resourced, right? In other words, when you have a company with the resources of a meta running around telling fleets of journalists, hey, I took this thing that's not open source and calling it open source, and the journalists, I don't blame them, right? In other words, the tech press is hard press these days, right? 20 years ago, you had people who had been on the beat for a while. They knew the industry in many cases, as well as the analysts did. Now they're covering way too much, right? And they can't keep track of these nuances. And so when you have meta, companies that size running around, misusing the term is very, very difficult for organizations, the size

and scope of the OSI to combat that. So my hope is, is that, you know, sort of, you know, they'll get more support, you know, from folks that are in industry and, you know, believe that term matters, but, you know, we'll, we'll see how that plays out. Well, you left us on a dour note, Steve. I don't know how to, how do we recover from here? That's the problem. I, every, every one of these conversations I tend to have, people are like, oh, you don't seem that optimistic. And I'm like, I'm not. And like I said, you know, I have said this many times. You know, there are, you know, there's this sort of meme or stereotype as analysts who are like, oh, no, I know everything.

And I know exactly how things are going to play out. And it's like, no. Not us, not me. So, I've been wrong before. I will be wrong again, and hopefully this is one of those times. But, you know, as somebody who has been publicly saying the things that I have, and, you know, privately, and I can't tell you how many conversations I have had, individuals, companies, projects, foundations, agitating on just these issues, the direction

of travel is, it's tough to see because it's like i said on the one hand you know you talk to the company you talk to an individual it's like hey i get your choice you know totally understand it but in the aggregate you know like i said that's one of the reasons i use the the climate change analogy where it's like hey you know people got to do what they got to do and yet what is it like at least up here in maine like nine of the you know 10 hottest uh seasons have been like in the last decade. That's probably not great. I'm in Texas and it's pretty hot this year.

Hotter than Texas should be. That's for sure. For sustained times, like 90 days plus at 100 degrees plus. And obviously in the evening it goes down, but peak temperature of the day recorded above 100 degrees for 90 plus days. I mean, my grass is not grass anymore. You know what I mean? Yeah, right. It's crunchy stuff, as they say.

Yep. And meanwhile, we have a hurricane poised to hit us this weekend. Yeah. That's very, I've been watching that too. And yeah, geez. Yeah. Good times. Let's focus on things we can control because we can't control the weather necessarily.

We can't control to some degree how we influence the weather in aggregate or maybe individually. If the OSI is important in this ongoing definition of open source and even the defending of it, what do you know about them that we can do? We've never had anybody from the OSI on this podcast here. Like we've talked to Josh Simmons when he was, I think, still part of the OSI, but not in light of the goings on at OSI by any means. So we've never had like a conversation. Yeah. I've reached out to Stefano, you know, for sure.

And, you know, so he'll come on. I'm sure he would. And, you know, at the end of the day, I mean, I think, you know, the difference between, you know, one of the differences, I should say, between climate change and open source is that there are things that every developer can do, right? So, in other words, you know, just understand and realize that you might not think this matters, but it does. It doesn't mean you have to do anything, right? But also, part of it is that, you know, hey, maybe you push back when somebody says, hey, I have this open source license. And you're like,

well, what is it? It's like a, you know, some weird non-commercial derivative. You can say, oh, cool. Hey, I appreciate the source code, but that's actually not open source, right? And so, you know, that's the thing. Like, you know, what can sort of an individual do about climate change? Probably not a lot. You know, you can make better choices, you know, from a household basis and all that, but there are things that every developer can do. And if developers as a group, you know, sort of demonstrate that, again, not that everybody has to license everything in one way, but if they demonstrate that, hey, we care, like this, you know, these definitions matter to us, you know, even companies that are

misusing the term will have to, you know, sort of stand up and pay attention. So hopefully that happens. And like I said, Stefano coming on, I think would certainly help that to that end. Well, they're a 501c3. I don't know if they do much funding rounds or donation rallies or whatever you might call this call to action. I feel like if they're understaffed or undersupported, maybe that's one way too to not so much be a meta-sized donation, but definitely which is sort of a nice pun in a way, that they can get support from

everyday folks to provide their time, their attention, and obviously their vote that it does matter. Yeah. I mean, that's the thing. I mean, every developer is just sort of giving them attention and basically acknowledging like, hey, this matters and it's something we should care about, you know, is a good thing. If someone's listening to this podcast, maybe they're a CEO or a founder of said company that may be considering a bait and switch in the future.

They've got a permissively licensed open source, commercially open source software, Koss, that kind of company or whatever. And they're considering, man, we've really got to get some control here. What do you personally say to someone in those shoes to consider with this choice? Do they go to RedMonk and say, can we have you analyze our source code in our community? What do you personally say to them in regard to this consideration of they may not mean to do a bait and switch, but if they do the thing, it would be? What do you say to them? Well, that's where it's kind of tricky in the sense that where, because our responsibility

is to our client, right? We have to tell them sort of what's best for them. I tend to, in most cases, not believe that a bait and switch is the right way to do things. Certainly, I don't believe it from an industry standpoint, as we've talked about. From a company standpoint, basically, my argument, we talked about this a little bit earlier in the show, was basically, look at your model. In many cases, people are trying to solve business model issues with a license. And that's not typically the way that, you know, at least in my view, right, things should be solved. So in other words, you know, if you're competing, for example, with, you know, or if you're poised to compete with, you know, larger clouds, what can you differentiate?

Well, there's lots of things, right? You know, for, you know, you're offering a service, you need to offer service first. But then also, you can offer adjacencies, you can offer, you know, features that are not present in the open source code. And, you know, on the one hand, that's a bummer, because it means less open source. But on the flip side, if you are still providing the code itself, the core code itself unencumbered right? What is the precise license that you're under? What is the nature of your community, right? What's the nature of your adoption? What's the nature of your market and so on? So a lot of times we sit down with companies, it's just going through these and trying to understand, all right, what's your exact position and what makes the best sense for you? And to the extent that we can steer people away from it, great, we try. And yeah yeah, you know, like, I think I can say that, you know, the majority of companies that have relicensed are customers of ours, we try to talk them out of it. And in, I think, the overwhelming majority of cases, and then, you know, once they'd said, okay, this is what we're going to do, then, you know, my job at that point is to try to provide the best advice in terms of minimizing and mitigating the impact on the community, right? Okay, If you're going to do this, you know, here's what to do is, you know, so for example, right. When Hashi comes out and

relicenses, but it's very clear to, you know, be, you know, be upfront and set expectations. This is not open source. That is the type of advice that we'd give, right. Which is, you know, Hey, if you're going to do this, there's a way to do it. That is, you know, less damaging than the way that some other folks do. So it's a hard, complicated question. How do you all maintain, I think you have great credibility. How does RedMonk and you personally maintain such great credibility when at the bottom of your post you say, disclosure, Amazon, Google, Microsoft, and RedHat are RedMonk customers?

Meta is not. You say that. How do you put such a good point out that is against clients even? You know, like, it's not always for them. How do you maintain that line when you have customers and clients and then your obvious opinion as a company and individually? Yeah, so, you know, we decided pretty early on,

you know, within the first month that, you know, you can't go down the, you know, sort of pay for play, you know, your opinions for sale model, right? Because once you do that, you just don't have, we were talking about reputations earlier. Once you do that, you just don't get it back, right? And so, we have always tried to be, you know, if anything, overly, you know, sort of honest and transparent. We're diplomatic about it. We're not going out and posting hot takes on companies and so on. But in other words, if we think that a company is doing something wrong, we say that we're doing it wrong. We got an interview years ago and it was like, do you think you should be under less scrutiny from a transparency and an honesty and ethical standpoint than larger analyst firms? We're like, no, we're much smaller. We should be under, if anything, more scrutiny. And they said, well, I don't understand, like, how does that function? And it's like, it's pretty simple. You know, we post a, you know, sort of list at the bottom. These are the people who are paying us and these are people who aren't. Developers, you know, they may or may not care about licenses, but they're

smart. And if we came out and we're basically consistently saying great things about our customers and bad things about our, you know, the people who aren't paying us, then, you know, our reputation is going to be gone pretty quickly. So, you know, we're fortunate, like, you know, the people aren't paying us, then, you know, our reputation is going to be gone pretty quickly. So, you know, we're fortunate, like, you know, clients are not always thrilled with the things we put out, but they also understand that that's part of, you know, it's part of what makes us, you know, hopefully, you know, sort of a trusted, you know, asset in that, you know, we're not coming out and just like, hey, this is the greatest thing in the world because, you know, so-and-so paid us, like not a model that works. So, like I said, you know, we have certainly gotten our share of emails like, what did you just write or whatever? And the interesting

thing actually is, is that, you know, very frequently we'll post something critical, you know, we'll hear from a whole bunch of people within the company. They're like, yes, please keep doing that because I've been saying this, no one's listening, you know? So, yeah, it's, as I said, you know, we we i'm sure we could make a lot more money if we just uh sold out and and um at least for a little while you know until your reputation shot but that's uh that's not the way we do things well we we uh we feel the pain of of towing that line we we have similar we're not analysts but we do certain examine and question and scrutinize uh players you know and some of those players decide to work with us through sponsorships or

promotions and some don't. And we always say what we think and how we feel with tact, of course, and respect regardless of the relationship. And we're always, you know, clear about those things as well, but it's, it's tough because like you said you could make more money if you did x but then you would like have zero satisfaction and yeah no one would really trust you and then our listeners wouldn't really care one thing we have around here is listeners first so every decision we make is listeners first like

if our listeners don't want to hear it wouldn wouldn't like it, you know, whatever the scrutinizing point might be, then we're going to reconsider that, obviously, or consider it even more closely. Because our ambitions and our desire is for our listeners to always trust and enjoy the content we put out. And then that translates also to the sponsors that we decide to work with. Because sometimes, in most cases, we get to say no just as much as we get to say yes. We sometimes in most cases we get to say no, just as much as we'd say yes. Like we choose them just as much as they choose us. It's challenging to toe that line. It's challenging. I think the one thing else is like, you know, the longer that you do this, at least in our case, like we've had, we've had a couple of clients, you know, frankly, you know, companies that have relicensed,

right. That basically, you know, we said, no, we don't think you should do this and blah, blah, blah. And they're like, okay, cool. We're out of here. And the interesting thing is that they come back later, right? Not for that advice, obviously, you know, they've already made that, but it's like, you know, I think if you provide a sort of valuable service, you know, not that you get it right every time or, you know, not certainly that we're right every time as we talked about, but, you know, I think people will sort of ultimately come to recognize what you stand for and, you know, they may get upset about things from time to time, but I think over the long haul, it's, it's really the, you know, the better bet is, is sort of in being honest with

your audience. Right. You know, cause like I said, credibility is, is, is everything, you know, to me in this business. For sure. It's not challenging to maintain our morals by any means, but it is challenging in the fact that just doing business is challenging when you have challenge. I'm like a famous politician in that moment. Anyways, I digress. Well, yeah. What do you got to say, Jared? Anything else?

What's left? Oh, no. I was just thinking that I literally could have. I said almost the exact same thing Stephen said like days ago to somebody about this exact same topic. It's just that I said, I think at the end, like, well, we have to sleep it.

You know, we make a lot less or we make a lot less money this way, but we do sleep well at night. So that's the choice that we continue to make because we'd rather sleep well than for sure. Roll around and short term riches. Well, Steven,

I just want to say thanks for coming on the show. It's kind of a shame. It's been so many years. We've never had you on so far. So we're happy to finally do that. I've been fans of your guys' work for a very long time. Yeah, right back at you.

The voice of reason and sense. And I'm nodding along most of the time whenever I'm reading something that Red Monk is writing. So appreciate you guys and your voice in the community. I think you're showing us what we need to do.

I think if we do believe that open source matters and we need to protect it individually or if we do believe that open source matters and we need to protect it individually, or if we can act collectively, of course, but loud voices of logic and reasoning, you know, more of those I think is kind of can't hurt in this battle to keep the clarity that we currently have and enjoy. So that'd be my parting words. Any, anything from you guys as we close out? No, I'm just a pleasure to be on.

And I had the pleasure of actually recommending you folks to one of our clients. Let's see the day. Cause it's a, it's a quality show. Happy to be on. Thank you so much. I like what Jared said.

Like it's, we've been fans for years now and now that we're friends to some degree, we'll have to have you back on more frequently and get more... Anytime. ...mild takes, hot takes. I don't know. Well-reasoned takes. Hopefully the news is better next time

than it is this time. Let's say that. Thanks, Stephen. My pleasure. So the definition of open source, it means something. And it's worth protecting. And I believe that if you're listening to this

podcast, yes, you, you are in the small, but vocal minority who cares. And if you don't care, and you're listening to this, you should care because open source has provided a way for many, many people to thrive and open source matters. It matters to me. It matters to Jared. It matters to many people out there in the industry. And we need to ensure that it remains fought for. It remains protected. The small but vocal minority is the last stand. And that's you. is a bonus. Yes, a bonus for our plus plus subscribers on this podcast. So you're going to like it. I liked it. I think you'll like it. If you're not a plus plus subscriber, you can correct that right now. It's too easy. changelog.com slash plus plus. It's better. That was ad lib just now, by the way. Yeah. changelog.com slash plus plus. $10 a month, $100 a year. Closer to that cool changelog metal. No ads.

Directly support us. And if we meet you in person, we owe you a hug if you want one. Or a very firm handshake. You pick. Again, changelog.com slash plus plus. A massive thank you again to our friends at Fastly, our friends at Fly, and our awesome friends at Type Sense, and our Beats master and residents, Breakmaster Cylinder, bringing the Beats as usual.

One more thing. There is no team talking friends this Friday. Jared and I are in St. Louis right now at Strange Loop. And if you're there, if you're listening to this for some reason and you're there or you're going to be there, come and say hi. We are in the sponsor area just hanging out podcasting. Make sure you come say hello. We want to meet you and we'll see you there. Well, that's it.

This show's done. We'll see you next week.