Matt Stauffer:
Hey everybody, welcome back to the Laravel Podcast Season 6. This is Episode 11 where we finally get to talk about Laravel 11's release and everything else. But first, hey, I'm Matt Stauffer and this is The Man, the Mystery.

Taylor Otwell:
I'm Taylor Otwell. Hey everybody. Hope you're doing well.

Matt Stauffer:
So there's a lot of things we have to talk about today, but first we just got to talk about Laravel 11. We actually both had between kids spring breaks and stuff like that. It's been a couple weeks, so we missed the initial Laravel 11 release, but I actually am excited about that because that means it's been in the wild for a couple weeks at this point. So can you just talk a little bit about how did the release go? Was it one of those where you had to push out a bunch of fixes? Like, what has it actually been like from your perspective to have it out in the wild?

Taylor Otwell:
You know, I really feel like this has been one of the smoothest releases so far, and it's not because people aren't using Laravel 11, thank you very much. But our response was actually bigger than ever, but yeah, we just didn't have a lot of issues post release. I mean, we did a couple of little patch releases, but nothing major. And I mean, I have to credit a lot of that actually to Nuno here at Laravel because he spent a lot of time making sure that every "I" was dotted and every "t" crossed as far as this Laravel 11 release goes. We had a big like basically Trello board within Base Camp, their kanban feature that like had all of these things that we know we needed to make sure it was totally buttoned up that everything was compatible that everything was working. And we just spent a lot of time actually making sure that everything worked exactly right, you know, when you're upgrading from 10 to 11, when you start new Laravel 11 apps and that everything the whole story was smooth, because it was a pretty big change on the skeleton side, not so much on the framework side, actually. But on the skeleton side, it was a pretty big change. So I'm actually super happy with the release, super happy with how the framework turned out. And the feedback has been really positive so far, honestly, on all of the changes.

Matt Stauffer:
I love that. I have not got a chance to source dive, but I usually source dive right after a release or actually in the middle of a release. Is there just a lot more conditionals now where it's just sort of like, hey, if this config file or this directory does exist, otherwise this, and it just goes, falls back to framework files?

Taylor Otwell:
In sort of the bootstrapping section of the framework, yeah, there's sort of some conditional logic to determine what kind of app we think we're running. Is this something that's running on the Laravel 10 structure or something that's running on the Laravel 11 structure? And a lot of that sort of revolves around, does certain files exist? Like, does the kernel file exist in the application structure? Does certain middleware files exist? Once you kind of get out of that bootstrapping section of the framework, I think things are pretty much business as usual.

Matt Stauffer:
Okay.

Taylor Otwell:
During those initial few tasks that the framework performs, we do have a few extra conditionals there. The config stuff was a last-minute audible. If you were at Laracon EU, you might have seen there was actually no configuration files or even all the way back to Laracon US. Within the last couple of weeks before a release, I was playing around with new Laravel 11 apps, and I was like, I don't know if this feels totally right. It feels like deleting files for its own sake and not for any real productive purpose for the end developer, which is a place we didn't wanna go to. We don't wanna just start making things minimal for minimalistic sake. We want to actually make things better for the developer. And that was one where we actually called a last minute audible, like, hey, let's bring back a few of the core config files. We didn't actually bring back all of them. So the hashing configuration file is still not in the config directory by default because it's just like, yeah, you never change it.

Matt Stauffer:
Mm-hmm. Nobody ever used it. Yeah.

Taylor Otwell:
The cores configuration file, probably actually a little bit more used in the hashing configuration file, but not by most applications, I would say. But the core ones like database, queue, those are all there by default, which I think feels fine.

Matt Stauffer:
Yeah, there was a conversation on Twitter about it. And one of the things that happened was a few people who were like, well, you know, like I think actually, what's his name? I almost forget his nickname, but Jason from...from Shift.

Taylor Otwell:
JMac?

Matt Stauffer:
Yes, JMac, I always forget the nickname he tries to go by, JMac, he was saying, we should keep all of them, and one of the things I've noticed is that he often has an opinion on having seen so many code bases that are older and need migration and stuff like that, and when he and I were having a little bit of a different perspective of it, I realized that every person who shares their public opinions is, and you know this, but it's sharing it based on their specific context, you say this all the time, but I always think of that as meaning like your company and your needs. But then I'm like, also like some people spend a lot of time helping new people join the framework and some people have never done that before. Some people spend a lot of time migrating legacy applications and some people have never done that before. You know, there's all these contexts where it's not just your app and your specific needs, but like whose experience of the framework are you even considering? And I think that you have a perspective of newcomers in a way that a lot of people who have voices in the community don't. So that's one of the reasons why I was excited for you to be thinking about this, because as I have had to try to welcome JavaScript people into the framework, I think I may have said this in a previous one, the number of files that are going on is definitely one that could confuse them. But I do think that if we optimize purely for them, like you said, a lot of us who are used to being like, yeah, just go to the database config. So I really just appreciate that there was a, you're trying to find that kind of balance line. And I also appreciate the fact that you're willing to try those things and make changes. I mean, this is not the first time where you've been right on the verge of a pretty significant change and either not launched it or launched it and immediately went, you know what, that doesn't feel right. Like I'm trying to, I didn't, was there a routing based on attributes at some point? I feel like it actually got into a release, right? And then at some point you're like, nope, we're just gonna stop documenting it because it turns out that's not how it should be.

Taylor Otwell:
Yeah, I think so. I mean, I think that's one good thing about Laravel is we've never been scared to say, this just isn't really working. Because a lot of us build applications every day, whether us internally with things like Laravel Forge and Vapor. So we're actually very connected to the framework and how it feels to use, I think, in a lot of ways, and very willing to say, this kind of sucks. We need to either remove it or undocument it, which is kind of one of my favorite ways of sort of like soft deprecating a feature without breaking everyone's applications, which I think is important. So yeah, I mean, I think that's good, you know, to always be willing to say what's not working.

Matt Stauffer:
Yeah, and I was just gonna name that about undocumenting it. I didn't know at first that was something you did, and then, I mean, we're talking years ago, but somebody would say, well, that thing you're talking about, it's not in the docs anymore. And I'd be like, well, that's interesting. I definitely remember it being there. And then I started noticing that, like, that's a way to just say, like, look, it's not gonna break in your app, but we're not gonna teach new people that this is the way to do the thing. I was like, I like it, a soft deprecation.

Taylor Otwell:
Yeah, we recently did that with cache tagging. Cache tagging still totally in the framework, works, as it has always worked, but it is not in the Laravel 11 documentation. It's actually, I don't think anyone's even mentioned it, that it's not in the documentation yet. It's just one of those features that's actually very complicated under the hood for us to implement. It's very complicated to maintain. Anytime there's a PR on that feature, it's very scary because it's just hard to maintain. So I was like, eh.

Matt Stauffer:
So complex.

Taylor Otwell:
I don't know if I want to be in the business of this whole cash tagging stuff. And maybe people can just write a package if they want to do that. Cause I think it's kind of niche and stuff and it's hard for us to maintain. So that's a recent example.

Matt Stauffer:
And if I understand correctly, it's implemented very differently across different caching platforms, right?

Taylor Otwell:
Yeah, that's another big problem with it. It's like very different on memcached versus like Redis. So yeah, that's

Matt Stauffer:
Mm-hmm, which I know that those sorts of things are not, you know, you really got it It's it's got to prove its worth to really merit like maintaining a lot of driver differentiation. Yeah I love it because it's making me think of just like the public versus private methods of your classes, right? Like it's there, but if it's not documented you got to be a little wary of it, you know in the future or whatever so

Taylor Otwell:
Yeah.

Matt Stauffer:
Okay, anything else to talk about? I mean, I know we're going to talk about Reverb and context and stuff in a bit, but anything else about the Laravel 11 release specifically? I mean, you mentioned, and I've definitely seen lots of people are using it. Lots of people are talking really highly about it. You kind of mentioned that there weren't a lot of fixes y'all had to do and props to Nuno for that. Is there anything else you want to chat about with the Laravel 11 release?

Taylor Otwell:
We did do the context, you know, that was kind of like our Laravel 11 Deluxe. I was joking on Twitter about putting out like the Deluxe version of the Laravel 11, kind of like, you know, people put out albums and then the next week they'll put out the Deluxe album with a few more tracks on it. So the context feature in Laravel 11 was sort of our Deluxe edition of Laravel 11 that shipped the next week. Context was a feature that's sort of the brainchild of Tim McDonald here at Laravel. So to summarize the feature, you know, like for example, when you write a log message in Laravel today, let's say in Laravel 10. So last year, you're writing a Laravel application, you write a log message, you can pass an array of contextual data. It might be like the user ID, it might be like the project ID, something that's going to also get written to the logs as JSON to help you sort of identify where this came from. That and that's great. But one of the issues with that, that Tim wanted to solve is what if you have a web request that then queues a job. So now you've got like a background job processing that say like processing a podcast or transcribing a podcast. And you write a log there, you don't have the contextual data necessarily from the HTTP request. So what the context feature in Laravel does, it's actually an entirely new context facade that you can interact with. You can say context colon, colon, add, for example, and put like user ID one in the context. And then even if you queue a job within that queued job, if that job writes to the log, the contextual data that you added during the web request that dispatched that job will still get written to the log. So you can trace like, oh, user ID one queued this job, and maybe you assigned some trace UUID to the request even from Cloudflare or something like that. So it lets you track things across distributed systems and through queued jobs that you weren't really able to do before without a lot of manual legwork.

Matt Stauffer:
Yeah.

Taylor Otwell:
So super, super cool. You can even write like hidden items to the context. So say you have a piece of sensitive information that you'd like to put in the context that you actually don't want written to the logs, but you want it available to retrieve out of the context within your queue jobs, because you can do like context colon,colon, get, just like a config variable and pull context data out of the context. So maybe there's some sensitive piece of information you want to put in the context because you want to get to it later in your job chain or whatever, but you don't want it written to the logs. You can use hidden contextual data for that. So it's actually like, it's actually a pretty simple feature under the hood, but it just gives you a nice little piece of functionality that required a little bit of manual legwork before.

Matt Stauffer:
Yeah, so I have a couple questions about it. The first one being, if I always want the user ID and always want the tenant, you know let's say I've got a multi-tenant application. If I want all those in added context all the time, where would you recommend that I put those in the booting process?

Taylor Otwell:
Yeah, so I would definitely throw that in a middleware. So I would put in a middleware at the end of your middleware stack, which in Laravel 11, you could actually just do this directly from the bootstrap file. You could just say, you know, middleware append and then pass a closure to that right there if you wanted to, or you could have a middleware class. And then just throw data in the context, you know, and pass the request along the middleware chain. That way you've always got it on every request. I mean, I think that's actually the example we have in the docs is using a middleware to assign like a UUID to the request and the current user ID, which I think is common contextual data. And then the nice thing nice thing about middleware or context as well is Laravel takes care of automatically clearing the context after every queue job. And if you're using Laravel Octane after every web request. Because if you're using Octane, your application is actually not shutting all the way fully down like it would if you were in a traditional sort of web server environment. So we actually automatically clear the context when you're using Octane as well so that contextual data doesn't bleed over between requests.

Matt Stauffer:
And side note before we continue, y'all, this is why I tell people you should use the defaults of every single Laravel system, even if you don't know why. Because when a new system comes along, if you're using the defaults, they play together. So, like, for example, with Octane, like, you could probably try and do things without Octane. And I've seen people be like, well, I'm not going to switch to Octane because I've already got my own ideas of multithreading. But like you didn't know that this was going to come up and you're going to need to handle this. And that's the same thing every time a new feature comes out for Laravel. It integrates with the other features not only really well, but sometimes the features are modified for you to play together with a new thing. But if you hand rolled your own system, you're not gonna get those benefits of these future things. So just another plug stick to the defaults. So Taylor, one of the things that I've done sometimes with clients is set them up some type of a value store that we bind to the container so it has access across the web request. And sometimes you just need this information bound and sometimes we'll make like a like a plain old PHP object that's a singleton or something else, but basically we use the container as like the place where data lives across different contexts of the application so that we can just kind of reach out and get that data. Would you say using contact hidden is a place where you would actually put real functionality or do you think it should mainly stay as stuff that's really just informational?

Taylor Otwell:
I'm not sure. So I mean, this exact use case actually crossed my mind because as we were building context, I was like, oh, you could actually, I've actually used the container in that same way just to put like, you know, call the container instance method to give it like an object and you're using almost like a global object store. You can kind of use the array cache a little bit in the same way. So you've kind of got three ways of doing that a little bit now with context, but I don't know. Like, I don't know. I haven't built a full Laravel app with since context has been released. I'm not sure how I would use it. I think that use of the container is pretty valid. I would just say that we, it's not what we intended context to be for. It's more like we intended it to be like for routing and contextual or for logging and contextual data. But yes, you like could use it that way.

Matt Stauffer:
Yes. You theoretically could, but it's not what it's built for. Yeah.

Taylor Otwell:
Yeah, right. I think the only gotcha with that in terms of using context would be if you put something that couldn't be serialized onto the context, because when it actually cues a job, you may get an error there if you have an object that can't be serialized onto the cue. That would be like a closure maybe or something like that.

Matt Stauffer:
Yeah. Okay. All right. Well, that's context. I haven't built a brand new app, but I'm in the middle of building my first Laravel app right now, or Laravel 11 app right now, and I'm very excited about it because I wanted to experience the new framework or the new, you know, the layout and everything, but I'm also wanting to play with context, so. All right, so there was another release. You released Reverb, and I've seen people doing a lot with Reverb. So from internally, from y'all perspective, how do you feel like the launch went?

Taylor Otwell:
I mean, pretty smooth, I think. We had been using Reverb in production for maybe a month and a half or two months. By the time it was released, we were using it for both Forge and Envoyer. We're running both of those on a small web server and serving over a million messages a day through there, which is not like web scale. That's not like insane, but pretty good for us.

Matt Stauffer:
That's still a lot.

Taylor Otwell:
Yeah, and I haven't seen any major complaints about Reverb as well and haven't had any memory creep or leak issues, which is always the concern with these sorts of long-lived processes. But it seems like it's a pretty smooth release.

Matt Stauffer:
Yeah, I had one buddy have a little bit of trouble with it, and it turns out it was his Windows setup, and he just had to reinstall something from scratch, and that was it.

Taylor Otwell:
Yeah. Gotcha. Yeah.

Matt Stauffer:
Again, once again, I think I said this in the last podcast, but I'm just so freaking excited about having production quality web sockets available to me that doesn't cost money because the number of ideas that I've had where web sockets would have served well and I was like it's but it's not worth Pusher you know? I'm not saying nothing's ever worth the Pusher but I've just it's just cool enough to not be worth it and I'm like I could just do it like I'm so excited to find my next excuse for it and be like, yeah, I'm actually gonna do it. So thanks again.

Taylor Otwell:
Yeah, and I'm happy with how the Forge integration turned out, you know, just being able to toggle a switch and have your Reverb server running. Super nice.

Matt Stauffer:
Yes. Speaking of which, there was a post that came out this morning. Obviously it will be, you know, old news for you listeners where, I think it was Christoph went through some top Forge tips. I unfortunately haven't gotten a chance to watch it yet. I've been using Forge since beta, you know, so I'm really excited about it, but we'll put it in the show notes for y'all. Taylor, I don't know if you had a chance to watch it yet, but if so, are there any top Forge tips that came out of that for you that you were like, oh yeah, people should know about this more?

Taylor Otwell:
I haven't actually watched it in depth. I've just skimmed it. I mean, we've done a lot with Forge over the last year or two. We've added a lot of additional functionality. So I'm sure there's some good nuggets in there. And we've been working on some cool upcoming stuff for Forge as well, which I'm excited about. So yeah.

Matt Stauffer:
Nice. I don't know if there's ever been a software as a service I love as much as I love Forge, just because the ways it's changed my developer work life. So. All right, so a few more new announcements. We've got new hires. So you did put out a tweet saying, and there's a couple people in there who I don't know and I'm very excited for them to have joined, but we've got, so Andr? Valentin, who we've been messaging a little bit, so I just got to know him. So great to have him on as the CTO. But then we have some people who've been around, and I'm not saying everyone else is not excited, so people who've been around. We got Chris Fidao, who I feel like is the first probably like five early bloggers of the Laravel world work together with that help spot like been around since the longest So having coming on. Is he doing mainly devop stuff or?

Taylor Otwell:
Yeah, he's been leading some infrastructure efforts on some new products that we're exploring. He's our first sort of like dedicated infrastructure hire, but some of the products we're you know trying to tackle over the next year are pretty ambitious and I think warrant having a dedicated infrastructure person and I think there will be more infrastructure people coming soon as well. By the time this episode is posted, we actually probably will have our Laravel.com Careers page up by the way. So because we're going to be hiring a few different positions.

Matt Stauffer:
That's awesome. So go take a look.

Taylor Otwell:
Yeah, full stack developers, infrastructure people, customer support techs for things like Forge and Vapor, and probably also an application designer.

Matt Stauffer:
This is exciting.

Taylor Otwell:
We've never had a full-time designer on staff as well. So yeah, but anyway, Chris is on board. Like you said, Andre is a director of engineering. We've got Mohammed is back on board, who is our first employee back. I don't even know when, maybe 2016. Something like that, 2017.

Matt Stauffer:
Is he doing serverless again or?

Taylor Otwell:
So Mohammed is helping us out a lot with customer support at the moment, but the goal is to scale up that customer support team and get him back into infrastructure dev stuff, which he's dabbling in now, but we would like to actually get him back into that. But he's kind of like pinch hitting for us on support at the moment, which is really nice. Because a lot of our support is super technical with things like Forge and Vapor.

Matt Stauffer:
Yes. Yeah.

Taylor Otwell:
Let?s see what else there's, there's been quite a few hires actually more like outside of the engineering department as well. So like, we've got Tom Crary who is our COO. He is like a very great counterpart to my lack of business knowledge. You know?

Matt Stauffer:
Uh huh. I love a good COO, man. They just kind of make things happen.

Taylor Otwell:
Yeah, because yeah, in a lot of ways, like I function in a CTO role, you know, even though that's not my title, even though I'm CEO. Obviously what I bring to the table is a lot of tech experience and the most Laravel experience in the world, obviously. So that's sort of what I'm bringing to the table. But he's got a lot of great business experience to help us navigate, you know, all the issues that come with scaling a company, working with partners, everything businessy, you know, that I don't really excel in necessarily. We also brought in a few other people on that side. So like Michael Ryan is based out of New York. He's helping us with business operations. Paulina, who's helping us with finance management. So I'm not keeping the Laravel books anymore, which is great as well. Yeah, and then sp Mazzina, who is heading up customer success, which I think will grow into a multifaceted role. But right now, it's being over our customer support team as we grow it, making sure we're keeping customers happy that tickets are being handled, also helping with Laracon type stuff. You know, it's sort of a multifaceted role, but she's also a great writer. So also helping our communications and things like that. She actually live blogged Laracon 2016, something like that in Louisville. So she's been around the Laravel ecosystem a little while as well.

Matt Stauffer:
Great. Well, this is super exciting. So we've got all these new people who just came on board and then by the time this releases, we'll probably be able to check out laravel.com/careers for more options. And of course, people listening to this podcast are some of the most ideal people to be applying for those jobs, so definitely go check them out.

Taylor Otwell:
Yeah, and can I plug that a little bit? So, you know, one of the things we're trying to do is make Laravel a really compelling place to work. So, you know, since this probably will come out after the careers page is up, you know, it's gonna be a fully remote work environment. Of course, vacation time, holidays, private healthcare, no matter where you live. I know some people have public healthcare in their countries but they also want to pay for private healthcare. You know, that's something that Laravel can cover as well, of course, retirement slash pension benefits. So yeah, check that out. Once it's up, we have quite a few positions we would like to hire for, and we would love to hear from you.

Matt Stauffer:
Yeah, I tell you this every single time, but if I did not own a company, I would be knocking at your door, man, real quick, real early. All right, so other releases that came out. So I think Herd Pro was out last time, but I know that Herd for Windows and Herd Pro for Windows were not out. So can you talk a little bit about kind of what led up to that? I know Marcel should be someone I should bring at some point, but you're pretty actively involved in that too. Like what did the process look like for y'all to make Herd for Windows and also to do Herd Pro and everything?

Taylor Otwell:
You know, I can't speak to the technical details, but for me, like the vision of Herd was always like a dream of mine to just have a self-contained desktop application to run PHP. And I think a lot of the initial discussions around Herd were actually born out of Marcel's work with native PHP because he had to sort of encapsulate PHP within the binary. And so I remember pinging him. I was like, can you just give me PHP as a Mac menu bar application? And I sent him the Postgres.app as like an example. There's, I don't know, I don't know who made this, but there's a Postgres.app, it sits in your menu bar and it gives you Postgres, the database. That's all it does. And I was like, can you give us just PHP in the menu bar? Because at the very least, we can just, if we have that, we can run PHP, Artisan serve, boom. Like you're up at least. And then he kind of like, I think I pitched him that idea a couple of times, but then of course he took it like way next level beyond that where it's like, you know, full, the full Valet experience encapsulated into the Mac menu bar. And now they've even added like databases and stuff, which was never on my radar at all. So of course, we knew we wanted to bring this to Mac, because that's what I think we were experienced with. And then, you know, Marcel, of course, it was like a pipe dream to bring it to Windows, like we would have loved to have done that. But it wasn't my baby in terms of I didn't code it. So I couldn't really boss him around that way. But he sort of took the initiative to build this prototype and got it working. It was like, man, I think it's actually going to work. And I just consider it, honestly, such a huge leap forward for the PHP development ecosystem on Windows. There's been the previous generation of tools, like MAMP or WAMP, I guess you would say, and other tools. But I don't feel like they had that full valet level of convenience where you just drop a Laravel app in a folder and then pull it up in your browser and boom you're up and running. So I'm super excited that's out there.

Matt Stauffer:
Yeah, and I've heard, you know, I did a lot of research two years ago, I think about like, what is the ideal way to set it up? And nobody was ever happy with their solutions the way people were with Valet at the time on Mac. Laragon was one that came up the most, and I haven't dug deep into this, but one of the things I read was somebody putting up a post from the Laragon person saying, I'm burnt out, I need a day job, and I can't do any more development, which kind of leads into the next topic of this, which is the fact that Herd Pro, which comes with a lot of things on top of Herd is a paid thing and it kind of led to some conversations online about like what What merits do you know charging money for open source work and not merits it? And so we kind of now have Herd Pro there. We've got this Laragon person burning out because they weren't making any money off of it. You got me the maintainer of Valet telling everybody look go use Herd. Herd is great, you know, like, you know like I'm not making any money off of Valet go use Herd and enjoy it and one of the things when we were talking earlier as you pointed out that Redis is kind of going through a whole conversation around this and I'm gonna say what I know, which is less than what you know, and then you're gonna tell me what I'm missing. What I know is that there was Redis as an open source concept. There was some kind of organization or company that very early on were the primary providers of Redis and then later renamed themselves to Redis. And then they recently changed the license of Redis or something for it to cost money because they found that Amazon and other people were using Redis as the foundation of something they were making all this money off of. And now there?s this big conversation of when should an open source thing be able to cost money or not? That's kind of the extent of my knowledge and I know you dug a little bit more into it. So can you share what more is going on there and we can dig into it a bit?

Taylor Otwell:
Well, I mean, it seems to kind of be like the age old tale of open source sustainability, you know, and to start with like, you know, I think the background with Redis. Yeah. I think your understanding is basically correct that, you know, Redis was originally free open source software created by one guy, essentially. You know, it's put out there into the world and maybe you never expect how big an open source project is going to get. Like I didn't expect that with Laravel, you know, and I'm sure probably he didn't fully expect that with Redis. Even if you think it's a valuable tool, you have no idea that it's gonna be used by Amazon, you know, in ElastiCash or whatever. And then you get to a point where it's like, you know, wait a second, Amazon's making billions of dollars off ElastiCash, I presume, just off that one service. And, you know, if you're the Redis company or you're the Redis guy, you gotta be like, like where? can I have any of that money? You know, like, because you created this software. You know, so I think with Laravel, we've always tried to walk this fine line from the very beginning of providing a lot of value for free through the framework, but we have to keep this whole thing sustainable. We all love Laravel, the framework. We want these packages to continue to be high quality, to exist for a long, long time. And in order to do that, we have to make money somehow to pay people to work on them. So it's just very, just basic business, you know? In the open-source world though, like, I see it from both sides of the coin because I think in some sense, if you want to make money from a project, you should just charge for the project upfront. I think that works in a lot of cases, but I think it can be a little bit too simplistic when you simply don't realize the full impact your project is going to have out of the gate. Which so I think it's fair in some sense for open-source people to be like, hey, I didn't know that like my software was gonna be used by these multi-billion dollar corporations to make these insane profits. And if I did know that, then I would have planned, you know, some sort of compensation for myself. But this was just a hobby project that I started because I was personally interested in key value stores and making them performant. It wasn't because I intended or knew that it was going to be this big business. So I'm not really sure what the answer to that is. You know, but I mean, back to the Herd thing. Yeah, we, we did like lock certain herd features behind a pro tier so that, you know, people like Marcel and D and the beyond code team members, which we have a partnership with on the software can continue to work on the software without you know, volunteer charity labor that will eventually burn you out because if you're having to do that kind of labor, it means you're working some other kind of job to actually pay your bills. So now you're working, you know, nights and weekends, often dealing with people that are complaining about your open-source software and are not in general giving you good vibes, which is going to lead you to burnout. So that's the gist of it, you know, and I think Laravel, you know, I think kind of like pioneered a lot of these kind of what in terms of like being a homegrown open-source ecosystem, keeping things in house and building out some of these like profitability avenues. I think Laravel, you know, out of the frameworks like Rails and Django and things like that was sort of one of the first ones to try to do that at a fairly large scale in a homegrown way. And it's been a balancing act for sure, but I think has been key to helping us keep it sustainable and have people work on the framework full time. Which some of these other frameworks don't have, you know.

Matt Stauffer:
Yeah. And if you look at other people in the Laravel community who contribute a lot, who don't work for Laravel, the vast majority of us work for a company that benefits from Laravel. So like the only reason I could even take the time to maintain Valet is because Tighten paid me to maintain Valet. Like it was Tighten giving back to the community, not because I could just find the time in my, you know, free nights and weekends. And sometimes I could, and sometimes it was only because Tighten was able to pay me to do it. And I know a lot of package authors do so because like, for example, Spatiehas tons of packages because Spatie's reputation grows from having lots of packages. I'm not saying that's why, but like, they're able to maintain it because it brings financial benefit to their company, right? And like, there's everybody here either burns out eventually or finds some way to find a sustainable avenue for continuing that work. And so that's why I kept telling people, I'm like, I'm fine for Valet effort to move on to Herd because they've now monetized part of Herd. They're going to get paid to do that. And they're going to get paid to like, I never could have taken the time to do all the native PHP work and learn all the stuff they did there. And I know it's taken them months of extremely hard work to get Herd for Windows working, let alone then also getting all the Herd Pro features working. And like DB Engine is free and it's wonderful. I'm guessing it's free because it's made by the people who make money off of Table Plus. Right? Like there's no long-term sustainable, I just do this work because I love it and I endure the abuse of, you know, some jerks on the internet, not everybody on the internet is a jerk, and don't get some benefit from it from it eventually.
If you don't, you're gonna burn out. And that benefit may be it helps your career, your company sponsors you doing it, you're able to monetize it or whatever. But like, I think that we're more accepting of certain reasons of motivation, like mine and Freek's, because it benefits our companies tangentially. And we're less understanding of other people's motivation because they want to actually make money off the thing itself. And I would just say like, allow people to try and get some benefit from the thing. You know what I mean? Like, I don't know. So.

Taylor Otwell:
Yeah.

Matt Stauffer:
All right, so that was the last particular item on our docket. Was there anything we didn't cover about all the releases that happened over the last couple of weeks that you wanted to make sure we got to?

Taylor Otwell:
You know, no, I think that's pretty much the highlights. Laravel 11, Reverb, Context, and we continue to ship stuff every week, you know. So every week there's a release of Laravel. Today I tweeted some of the new features in that release. So keep an eye on those weekly releases, because sometimes there's really some hidden gems in those releases. Like one of the recent ones someone brought up on Twitter again today was the where any and where all query builder methods, which makes it super easy to do textual search across multiple columns. So there's some actually really cool features that go out in these releases that are not like surrounded by a lot of fanfare and Laracon and all of that.

Matt Stauffer:
And speaking of Laracon real quick, are there any tickets left for US? Okay.

Taylor Otwell:
Yeah, there are still tickets left. I know we're under 100 tickets left. You know, so probably be sold out sooner rather than later. We have to hold back quite a few tickets for sponsors, speakers and stuff. But yeah, I think we still have under 100 like general admission tickets remaining, which will put us right out about like 950 people in the building, which is not gonna leave a lot of open seats. We will, we always leave a little bit of wiggle room of course, but last year we were at about 800, so it'll be a little bit of a bigger conference this year.

Matt Stauffer:
Yeah. Okay, and one of the reasons I keep mentioning is every year I have friends, clients, whatever, who come along and say, oh man, I really wanted to go, and I'm like, okay, you gotta know now that this is your chance because it's about to be gone.

Taylor Otwell:
No, I know. It does not, it doesn't seem to matter how much we tweet about it, how much we email about it. There will be people in the weeks before the conference saying, oh, I didn't know Laracon was happening at all actually. And I would really love to come. It's actually pretty mind blowing.

Matt Stauffer:
Well, thank you as always for the release. This stuff is super exciting. I'm really having a good time building my first Laravel 11 app, and I'm literally just trying to find a way to sneak context, or sneak reverb and context into it. And really exciting to see these new hires, people coming back into the community. And yeah, it's just good stuff, man. This is a good episode. There's a lot of stuff I'm excited about here. Okay, well, for the rest of y'all, thanks for hanging out with us, and we'll see y'all next time.

Taylor Otwell:
See ya.