The Changelog: Software Development, Open Source
ANTHOLOGY — Packages, pledges & protocols (Interview)
Wed, 06 Nov 2024
The hallway track at All Things Open 2024 — features Carl George, Principal Software Engineer at Red Hat for a discussion on the state of open source enterprise linux and RHEL (Red Hat Enterprise Linux), Max Howell, creator of Homebrew and tea.xyz which offers rewards and recognition to open source maintainers, and Chad Whitacre, Head of Open Source at Sentry about the launch of Open Source Pledge and their plans to helps businesses and orgs to do the right thing and support open source.
Okay, friends, this is the changelog and we're going back to the hallway track at All Things Open 2024 in Raleigh, North Carolina. This episode features Carl George, Principal Software Engineer at Red Hat for discussion on the state of open source enterprise Linux and RHEL, better known as Red Hat Enterprise Linux.
We talked to Max Howe, creator of Homebrew and the Tea Protocol at Tea.xyz, which offers rewards and recognition to open source maintainers. And last, we talked to Chad Whitaker, head of open source at Century, about the launch of Open Source Pledge and their plans to help businesses and orgs do the right thing and support open source. A massive thank you to our friends at fly.io.
That is the home of changelog.com. Deploy your app in five minutes at fly.io. Okay, let's do this. What's up, friends? I'm here with Dave Rosenthal, CTO of Sentry.
So Dave, when I look at Sentry, I see you driving towards full application health, error monitoring where things began, session replay, being able to replay a view of the interface a user had going on when they experienced an issue with full tracing, full data, the advancements you're making with tracing and profiling, cron monitoring, code coverage, user feedback. and just tons of integrations.
Give me a glimpse into the inevitable future. What are you driving towards?
Yeah, one of the things that we're seeing is that in the past, people had separate systems where they had logs on servers written to files. They were maybe sending some metrics to Datadog or something like that or some other system. They were monitoring for errors with some product, maybe with Sentry.
But more and more what we see is people want all of these sources of telemetry logically tied together somehow. And that's really what we're pursuing at Sentry now. We have this concept of a trace ID, which is kind of a key that ties together all of the pieces of data that are associated with the user action.
So if user loads a web page, we want to tie together all the server requests that happened, any errors that happened, any metrics that were collected. And what that allows on the back end You don't just have to look at like three different graphs and sort of line them up in time and try to draw your own conclusions.
You can actually like analyze and slice and dice the data and say, hey, what did this metric look like for people with this operating system versus this metric look like for people with this operating system and actually get into those details. So this kind of idea of.
Tying all of the telemetry data together using this concept of a trace ID or basically some key, I think is a big win for developers trying to diagnose and debug real world systems in something that is, we're kind of charged the path for that for everybody.
Okay. Let's see you get there. Let's see you get there tomorrow. Yeah. Perfectly. How will systems be different? How will teams be different as a result?
Yeah, I mean, I guess again, I'll just keep saying it maybe, but I think it kind of goes back to this debugability experience. When you are digging into an issue, you know, having a sort of a richer data model that's, you know, your logs are structured, they're sort of this hierarchical structure with spans.
And not only is it just the spans that are structured, they're tied to errors, they're tied to other things. So when you have the data model that's kind of interconnected, it opens up all different kinds of analysis that were just kind of either very manual before, kind of guessing that maybe this log happened at the same time as this other thing, or we're just impossible.
We get excited not only about the new kinds of issues that we can detect with that interconnected data model, but also just for every issue that we do detect, how easy it is to get to the bottom of it.
I love it. Okay, so they mean it when they say code breaks. Fix it faster with Sentry. More than 100,000 growing teams use Sentry to find problems fast, and you can too. Learn more at Sentry.io. That's S-E-N-T-R-Y.io. And use our code CHANGELOG. Get $100 off the team plan. That's almost four months free for you to try out Sentry. Once again, Sentry.io. All right, hard question first, Carl.
You ready for this?
Should I introduce myself?
No.
Carl George. Go ahead, Jared. You got one teed up. I was just trying to get his name on the record here, just in case he says something. He might run away.
My name's Benny Vasquez. Actually, get a little closer to the mic and give me a sound check.
Sound check. One, two. I like barbecue. How about that? Tacos are good, too. I love eating.
Do you make your own barbecue?
Oh, yeah. Do you? I'm a good amateur. I'm not professional level, right?
You're a backyard barbecue guy.
Backyard barbecue. Tell me about your tools, your tooling, your cooking methods. So my smoker that I have, my father-in-law gave it to me before he passed away.
It was in his backyard for a while, and I was picking up my kiddos from staying at Grandma and Grandpa's house one weekend, and my mother-in-law mentions, oh, I told Catherine, my wife, she's like, I told Catherine that you could have that smoker. And I'm like, what? She never told me that. And my wife denies it to this day. She's like, she never told me that. She's making that up.
I was over there in like 12 hours. I had like four full grown men over there lifting this smoker in the back of my truck. Like, yes, I will take a free smoker. How many gallons? I don't know. It's not huge. Well, four guys to carry it. Yeah. I mean, it was like. 18 gauge steel, thick steel. Yeah, it was very thick and heavy. One of their cousins made it for him for an anniversary present, I think.
That's cool. So very old, but very good smoker.
Gotta love a good smoker hand-me-down, you know, really.
I mean, better than paying, you know. It's already seasoned. Yeah, better than paying a grand or two for a brand new one, right? Oh, for sure.
That's where I'm at. I'm like, I don't have a hand-me-down. So I'm like, my only option is to either build one myself, which I will probably not do. Or spend money on a mill scale or something else.
Could you build it yourself? Do you know how to weld?
I have friends. Okay. Yeah. I can get it done if I wanted to, but it's heavy. You've got to bother your friends.
You want to build it on site so you don't have to move it?
I don't have the expertise. I want to leverage Aaron Franklin's expertise or mill scale's expertise. Why do I have to become a barbecue manufacturer expert just to become a backyard amateur?
Yeah. I don't have any other tricks than that other than like you want to use a good smoker. Volume matters. Like you said, I don't know how many gallons this one is, but I noticed that where like you have like a backyard smoker compared to what you get at the restaurants, the real professional stuff. You have a tall stack.
They've got like, you know, like 10,000 gallon or 1,000 gallon propane tanks that have been converted into smokers. And I think the volume makes a huge difference on that on how much you can control the temperature variation. It's huge.
Yeah, there's a lot of...
ongoing barbecue science yeah it's endless in texas the smaller it is the harder it is like i have trouble sometimes keeping the temperature even because it's not a huge smoker it's a decent size but yeah yeah the that's how i think the big that's the the real secret from the big professional joints is they can they can afford the massive smokers doing you know 20 briskets at a time and that volume helps them keep the temperature so consistent like one maybe two you know yeah i mean brisket alone is expensive so i'm gonna afford one to mess it up yeah i mean all right
Wings, stuff like that. But I could talk about barbecue all day. Same. But that's not why we're here. Let's talk about the confusion, I suppose, around Red Hat Enterprise Linux, the history of CentOS to some degree, and really the state of open source Enterprise Linux. Sure. What could you share? You've shared. We've had conversations. None of them so far recorded.
And here we are. Good.
So... Help me demystify for those listeners out there. You work at Red Hat, to be clear. You are a principal software engineer. And you work on, what was it, the extras?
Apple. Extra packages for Enterprise Linux. It's an add-on repo. The closest analogy for people that are... I like to compare it to Ubuntu's universe. The main difference is Ubuntu, they enable their universe, their community packages out of the box. You just have it. They're available. But they're not...
I think they've changed it a little bit with the new Ubuntu Pro stuff, but for the longest time, Ubuntu's universe repo was these are the community things, Canonical doesn't handle these, and that's basically what Apple is for RHEL. It's just we don't have it enabled out of the box, we make it an opt-in thing.
You have to go out of your way, add the Apple repository, and then install the community main team packages you want. And a good thing to note is Eppel, it's not its own project. It's part of the Fedora project. And the way the whole thing fits together, it's much easier visually with the diagram. So I'm trying to think how I can describe the picture in my head.
But there's this line going across that's Fedora Rawhide. That's our rolling release. And that's where all the newest stuff goes right away, kind of like Debian SID. But after this point, the Debian analogies fall apart, it doesn't work. We do our Fedora releases every six months. Fedora 41, I think, just got released today. Those branch off of Fedora Rawhide.
But then that's something like, I think the last time I looked, it was something like 60,000 packages that are in Fedora. Red Hat doesn't want to support all of those in the product, eventually where it gets into into RHEL, Red Hat Enterprise Linux. So it's only a subset. I think roughly around 10% of the Fedora packages, like 6,000 or so, actually make it into RHEL.
And that happens by going through CentOS, or CentOS Stream, rather. There's a whole bunch of confusion around the name change we did. It's still the CentOS project. CentOS is not dead. It's just a little bit different now.
It's still available, right? Yep. For those who think it's not there...
It is there. There's been a lot of misleading messaging around, CentOS is dead or you have to replace CentOS. No. There's differences, you should understand them, but I think there are a lot of positive changes that people are missing out on it because they're not just buying the marketing line of somebody that says, I want to be the new CentOS. Well, That's kind of flawed.
Why don't you just be a distro on your own, make your own reputation, and then see what CentOS is doing. If it works for you, then keep using it. I think it would work for a lot of people. There are some people that, I think there's one guy I know at work that says that if you have a RHEL-sized hole, we want to sell you RHEL. 10 year life cycle, vendor escalation. Assurances.
Yeah, assurances, the partner ecosystem.
Before we started recording, I was telling Adam that one of the big value propositions that I know Red Hat talks about a lot, but I think a lot of people miss out on, whether it's just phrasing or it doesn't convey well, is that Red Hat has spent literal decades and countless amounts of money building a partner ecosystem with hardware vendors, software vendors, and upstream communities, right?
and the big value premise you're paying for when you buy RHEL, and I'm not a RHEL salesman, this is going to sound very sales pitchy. You're an engineer. I'm very low in the weeds.
We purposely wanted to have you on here. We could have had others talk, and it's not we don't want to talk to them, it's that we want to hear from an engineer that doesn't have a dog in the fight insofar as you're trying to sell something or market something. We want to hear from an engineer who cares about and has been at Red Hat since 2019, is that right?
Yeah, 2019.
So you've been there for a while.
I think a good bit of nuance to that is that, yeah, I've only been there since 2019. Relatively short, I've been in the CentOS and Fedora and Apple communities before that. I got hired out of those communities to do it full time at Red Hat, which is another huge value that they do is employing people in open source projects to keep making open source, which we have.
There's a whole track yesterday here at the conference about open source sustainability and sustainability versus freedom and choice and open source purists and things like that. And yeah, a lot of people, the dream is to get paid to work in open source. I feel great, I've achieved that dream.
Other people aren't as lucky or they get it like, I know my last employer had a thing where it was like, well you can do open source part time and then this much time you have to do these things inside the company. You have a lot of that. And I know a lot of companies, their OSPO offices, open source programs office or equivalent name,
They struggle around how do we get our engineers to be better open source citizens. They're consuming all this open source. How do we turn them from just consumers into making sure the things we depend on continue to exist long term? Which is a theme that I'd like to segue off of in DescentOS.
Yeah, let's go back to that. We've set the premise that you're a credible person to talk to. You're not selling anything. You're not marketing. Not that they're bad people, but we don't want to be marketed to. We want to hear the From an engineer, from the inside. Layout, CentOS, it's not dead, it's still there.
How that relates to RHEL, how that relates to Fedora, and the whole life cycle of how you get to these packages that people can rebuild off of, and this sort of conundrum of the open source enterprise Linux we live in.
So, big question, right? I started going on a little bit, started talking about how I wish I had a diagram of Fedora branching from Rawhide into its releases. Every three years or so, we'll take one of those Fedora releases and we'll branch it again and start building the next major version of RHEL. That starts as CentOS Stream, but before we've announced it. It's still very early.
We're still forming pre-alpha days. We're putting all this stuff together. And then at a certain point, they have enough of the changes that they want to go into the next major version of RHEL. Like we want this version of Apache, this version of OpenSSL. Maybe it's the same ones at the exact time they branched. Maybe they go one forward, one back.
Maybe they add a few other features, build a few things differently. but that is the process of turning the Fedora fast-moving, innovative project into the enterprise product, and that happens through CentOS. There's a lot of chat about how they talk about RHEL compatible and like the Enterprise Linux standard, other people with other projects. There isn't really a standard.
There's Red Hat making a product, and to whatever extent there is a standard of Enterprise Linux, CentOS defines that. That is where it happens. And so, because it's happening there, you can influence it. You can actually contribute to it.
I know you all have a big developer audience, and the analogy I used earlier was that if you've got a choice between two libraries, one that is active development, getting features, you can contribute to it, whether or not you have the ability to or the intent to, the fact that you can contribute to a vibrant project that's growing and active,
Would you rather use that or something else that says, yeah, we're going to be exactly the same as the other thing. And if you send us a bug report, if it's in the other thing, we're just going to close it. And you can't contribute here. We are bug for bug compatible. There's this whole mythos about bug for bug compatible.
And really, when someone says I want bug for bug compatible with RHEL, what they mean is I want RHEL without paying for it. That's really what it boils down to. It's a pretty blunt statement, but it's true. What's different from the past when CentOS originally started was that you can get just RHEL for free. There's a lot of free programs.
There's the, and this is going to sound sales pitchy again, but I'm telling you how to get free stuff. There's the Red Hat developer subscription for individuals. Anyone can sign up and get 16 free RHEL instances to do whatever they want to with. No limits. You can even use it in a business. It's just a little fuzzy because it is individual, right? You can't agree to the terms on behalf of an org.
So for most businesses of more than one person, it's not really going to work.
Yeah.
There is also another program, Developer Subscription for Teams, that'll give you, I don't remember the exact number. It's high. It's in the thousands of free RHEL instances in your non-production environments if you're paying for RHEL in production. And then there's also programs for giving open source projects free RHEL.
There's programs for giving educational institutions free or heavily discounted RHEL. There's tons of ways to get RHEL without paying for it. But there are definitely scenarios where Red Hat once thinks that, yes, this person should pay for RHEL. And a lot of those people are the ones that they use CentOS rather than just, I want an operating system.
They wanted just to get RHEL without paying for it or get a discount on their RHEL. They'd use, you know, 10% of their fleet on RHEL and then the rest on CentOS to cut cost. That was never a good fit for it because of small, subtle differences in the engineering and how it's built. One of those is that Red Hat Enterprise Linux actually has overlapping minor versions.
You can stay on, say, 9.0 after 9.1 and 9.2 come out, still get security updates, and some third parties only certify on specific minor versions. So if you've got third-party vendor software that hard requires 9.2 using anything that's on, you know, like...
one of the other rebuilds that's on 9.4 on Centro Extreme that basically has 9.6 content right now, it's a little bit ahead on minor versions, then if a vendor requires 9.0 strictly, then it might not work. But Red Hat will sell you 9.0 still with security updates. 9.2 might be a better example, because it doesn't last forever, you can't stay there forever, it's just an extension.
But those overlapping things are things that community projects have never had. CentOS never had them. And the new RHEL rebuilds that are trying to claim that they're the new CentOS, they don't have them either. They also have corporate sponsors that sell those extensions. They're trying to make their buck too, which is understandable. We're all trying to make money in open source.
The big value prop that I talked about with Red Hat with the ecosystem stuff is that, not that you'll just go use this and it's a cheaper price than RHEL, it's that you can go to the people creating this software. A lot of times they're maintaining it in RHEL, they're maintaining it in CentOS, and often times they're maintaining it in Fedora too.
Not always, but there's a huge, huge participation from Red Hat in Fedora all the way. It is separate from Red Hat, but we're very involved at every step of the process. So if you can make a feature request and say, I wish this software did this thing, Red Hat can say, all right, that's a good idea. Here's how we'd go about it.
First, we're going to put it in the upstream project where we're also participating. Then we'll build it in Fedora. And then it'll go into either the next minor version of RHEL or the next major version of RHEL, depending on how disruptive the change is. And then they put it in CentOS Stream Next. And then it goes into RHEL after that.
So having people that are holistic across the entire pipeline, that's the expertise thing. From the engineering angle, that's the real value I see looking at it with a set of engineering eyes.
Any thoughts, Jared? Where are you at with this? I guess I'm just still confused. Not because you're not doing a good job.
Sure.
It's a lot of information. It's a lot of information. And maybe I do need a diagram, perhaps. Yes. Because I'm jumping kind of from noun to noun. I can put a diagram in your show notes. Yeah, that would probably be helpful.
You mentioned about how it works differently now. I want to go into that a little more if I can. What do you mean by that? CentOS and working differently, right?
Working differently than what? Differently prior to acquisition.
The IBM acquisition stuff is kind of tangential, right?
No, no, no. I mean the acquisition of CentOS open source to CentOS Red Hat controlled.
So CentOS started outside of Red Hat. And then I think it started around 2004. About 10 years later, the project was kind of on the ropes. Maintainers were burned out. They had day jobs. No one was getting paid to work on it. And what Red Hat saw was that... And it's kind of weird. It's a bit of an incompetence thing.
We had inside Red Hat development teams using CentOS to build with because we couldn't get out of our own way and give our own teams free RHEL. It's super messy, and it's gotten better since then. But at the time, that was kind of the state of things. That's pretty funny. Yeah. Maybe I should talk about that. But I think it's hilarious.
It's too late.
I'm just kidding. Nobody's told me I can't say that.
uh but that kind of drove it they basically red hat was like we want this this project to keep existing and so we're gonna you know they made job offers to all of the developers most of them took it a few of them turned it down and then um they basically came into red hat partially they were still kind of kept off to the side they're like well you're still kind of duplicating this product but we want you to keep going and and uh exist and so they kind of sat in that limbo for a while where they weren't growing they weren't getting
They weren't getting people resources, but they had the resources they need to focus their full time on it, get a paycheck, and keep the project going. That was a little bit of an infusion, but we still had this problem around this whole bug for bug thing and also being a duplicate of the product.
There would never be a business incentive to put the same engineering resources into your product and this project that is trying to match it as close as possible. That would never make sense. No business person would agree to that. but because of all the nuance around how it was being used as a development platform.
But we also saw the pain points of it being a development platform that lagged behind the thing it was trying to match, right? CentOS would typically lag about a month behind on the minor versions, like RHEL 7.6 would come out, and then CentOS 7.6 would be, it'd be 7.5 for a while, they'd finish the rebuild and publish it, and about a month later you'd get it.
So those rebuild gaps were real painful for the developers trying to use it as a platform to build on.
Because at that time, CentOS was behind RHEL. And the transition that a lot of people got upset about was they were using CentOS as this open source RHEL-like operating system in production, which was the bigger backlash. And then Red Hat's move was to push CentOS in front of RHEL, let it be CentOS Stream.
That push wasn't about that reaction. That reaction came later. But yeah, I get you.
It's kind of like if you're painting this visual, CentOS used to be behind RHEL.
Yeah.
where RHEL was in front of it, and then it became CentOS Stream, which was in front of RHEL. The innovation was happening in Fedora, landing in CentOS Stream, and then ultimately RHEL as a product.
That's where we're at now. It was just a really messy transition. Part of that was like rush timelines. That's a compression of a lot of time. Yeah, definitely.
I'm not trying to like not go into the details.
For sure. We don't have a lot of time. And that was the dream originally of it, right? We had CentOS lagging behind RHEL. It was painful for developers. It needed to exist, but we had developers frustrated that, okay, well, I'm making this change, but then it changed in the next minor version, and I didn't find out about it until a month later.
So they wanted to get ahead of those things, and they basically wanted RHEL a little bit earlier than they were getting RHEL-like things in CentOS, in what I call classic or legacy CentOS. The official distro name is CentOS Linux. The way it should have gone down was we just did a clean break at a new major version and said, for example, CentOS 9 is here early and it's different now.
But because of some compressed timelines and people were excited to get it out there, we ended up doing two variants in version 8. We had the classic variant, which was a rebuild following RHEL, CentOS Linux 8, and then we had to make a new name to distinguish the variant, which became CentOS Stream 8. It's still the same basic operating system, just released on a different cadence.
And I can say that because at the time, that was my full-time job. I'm working on Apple now, but that was what I got hired by Red Hat to work on. I was doing those builds. It was still, and I mentioned earlier that the RHEL maintainers are taking over control and doing all that work in CentOS now. The early transition wasn't that way.
The small group of people, like three or four of us that were building classic CentOS, started having to do two rebuilds. The rebuild of CentOS Linux following RHEL, and then the rebuild of CentOS Stream that was ahead of RHEL. and it was really messy for a while until we could get it actually properly onboarded in version nine.
We ended up putting it on GitLab, and so all the rail maintainers would do their packages there, create them, and do all their development, and then there wouldn't be a rebuild process. They would just build it, and it would become CentOS Stream. But in the early days, we'd have builds, They were all rebuilds, we tagged them at different times, basically just released them at different times.
And some of them would be classic CentOS Linux, and some of them would be CentOS Stream 8. But it was all from the same build system, all from the same people, all from the CentOS project. So that's one of the things that irks me when people say, this isn't the same CentOS. I'm like... No, but yes, it is. Like, it's the same people. It's the same project. CentOS isn't dead.
Technically, CentOS is the project. CentOS Linux and CentOS Stream were the distributions. But thankfully, we don't have that double thing anymore. We onboarded all the RHEL people, and it's just CentOS Stream. And I think my personal opinion is that we should one day just drop the stream and just say, yeah, this is just CentOS. Most people just call it CentOS. And let's avoid the confusion.
We should have never had the overlap. It should have just been a clean break in a new major version and leave all the old major versions on the old model. That's not the way the transition happened. Clean breaks are good. Poorly executed transition, in my opinion. Some of it predated me. Some of it I was front row and center and doing what I could.
Yes. Where are the open source lines drawn across these distributions, like Fedora, CentOS Stream?
So it's all open source. And everything in Fedora is just out there in the open, built in the open. There's nothing private. Everything in CentOS Stream is the same way. It's built in the public. It's all public. And you can contribute to it. RHEL, the contribution path into RHEL is through CentOS because functionally the way it works is it's the major version of RHEL.
You've got like CentOS Stream 9 now is where all the RHEL 9 development happens and then periodically they branch that into 9.4, 9.5, 9.6. So you can't actually contribute directly into a RHEL minor version because those are built inside Red Hat. But then the major version, you can get it on there.
So from the developer angle, like you can do pull request to master, but you can't do pull request to the 9.4 branch. Okay. Sometimes the RHEL maintainers will say, yeah, we also have customer pressure to get it in these older, minor versions, and then they can do that part internally. But then the After Effects, it's still all open source.
It's still all published, all compliance with all the licenses. Once you have RHEL, you have access to the source for every package, even the ones with licenses that don't require it, like MIT or BSD license. So it's fully open source, top to bottom.
So it sounds like we're in this... rebuilder world where you have the Rockies and the Almas and the many others, I don't fully understand it.
It seems like from an outside point of view or from a purview sort of point of view that it is more about trying to get what is literally the RHEL product, which is a product, and you can say it's open source and you can get access to packages and RPMs, etc., I tried last night with your help to find a way to download today, in a moment, RHEL. You said it's open source.
I had to sign up for an account with Red Hat. I had to go through hoops essentially to get it. And it may be literally open source, but it's very challenging to play with what is the RHEL product. And what I mean by product, it is open source derived as a trademark product given to customers who pay for it with a license more so for support and assurances and security.
Totally cool, right? I'll push back on you a little bit. Okay. You tried real quick on your phone while we were drinking at the bar. I wasn't drinking. You were drinking. I wasn't drinking. I was drinking water. Well, very quick attempt on your phone. It's not the same as sitting down like, yeah, let me create this account. I won't create accounts on my phone.
I'm going to wait until I get on my laptop again, right? Okay, let me push back to you then. There's a little bit of a barrier, yes. You have to sign up. Let me push back to you then.
If I want to go play with the product called Ubuntu... What's the latest version, 24.04?
Yes.
I can go and tap a download link.
24.10.
Well, LTS.
Download the ISO. LTS. Sure, your point.
I can click on it. No account required. Yeah, no account required. So there's no hoops to get to that product, but there is hoops to the rail product. So that's my point.
It's challenging. I'll give you a throwback to one of your older episodes when you interviewed Adam Jacob. Sure. Fantastic interview. And he brings up the point of, like, you make a product and you sell it. You don't give it away for free. I agree. Ubuntu's model is that they are giving their product away for free, which there are pros and cons to that.
And I'm not going to... I don't want to criticize another company's business model. You know, I wish them all luck. I've got friends that work in Ubuntu and work for Canonical or ex-Canonical. But the... You know, it gets back to that problem. You can have all of the market share you want by giving away your product for free. And it's hugely successful and popular.
But then I know that my canonical friends have told me before that Ubuntu's biggest challenger was always free Ubuntu. Like everyone that's getting it for free because they can and the conversion rate of people that are like should be paying for it to help sustain the engineering of that product is a vanishingly small number.
And it's extremely hard sell to say, here's why you should pay us when you can just get the product for free. Right. So Red Hat tries to take a different stance.
I'm talking about access, not selling a product in this case.
Well, the access is the same thing, right? Because access is part of that subscription, part of that product.
What I'm trying to say is the angst. The angst is there was CentOS prior to Red Hat's acquisition of the open source project.
And a lot of that is confusion, right? People looked at it as, this is the free access version.
Right, this is the RHEL, alternative to RHEL, that's open source, that I can use in production. It is blessed for production.
What would I tell you if, what would you say if I told you that, one, it was never blessed for production, and two, that there's even a website... It was marketed as that. No, it definitely wasn't. Show me a page that says it was blessed for production. But anyways, that's a tangent.
Wasn't that the case, though? I mean, that's the major issues that people are using in production.
That's what people said. There was no blessing, right? But that's a minor point. Yeah. There's some nuance to it. There is nuance there. That's not the point I'm trying to get to, though. What would you say if I told you that I can show you a page right now on the Red Hat website that says RHEL is not intended for production? We had this conversation last night. I'm down for it. Yeah.
It's because on the page I'm talking about, it's in the product store where they say it's a self-support rail where you can buy just access to rail and can't file support cases. And it says this is not intended for production. Because... Red Hat thinks that you should have production or support for your production instances. It's that simple.
So when they say that, you know, there's also a blog post that says CentOS Stream is not designed for production or intended for production because it doesn't have support. It's around that part, but it's been misinterpreted to say even Red Hat says this isn't good enough for production. Right.
And there's other interviews with other Red Hatters, like from the Fedora Flock Conference, Brian Axelbeard, he said that just because we don't say you should use it for production or we don't intend it for production, doesn't mean you can't, and there's lots of companies that do. I've got some friends over at Meta, Facebook, their fleet is probably the largest fleet of servers in the world.
I think the last PR approved term they got to use was millions, plural, of instances. And they're running CentOS Stream everywhere. and they get on the new versions as soon as they can. They're active contributors, and they're deploying this stuff regularly. They use it at massive scale in production. So it certainly can be, it's still rail-like, and it can be used in production.
100%.
Right? And there's even more detail to that. We talked about that partner ecosystem stuff. The whole idea of being real compatible is because they want access to that ecosystem. The real brand name.
Even the brand name.
Yeah, a little bit of that. There's some of the confusion, and that's going on now with the whole automatic and WP Engine stuff around brand name and how you identify that. But the bigger thing is... They're like, oh, I don't care about having RHEL. I care about this app I can install, and it works on this hardware, that whole ecosystem.
That is what they're buying into, and that is what Red Hat sells. As a product. Yeah. Which I'm cool with. I get that. The whole idea of being exactly RHEL compatible is the idea of getting a foot into that ecosystem and taking advantage of that ecosystem from people that did not spend decades building it and countless dollars building it. Right.
And it's just weird that there's this angst out there because they essentially want... If there were other people here who could argue against it, they would probably argue against it, but my opinion, my summarization of what I understand about it is they essentially want what REL gives as a product for free, as in freedom of open source, and free as in cost.
Yeah. And that conflation is a sticking point for a lot of people.
And CentOS used to give it, I'm quoting, used to give it prior to being acquired by Red Hat. Now it's upstream from RHEL in terms of a visual diagram. It was acquired by, as an open source product, acquired by. Now it is where the active development happens, which ultimately lands in RHEL the product. Mm-hmm. And so the angst there is the folks want what is enterprise grade Linux.
Well, you're considered the gold standard of enterprise grade Linux. They want it for free. That's the angst.
What I realized around that angst is that We made all those changes, and some of it predates me, some of it was right around when I was getting hired. But what I learned about the CentOS community was they're basically two different personas. And it kind of splits evenly in the lifecycle. They were the people using CentOS in the first five years of the lifecycle.
New version would come out, they would say, yes, I want these new features, I want these new capabilities, and I'm also frustrated. Those happened to be the same people that were frustrated that they couldn't contribute to it and make changes to it. Then there were people kind of using it in the last five years instead of using RHEL. For them, it was just the free, unbranded RHEL.
They were never going to contribute. They don't care about being able to contribute. They just want to get the product for free, and they want it to be maintained for as long as possible. So those two personas were kind of where we unintentionally divided the community.
People that liked what we were doing with CentOS Stream, being able to contribute, and it still has a five and a half year lifecycle, which, I mean, that's the same thing Ubuntu LTS gives you without the pro subscription, five years. So it's still a pretty long time. It's still an LTS. Those people, they're like, yeah, I like these changes. This makes a lot of sense to me. And the people that...
do not care about contributing, do not care about getting their bugs answered. They just want to get the product for free. They're like, oh, no, I'm going to go to these other guys that give me the same thing.
The big change is that because it got actually harder on CentOS and Red Hat once the AquaHire thing happened and they were paying the CentOS maintainers because customers would come in and say, well, you're making both of these things, so why should I pay you for one and not the other? Or why should I pay you for the one when this other one's free?
And that conflation of having Red Hat sponsorship, it helped the project not fail and collapse, but it also made it harder to have those conversations, to draw that line between the product and the project. And so now the new rebuilds, like I heard one guy inside Red Hat described it as these changes are Red Hat getting out of the rebuild business.
Like we decided that's not where we want to spend our time. Here's the way that building an operating system works in our pipeline holistically to make a better product. And it's still really close to RHEL and you can still use it for whatever you want to, but it's not going to be trying to match RHEL identically anymore. It's getting six months ahead of RHEL on features and fixes.
But like you said, a lot of those people that are going to different alternatives now, they're in that latter group, the five plus year usage where they just want the same thing. They don't want anything to change ever. And they don't want to think about being able to contribute being a benefit.
It's mostly what I wanted to cover. I know we can probably go deeper. Wherever you want. And I got more I can say, but I don't know how much more we want to go. How much more do you want to spend on this, Jared? Five minutes? Five minutes.
I want to hear about the future, man. Yeah. Juicy. Juicy future stuff. Well, real quick before that, how does Meta get their support when their CentOS stream doesn't do what it needs to do? Like, what do they do?
They're self-supporting. They're active in the projects. They're contributing. They identify a feature that they want or something that's broken that they want to fix, a bug. and they're contributing that into CentOS Stream. They're active contributors there. They're contributing to upstream projects. I know they're heavily involved in SystemD. They participate there.
A lot of times you'll find talks from them at conferences like Scale where they're talking about the internals of SystemD because they employ a lot of SystemD developers. They have kernel developers, ButterFS developers, all kinds of stuff. So they have a lot of that expertise in-house. Gotcha.
So they're not really, they don't really need to leverage that support any more than just interacting with those communities already. All right. So the future stuff. Juicy future. Juicy. So the major version right now of RHEL is 9. Everyone knows that. Same for all these RHEL-likes and CentOS Stream, which is still RHEL-like. It's all major version 9.
Everyone can count and knows that the next number after that is 10. Is it 10? Yes. Was it eight, nine? I'm making this joke. Go ahead. It's a little silly because there was actually a time before I got hired where there's some weird marketing thing around it where they were telling engineers that they couldn't say that the next version was eight. And I don't know where it originated or why.
Oh, wow. But then, like, some real marketing folks showed up at the, I think it was the Fedora Flock Conference, with stickers with the rocket ship and the number 8 on it. And after, you know, all the messaging to the engineers was like, don't say the number 8. Just say, oh, whatever, you know, whatever the next version is. And so the engineers were all mad.
They're like, oh, these guys showed up with the number 8 on a sticker, and they told us we can't say it? That's so stupid. Like, why do we even have this problem?
Okay.
I missed that joke. Big company, inner things, whatever. Weird things. The next version's 10. Juicy stuff. Go. So RHEL's on a three-year major version cycle now, six-month minor version cycle. It'll be a little more reliable. It used to be kind of hit or miss, and one of the feedback we got from customers was bringing it back to Ubuntu.
They have their schedule where they're like, yeah, we're publishing this month. You can count on it. And a lot of customers really value that. So eventually, version 8 was when they adopted that in 2019. So three-year cycles, you can see that RHEL 9 came out in 2021. Sorry, 2022. So 2025 is when RHEL 10 is going to come out.
We can't officially say dates, but there's an event in 2025 in the spring that Red Hat puts on that might make sense for there to be product announcements at. Anyone can figure that out just by looking at public websites. It's not that hard. Not that that would be the exact day, but probably pretty close. It's a good time frame to expect it. CentOS Stream 10 has already branched off from Fedora.
It's getting that initial productization to become, to stabilization, to become RHEL eventually. It's in a state now where you can get it and install it today, but we haven't announced it as, you know, ready's a weird word,
I think we usually use launched or released, but there's going to be a launch announcement or release announcement for CentOS Stream 10 pretty soon because it's getting to the point now, it's not that high pace of stabilization. It is, okay, well, we basically have all the features we want.
We might make a few more changes before it gets released as RHEL 10, but it's basically stabilized, and this is what you can expect RHEL 10.0 to be whenever it comes out next year. So we're going to have that announcement pretty soon, probably next month or the month after, where we announce CentOS Stream 10 is here. You can use it now. It's pretty good. We like it.
Also, Eppleton, the thing that I work on directly, we're going to announce that about the same time. Usually when we've announced them separately, we usually have the feedback that, well, why would you announce, you know, If we announce one, immediately the question is, well, I want the other one to use them together. I want those extra packages, and I want the base operating system.
They're useless without each other and a lot of people's opinions. So we're going to do kind of a joint announcement probably the same day or the same week where we say, yep, Apple 10 is here. We've got all these extra things you can add. The community has been building them for the last few months, and we've had the infrastructure online. But we're doing like a flag day, like here it is.
It's as ready as it will be, you know. It's the thing, do we say it's ready at 2,000 packages? Do we say it's ready at 3,000? We're going to keep adding stuff, and even after we announce it, it doesn't stop growing. So we've got those things coming up. And timeline-wise, you can look at it as that's about six months before the RHEL 10 launch.
Yeah, so spring of 2025 is when RHEL 10 is going to be coming out. And then we're about a little bit more than six months before that right now. We're getting all this stuff buttoned up to say, yeah, CentOS Stream 10 is here. You can use it. It's a major version, stable operating system. It doesn't have minor versions, but it's going to be maintained for five and a half years. It's very RHEL-like.
You can add all of these Apple packages we've been working on and use it right now, and it'll be good to go. I love it. That's the good stuff coming up.
What exactly is extra in the extra?
Okay. That is just the mentality of it. It's only packages that you can't get in the base operating system. So I kind of mentioned that there's like 60-something thousand packages in Fedora, and only about 10% of those go into CentOS and then eventually go into RHEL. Everything else in Fedora that isn't that 10% is eligible to go into Apple. So, like, say I maintain, like, the Caddy web server.
I maintain that package in Fedora, and I also maintain it in Apple branches. Up to date, I haven't seen anyone say, like, we need to put Caddy into RHEL. We have customers asking for Caddy. Maybe that changes in the future. But for now, I maintain it in Fedora, and I put it in the Apple branches for each release, Apple 7, Apple 8, Apple 9, and Apple 10 now.
Put it in there so people can use it on that RHEL release or that CentOS release or any of the other RHEL-like things that are out there. They use it there, but it's not a RHEL package. It's not maintained by Red Hat. You can't file a support case for it. So that's what the extra in the name is for. It's only additional things.
If, for example, Caddy, if Red Hat decided to add that into RHEL, into the product, it would then become ineligible for Apple, and we'd retire it from there, and instead of getting it from the community repo, you'd get it from the main repos. Gotcha. Does that help clear that up?
That was a good summary, I think. I think that's what I wanted to cover for a while. I think it's been challenging to, from the outside, as a non-Red Hat Enterprise Linux user, I'm not that person. But I care about Enterprise Linux because I have friends who care about Enterprise Linux. Using it at work or at home? All over the place. Friends at Facebook even that rely upon CentOS, of course.
And it's just kind of crazy that how the world is fractured And then the parts we can't, that I won't really go into, but that other side, on the rebuild side, is also offering support and financially backed services. So why not just buy Red Hat Enterprise Linux in the first place? We've talked about that in the side conversations, Jared.
I'm not going to argue with that point.
I know you won't, but what do you think about that, Jared? We've talked about that. It seems strange... to go through all this and have these rebuilds that is either bug-for-bug compatible or there's words that leverage the RHEL brand to be RHEL-like that says it's free and open source.
They're trading on the RHEL brand.
But then they're offering support or other financially backed services. That's basically what Red Hat's doing. to rail it in the first place. The rabbit hole goes deep. It is. Carl, thank you for sharing that story. Yeah, I'm always happy to talk about it. Going deep with us. We appreciate it. Thanks, Carl. Appreciate it.
Thanks, Carl.
Thanks for having me on. What's up, friends? I'm here in the breaks with Kyle Carberry, co-founder and CTO over at Coder.com. Coder is an open source cloud development environment, a CDE. You can host this in your cloud or on premise. So, Kyle, walk me through the process. A CDE lets developers put their development environment in the cloud. Walk me through the process.
They get an invite from their platform team to join their Coder instance. They got to sign in, set up their keys, set up their code editor.
Step one for them, we try to make it remarkably easy for the dev. We never gate any features ever for the developer. They'll click that link that their platform team sends out. They'll sign in with OIDC or Google, and they'll really just press one button to create a development environment. Now that might provision like a Kubernetes pod or an AWS VM.
You know, we'll show the user what's provisioned, but they don't really have to care. From that point, you'll see a couple of buttons appear to open the editors that you're used to, like VS Code Desktop or, you know, VS Code through the web. Or you can install our CLI. Through our CLI, you really just log into Coder and we take care of everything for you.
When you SSH into a workspace, you don't have to worry about keys. It really just kind of like beautifully, magically works in the background for you and connects you to your workspace. We actually connect peer to peer as well. You know, if the coder server goes down for a second because of an upgrade, you don't have to worry about disconnects. And we always get you the lowest latency possible.
One of our core values is we'll never be slower than SSH, period, full stop. And so we connect you peer to peer directly to the workspace. So it feels just as native as it possibly could.
Very cool. Thank you, Kyle. Well, friends, it might be time to consider a cloud development environment, a CDE. And open source is awesome. And Coder is fully open source. You can go to Coder.com right now, install Coder open source, start a premium trial, or get a demo. For me, my first step, I installed it on my Proxmox box and played with it. It was so cool. I loved it. Again, Coder.com.
That's C-O-D-E-R.com. And also by our friends over at 8sleep. Check them out, 8sleep.com. I love my 8sleep. I've never slept better. And you know I love biohacking. I love sleep science. And this is all about sleep science mixed with AI to keep you at your best while you sleep. This technology is pushing the boundaries of what's possible in our bedrooms.
Let me tell you about Eight Sleep and their cutting-edge Pod 4 Ultra. So what exactly is the Pod? Imagine a high-tech mattress cover that you can easily add to any bed. But this isn't just any cover. It's packed with sensors, heating and cooling elements, And it's all controlled by sophisticated AI algorithms.
It's like having a sleep lab, a smart thermostat, and a personal sleep coach all rolled into one single device. And the pod uses a network of sensors to track a wide array of biometrics while you sleep. It tracks sleep stages, heart rate variability, respiratory rate, temperature, and more. And the really cool part is this. It does all this automatically. without you having to wear any devices.
62%.
That means that it updated and changed my temperature to cool to warm and helped me fine tune exactly where I wanted to be with precision temperature control to get to that maximum REM sleep.
and sleep is the most important function we do every single day as you can probably tell i'm a massive fan of my eight sleep and i think you should get one so go to eightsleep.com changelog and use our code changelog and you'll get 350 off your very own pod for ultra you can try it free for 30 days but i am confident i sleep on this thing every night i'm confident You will not want to return it.
Trust me, once you experience this AI-optimized sleep, you'll wonder how you ever slept without it. How do I know? Because that's exactly how I feel. They're currently shipping to the U.S., Canada, United Kingdom, Europe, and Australia. Once again, 8sleep.com slash changelog and use our code changelog and get $350 off your very own Pod 4 Ultra.
Max Howell, creator of Homebrew, creator of Tea Protocol. Did I cover all the gamut, or is there more?
Oh, there's more, but those are the things that people care about.
There you go. I do like to hit on what people care about. Now, I think... The last time you and I crossed paths was some sort of announcement around T, I think. And maybe that was TXCL or something. There's more to it. It's been a while. But I remember you put something out. I covered it on Change Dog News. And I wrote something about it, like, I feel like they're trying to boil the ocean.
I don't know what I said. Oh, yeah, yeah. And that affected your game plans by some way, right?
Yeah, yeah. It was an important little pointer for me. I appreciate that. Okay. That's all I remember. Yeah, I was trying to do too much. That was what was T-Klee, which we now call Package X. Okay. And... Well, I was very much aware of the fact that homebrew is enormous. And here I was trying to do homebrew 2.0, something I said I'd never do.
And I think Ryan Dahl with Dino is seeing the same kind of problems, right? Once you've had something that's a huge success, how do you make something that is... as big even as that. So you've got this enormous momentum behind the previous thing. So I was very much aware of that when I was building out Teakley.
And so I put too much into it thinking, well, that's the only way I'm going to get people to come on board with it. Right. Right. And you point out quite sagely, I think it made me realize that, yeah, it was doing too many things and that was just confusing. So we whittled it down to just what it is now, which is like an executor for packages.
So you don't think about installing them, you just run them. And that's enormously powerful, actually. I think over the next few years, people are going to start seeing that. Because it's so good for scripting, for example. You can write a package X shebang in your script and then add all the packages you want.
And then you've got a portable script you can just pass around that you don't have to worry about if people have things installed or not. It opens up the entire open source ecosystem to it. So I've got a few things planned to use that. But we realized along the way, this is all part of T protocol, right?
That even though we thought initially we would be putting functionality for the protocol into TKli, actually no that doesn't make sense it's diffusing the messaging once again i think i was a little too influenced by our investors and that's why we went down that path but we course corrected so now we're completely focused on just the protocol which
You know, that was the original vision that I had to build something that could help people who create open source to actually, you know, get some of that value that they create back to themselves rather than just creating value for people who build on top of it.
Right. The people beneath the people beneath the people, right? Like the dependency of the dependency and letting that value chain trickle down or trickle up, whatever direction you're looking at it from. So how does that work then?
Yeah, so we've built it. We've been running the testnet since February, and we got 1.7 million people who've signed up to use this testnet, which are pretty great numbers by any standards, but especially in the Web3 space, you don't get that kind of users.
I think it's a testament to people understanding that what we're doing is important, but also that we've cracked it, that we understand how to take the value of open source and actually expose it. So until now, we all understand the value of open source. Everyone builds everything on top of it. But very little of that value ends up going back to the people who maintain it. That's my story.
Homebrew was a passion project that became my full-time job for free. And I had to keep taking new jobs. quitting them after I'd saved up some money working on it. And that's why I founded T-Protocol. I was once again in that position, wanting to work on open source full time. So our system, it changes the economics of open source.
That was one of my conclusions before founding T-Protocol, is that the system of economics that we use in this world, it doesn't fit cleanly onto how open source works. Open source is really weird. There's no real thing that's like it elsewhere in the world. So it was necessary to build something new that used economics in a new fashion. So that's what we've built.
We have an on-chain Oracle called Chai that computes the impact of all the open source projects, all 10.5 million of them.
using package manager data and dependency data to calculate that the higher your impact the higher your rewards every 24 hours we just give you free t token and then we have uh like with the 1.7 million people who signed up only a third of them are developers two-thirds of them are people that maybe didn't even know about open source before once they heard the story
of how everything they've used on the internet for the last 30 years is built on top of this open source. They understood that there's a huge amount of untapped value there that they want to participate in. So they're the input for the monetary parts that allow the open source to be remunerated. And I've had loads of tokenomics experts looking at it over the last three years.
You know, you have to calculate the sell and the buy pressure correctly in order to make it so the token price stabilizes at something, which then makes it so the open source maintainers can sell their token and use it to fund the developers.
Right. Because if they received a bunch of token for their package getting popular and they went to go sell it and they were just dumping on the market and the demand wasn't there, then the price would crash and you'd have your typical peaks and valleys of the crypto sphere. So you're trying to stabilize the coin, basically? Or what's the tokenomics?
You're trying to stabilize the value of the token?
Yeah, exactly. It's very important that we do that. Otherwise, it will be a project that just goes whoop and down, as you were saying. Right. And then it hasn't succeeded at all. And that was a difficult problem to solve. We have lots of mechanisms in there that will be there for the launch. We're hoping to launch later this year or early next year.
Gotcha.
So it's not live yet. No, but the testnet is, so people can sign up. We have 17,000 open source projects that have onboarded 2T protocol during the testnet. So, you know, we've got good traction. I'm hoping when mainnet goes live, the proof will be in the pudding, you know. People will see that this is something that actually could fix these fundamental issues with how open source is funded.
And it's really a no-brainer if you're an open source project with any clout. Onboarding is free. It's very low effort to do so. Too low effort, as you probably saw some of the negative press we had over the last year or so.
Yeah, there's been some spammers spamming.
Yeah. We incentivize people to try and break T-Rank or Chai. And they found a way to do it by creating more than 200,000 packages on NPM. We're glad they found a way to break it because that meant we could fix it. And that's what the test set is for. But yeah, don't feel good about it. But when you're building new things, there's always unanticipated consequences to that.
A lot of people think I should have seen this coming. I kind of agree with them. I should have seen it coming, but when you're building stuff, you only have so much time.
Yeah, yeah, yeah. I mean, sometimes you learn as you go. I remember that happening. I don't remember what my comment was at the time, but once I saw it, I was like, yeah, this seems like a natural progression. So you live and learn, right? Live and learn. And it was still early, so that's good.
Yeah, and it won't happen again. We've closed the gap.
Cool.
What exactly is T? Well, the main purpose of T, at least, you know, what I wanted to accomplish when I came up with the idea, was to use cryptocurrency to fix what we call the Nebraska problem after that famous XKCD comic. You know, the tower blocks representing all of... open source as they get stacked on top of each other.
And those little projects near the bottom that are fragile because the people who maintain them don't have the time or the incentive to do so. And yet it's holding up so much critical infrastructure. So, yeah, it's a cryptocurrency project that uses a unique tokenomics model in order to give open source developers token rewards on a 24 hour basis.
And a lot of the other pieces of it are designed to attract the interests of typical crypto investors or just like normal developers who want to show real support for their open source projects. A key differentiator between us and most ways of supporting open source is that there is no donations in our system. You can buy a token and then stake it against projects.
So both you and the project is gaining from this. There's no gift. It's more like an investment.
So what would, so say there's a piece of software that's signed up for the T protocol, and so I can use T to execute it, right? Am I then required to also buy into the, like to give back value, or is it still I can just use that without doing it if I want to? Like it'll lock you in?
So nothing's different. Going into it, I knew that this wouldn't work if we changed anything about how open source already works. Right. You know, you can't charge for open source. You can't make it so you have to, you know, buy token and stake it, even if you can get that token back before you can use things. So it works based on calculating the impact of open source projects.
And then you are creating a yield on top of those projects that then goes to the project maintainers. They then distribute the token however they see fit. But yeah, as a user, nothing's different. And as a maintainer, Nothing's different. I didn't want to change the incentives in open source either. It's still incentivized in exactly the same way.
It's just now you're getting token for doing that rather than before where all you get is reputation or kudos, satisfaction perhaps.
Now, inside of the T protocol, can I place specific bets or buy into specific packages?
You can stake against specific packages.
So let's say I know my buddy Adam is about to release a new NPM package, a JavaScript thing. It's going to take the world by storm. I could stake his package when it first comes out, and as that package gains in usage, I would benefit from that? Is that how it works?
Not exactly currently. This is an idea we're playing with. You should be rewarded for seeing up and coming open source, right? That's fun. Right.
Plus I can do it on my own packages, right?
It's good for the package because they get more stake yields initially that way. But currently, if something isn't very staked by many people, the yield you get is higher. So there is an incentive to go and find open source that isn't yet popular, but you think will become popular getting there early. Because your yield is also dependent on the impact of that project, the T-rank. of that project.
So initially, the T rank of any new project is going to be close to zero. You don't get any rewards for less than 25. It's necessary to have a cut off, because otherwise people would just create fake open source packages, stick them in the system, and try to gain rewards that way. The T-Rank only grows as you become something other projects use, the dependency tree.
So you do have to convince other projects you're worthy. And that's exactly how open source already works, right? You release something new, it takes time for the community to trust that your package is worthy and use it. So we don't fix the initial uptake problem, but that's the case as it is right now.
Gotcha.
What is the idea of staking? I don't understand it in crypto as normal, but if I bought in and I staked against a project, what does that do for it? You get a yield. Describe that to me. Like four, five percent.
Like a percentage back? Mm-hmm. Why would I do that? Because you want to have a yield of 4% or 5%. What does the project maintainer get? They also get a slightly increased yield because they're encouraging people to stake. Now, the T we gain from people staking because it locks the token up, prevents people from suddenly selling it. There's an unstake period.
This is common with crypto projects to prevent rapid fluctuations in token price. Yeah.
Interesting. When I buy in initially, who am I buying the token from?
So we're going to launch with several major exchanges, still haven't announced them. So most likely you will buy from them. But there will be other ways the token is distributed initially.
Gotcha. Do you all keep a large percentage of the token as creators of the token?
There is a distribution of some of the token to the investors of my company, the founders like myself. some advisors as well, but it's a small percentage. We're doing what was considered a fair launch where more than 50% of the token goes to the community.
Right. And it makes sense because you're investing in it, making it. There's obviously economic incentives involved.
across the board for it. If I knew then what I know now, I wouldn't have done it with VC. I would have just launched the token myself, taken none myself, and then made it so 100% just goes to open source. But, you know, too late. It's fine. Can't do it. Can't change. Not if I don't want to be sued personally. But it's a very small percentage relatively.
One of the things we're doing is we're launching the token from a completely separate company in Switzerland. It's a non-profit and the long-term goals for that company are to have it be governed and run by the open source community as well. But none of my investors or any of the other people that are related to the company they invested in have any say in how that company runs.
It's very important to me that this is an open source project for the open source community that's governed by the open source community in the long run.
17,000.
17,000. So that's a lot of... It's a decent amount of projects. What does it take to onboard? What's the incentive? Obviously the incentive is to be able to have, what is it called, T? Is it called T or Chai?
T token, yeah.
Okay, T token.
Chai is the technology, the oracle that runs the chain.
Sorry, I'm uninitiated here, so a lot of my questions are from the uninitiated standpoint here. Okay, so you have the T token, and me as an open source maintainer developer, I go and put my open source T-enabled, onboard, what is that like?
Yeah, so the way the system works is it's project-based. So we declare that a project will receive X amount of T-token rewards every 24 hours. In order to have that token go to that project's wallet, it's a project wallet, one of the maintainers of the project needs to commit a file, the T-constitution, as we call it, to the GitHub repo or any Git repo. We're not GitHub-specific.
Once our system sees that file, then the rewards start coming in.
Is it challenging to determine ownership at that standpoint? Because you've got multiple maintainers, core maintainers, trademark holders, especially with the WordPress world, you've got a lot of things happening in this ownership state of open source. There's a lot that can happen.
How do you determine who is the true owner, I guess, of the token when it comes in, if it does become valuable enough to... Cash in, so to speak.
The token goes to the project wallet, and then whoever commits that T-constitution can declare any number of people that are considered core contributors to the project. They all have control over that wallet. Now, we haven't made any deliberate decisions on what should happen next. Every project's different, right? Most projects really are just one person, so it's very simple for them.
It gets a lot more complicated when you have large projects like Python or Node or whatever with loads of people. WordPress. And WordPress, exactly. So we're waiting to see what they're going to do about it. But it's on the blockchain. It's an EVM-compatible blockchain. We're using Coinbase's base, which is just Layer 2 on top of Ethereum. And you can write smart contracts to distribute the token.
So that's what I'm hoping I'll see, is the open source community stepping up, writing smart contracts to fairly distribute the token. One easy way to do it is like, here's a list of people, split it equally. A much harder way to do it would be based on pull requests or code contribution. Lines of code. Just kidding, just kidding, just kidding. I've already thought this through.
Lines of code is not going to be a great metric for sure. Just incentivize people to make PRs that are longer and longer for no reason.
Do you anticipate challenges there that you will get mud on your face from, regardless if, I guess, maybe egg in your face is probably the better term? Because you're kind of leaving it to them to decide, and it might cause drama?
On that front, I don't think we'll get egg on our face. But who knows? Mud in your eye, egg in your face, yeah. One thing I've certainly learned during this project is there's going to be people that really just don't like it. don't like what you're doing and they're going to be angry no matter what you do. When you're doing things that are genuinely new,
You've got to cross your fingers that you're doing it right and see what the community thinks in the end.
Sometimes it's easy to squash that to some degree with the why. Like, why did you do this? It's one thing to have a capitalistic intent, either personally because you're creating a company around this with venture capital and incentives, and then to enable open source developers to get paid. So there's lots of reasons why, I'm sure. But what is your personal reason why?
Like, why did you do this? So, yeah, we're going to be quite transparent. As transparent as possible, we're going to be open sourcing most of the... Probably all of it by the end of the year, actually. Even the website, who cares?
But my personal reason for doing this is because three years ago, I was in between full-time work, trying to work on open source once again, and I looked to see if anyone had come up with something that could... pay me to work on it full time for, you know, this time. This time. I've tried things in the past, like Patreon.
Spent half my time marketing myself rather than writing code when I was trying to get that Patreon working. And there wasn't anything new. Everything treats open source like all it is is charity. All you can expect is a cup of coffee and five bucks. So I decided that maybe it had to be me who fixed this problem. And I went down the rabbit hole finding new ideas, trying to find new ideas about it.
And it was a moment of inspiration one evening. I've had some weed. And I realized that crypto smart contracts and that package manager data, that dependency information, I could use that. I could do something with that. Maybe that would be the solution. So we're going to see. MARK MANDELMANN, We're going to see.
When are we going to see?
When? When? Yeah, so hopefully by the end of the year, maybe early next year. And how long will it take? Everything's built. Everything's ready. Well, why aren't we hitting go? It turns out crypto's got a lot of legal red tape. Yeah. As you might expect. Yeah. So, yeah.
I think I appreciate people trying new stuff. I think there's a large number of developers who are just so anti-crypto that it's going to be a stumbling block or something you'll have to overcome. Now, if it starts to work and work well and it's on Ethereum, you said, so that's proof of stake, right?
So it's not just it's not the proof of work like Bitcoin, which a lot of people have problem with energy draw. So it doesn't have that particular problem. Maybe you can overcome some of the anti-crypto stance of the developer community at large. Is that fair to say? I think so.
I've been always more on the fence because I think there's potentially cool and interesting new things you can do that you couldn't do before. And I'm waiting to see them, kind of where I've been. And so maybe this is one where we say, here's a cool use of crypto that actually... does what it's supposed to do and brings value and all that. I hope it works out.
As he was describing the dependency graph, it reminded me of the way, I suppose, Google or a search engine attributes weight to or importance to a website, which is backlinks. It's the same kind of idea where you sort of define some sort of perceived value based on being in the dependency graph of a project. And I imagine that totally makes sense.
And it's not based on whether I think your thing is cool, whether I think your thing is worth funding. It's a matter of, yeah, it's like, is it literally being used? How deep is its importance? Then you can't scrutinize back to the Nebraska XKCD drawing and cartoon because... You can see the weight. You can see the graph there that says it truly is important.
And going back to what you said with Patreon or even GitHub sponsors, you spend most of your time marketing and promoting the fact that you could be paid, not doing the things that should get you paid, which provides the value. And so it seems like if you can get past this, I don't know how to describe it, I guess, the idea of crypto.
Anti-crypto sentiment.
Yeah, the anti-crypto sentiment. if it couldn't play out well, because it seems like it should. Because you can't argue with the graph. You can't argue with the importance that gets placed on it, or the weight, the perceived weight and value that comes from that as a result. And the developer can keep doing what they're doing. Not remapping around this new idea of how to get paid.
They can just keep doing what they're doing. The dependency graph predicts their future. He can stick against it if he wants to, which increases my yield, increases his yield. Seems like it has the right kind of ideas. What's the reception so far? Like, you're in the percolation stage. What's the sentiment?
Well, you're totally right that a lot of developers are very anti-crypto, and so that's been a battle from the start. Hacker News hate me even more than usual. But inside the crypto sphere, it's very popular. 1.7 million signups is pretty unheard of.
And what it turns out to be the case, to my surprise, I've spoken to over 300 open source devs over the last three years, just for market research reasons, a lot of them don't care if it's crypto or not. They like crypto in the respect that they like technology. Open source devs aren't as anti-crypto as the others, the rest of the devs.
And yeah, I think we have a reasonable chance of showing that crypto is just a technology. We're not a scam. There's nothing scammy about what's going on with us at all. They'll see that once we've gone live and no one's, you know, rugging the token or anything like that. Right. And, you know, it's all open. That's one of the beautiful things about Web3.
All those smart contracts are transparent and readable. You can see what's going on. Right. So I'm hoping a few success stories after the launch, people will start to reconsider. I have an idea for you.
Or at least, let me see if I understand this right. And this is where my idea comes from. What if, let's play out a scenario. What if the developer world rejects this because they're anti-crypto? What if T, because you can still determine the dependency graph with or without onboarding, right? You can still determine the graph because it's in Git.
So long as it's open source and available, you can determine that graph and its importance. What if it becomes a speculation engine so the people who do care about speculating can leverage it as crypto, whether developers or not, and now it's sort of like maybe this adjacent engine this adjacent proxy to value. And not me saying this, but I'm going to say it.
Who cares if the developers are anti or for crypto? And who cares if they truly adopt this or not? It can be a way to speculate the value of the lone developer in Nebraska's thing and create value whether they take it or not. Because you can now have a betting world basically against all of open source.
And there's a way to make money or make money slash create value or speculate value and take away that value if you want.
Seems like a pretty genius idea, to be honest. I might have to give you an advisory token allocation. But yeah, like... You got a wallet?
I can't tell if he's being serious or not.
There's certainly stuff we could do if the main idea doesn't work out. But my passion won't be in it.
Plan B. How about Plan B? Yeah. That's Plan B. Yeah. Because, I mean, it's possible you'll be rejected. That would suck. Right? Because you spent years... Three years? Yes. Doing this? That would suck, right?
It would suck, but not everything always works out. You know, you kind of accept that when you're building things. Yeah. I think it would be a real shame if the only reason it doesn't work out is crypto skepticism.
Yeah, I hope it's because it doesn't, I mean, I hope it works out, A. But B, if it fails, I hope it's because it just, the idea fails, not because it's haters.
I just, you know, did a bad job.
I don't know, though. I think with my idea, if it truly is a good idea, I think you could do both. It doesn't have to be just because you rejected plan B as X. I think it could be both based on what I hear. Now, this is 20 minutes of podcasting, which I haven't dug into the white paper or the details and stuff like that. But I can't see, based on what I've heard so far, why it couldn't be both.
Because it's already doing that. It already can be speculated against. If I have a project and Jared wants to stick against it, he can. So that's all you're doing. It's about perception and mechanics and marketing really is story than it is simply what it can or can't do.
Yeah. I'll certainly go away and think about it. I don't think it's likely we would launch with both. Partly because, you know, we're a small team at this point.
You could do both, though. It's still possible to do... Just because you don't market it that way doesn't mean I can't use it that way. That's my point.
Well, they would have to do a dependency graph against all projects everywhere, right? True. Versus the ones that are registered.
You're currently tracking... Well, we do do the dependency graph against all projects everywhere. Already? Yeah. Gotcha.
And then you give a pathway to this thing that's won... software's eating the world, open source is eating software, kind of thing. Now anybody who ever wants to speculate against open source can, not saying they would, I have no idea about that, but... It's an interesting... Something to chew on, at least. Something to chew on, for sure.
There's certainly lots of things we can do with the data, like the Chai database, on-chain, Oracle. It's got all the dependency data, and it's got the rankings. We're exploring the idea of building out S-bombs based on that, which give you actual impact for your stack, and threat identification, essentially. Allowing companies to donate or stake based on the S-bomb we're generating.
The idea of building out some sort of polymarket-esque thing as well. But as you say, other people can do that, right? The data is on the train, you can build against it. It's one of the things we're looking forward to, actually, is seeing what the Overtools community just do on top of these primitives that we've built for them.
Interesting. So is this limited to libraries then?
Almost, you know, because like I was saying... Because it wouldn't solve homebrew's problem. Not itself, no, interestingly. Homebrew isn't even actually in the system because it's not packaged by anything. Right. Pretty popular project, though. Kind of embarrassing for me. But it's a limitation of the current model. Yeah.
Like once Chai is open sourced, which, spoiler alert, I'm doing that during my keynote in an hour. Nice. We're hoping that people will come forward with suggestions for how to fill in these gaps and help us to build it out.
Yeah, that would be cool, because right now it would be limited by the dependency graph, so you need to have dependencies. Yeah. So you can't be a command line tool or an application or these other open source projects.
to use this particular... Well, sometimes you can be a command line tool, because some of the command line tools are dependencies of other command line tools. Sure.
But it wouldn't track your actual usage, right?
Well, we don't really track usage either, of course, but... But you would want to, right?
Like, if Homebrew gets more used, I know it's not in there, but if you imaginarily covered it, it would be based on usage, right?
Well, we have a new idea that we've been developing over the last few months that will fix this, that we'll be announcing next year. It's a different... You want to spoiler alert us? I... better not, better not. But it's rather lovely. I'm very excited about it, and it does solve some of these issues for a different use. It tries to tap into the fundamental utility of open source.
So phase one, we're releasing this essentially a remuneration platform for open source maintainers. Phase two is exposing the real value of what open source represents. And yeah, it should be pretty exciting.
And you said it's trackable on Coinbase, is that right? Because of the way it's protocoled? He didn't name a specific one.
No, I... You said something... We use Base, which is Coinbase's blockchain.
Okay. So certainly it's going to be on Coinbase, but he hasn't said where you can buy this token.
To be disclosed, where we will be selling.
Is there a way that you could... leverage this to secure the open source supply chain as it's said? I don't really like the term supply chain, but that's the accepted term of open source supply chain.
Is there a way to leverage what you're doing with T, not just to incentivize to maybe gain value, but maybe leverage that in a way that can ensure security for open source packages or reward those who are more secure or just anything that just bolsters the security of open source?
Yeah, so going into this, that was definitely one of the things I wanted to achieve. And we have ideas for how that could play out with what we've built already. We're kind of securing it to some extent because we're securing the maintainer's ability to actually work on these things. But we have plans later.
One of them is inside the thing I was just talking about that we're going to be announcing early next year, which do have tangible benefits. as extra security benefits to the open source ecosystem.
So, yeah. So it's in our best interest to find a way to make this play out. Me and yours? Like, generally. We as in the community. Because if they have these kind of plans and there's altruistic ways to get there, we just have to— Well, I certainly want to know what he's going to disclose in the early next year.
I'll tell you after the podcast. Well, Max, best of luck.
T.XYZ, is that right? Yeah, T.XYZ. T, the drink. T-E-A. T-E-A. Not T-E-E or just the letter T. T, yeah. With hindsight, the name wasn't great.
A lot of hindsight. Well, hopefully some foresight. I'm excited to see what happens when you launch. So, launch.
Yeah, well, thank you. Get to it. I'm looking forward to it. End of year? It's very soon.
Hopefully. Very soon. All right. Famous S-words. Good luck with your keynote as well. Yeah. All right, Max. All right. Thanks. What's up, friends? I'm here with a new friend of ours over at Assembly AI, founder and CEO Dylan Fox. Assembly AI is where you can turn voice data into insights, chapters, transcripts, summaries, and so much more with their leading speech AI models.
So Dylan, give me a glimpse into what you're doing with speech AI models at Assembly AI.
So at Assembly, we're building industry-leading speech AI models for various tasks like speech-to-text, streaming speech-to-text, speech understanding, to help developers easily convert voice data, whether it's live or pre-recorded, into super accurate text. And then to help developers extract a ton of information and metadata around voice data or even around the text that they just recorded.
We're able to convert from that audio data. So these are things like picking out entities or PII that was spoken in voice files or summarizing voice and audio data down into custom summaries. It's things like being able to detect how many speakers spoke and who said what and what the names of different speakers were.
So we bundle all those things into a super simple API with really great docs that developers can just sign up to for free to start, use the API, build into their apps, and then build these really cool AI apps and products and workflows and automations on top of voice data with.
i dig it okay can you take me a little deeper into the opportunity for developers because it seems like there's a lot of voice data out there and there's a lot of trapped value in that voice data there's so much voice data being created on the internet now podcasts videos phone calls voice messages audio books virtual meetings it's crazy and you can now transform and understand all this voice and audio data in ways that were not even possible a year 18 months ago
So what we're seeing with the help of these new AI models that we're creating at Assembly, developers and organizations are just racing to build all these new applications, workflows, automations that leverage the voice data they have either within their organization or within their product to build really cool new products, services, workflows that are just like taking off in the market.
So at Assembly, we're building the industry leading models for all those different apps and workflows, whether it's speech to text or speaker diarization or speech understanding capabilities to summarize voice data or extract entities voice data or mask PII from phone calls for various types of automations that might be built.
And we're exposing that through a super simple, super scalable API that's just constantly being updated and constantly getting better. And so we're seeing a crazy amount of developers and companies just build really cool apps and services on top of our API every day.
It's really only just getting started, especially with the model updates that we have planned over the second half of the year that are coming out. They're really excited to launch to the developers on our API.
Okay, constantly updated speech AI models at your fingertips. Well, at your API fingertips, that is. A good next step is to go to their playground. You can test out their models for free right there in the browser. Or you can get started with a $50 credit at assemblyai.com slash practical AI. Again, that's assemblyai.com slash practical AI. Tell us about this. What do you guys want to hear about?
The state of open source funding, sustainability, pledging. OSSpledge.com. This is your new thing. OSS funds, open source funds. What's the state?
So we got a couple things. So the state of funding. There's a couple ways we could take this, and since we're going to cap this to 20 minutes, I'm going to say the words fair source. Okay. And I'm just going to put that there, and maybe we'll come back to that later. Okay, so don't bite on that. I know that's maybe something we could have a little more vigorous conversation about. Let's do it.
But yeah, man, no, the past... Past year, launched two initiatives, Fair Source and Open Source Pledge, both kind of coming out of this place of trying to balance the user freedom that we enjoy in open source with the pragmatic, practical realities.
So you're not idealist either?
Correct. We're not idealists either. Correct. Correct. Okay. Yeah, balancing freedom and sustainability is how we think about it. Developer sustainability. So Pledge in particular is really exciting. We launched this on October 8th. What day is it today? It's like the 28th or something, right? So... Not quite three weeks.
About three weeks ago, three weeks tomorrow, we put up three billboards in San Francisco. We rented three of the most expensive billboards in the world to tell a story about the change that we need in the industry to pay the maintainers. And this is The Pledge. The Pledge is a group of companies that are working together to change the status quo in open source sustainability. Companies that join...
make a commitment. So there's two parts to joining. Number one is you go pay maintainers. Number two is you blog about it, okay? So the pay maintainers, we have a barrier to entry. We have an entrance fee, if you will. So we use this dollars per developer number so that companies of very different sizes can kind of, you know, we can compare across.
$2,000 per developer on staff to open source maintainers, meaning no strings attached payments to your dependencies, essentially, okay? Could be foundations, could be GitHub sponsors, Open Collective, whatever. So Pledge itself is not actually touching any money.
What we're doing is bringing kind of the social validation layer to it and saying, we've already got GitHub sponsors, we already got Open Collective, thanks, Dev, platforms that'll help you do this. We already got all the foundations. So number one, go pay maintainers. So a company has 100 developers, they would pay $200,000 per year to maintainers, and then number two is blog about it.
Blog about it means you tell us who you paid and how much. That's your annual report. And that does two things. Number one, it drives awareness because now we've got blogs on everybody's blog out in the world talking about the open source pledge. So building kind of that social validation piece.
But then it's also the accountability so that people in the community can, you know, we're looking for receipts. Who did you actually pay what, right? So it gives the community a way to go and look and say, you know, All right, Sentry says they're paying $750,000 to open source. Who'd they actually pay, right? Look for those receipts. Yes, that's the pledge.
So two inputs. One being money and the other being... The blog post. Blog post. Annual blog post. And what do they get out of it? What do they get? JSON.
JSON.
Always JSON. Yes, man.
JSON.
All right. Tell me more.
That's how you pay maintainers, JSON.
Tell me more about JSON.
This must be some pretty good JSON. That's it. Yeah. Always down for good JSON schema, you know. Yeah, so what do you get out of it is you get... Essentially it's a lightweight certification. You get a member badge that says open source pledge member.
So then you can go out, you know, a lot of who we're going for at the beginning is developer tools companies, you want to sell to developers, you want to demonstrate your good will in the open source community, you get that badge that says open source pledge member, And then, you know, as we build this thing out, that starts to mean something, right?
So I want to make my decisions about what tooling I'm going to use. If I see that open source pledge member badge in the footer, I know that this company is actually paying maintainers in a real way. So that's the number one thing you get is that kind of cred. Yeah, I mean, it's really about the branding, the marketing, you know, and companies who want to tell,
who want to tell a good story about open source, saying, all right, you want to talk game? This is how you do it. This is how you actually support open source. Okay.
You buy it? I don't know. I mean, I think... I'm on the fence still yet. What's that? You're on the fence?
I'm on the fence still yet. I think that, I guess, if you get the company, if you actually, if it becomes a thing.
Yeah.
Right? So it's kind of a... It's not really a thing yet. You're trying to make it a thing. If it becomes a thing, then I get a thing. But in the meantime, if nobody cares about it, then I don't care about it. Just thinking as a guy who's running a company. Yeah, yeah, yeah.
It's like, well, if I don't currently care about supporting my dependencies because of all the reasons why I should, instead I'm going to do it because the pledge exists and I want to look good. I don't know if I'm sold right now because it's brand new, right? And you got a handful of companies doing it.
So we launched. So it was brand new on August 28th.
So what?
That's two months ago exactly, right? Pretty new. So it was brand new on August 28th. Sure. The two companies that were the first to join were Sentry, my employer, and you want to guess who the other one was?
It was a... I was surprised, too. I was paying attention. I think it was like a, I don't know, tell me, but I was surprised.
It was Astral. Do you know Astral? Astro.build? Astro.build is also coming along. Astral, A-S-T-R-A-L.
Oh, yeah.
They're the ones that are doing like Python tooling and Rust. Yes, yes, yes.
Yeah.
And they are venture-backed by Excel. Correct. Okay. Just like Sentry is. Okay. So actually Excel... So Excel partners are kind of like... So, I mean, it's networking, man. Right. This is all the social... Like, this is social networking.
Right.
This is like... herd mentality. I mean, what company is not an AI company today that three years ago, you know, we weren't talking about at all, right? Like for better, for worse, humans are herd animals, companies are herd animals. And that's kind of what we're trying to work with here. You know, when you're, you talk about sustaining open source, I see there's three levers that we can pull.
Number one is commercialization. So you build a company around your project. Open source itself is not a business model. But, you know, over the past decades, we've come up with business models. So commercialization is one way to sustain open source, to subsidize an open source project. On the other end is taxation. So Sovereign Tech Fund is doing this.
They're spending German taxpayers' money on critical digital infrastructure.
Yeah.
Okay, so both those are fine, that's good. What we're going after with Pledge is this middle lever, which I think of as validation, social validation, right? Again, you want to be seen, another way I think of it is, it's not an exactly perfect analogy, but open source is kind of like a restaurant, okay? Here's what I mean by that. Please, yes. Tell us more. I'm excited. What?
What's on the menu?
Open source is kind of like a restaurant. It's not perfect, but bear with me. I go into a grocery store, and I pay for my food first, and then I take it home and I eat it. I go into a soup kitchen, and somebody else pays for it. It's a charity, and I get to eat. I go into a restaurant, and... We go in together. It's social, first of all.
We go in, we sit down, we have a nice meal, and it's at the end of the meal when the food's in our bellies that we settle up and we pay the tab. So it's like a restaurant in that you're paying for this thing you already ate. You already consumed it. So year after year, our companies are consuming open source. We're feasting at the open source table.
And what we're doing with Pledge is saying, all right, now it's time to settle up, to pay for the open source that we've consumed year over year. And I get there because of the social aspect, right?
Yeah, I understand. That's the part you're trying to drill down on.
See, I saw it differently then. Okay. Not the analogy. I don't disagree with the analogy necessarily, but... All right, what are you seeing? I saw what you were doing with the open source pledge or OSS pledge, to be more clear. was an extension from what we did a while back with maintainer month and maintainer week. It was maintainer week and then maintainer month. And it was OSS fund.
It's the same idea that you started with Sentry, which was for every developer, whatever your number is, is your number. But you said $2,000 per developer was the good algorithm to use.
Yeah, that's our minimum, yep.
And so I saw open source pledge, this OSS pledge, to be an extension of that, but more with an awareness piece to it. Because it was hard. It was like you were pushing this uphill battle to say companies should have an OSS fund, which is a great thing to say. But then it was like, well, how do we do it? Whereas this, yeah, the FOSS fund. Thank you for clarifying.
Yeah, yeah, yeah.
I saw it as like an extension of that, but potentially better marketable, you know, and potentially with this social component that is not so much a force multiplier, but more like you should because this is where people who are doing this and believe in this model are collecting. Whereas the other way it was more like... soapbox, you know?
Whereas here, you're sorta like, what was it, Hands Across America, like back in the 80s, remember that? It's more like that, you know? Like, hand in hand across America feeding, I think it was The Hunger, something like that.
No, you're right, I mean, so FosFunders, I mean, it still exists, but FosFunders isn't, this is in some ways, A version of that. FOSS Funders V2. So Dwayne O'Brien is leading FOSS Funders. Love Dwayne, love FOSS Funders. Open Source Pledge is, yeah, it's kind of a V2 where we're saying, let's get an actual dollar amount. Because the thing with FOSS Funders, like, I built a FOSSFunders.com website.
I recruited companies to put a logo on it. You know, it links out to a blog post. Some of those same mechanics were there. Yeah. What was missing was there was no threshold. There was no consistency across that. It's like one company gives $10,000, another company gives $100,000, and how are you thinking? It's got to mean something.
It's like when I see that a company's on open source pledge, when you see it, Here's what I want to say. When you see that a company's on an open source pledge, or when your listeners see that a company's on an open source pledge, they should think, oh, this company's putting their money where their source is. This is your meme. All right.
Speaking of memes and credit, when you said that, we picked up on it. Yeah.
Oh, nice. We used that somewhere. You said that? I've said it a few times over the years. I said it on Change Dog News, and you picked it up?
Yeah.
That's on my copywriting there, Adam. Putting your money where your source is. Yeah. Yeah.
Send us the bill for the copywriting, Jared.
Yeah, I will.
No, we like that one. Put your money where your sources.
Now you've bellied up to the buffet. You've had your meal.
Yeah.
Now it's time to pay the piper.
Yeah, I mean, that's the main message. It's like, when you see that open source pledge member badge, you should know, wow, this company, they put their money where their sources.
That's what we're going for.
But yeah, man, early days, so... Two months ago, we launched with two. That was a soft launch. We put these billboards up. I don't know how much time we have to get in all the billboards and everything, but we put these billboards up on October 8th. So that's the three weeks ago? Yeah. By the time we put the billboards up, we had 25 companies on board. So we went from two to 25.
And I'll tell you, when we had those two, I was like... What are we going to have on October 8th? Because we signed a contract for billboards and we're going one way or another. And I don't know if it's just us and Astral, then it's just us and Astral. But we had, yeah, 25 companies join us for that launch. So we feel really good about that.
We had seven, well, six open source foundations that gave us endorsements, you know, because the pledge is companies. But, you know, on the other side of the equation, it's all the foundations and the maintainers. And so we got endorsements from OSI and five other open source foundations, PHP and Django and whatnot. Yeah. So I feel like we had a lot of good momentum for launch.
But, yeah, man, it's all about what happens next, right? It's like the next three, six months. I'm a salesman now, you guys. I'm like, this is what I signed up for. Now I got to go door to door and be like, hey, who wants to join?
This is your baby.
Well, it's David Kramer's baby, let's be honest.
But you're carrying the torch.
Exactly.
Fair enough. Fair enough.
That's your job. That's my role these days.
All right. Well, I mean.
Keep an eye on it.
Keep an eye on it. Yeah. I'm excited to see what happens. 225 is definitely a move. Yeah. That's a move. If you went 2 to 4, I'd be like, meh. 2 to 25 is legit. 24 is a... No, if you went from 2 to 4... I was like, 2 to 24, I'm like, what's wrong with the 1?
I put out the Twitter poll, and I was like, where are we going to be at launch? Everybody had me at 5 to launch. So I feel pretty good about 25. Yeah, fair. Yeah, for sure. It's what happens next, right? Is it on the honor system?
Well, so this... There's no vetting and verification, right?
Blog it.
It's the blog. The blog is there. The blog is there. And we do go look at the blog when you get onboarded. Right. We look at your blog and we go back and forth. This is what we're looking for. Who's we? So there's four of us on the core team. Okay. Two of us from Sentry. two organic community members that showed up to participate. Vlad and Ethan are not employed by Sentry.
Myself and Michael are at Sentry. So that's the we. And we'll grow that kind of formality of it over time as we grow. But yeah, we launched with 25. So we do vet. Here's what I want to say on that. Going back to what I was saying earlier, GitHub sponsors, ThanksDev, Open Collective, these platforms that do this, our goal is to build that up so that they help with the receipts.
So ThanksDev's helped me out a ton, okay? So I'm doing, I'm going to, you know, past years you guys and I have talked about Sentry's own funding program. So this is kind of the extension of that where we say, all right, now can we get other companies to join us with this? So Sentry's own funding program for this year is going to launch in a couple weeks. We'll land that in a couple weeks.
Had to push it back because I was distracted by the pledge. ThanksDev is my main vendor for that. And they, yeah, they're helping us out with, all right, what kind of reporting do we want for the pledge and how can these vendors help us with those receipts so that it's not just an honor system, there's a little more meat to it. So really trying to incentivize that ecosystem.
Well, whoever would put out a blog post saying you funded open source and you didn't fund open source... I made a face, by the way. It was not a good face. Well, there is.
Does this happen? No, I'm just saying like that, if you didn't... If it did happen.
Right. If you would go through the motion of saying, I pledge, I blog, and that blog was non-factual.
Yeah.
I mean, big time, you know? Yeah, yeah, yeah, yeah. So... Yeah. Receipts. And so I joked about the JSON earlier, and you never closed the loop. Yeah, what's the JSON deal? What's the JSON? There is... Let's close the loop of the JSON. I forgot all about it.
So there is... Well, so what we have people do, and I don't know if we'll do this forever, but the way the system is set up, we're going to geek out for a second here. To join the pledge, a company publishes a JSON file. They publish their blog post, but then they publish a JSON file. Because this is an annual thing, right? It's an annual thing. So every year you got to pay.
Every year you got to publish a blog post. So I built a system where they publish a JSON file that says, here's the number of developers we have. Here's the amount of money we spent. And here's the link to our blog post about it. And then they can update that year over year. And then we pull that in with a GitHub action or whatever on our side. Yeah, so that's where the JSON comes in. Yeah. Anyway.
So they give a JSON. They don't get a JSON. That's just more given. Yeah. But they become part of, I mean, you're going to, like, report that or, I mean, somehow that thing. You should pull it together to a master JSON file.
They do get a JSON, though, because when they go through the flow, they generate the JSON file for them. Who does?
We have it. We built that out.
OpenSourcePledge.com.
Vlad, one of the folks working on it, built that out on the website. So if you're at a company that wants to join the pledge, then you go to OpenSourcePledge.com. You'll see a join button there. OpenSourcePledge.com slash join. We'll walk you through the steps, including, yeah. We'll build that JSON for you. We'll give you a gift of a JSON file. They gift you a JSON, but what do I do with that?
Then you put that on your domain to validate that it's legit with your company. More work for me. That's more work. We'll streamline it. Early days.
Early days. Yeah.
Cool.
Well, good stuff. Yeah.
Yeah, keep an eye on us.
So let's wave a magic wand.
Okay.
Okay?
Yeah.
Put it here down right now. All right. How much time you got? Three minutes?
Yes, three minutes.
Three minutes. Okay, he's got less than three minutes to wave this magic wand. It is, pick your number of years from now.
Yeah.
One, two, five, whatever. What's the goal? What do you want to, like, what would be best case scenario? Yeah. Yeah.
You know, so when I go to San Francisco, I like to read embarrassingly basic, cringey business books on the plane, you know? So I was there two weeks ago, I was reading Crossing the Chasm. I want everyone on the plane to know that I'm reading Crossing the Chasm.
Yeah, exactly.
Work OS. Yes, exactly. Crossing the Chasm. That's it, right.
Innovator's Dilemma.
Sorry, Crossing the Enterprise Chasm is really the long term. That's kind of the playbook that I'm seeing for this. For this to be successful... The intent is really to have as much of the industry as we can participate. So we're looking at this whole thing with the innovators and the early adopters and the early majority and the late majority. You know, wave the wand.
If it's five years from now and we're across the chasm and we've got 1,000 companies on board and some of those companies have 5,000 developers on board, we're doing great. If it's a year from now and we've got I mean, 100 companies maybe, 200 companies, and there's some of those, Century's 135 developers.
If we have a company that has 500 developers on board a year from now, I'm feeling really good about it.
You're currently the biggest one?
Yeah, absolutely. So you need some big fish.
You want a lot of fish, but you want some big fish.
Yeah, so we're going broad, and then we'll grow it up. Because it's about, I want to say peer pressure, but it's about that validation that we're doing this together. Century and 135 developers, like Microsoft's not joining tomorrow. You know what I mean? It's like we've got to make the environment a little different before we can get there. Build it over time.
All right. Thanks, Chad. Opensourcepledge.com. Go there now.
Yeah. And look for that badge. Get your JSON on. That's it.
All right. Thanks, Chad. Thanks, guys. Okay, to the many people we saw in the hallway at All Things Open, well, hey, it's good to see you. We met a lot of people who were there on the coupon code we gave out, the free one in most cases, and in some cases, the discounted version. And that's so cool. Lots and lots of listeners of the changelog at this conference. And that that's even cooler.
So this anthology episode covered lots of stuff. The state of enterprise Linux, RHEL, CentOS, Fedora, Ubuntu, Alma, Rocky. The list is long. We cover T.XYZ, this new protocol that may give value back, may give rewards back to open source maintainers. That's cool.
And of course, opensourcepledge.com and Chad's work and David Kramer's hard work on this from Century to support open source maintainers to find ways to find models for for organizations and teams to adhere to so they can give back so they can do the right thing and to support their open source that they're using. And that's cool too. Lots of cool stuff.
Okay, on Friday, a fun friends episode from the hallway track again. Add all things open. Different people, different conversations, maybe a little more fun. I don't know. You tell me. But a massive thank you to our friends at Sentry who happen to be also a sponsor of this episode. Just happenstance. We love Sentry. We use Sentry. Sentry is awesome. And our friends over at Coder, coder.com.
8sleep, 8sleep.com slash changelog. My gosh, get one of these. Sleep on it. It will change your sleep life. Trust me. And of course, our friends at Assembly AI. Check them out, assemblyai.com. And those beats, they're bangin', bangin', bangin'. Thank you, Great Mesa Cylinder, for those bangin' beats. The beat freak in residence, always bringin' the beats. So good. Okay, that's it.
This show's done. What are you still doing here? It's time to go. We'll see you on Friday, okay? We'll see you on Friday.
Doodly-doo, doodly-doo, doodly-doo, doodly-doo, doodly-doo.