The Impact of Open Source Companies and Industry Insights - RRU 253

Hey, Welcome to React Roundup, the podcast where we keep you updated on all things React related. This show is sponsored by Raygun and produced by Top and Devs and Onvoid. Top and Devs is very great Top and Devs. We get top and pay and recognition, but working on interesting problems and making meaningful community contributions. An Onvoid which provides remote design and software development services on a task basis, so clients only pay when tasks are delivered and approved.

In today's episode, we have a very special guest which is Max Steiber, the CEO and co founder of Stalt and you might know him as the creator of Styled components. So we're going to have a very interesting show about his projects and his career progression from being a contributor as a developer to the role

that he feels currently. My name is Lucas Paganini. I'm your host in the podcast, and joining me in today's episode are also the amazing hosts Chris Bruen, Hello everyone, Peter Osa, Hi everyone, And just to give an opportunity to introduce himself, here is Max Steiber. Thank you for the beautiful injury, Lucas. That was great. I think for people that are

listening in that might have been in the React ecosystem for a while. I co created way back when in twenty fourteen fifteen ish when React with Press release React boilerplates, which at the time was maybe the best way to manage whippak.

This is now ancient technology because afterwards, very quickly people realized that that was boilerplates were maybe not the best way to do that, and create React that came around, and later of course Nick Chase and Gatsby and all these meta frameworks and remix of course, and then as part of that also later on I co created stock components, which is a CSS and j's library that got very widely adopted because it moved see this as closer to the components.

So for people that have been in the reacting ecosystem for a while, you might have heard of some of these, you might have even used some of these. Uh, and later on a transition to founding a startup in the graphical space called Stillates. So happy to talk about any and all of those things today. Nice, Well, let's get started, So why don't you give us a little bit of history and context, Like I'm sure that if

I just say, let's go from the beginning. Then I'm not sure if ye five hours here, but I'm thinking perhaps, like most people are gonna at least most people listening to this episode are probably going to know you as the creator of stock components, just because it's so widely adopted in the React

community. And well, we're talking about React developers here, so perhaps we could start with that, and well, why did you created this library, and how the process of like this in itself was kind of a successful business, right like, not necessarily bringing you money, but it was a product that you created and you needed it to create traction. So there were many different solutions for the same problem that style Components was solving, and for some

reason, the most of the developers preferred your solution. And I wonder if this was entirely organic or if there were any more directed and strategic steps from your part to make this library successful. Yeah. Style Components came to be because I was working at a company and we were building a sort of usable component library called elementally Wife, and as part of that, we wanted to publish this component library to impment I have other people be able to use it.

Right This is, you know, sort of an internal science system we wanted external people to be able to use. But very quickly back in those days, we started to realize that there was no very consistent way of distributing CSS with the component library because ultimately what people mostly did in those days is they used webpac and configured it to publish CSS modules right, which required setting

up a webpac loader correctly with all these options. But the problem is if our users of these component library didn't use CSS modules, suddenly they had to add this webpac configuration and it messed up all of the rest of their CSS right. If they were doing CSS in another way, suddenly they had this extra webpac loader that would conflict with the way that they were doing CSS, and they would just break everything. And so basically the component library essentially wasn't

really reusable outside of our specific use case. And so that was the initial problem that we started with. And I met Glenn Maddon, who's the co creator of CSS modules and then co created style Components with me, and we started talking about this problem and we realized that there'd been this at a time recent new innovation around moving CSS into javascripts. Particularly GSS was one of the

first library to do this really and bring this popularity. And the thing that we didn't like about all the existing libraries at that point is that they forced you to write CSS as JavaScript objects, not Jason, but like as objects in javascripts. Right, And we love CSS and we still do love CSS, and the problem with moving it into objects and what most of these libraries did attach it as in line styles is that you lose a lot of the

CSS power. Right. You couldn't do media queries, you couldn't do harverd states alias, a lot of that in JavaScript, and it was sort of a very complex way of doing the thing that the browser can already do with CSS. And so we set out and we were like, hey, what if we build the CSS and GS library that just let you write actual CSS

in your JavaScript file. It sounds slightly ridiculous and preposterous, but actually that might be a really good way of distributing the CSS to people because it would allow us to use all the power CSS while still people who install the component library to not have to worry about whitepack loaders and all that complexity. And very quickly, the other pop part we realized also at the time is that this is you know, very early on in React to evolution. Right.

The style components came out in twenty sixteen, I believe over for twenty sixteen, so this was like two or three years into React being a publicly available on Salt projects. It was very early. And this the other innovation that we saw takes sort of the industry, or the pattern that we saw take the industry by steam, was this concept of having style components, having a

component called a column, having a component called a row. And often these components didn't do much other than render a div or a span and attach a class name. Right, a column component doesn't really have to do much more than that, But that became a really popular pattern in the React world because

just feels really nice to use, right. And so then the other innovation that we coupled with having leading you write actual CSS in JavaScript is that we let you write actual cess in JavaScript, but rather than having you deal with class names, you had to create a component. For every single sort of style that you create, you had to encapsulate it in a component like a

column, like a row, like a button. And Glenn and I played around with a bunch of different apies and ended up with this sort of styled dotative and then a hacked tempered literal API that allowed you to write literal CSS syntax in your jiascript file. And that was extremely controversial, of course, because you're now mixing two programming languages in one file, similar to what React had done with HTML by moving into jivascript. We did this very similar thing

with CSS. We moved it into JavaScript and into components, and half of half of the industry hated us. I got so much vitrio for when when we announced ole components, because people were like, how can you put CSS in jolskip? That is ridiculous. That is the stupidest thing I've ever heard. The browser is different, it's a different thing. The browsers up to Master for having that as a separate file, like, why messed with that?

You're just you're just making it worse. And the other half of the audience actually tried it and went, holy smokes, this feels so much better to use than any other way I've ever written cess because I don't have to worry about the stupid cascade anymore. I don't have to worry about class names clashing over anymore. I immediately confined the CSS that that's affecting my component.

I don't have to go dig through some CSS file fifty files down. And so it turns out that that half of the audience was actually the one. The one that tried it turned out to be like, hey, I love this. I have some performance problems with it, you know, I'm missing some APIs to handle these edge cases, but overall, I love it and I want to make this a thing. And so it ended up growing really

quickly. And to go back to that sort of the quick summary of that story that to go back to your question of what we did that made it grow, I think it's really two things that helped stock components become very popular.

One or three things, I should say. The two things that we had controlled over were one, we focused very heavily on making it feel really nice to use, and in fact, often the initial response that people had was like, this is stupid, and then I would always just say go try it, just go build like a component with it, and inevitably, I think one hundred percent of the time people tried it and it went well, actually it's kind of stupid, but it feels really nice. I actually

like using this thing, you know. And then the other thing that we feel that we really focused heavily on that. I think a lot of people in the open source space miss. A lot of developers in the open source space miss is that before we released it, I probably spent twenty percent of

my time writing code and eighty percent of my time writing documentation. We shipped with an immense set of documentation comparatively to how much to how long we worked on the code, because I knew that if people, even if it feels nice us and it's somewhat intuitive, right, if people get stuck, they're not going to want to use it. Right. So we needed to have the documentation to support people actually doing most of the common things that they needed

to do. And we got to, you know, eighty ninety percent of covering what people needed to do. And then the other thing I always say is when you're building something new, focus on making it work fast. Then make it right, and then make it fast. Any other way doesn't work because you have to make it work fast and ship it and ship it fast

because then you get feedback. Right immediately, we got feedback from people that was like, hey, I need these global styles right, this component thing is great, but I have this one, you know, I want to inject normalized CSS through stock components as well. I have some of these global slasts that I just need, so we needed to add an API for that. And there's many examples, like theming people were like, well, I

need a slightly different theming APN. The way theming work doesn't really make sense to me, Like I have this use case, can you support it? And so through that feedback first making it work, then we were able to make it right right because we got the feedback, because we've got people to come back to us, we were able to iterate on the library and add APIs and a trade on the APIs that we had shipped initially to make it

a really solid, complete experience. And then finally once it was right, once we knew we had APIs that were stable and we were pretty complete, then we could focus on making it fast. Right. But if we had made the old APIs fast, we would have wasted a whole bunch of time because they turned out to be the wrong APIs in the first place, and so would have just been a pure waste of time. So always make it work, make it right, make it fast. And then finally, this

is something maybe that is not as easily reproducible. We were just in the right place at the right time. Right the React was gaining immense team and growing really quickly, and everybody that was using React essentially didn't really have a

solution for CSS. Everybody was using global CSSCs as much as came around and was sort of a first solution, but that had problems attached to it that some people didn't want to deal with, and so then stock components became the solutions to those problems and fundamentally just overtook because as we React grew, stock components just kind of grew with it. So we also just got lucky on

the timing. I think is a big part of it that I don't want to just you know, I don't want to be like, oh, yeah, we built a great library and we wrote documentation and then you know, whenever you do that it's going to be success. No, you also have to have good timing and gift to solve a really important problem to people at that time, Right, So there was a lot of timing and luck involved

as well. I really like what you said about the effort put into documentation that is so easy to be overlooked, Like there are so many people out there that simply they have the best solution that exists out there, or at least they think they do, but you just don't know how to use it.

There's just no documentation. Like I am also the host of Adventures in Angler, which is a podcast focused on Angler development, and one particular feature of Angler that I absolutely love is something called contra value assesssor It's a native way inside the Angler framework for you to create components that control an input just like a regular input. So it's a way for you to create components that are meant to be used in forms. And it's brilliant, it's so flexible,

it's so powerful, and it's so undocumented. There is literally no documentation about it in the entire official docks of Angler, Like the only thing that you can see is the actual docs of the API itself, but there's no guide on how to use it, how to extend this functionality. Every article that exists about it is from other creators in the Internet that solve the power

of that feature and create a content about it. And it came to a point where every senior Angler developer knows about this feature, and there's still no mention about the Guides of the Dogs. It's crazy. It's like everybody sees the value in it, but it's just not documented. So I really want to hammer this down. It's so important for any of you that is currently

creating a library or think about creating a library. If you are going to publicly share this library with the open source community, you need good documentation. Like it's just currently, this is a requirement because there are so many other libraries that get this right currently that there's just no space for you to ignore this. But at the same time, there are so many others ignoring it that just by doing this, you're narrowing your competitors so much. So definitely

do that. And if you're doing something internally, it's also interesting to consider just documented just doc generators and just using regular JS docs and TS docs and your functions. You obviously don't need to write an entire getting started for internal libraries, but if you could at least document the main functions and how they should used, like put up some examples in it, that's definitely valuable, not just for open source projects but also for internal projects. So yeah,

excellent, excellent mention. Yeah, but if I may object their firsturself Second, the thing about documentation is that people often think they need to be write down how the library works. But that's actually the part you don't need to write down, because that's the part that doesn't matter. But if you think

about style components, it's a cssn jazz library. So the thing that it does internally that's sort of the difficult and gnarly part of style components and implementing is that it takes the CSS that you write in your dromascript file, it parses it because it's written in actual CSS language, and then it compiles it into sort of handles like tempo literals, injects the props and the theming, compiles it to the set of styles that need to apply to those HTMIL elements,

creates a unique class name, injects it into the style sheet, into the dome, and then also manages the cascade as to how those things relate to each other, particularly as it relates to inheritance style components some inheritance features that requires to manage to cascade in a certain way so that they work the way they should. None of that is documented. If you look at Stetle componentscgmidation doesn't talk about any of that, because the whole point of it is

that you don't have to think about it. Right. The whole point is you just write your sees as in jovskip, and we figure out how to get it to the right place and get to the result that you expect based on the API. Right, the whole point is you don't have to care about it. If we've written documentation that was like here's how style components work, here's how it injects nobody, that's the least interesting part of the documentation.

Right. That is valuable in its own right in terms of, like, you know, documenting the architecture, getting contributors, blah blah blah blah. But that is a different purpose, right for users. The whole point is that that is abstracted the way. The whole punt is that it's an abstraction where you don't have to think about any of that. You can write a certain code where you expect a certain result, and the library make sure that the result that you get is the result that you expect, and that

is the part that you need document. Then is the use case and the examples and how do I actually use this to achieve the goal that I have. If I want to make a theme from my app where it can quickly switch between different colors and make it user customized, well, how do I add that to my app? Right? If I want to inject global styles because I need normal I CSS, how do I do that with style components? Right? How do I make a button that's which is color when it

changes variant? Right? All these things are the things that be documented is how do you use the library? And in fact a lot of it was actually just documenting CSS features. A lot of it is like how do I do media cares? You write a freaking media crery, you know what I mean? Like it we didn't implement anything for media carerise, you know, like we didn't implement media cares in the or however selectors in CSS, that's

not what we do at all. We just partial CSS and injected. But from a user's perspective, right, when they come to the documentation, what do they want to get done? They want to create a media career, right, they got to create some mobile staff. They want to add a horverer style because their buttons has as a hover style. They want to create a variant of a button that has different colors. Or a different outline.

That's what they care about doing, and so that's what the documentation focuses about. It's not perfect, but fundamentally, think about not how does your library work and what does it do, because that's the part that shouldn't matter. It's what is your user trying to do? And how can you help them achieve that more quickly through the documentation? How can you help them achieve their

goal? And that goal is hopefully not to learn about how style comportis SOCSs injection right, because otherwise you've done something wrong with your library right and it's not abstracted enough. That is a great point. There's a great point. I definitely saw some libraries explaining their internals and I always keep that part because I'm like, I really don't care. I would much rather if you just put some benchmarks so that I can see that it is performing. That would

be a lot more interesting to me. But yes, great points. Let's keep on with the story. Alimax, So cool. Now you created this library, It got a lot of traction. Currently, are you still maintaining it or do you have other people maintaining it? Do those other developers are they in your payroll? Like are people that you hired and you and this is one of their tasks, or did you found a way to over time completely delegate the maintenance of this library to the open source community as a whole.

How is that? Yeah? Great question. So initially Glenna I created the library and then a lot of the step from making it work to making it right is that it's the part that Glenn and I focused on building the right API is building the right abstractions, making sure that people could do and achieve the goals that they wanted to achieve with the libry, making sure that

the result was what they expected. And then over time other contributors on board onto the code base because they were using it, they were loving it, then they wanted to help make it better right and their own ideas of what that means specifically feel even there's a few people that have really contributed the majority,

even in particular. Eventually, then later on took over maintenance completely and did a lot of work on making it fast and sort of like improving the performance of it over time by optimizing it for the way the browsers parts childscript and the execute jilescript and so over time, my expertise and Glenn's expertise, which is I don't want to speak for Glenn, but my expertise for sure is around the developer experience, right, and how something can feel and be

as intuitive as possible. And then I'm not an expert on joscript engine performance, right, I'm not an expert on how do I optimize this JavaScript code to run this efficiently as possible. I'm not an expert on how do I inject this thesis in the most efficient way possible. And that was a lot of the work that happened later as the library gain steam. People were like, hey, look, performance is one of our concerns, and in fact, for people that were around back then, emotion was a big driver of

that. Emotion came around and was like, hey, we implemented style components, but it's two times faster, and we were like, wait, what are they doing differently? But that is possible, and a lot of it was STARSCIN engine organizations and then also more efficient way of injecting cuisis and that kick started a whole sort of like spur of energy around hey how can I

make style components faster? And in fact, eventually style components ended up getting faster than Emotion ended up getting faster than stal Components ended up getting faster to where now performance doesn't matter anymore because all the libraries are so fast, and that's a lot of the work that even and Phil ended up doing, and they've completely taken over maintenance. I don't think I've written if you look at the contributed graph, I don't think I've written a line of code for style

components since maybe twenty eighteen, twenty nineteen. I want to say it's been a long time. And in fact the library also ended up being very stable. Right once we had figured out the APIs and sort of like what is the API that we want to present and what is the result that people expect

from that API? There isn't that much more to do. We had to you know, there were bugs to fix, and there were you know, certain edge cases to iron out, and again performance was a big, big focus, and eventually it was just stable, like it just worked for people,

right. People didn't really run into problems anymore. It was fast, it had all the APIs that people needed, and so the maintenance went over into really largely Evans hands, Evan Jacob's on the score probably up on X on Twitter really took over a lot of the sort of like long term maintenance over the last five years, and it's been the main person sort of like fixing all these small bugs, making improvements to the code base, making it

even faster, making it or maintainable, and really pushing a lot of that forward, while I ended up going and doing lots of other things. So it's really in the open source community's hands. It also never became or we never tried to make it a business like it's very much an open source project that would just shipped because we thought the world needed it. That we never

really made any money. There's an open collective that I think over the course of the last eight years has collected maybe ten thousand dollars or something to that in order of magnitude that we never even spent. It was very much like we just want the open source community to have this, and so nobody was really ever paid to maintain it. I think there was once a bug bond that we want to fix and we want to send somebody to a conference,

and that was the extent of it. We never really paid anybody for it. It really was very much a community thing and sort of like ended up shifting out of my hands and to people who knew more about the problems that we were facing later on. I think most interestingly, the thing that I live and try to live a free data is that it is that I default to open. And what I mean by that is I default it being open to new experiences and new opportunities and sort of like external input and external feedback.

And one of the ways that showed in my stories that after after we released start Components, this person that I had known from online Bring Jackson, pinned me via Twitter and was like, Hey, we've been using stock components to build this new product, but we're running into this weird bug. How can we fix it? And I just replied, I was like, hey, let me just go look at your copase, I actually don't know why this bug you're hitting, Like, I don't have enough context. Just give

me the copies and I'll take a look at the code. And ended up looking at the code and that what they were building. The park they were building was called Spectrum and was a community platform for their podcast network. And I looked at it and I was like, wait, hold on, I need this for my open source communities. I need a place for them to go because at the time Slack had just sort of kicked out all the communities. Kitter was a thing, but it was sort of shitty excuse me for

people that worked on Gether, it just not a good experience. There was no real place for open source communities to hang out. And so I ended up talking to Brindan Bryan, the two people who built Spectrum, and I was like, Hey, I want to go do this with you, and I ended up co founding that startup together with them, and we built this community platform for developers that was eventually two years later acquired by kits up and

turned into kits to Discussions, right. But that came to be ostensibly through style Components and my work on style Components, but really came to be because I was open to new opportunities and I was open to helping people, and I was open to connecting with people through that experience of having created this library,

and that kickstarted a lot of my career. That's amazing. So in a way, you were like the designer of the project, and then after you designed it and you made sure that it was what the audience wanted, it was aligned with their expectations and the best experience possible. Then it's almost like you handed this design to the engineers that would maintain it. Right, of course you actually implemented it, but just to make an analogy between design

and development, it was pretty much it. That's an interesting position to be in because I think a lot of people think about projects in a way that they have to code it, they have to architect it, implement it, and maintain And it's always good to take a step back and realize that there

are actually spaces available for every different type of professional. So you can definitely be the type of person that enjoys a lot more the architecture in structuring the project and designing the APIs and then kind of leaving the maintenance and the rest of the implementation to other engineers that might prefer that better and other people that we want to refactor this endlessly to make it to extract as much performance,

juice and broader compatibility as possible. So really interesting to also keep in mind that this is a possibility for people. But yeah, let's keep on with the with the storyline because I'm interested in how we're now getting into your entrepreneurial opportunities. Right, So you became the confounder of Spectrum, and when did you, like, did you ever left this position? You left that after

it was bought by GitHub. How did it came to be for you to be the founder of Spectrum up until the point where you are now the CEO and co founder? Off stallied, so we Spectrum. Let me we start where I left off with Spectrum. We built a product that worked well for the purposes it served, and then eventually get Up acquired and turned it into get the Discussions to help open source communities talk about things other than issues right,

which was really previously the only main conversation piece on gitub. After I left Kidsup, eventually I joined Gatsby, the static site generator startup that built

this framework based around Graphkill that helped people build static websites with Gatsby. Sorry, with React and graphkill and really broad The main innovation to mean in Gatsby at the time was really the graphicilled data layer, where you could use the data lader that could very easily tie in lots of data sources from your CMSs, from a databasis, from whatever other systems you're using into one graph and

then allow you to build static sites with that graph. Very very easily, and I came to against me because I was working on some of their more future looking sort of visual editing experiments. We did a lot of work around how could you build a visual editing system that is that generically solves the problem

of editing REACT components. Right, So we had first versions of something COMPLEXI that allow you to literally go into your browser, click on a component and change a prop and it would propagate back to your code base from there, like you literally visually edit code. You could move components around and it move it around in the in the jsex stuff like that. We never ended up getting that production ready because there's a lot of complexity to editing codes visually.

That's not a very simple problem to solve, and trying to solve the sort of biggest scope of that, which is you can edit anything, it's very

very difficult. And in fact, it turns out that probably better approaches are more similar to Framer or web Studio if you've seen those things, where you have a more constrained approach where you get to use these pre po components and you get to move them around, but fundamentally that eventually generates code that you can deploy but it's not a two way sinc right, it's not a back

and forth street. You can at your own costom components, but it's not like framers editing your code base, right, because that part is really really difficult. To have humans be able to edit the code base and have a system for visual editing edit your code base just proved to be an immensely difficult problem. We never actually got it to work reliably enough to ship to production

and make a product out of it. And then through working on Spectrum, where we're using Graphicill really heavily and gets up where I was using their graphically

and then gas PEP, which obviously was based around Graphkill. I had been in the graphicill space for many, many years, and then back in twenty twenty one, I realized that at Spectrum one of our core problems was grow that we were growing really quickly, but our infrastructure couldn't keep up with the growth that we had because I chosen a database reading dB that just wasn't mature enough to really scale to the scale that we're ad and so we were using

graphkill and we had, you know, a use case where lots of our data was public and rehavy, and so my immediate thought was, let me just put a cash in front of our graphical API, because ninety percent of our traffic is re traffic, that traffic never actually has to hit our infrastructure, right that that doesn't have to put load on our database. But nothing existed. So I ended up building a cashing system internally that was, you know, a first MVP, but wasn't nearly as powerful as I thought a

graphical caching system could be. Because graphicill because of the unique ways that it's works, which'm happy to talk about too, allows you to do really really smart caching if you can do it right right, and graphical clients actually end up doing a lot of that. And so I ended up taking that meeting my co founder Tim, and he had actually built a prototype of a first graphical hitch cash that runs at the CDN level, and we made a company

out of that that's not called Stelly. And so for the last three years I've really been on this journey of co funding this company and then transitioning built the initial product, of course, but then also transitioning out and transitioning to being a CEO leading a team of now fourteen people and and sort of like all the complexities that come with being a founder and building a team that are very different problem sets and very different and require very different growth than what it

took to be an engineer and what it took to build you know, large open source projects and other products. And so that's that's really been my journey with the last you know whatever eight years, going from hey, I'm an engineer, I build open source projects, I build products. So now running a whole organization and leading a team to hopefully success, which is just requires a very different skill set. And so that's been a lot of the journey

of the last three years, specifically with still It. It's both the graphicill part and sort of like building the best product that we can to help people operate their graphic COALPI and then also building an actual company from scratch and team from scratch, you know, and all the complexities that come with that.

Awesome. Awesome. I have several questions, the first one being not directly related to your story per se, but well, directly related to your story but not directly about you, which is when you were working at Gatsby, did you got to meet Josh Camillo. I never met him in person. But oh, actually no, I think made even in person in one of our off sides, and I spoke with him a bunch of times internally of course. Yeah, oh gotcha. Yeah, just mentioning that because he is

definitely one of my top ten content creators out there. I really enjoy the quality of his content is really really really good, really simple too. So it almost feels like everyone that I see that had a background and gets be are excellent developers. It seems like you guys all came from all got together

at that point. That's kind of interesting. Yeah, And I'm also curious about gets be itself, like just just from a pure curiosity because gats be is well, I'm not sure how stellid is with regards to open source, but gets me itself is an open source solution that has a company behind it

and actually generates money and pays employees. So, since we're talking about entrepreneurial spirit here, how do you see tech startups that are trying to create profitable model based on open source technology, Because I, for one think it's probably way more challenging than just having a closed sourced system. Like I'm well, maybe there's pros and cons right there, is a lot more traction because you have more people that get to know your product because they can just get started

for free. But at the same time, if they can get started for free, and most of it can be done for free, then how hard it is to actually convert them into paying becausts the merge right. So, I'm not sure if stell it also has an open sourced version of it, but if so, perhaps you could even bridge get to the install it and tell us how do you see those types of business models? I think it's a very interesting question that a lot of people in the industry are battling with

right now. Because during the zero interest rate phase of the world, where money was sort of free in many regards and there was a lot of investment and there was a lot of money to spend on lots of different things, that business model was more tenable than it is in twenty twenty three and twenty twenty four, because there just isn't the same amount of money anywhere right not to buy things, not to hire people, not to do much of anything

right, And in truth, pulling off an open source business model to me is in many ways more difficult than just building a business because already. Just building a business that provides value and makes money is an immensely difficult task that most people fail at. Right. It is unbelievably challenging to do that in the digital space, particularly because in the digital space everything is global. Right.

If I'm building a local bakery, assuming you have a good you know, I can find a good location with the rent that makes sense, and I can find suppliers that charge money that allows me to have a margin that allows me to pay my employees. It's very difficult to build a local business, and you're only competing with other local businesses. Right, you only have to be better than the big career around the door. You only have to

have a better location than the calf coffee shop around the corner. In the digital world, you're competing with the whole world. Right. If you ship a product, if you're colendly, you're now a large company that shipped the product. Suddenly, Savig Call and cal dot com are like, Hey, what if we built the same thing, but we made it nicer, or we made it more specific to certain use cases and made it work better for

certain us cases. You're literally competing with the whole world, and so building a digital business, I think is often peddled online as something that's easier, and in some ways it is. Right. In some ways, the friction is lower than building a physical business. There's less overhead, there's less initial costs. You often have immense margins because your cost of actually, you know, having a lot of customer essentially zero. Right. If somebody buys a

croissant, you still have to pay for the for that croissant. If you have software, you can sell it a million times and it doesn't cost you anything anything anymore. Right, there's no extra cost to selling software outside obviously the sales of it and whatever. But but largely your margin's going to be insane. Right, So in some ways it's easier, but in other ways

it's harder because you're competing with the whole world. And I think a lot of businesses think they can or a lot of the difficulty with building a business around open source is that it becomes very difficult to assess what goes into open source and what is paid, and you sort of a very slippery slope if you're looking to get more revenue to move features into the paid offering that you have that really should be in the open source world, and actually that was

a lot of what Gatsby ran into even before I was there. This is I have no internal information on this, but a lot of the sentiment around Gatsby was, hey, GASB's builds are slow, right, I have a static website with a thousand pages within thousand pages, and my site every time

make an update takes four hours to build. And so Gatsby really gats be Cloud, which was a Gasby specific hosting service that in some ways just understood gaspe really well and the data layer really well and could very efficiently do rebuilds of only the pages, incremental builds of only the stuff that actually needs to be updated. They kept track of data depends on all that stuff, which is awesome, and that was a paid thing that gats Be charged for.

But then externally, the sentiment was, well, you just made me use an open source projects and the static site generator that is slow, and then you're selling me it being fast. But why is it slow in the first place? Why can't that be Why can't the open source project just be fast

and you offer me hosting? Right? That was often the tension that people felt with that business model, and that's very difficult to execute on the counter example, and I think the shining star of a company that has done this well is Verssell, who've built next years and they have a very clear sort of differentiation between what nixt Chios does, and they make nextchures the open source version or the open source project as good as they humanly can, and then

rosell is the platform where people host it, and through that they get you know, pre deployments and you know, great infrastructure and edgewares and all this all these features that they want that require infrastructure that you cannot have in an open source project, right, And so suddenly they've sort of drawn that line in a beautiful way where the community loves what they're doing with mixture is.

And then a lot of them also end up deploying on ver Cel, which is great for Versil because obviously they're also a business and they need to make money. But Versale to me is an outlier. Right. There's Resale, there's hashally Corp. There's a few other companies that do this, but most companies that do this fail and it's because it's really really difficult to figure out that distinction. And then also you're immediately sp splitting your company in half.

Again, it's really difficult to build a viable business online. That's not an easy tasks. It's a monumental challenge that people I think underestimate that I certainly underestimate it. It's really freaking difficult. And suddenly you're having to build a business, and then you're also having to build an open source project. Right is that is an immense amount of work that you suddenly have to do with a small new company that has very few resources, right, that has to

move really quickly. That's just that's a Mount Everest to climb, you know, And that's why I think so few people ever managed actually climb that Mount Everest. It's just because it's freaking difficult, right. It seems simple, but it's it is immensely difficult to execute upon. And so I have a lot of respect for people that try that and that pull it off, like Briceille, and I have a lot of respect for people to try it and

don't pull it off. I think that they amount equally much respect because it is a really difficult challenge. Stelle, it's specifically we're not open source. We are a graph col CDN. As a way you could think about it, and so we're based around graph Kill, which is open source up within.

Lots of people use Graphkill without stell it, but then once they hit certain scaling problems, once they have performance problems, once they have too high infrastutional costs, once they need better observability, then they put stell it in front of their graphical EPI, which is sort of, you know, just our product, and they get edge caching performance benefits through that, and metrics and security through using our product. But our product itself is not open source

at all. It's only a paid offering. And in fact, you could argue that stell It itself doesn't really have an open source offering because we're just based around around the framework of Graphkill. And sure, we contribute to GRAPHICI and we build graphical clients and we help graphical and you know, we do a lot of open source work, but it's actually kind of unrelated to our business. Our business is really a product that's faith that's built around graftkilling.

We are not I would not describe Stalite as an open source company, even though we're sort of open source adjacent maybe, but really we're not an open source company. We're really just a business that makes the product that we sell to customers. Yeah, that was a long tigent answer to your original question. I hope that that makes sense. It did, So what you said is basically that the companies that well, at least the ones that you saw

executing this model really well are the ones that separated the products. So Versull, for example, has different products and one of them is fully paid or well, actually they do have a free tier, but it's it's closed source and it's meant to be paid, and the other is open sourced and it is meant to be fully open sourced and fully free and fully owned and used by the community. That's interesting. Have you seen other companies that are like

you mentioned call Con. I think that's a good example of a company that is open sourced, but they are generating profits or not sure if profits, but they're generating money at least, And maybe that is because they are positioning themselves directly against a competitor that has already established himself as a fully paid solution. Right, so call Con even publicly positions themselves as an alternative to Calendly

that is also open source. So if you are already a user of Calendly, you already have this previous expectation that is going to be this way. Also, it's just so much harder for you to It's so much easier for you to just click on a bottom and create a cloud account than it is for you to actually host the entire thing on your own services. Even if you can just get a droplet on Digital Ocean and put it up and running, it's still a little bit more effort and you actually have to maintain it.

It's different from a technology that you're going to introduce in your code base, and you're already going to have to maintain your code base anyways, so it's not like you're adding too much of a burden in terms of maintenance. But call Con, for example, it's a full standalone product that if you were to integrate it, it would probably be via API calls directly to a hosted instance, which is completely different from just an open sourced library that you're

going to integrate in a larger code base that is proprietarily yours. So I think that's also one difference in that. So we have here examples of companies that did by completely separating the products. We have an example of a company that got it right by having a single product that is open sourced, but it is a standalone it's a standalone product. Now just open source code bases that also have a paid version, and they are meant to be used within

your proprietary cobase. I can literally only think of one which I think is very very clever, and it is boo MQ. It's a library for you to connect to a read this instance and generate an asynchronous Q so you can just use it to create micro services. And what they did is they created a fully free, open source version of the library, and they created a

pro version that requires a lice sense. But the pro version has a few advanced features that are particularly interesting for companies that want to extract a little bit more from their cues. So for example, they have groups, so you can't have grouped queues in the free version. You need to pay to get that. So that it's like you're you literally have a plan, right, you have the free plan, and then you have the problem, and the

problem is not open sourced at all. And we're not talking about making it faster. We're talking about not having something and now you have it. So perhaps that's one difference from Gatsbee. It's not making it. It's not a feature that is just about making it faster. It's about adding support for one way of doing things that were simply not possible in the free version. I sort of have a hot take on businesses like Carlocom, which is I think

they're successful despite being opened not because they're open source. My guess is that because there's a whole swath of these products now, like cal dot com, like documents o, which is a document alternative that's open source, a lot of people are trying to be you know, I'm going to build this product that's really successful, but I'm going to make it open source. In truth though, where I think maybe prefaces that has some advantages, right, It

comes with great marketing, particularly you know indie hackers and software engineers. We love these open source products. We can look at the code base. It feels cool to use, like it's nice that it's open source. It's awesome.

It has some marketing benefits. It also has some benefits in terms of like making it easier to sell that solution into governments, into healthcare, into these industries where there's a lot of security and data requirements that are hard to meet otherwise if you're a proprietary product, but if you have a source open

source, then it might be easier to get into those industries. I think the sort of the thing that I'm not sure about is how often do this end these use kids in there paying you because there's self if they're just self forcing it on their government cloud infrastructure, how do you make money of that? Right? Like, I don't really see how what benefits there, but

I don't know if enough context. But I think the downside is actually like you don't have a competitive advantage compared to your competitors outside of those specific use cases. Because fundamentally, if cal dot com is open source but a shitty

version of Calendle, people are still going to be using Clendly. Right, the product has to be better than what other competitors can offer in order for you to win in the market the open Like making a shitty version of cleanly making it open source in no way, shape or form is going to help you win the market. There's no way that you're going to win a lot of revenue through that approach, Right, you have to build a better product

than Clendly. Now, the other part of that is building a better product than a than a large established competitor. In some ways is easier. In some ways, it's really hard. And one of the ways that it's really hard is that you have to be the Only way that I see companies that win at sort of like taking over niches of from established competitors is that they choose niches. They choose a use case and audience a persona that is very

specific where Clendly works for everybody. And then Savikaal came around was like, hey, we're for people that want Calendi, but it looks nice, right. That was sort of the initial framing that they had, Right, It's like, it works nice, it integrates your calendar that they use. Experience as great for both you and for people that schedule links. So if you don't want to look shitty like calend lye, go use us, then you

will have a better impression with the people that you schedule meetings with. That was sort of the initial pitch. Now it's shifted a little bit. That was the initial pitch, and that was the initial wedge into the market. Whether or not Savocal is open source doesn't matter to that pitch. It's completely

irrelevant. They could have attached and were open source at the end, and it wouldn't have mattered, right, because today what mattered was they chose a persona which is design oriented people that like good use experience, and they were like, hey, Calendly, it sucks in this way. We're gonna build a version of clently that works great in this way. And the other part of that is too. If you're doing that, you have to let go

of a lot of the other stuff that Calendly does. Right, Calenly doesn't have a shitty user experience and looks ugly because they want to look ugly. They have a shitty user experience and they look ugly because they realized that for their business, it's more important to focus on other things, right, because everybody has constrained resources, and so for Klendle, it was more important to build SoC two compliance. It was more important to build data compliance. It

was more important for them to build global deployments. It was more important for them to build and single sign on because that is their audience, right, And so they just realized the researchers are better spent. I have no internal context on Calendia and making this up, but I'm assuming they realize their internal means are better spent on all these enterprise features then on making the user experience

better because the market for the enterprise features was just so much larger. And SAVIACL came around and was like, well, we're just gonna ignore all the enterprise stuff. We're only going to focus on us experience. We're gonna take this niche, We're gonna take the slice of your market away from you. We're gonna take over that that that specific wedge, and we're gonna win in the market. But for that persona that way, the fact that CalCon Com

is open source is not helping them win. It doesn't matter right If again, if it was a worse product, people would still be choosing Saviaca or Cleanly, but calum Come in some way is better. Now. The big downsid of being open source is that suddenly you have a lot of people contributing a lot of crap. Excuse my language, if if any of you have ever contributed or run a large open source projects, the amount of terrible contributions

that people propose are immense. The amount of issues that you get that are complete crap is immense. Like it is a lot of work to manage large open source projects in large parts because a lot of people think they can grow their career through contributing to open source, which is great and it's true, and then they just submit bullshit contributions so that they can say they contributed to Notches or to react or to whatever. Right, that is a very common

pattern that is very frustrating for source mantainers. Now, for Caldacom, that means that I'm sure they're spending a lot of resources on managing their issues, on managing their pre requests, and managing external contributors, on submitting bounties, on giving feedback, and then in turn, though, they also have to be very strict about saying no, because I'm sure what's happening is that a lot of people are submitting contributions for their use cases, for their thing that

they need from Caldocom. What in turn means though that Caldacom's feature said is just going to explode and be everything for nobody, right, They're just going to end up being if they're not careful, They're just going to solve all the problems for no specific audience, for no specific persona, and then in the end they're going to be a worse product right, So they have to spend a lot more time on actually product managing the contributions that external people are

making who have no idea what Caldacom is doing right, many of them won't have the time or resources or in interest to dig into you know, calocom's persona definition and what is the audience that that and what is the product roode map, and how do these features align with their product comap and why do they want to have these features and how do they think about their producthilosophy.

If all of that's very clearly defined and documented, then maybe, But even just documenting all of that and defining all of that is a lot of effort, right And so to me, looking at cal do com, if they win in the market, the reason they will win in the market is not because they're open source. To me, the reason they're going to win in the market is despite them being open source almost at best. I think it's a neutral thing that they can do when it gives them some marketing. But

I don't see a world in which they win because they're open source. Now, I would love for pere Rich to come around and tell me I'm completely wrong, and I'm it and I'm completely missing the point. That will be awesome, But in my view, I don't understand why they would win in

the market because they're open source. That's me just not a thing. And so I think, to go back to your differentiation, there's businesses built around open source libraries and frameworks like versus Nextture is like gads peoples around gats speachres the framework, and there's a few old examples of this. And then there's a category of businesses that open source the whole product, right, gidlab being

the most famous large scale one. But again gidlab, maybe if they, like if they had built a better version of kid up, maybe they would have won in the market they lost. Kidsub clearly took over, at least in the open source world. Right, they're the predominant COT solding platform on the platform in the world. I don't know what the specific distribution of of like market share is, but there's no way the good lab has even closer

the same market share the gidub does. If they had built a better product and gets up, maybe they would have won. Then being open source, they didn't win, you know, you know what I mean, Like, they didn't even win the open source community. By being open sourced. All of the open source stuff happens on gidsub. I don't want to know this, I don't know the statistic, but I'm one hundred percent certain that ninety ninety five percent of open source packages on MPM are hosted on gid ub,

not on good lab. Good lab itself. The product is open source, and nobody cares. Right, they built the worst product and they didn't win. Like for that category of business, you just have to build a better product. That's all that ultimately matters to me. Whether or not your open source is sort of an implementation detail and maybe a marketing thing, but it doesn't make the big difference in you winning in the market or not outside of

maybe you know, government, health care and all that stuff. But I yeah, see it, and so to me, the true open source businesses are the ones that are building around an open source framework and whose success is attached to the success of that open source framework. That is, to me, a true open source business, not unlike some you know, I don't care if you callage if an open source business or not. But to me, the riskier thing is versell basing their whole business on their freaking next Chress

framework. If next Chus stops working, versill has a huge problem. Right. If cal dot com skits have been put us stops getting stars, it doesn't matter. If they built a better product, people will still buy, you know, it doesn't. It's completely irrelevant to the success of their business. To Versel though, if people stop using next Chress and start adopting something else that is better deployed somewhere else, holy smokes, that is a huge

risk to their business. You know, same thing with gasps because gats we stop getting a lot of adoption in the market. Gas pick Out only had a very limited market to sell to, and so the revenue potential wasn't there, right fundamentally because more people started using next Chress for various reasons that I'm happy to talk about. But like, that is a core risk to your business on me for cal dot com, for kid lab, I don't know,

people look at their open source core is completely irrelevant. The thing that matters is have they built a better product? Sorry for the right, That was a whole take that I that I've been sitting on for a while, but so apologies for the ten but I just don't see it nor is nower Is. I definitely appreciate it. It's always good to listen to the opinions

of other people that have been thinking about this for a while. It's really interesting to think about, Like you said, Calcom is gaining traction despite being open source, right. I think that I disagree with this in parts,

just in the specific case of Calcom. I'm not generalizing it, but for Calcom specifically, I believe that they did got a lot of traction, and still most of the traction that they have are developers that just thought it was nice that they were doing it open source and got interested and decided to use it because of that. But it's just a branding and marketing positioning. It's

not really an operational advantage, as you were saying. They probably spend a lot more time trimming down and filtering the work that their open source contributors are doing then actually directing the product and the company to where they would like it to go. And there's also so much more exposure for everything that they do, Like there are so many downsides, but at the same time, this level of visibility I think created a very specific brand for them that made other

developers resonate with their mission. It's almost as if people are using call call not because it is better than the alternatives, but because they emotionally like what they are trying to do. So I do think that they are growing because of them being open source, not despite of it. But I also think that this is going to eventually become a problem because unless their target audience is only developers or very tax savy people that care about the open source community,

then at some point they're going to have to consider closing the source. And this is if that happens, it's going to generate so much frustration. I remember there was this company that had open source designs for three D printers. I think it was Maker Bought, I don't know, it was something like that. I don't know if you guys recall it. But they had a three D printer and they had all the all the project information, how you

can build it, how the software. Everything was open sourced and anyone could build on top of it. And then they started actually having competitors that were building products based on their specifications, and the competitors were just closed source. Right. It's it's just like open AI. At some point it's gonna buy you, you know, Okay, where we have this mission of making AI open and now you just have a company that is called open ai, but

there's there's no open model in it. So at some point it becomes a communication problem because you keep getting reminded of how you got to the point that you got, like how you you found your initial product market fit, and then suddenly, at some point you decide to turn around something that was so core in your positioning, in your messaging, in your brand, and it definitely hurts, and it hurts kind of forever because that was how it started

and then it changes. So also curious, like do you have any takes on companies that start open source and then eventually become closers. I think this goes back to what I was talking about earlier, and then sort of like one of my main learnings over the last three years of being a co founder and a CEO and and sort of transitioning from an engineering role building a business

that makes money really freaking difficult. It is extremely hard to do that, and in many ways for these companies at scale, like even recently Radis Labs right realized that their business was a risk of just flatly dying because the other companies were taking the open source projects that they invested so much money into and that hosted it and made a better hosting version of rais labs, which makes total sense, right if you just think about it from like a purely logical

sense. Raddis lab has invest in number of resources to make reddis grade, and then they can only invest you know, X number of resources to make reddist labs the hosting grade. Everybody else can ignore the in part they don't have to make retis grades because riz labs is doing that. They can invest in plus x the whole resources just to make the hosting grade, and so inevitably and totally logically speaking, they are hosting will be better than reddis Labs.

Right, radist labs has no way of competing because they don't have the same amount of resources. Now this is very simple for of course, truly in a market of more differently, there's you know, many confining factors whatever. I don't want to pretend like the world works in this oversimplified way, but just purely logically speaking, you just end up in a situation as a business where you literally cannot compete. How are you going to do that?

And so in fact, many businesses like Century as well, like like reddist Labs. They're moving to a model where the source is available. Right.

It's a source available model where you can read the source code of the thing and you can use it for non commercial use, but if you want to use it for commercial use especially, and then there's some nuances there where you know, some open source paces are like you can even use it for commercial users in like in your business, you can host it yourself, but you cannot sell a hosted version to somebody else, right, Because often what ended

up happening with these businesses, aws would come around, they would offer they would just take your code, offer a service that paid service of it, and just eat your whole business because everybody uses it bus and they don't want to onboard a new vendor. Right, And that's it again, going back to building a business is freaking hard. That is an existential risk for your

business. That is an existential ways for any business. Right. If ITA suddenly comes around and it's like, oh, thank you for building the green up source portuct, We're just going to offer the same hosting service, you have no way to compete BECAUSEWS has all the customers, so they can just go with all their customers and they can be like word Scale, we can

make this cheaper. It's much easier for you to do because you don't have to onboard a new vendor and your whole business skill goes out of business right like you literally don't have a choice. And so to me, it's unsurprising. It makes a lot of sense to see a lot of these businesses moving to source available licenses that restrict either commercial usage or just making a hosted service out of the thing outside of the business that makes it. It makes the

tonal sense to me. And now with for example, reddis Labs in truth the competition that they're now running into like upstash And if you folks have seen upstash, Upstash just completely re implemented reddits on a completely different architecture that's faster and better and h compatible and in some ways just more modern. And so now reddits Labs has to compete with upstash on who can build the better reddits right and upstash is building really upstash. It just happens to use the reddest

api. But fundamentally they're now competing at that level and they're because they're if they there's a timing question. But if they had made reddis stores available from the start, then they wouldn't even have had to compete with other reddits hosting services. They would only have had to compete with businesses on an even footing where every business has to build the reddest thing itself, right, the actual

storage engine, and then build the hosted service on top of that. Every business would upstairch is competing in that way, and reddis laps is competing in that way. That's a fair under air quotes fight. As far as fights, the market's never fair. But you know what I'm saying, So to

me, that makes a lot of sense. I can totally see why business have to do that, and why even companies that are very, very successful, like Hashikorp, there were recent news that looking to get acquired by another company because they're just running into market issues but being built around these open salt projects, and somebody else can build terraform cloud around Terraform, but doesn't have

to invest the resources into building Terraform. Right again, Hashi Corp. Has invested all these resources into making Vault and Nomad and hot and Terraform and then

build hosting services on top of that, which is great for branding. But then if somebody else comes around and just focuses on the hosted services, they can outcompete them on the product, and people will generally choose the better product in many ways, not always in it that you know, Hashi Cook gets a lot of advantage of being the people that make the thing, and so

people trust them more. Whatever. There's a lot of confounding factors. But probably speaking, if you can make it t an next better Terraform hosting platform because you can invest all your all your resource into making the hosted platform versus making Terraform better, very likely many people will buy you just because you're the better product that they will go O, hey, let me look at I'm using Terraform. Let me look at teroform cloud. But also there's a new

observe vendor that I've heard about that might be better. Oh, actually, there's so much better for our use kids. I'm just gonna pay for them, even though they're not Hashi Court. So I totally get it. I totally get my businesses to do that, and I think it's I think it's the right choice. So I think there's one exception I can think of, and I guess I should also say I'm also still I think we could probably talk about this for hours, like the open source firsut closed source thing.

I'm still I don't know which is better. But a huge exception that I can think of is super Base, right, and I think they even had one of like the world record of if there is such a thing for like seed funding around And I think it depends on the product. Like I agree, if you offer like an open source tool where you can just I don't know, like I'm saying, like MPM install something and that is the product, then you're at high risk that basically someone will just hire a dev and

do whatever they want with your product. Right. They can always go faster than that if you're not, if you're the one who has to fight the triage of issues and all this stuff. But with something like super base, I really think it depends on the nature of what the product is and case

it's if anyone has done this before. It's like a series of Docker images, like you can really recreate their entire cloud offering product on your own instance, but you have to like you have to install like Kong, which is like a more modern engine X, you have to install their their UI container

and anybody who knows like the pain of doing that. I think a lot of companies may even like they may even go so far like, hey, we can you know, we can do the open source version of this, but we need like, I don't know, three weeks, three devs and we have to configure everything. So I think if if companies stay like kind of a should I say, like like crafty with with how they offer their open source tooling. Of course you're always on the edge. Of course you're

always going to have people who will just copy it and reuse it. But I think that's only on the margin. And like for me, like I have a paid like the Mini Superbase instance, just because I don't want to go through the whole thing like the tooling of you know, of doing that. So yeah, I'm only whatever twenty five bucks a month, so I'm not a huge consumer. But I can imagine for larger, much more large corporations, they'd be more than happy to pay for whatever there they have some

enterprise offering. So I don't know, I like I said, I think you could talk about this and argue forever, because I also like the one product that I have that is profitable is closed source. So I'm experimenting right now with the open source. So maybe I'll be eating eating my words in a few months once there's like twenty clones of my product somewhere and I'm not getting any money, so oh boy. Yeah. And well, we are at one hour and in four minutes of show already, so I imagine that

we will soon start wrapping things up. But I really want to give you Max a space for you to talk more about your current company, because I do think that it is not just giving you space to promote yourself just because of that, but because I actually believe it's Zach is very valuable for the audience that is listening to this. So please sell your company to us, Like I do think it's a really great idea, So tell us a little bit more about the problems that you solve and how does it work. Yeah,

thank you. Probably speaking lots of companies, especially at the enterpase level or adopting graphical as their central API. And many of these businesses, particularly for US, we largely see e commerce and news, retail and media organizations. They have use cases where they have lots of public and redtavy data. Right if you think about an e commerce webshop, everybody's looking at the same shoe. If you're thinking about a news website, everybody's looking at the same

article. Right. That data is very public, it's very reat heavy, it doesn't change very frequently, and so by putting us our graphicll cited in front of your graphical EPI, we can cash those responses at the edge, really close to the user, and that has really three main benefits. One

is it's much cheaper. Some of our customers literally have ninety nine percent cash itIt rates, meaning their origin infrastructure has to handle ninety nine percent less traffic because we just respond with the result from the age immediately that we have cashed. Now, that in turn means that they can reduce their infrastructure significantly, and in fact they say, you know, thirty forty percent of the infustry costs just by pure virtue of having us in the front and cashing all the

data at the age. And then the other part is traffic spike handling, because if you think about news website, for example, if everybody's reading the same article, it's very spiky traffic. Right if something happens, if some tragedy happens then a news website, We've got an immense traffic spike on that

specific article, and everybody's looking at that same article. Now, by default, your origin infrastucture has to handle that traffic spike, right, And many or news organizations just keep their infrastructure scaled up to the maximum so that when the traffic spike comes in, which is when their business makes money, they

can handle the traffic spike. Choose. All of that traffic is almost always accessing the same data, right, And so fundamentally, if you can catch that at the IG, your origin doesn't even notice the traffic spike because we handle it for you, right, you literally don't have to worry about traffic spikes anymore. And then finally, of course, the main benefit from the

edge catching is performance that a lot of developers love. Where because it's at the edge, we can serve a cash result to your users in about thirty five to fifty million seconds no matter where you are on the planet, right, And so if you have your origin of such you're sitting in US is one in aws. Then even if your users are in Italy, or they're in Australia, or they're in Asia or they're in North America or they're in

South America. It doesn't matter. If something is cash, they're going to get it within about thirty to fifty million seconds, depending on their Internet connection. It's just going to be ridiculously fast. And the interesting thing I think for a lot of people that are listening. Of course, if you're if you are an e commerce or a news organization, you use graphicill, please come talk to us. We'd love to figure out if you our products can

work for you. But really the interesting thing is that a lot of what we do is only possible because of graph kill, right, one of the one of the sort of historical If you look at any ur online that's comparing rest to graphicill, almost always you will see rest is great for cashing and graphicill sucks for cashing, and the truth is actually much more nuanced than that. In fact, graph killing in many ways is better for cashing than rest

because it tells us what data is in the response. It tells us, through its in respectability, what is the actual data that's coming back for this query, And so that allows us to do things like partial quarry cashing.

We can at the edge, look at loop through your cash rules or a cash configuration, figure out which parts of this query are how cacheable, make them distinct cash entries, and then only have to fetch the data from the origin to fulfill the rest of the data that we don't have in the cash

yet. Right, that is literally impossible. With rest, we can do really smart cash validation because when imutation passes through us, we know exactly what data has changed, and so we can invalidate only the specific cash entries that contain that specific data. And it's not like, oh yeah, if a post for if a post request for slash user comes in, then invalidate the

corresponding gets for slash user. It's much more advanced to that because when a mutation comes in for edited user, we know every single quarry that fetched the blog post author that was written by that user, We know every single quarry were the user settings for fetched for that user, and we can invalid it

only and exactly that within about one hundred and fifty million seconds globally. And again that's only possible because graphicill tells us what data is in the what data we're actually cashing, right, what objects, what entities are in the data that was fetched and that are cash at the agent that are changing over time, and so a lot of the things that we do are we've really built

the most advanced API casing solution. It just happens to be graphical specific because graphicill allows us to build this advanced API cashing solution, and through the way graphic will works, we can do a lot of things that otherwise wouldn't be

possible. And so we're focused on Graphkill simply because it allows us to build the best product and because we believe and we love graphicill quite frankly, like as an organization, everybody that works here loves graphical We've all used graphkilled at

large skill. We freaking love it. And then later on, so that's what we started with, and then later on also we added now on graphicel metrics that give you very graphical specific insights into the operations where we're seeing in production, into what types and fields are, how used or how slow,

and how many areas. You're getting very specific air tracking for graphicill. And then also now we've shipped the security features around graphkill, both for sort of common exploits like aliases and pipths and and all kinds of limits, but also persisted operations and rate limiting sort of help you protect your graphic COLPI in many ways similarly to what you would do with the rest API, but very graphicill specific again with a deep understanding of graphill and how it works. And so

that's really if you're using graphkill scale. If you're if you're running into operationalizing issues either because you're you know, you have large traffic backs in your news organization, or because you don't have the observability that you need, or you're getting malicious actors trying to deal with your API, come talk to us. We've built products around graphkill, going back to the open source point, our

product are fully proprietary. Will bullet on graphkill, but come talk to us, Go go use our CDN in front of your graph CLIPI and we'll happily solve those problems for you. So just to make sure I get this right, Max, And first off, congratulations on the product. It's definitely a major thing, and I can only imagine how long it took for you guys to build this thing and the effort that it takes to actually maintain it. So congrats for that. My question is just to make sure that I fully

understand the product. So from your description, my understanding is that it's kind of like cloud flare in the sense that it's a proxy that sits on top

of your API and on an application layer. It can interpret the graph QL requests parts that query and figure out in a smart way which parts of that querry can be cashed or not, and then the parts that can be cashed it already returns directly without even going to your API, and if it can't be cashed, then it goes to your API, waits for the response, saves that response in a cash database that I don't even need to carry to care about, and then returns that to the end user. Is that correct?

Yeah, that's right. And if you think about you know what ret API, you have an endpoint like slash gate users slash one. If you have some of that user data cash from another quarry, that doesn't help you in cashing the get slash user slash one route. Right, that's a completely distinct endpoint that that returns opaque data where you don't know what it is.

With graphkill, we can know exactly when you're fetching user number one whether or not we have that cash entry already and we can just return that immediately without

even having to go ask the origin. And on top of that, if you're fetching say users, and in one quarer you're fetching some of the data, then another quarer you fetching more of the data, we can know that we have some of the data in the cash already and take those fields out of the graphicill career and only send a request for everything else that we need

to the origin. Because graphicill allows us to select the exact fields that we need to fulfill the data requirements, right, and so we can do essentially the most efficient API level caching that you can do at that layer, because we have full control over which fields that we have in the cash, however we cash them, and how do we get the rest of the fields from the origin. So yeah, you're totally right. Nice. I really like the end user experience of it, and I really like how it doesn't force

me to conform to any specific way of writing my APIs. I can just do whatever whatever I'm used to and build my APIs in whatever way I want to, and then put your service on top of it. That's pretty cool. That's pretty cool. Nice, okay, and to which types of businesses do you think this is more interesting? Because well, I imagine that anyone that has a graph quol API could benefit from it, probably right, Like, there's no specific use case besides having your API built on graph qol.

But what if I am just not so close to the edge of technology yet and I'm not built on graph quol. Is there any way for me to steal extract value from your solution or is it really just graph l specific. It's really graphical specific. And it's like I said, a lot of what we do we couldn't actually do any other way, Like we couldn't do for rest APIs we really have to go figure that out for for graph kill,

and it really only works with graphicills. So the kind of companies that we do with our large organizations that use graphkill at a really large scale, and for the edge caching, it's businesses that have you know, very what we call it read heavy and public traffic. And then for the matrix in the security is just any company that uses graph kill and that is that doesn't have the observability they need or the security that they are a need to protect from

malicious actors. Gotcham Okay, I just sent the link to stell it on the comment section, So if you're listening to the show from a player that doesn't have a comment section, just know that is s T E l l A t E dot co so stell it dot co it to house. You can also just search online for stell It, Max Stoiber, and Google is going to somehow figure out what it is that that you typed and point you in the right direction. So yeah, definitely check it out. If you're

working with APIs guys, I think we can start wrapping things up. So unless Max, you have anything that you would like to say that you haven't yet that you think it's really important, I will just say thank you for letting me rent about a whole bunch of different tangents. I don't know that this went in the direction that any of you expected here this podcast, given

that the title style components. We went a bit prower than that. But I hope it's most insightful to people, and I hope you all enjoy it. I circle enjoyed the conversation. I hope your listeners will too. Thank you. Yeah, I don't think that people looking at the title of the

episode are going to grasp the entire context. But yeah, thank you for those rents, like it's it's actually really good that you you were so open to sharing your opinion because oftentimes people just don't want to share those rents in a public content such as this, So I definitely appreciate your honest opinion about such topics. So yeah, let's start wrapping things up. Let's do a quick round of promos, so we can do you for last Max, but

I'm pretty confident that you kind of already did your promo. But in any case, if you want to promote other stuff, you can definitely do that. So starting on my end, really not in major, just gonna promote the companies producing the show. So for any of you that want to learn more about software development, you can check out the other content produced by top and dovs. There are several other podcasts that top and Devs produces, and

they are all courses that they offer. So yeah, definitely check out the website topendewth dot com if you're interested in that. And void dot com is U n voi d dot com. So the opposite of void unvoid. Some people think that it's on in terms of like On and Off, but it's

u N and they offer task based design and software development services. So the difference being that whenever you need to hire external professionals to do work for your company, you generally have to pay them by the hour, and that incentivizes them to just take their time because they're going to get more money. Right.

So Void completely flips that business model by making sure that the clients only pay after the tasks are delivered and approved, and the clients know beforehand how much the tasks are going to cost because Void estimates points for each task, and the clients pay on top of this point estimation. So clients get cost pervisibility and they also get quality assurance because they can just request changes until they're happy with what is delivered. So if you're interested in that, definitely check

Outvoid dot com. These are just gonna be my my promos for this episode. So, Peter, do you have anything you'd like to mention? Okay, how about you, Chris? Anything new? Yep? Yeah, I'm just going to post something from Superbase. The founder posted. I mean, you can take it with a grain of salt. Maybe it is all marketing, but he talks about if you should open source your company. I think it's I think it's interesting. And then the product I've been working on,

I've posted it quite a bit the last few weeks. I actually recently got into the finalist stage. I don't know if you guys have heard of backdrop build before. So it was like one thousand or so devs or so when they pick like fifty finalists, but you can it's basically a decorative way to create software engineering videos, perhaps later other types of videos. But over the weekend I got the API n point up, so it's not on that website yet, but it'll be up soon. Basically, you can think about it

from a very high level. You give Jason to an endpoint, and you get an animated video, like a lifelike animated video of you know, dictating whatever you're coding or whatever you're building back as an MP four URL. So pretty good. And I sent all those links in the show notes in the comment section, So definitely check it out if you're interested in that. So Max, just circling back to you, is there anything else you'd like to promote? Well, I sure, hope I didn't. I've set any open

source funnels that are listening to this episode. I would love to hear a country and thinking, I'm definitely going to take that super based article. I'm very curious how they thought about open sourcing their company. I have nothing else

to plug. Go go check out Stilly if you using graph pill. I'm at mx SDBR on all platforms, Twitter, get up, Instagram, wherever you want to follow people, even blue sky Master it on whatever at MXSTBR, which is my name which looks really complicated, but it's really just my name without vowels, so you can find me anywhere. And thank you all so much for having me. Thank you very much. Max. Feel free to join and rent a little bit more about other subjects whenever you want.

And congratulations on your company. I hope you are very successful. I'm pretty sure it will be because everything else that you've worked on thus far has been so I'm pretty excited about the next steps in this journey. So yeah, man, congrats, and feel free to hit me up if you want to join the podcast any other time. Thank you