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