What's up, everyone?
This is Cortland from IndieHackers.com, and you're listening to the IndieHackers podcast.
On this show, I talk to the founders of profitable internet businesses, and I try to get a sense
of what it's like to be in their shoes.
How do they get to where they are today?
How do they make decisions at their companies and in their personal lives?
And what exactly makes their businesses tick?
And the goal here, as always, so that the rest of us can learn from their examples and
go on to build our own profitable internet businesses.
Today, I'm lucky to be talking to Evan Yu.
Evan is a creator of a JavaScript framework called VU.js, or sometimes just Vue.
Vue is used by hundreds of thousands of programmers all over the world to help them build their
apps and websites, and it's even in use with companies like Netflix and Facebook.
So it's tremendously popular and influential.
And I think my favorite thing about it is that it's essentially the brainchild of just
one person, Evan Yu.
So Evan, welcome, and thanks for joining me on the podcast.
Thanks.
So we've got a mix of people who listen to this podcast.
A lot of them are programmers, who know exactly what Vue is, and I'm sure some of you don't.
But there are also a lot of people listening who have no idea what Vue is.
They don't know what a JavaScript framework is or even what JavaScript is or what open
source is.
So can you take a stab at maybe explaining what you're doing in a way that everybody
can understand?
JavaScript is language, programming language, almost everyone used to build applications
on the web.
So if you're using Gmail, Gmail is built with JavaScript, and Gmail is an application inside
the browser.
It's pretty complex, and it has a lot of special logic, and it has to manage all these interfaces
that you're seeing, things you're clicking on.
So naturally, it becomes very complex when you try to build something like that instead
of a simple website.
And this is where frameworks come in.
frameworks are essentially abstractions and a set of libraries that help developers to
build this kind of complex applications, make it easier for them to build such applications.
And DJS is one of those frameworks.
It is open source in the sense that we publish our source code completely free, anybody can
just use it whenever they want to, which means we don't charge any money for people using
it.
So it's kind of unique in the sense that we, as someone who works on it full time, I still
need to find ways to monetize it, but just not directly sell it.
I think most people listening into this would think that you're sort of the stereotypical
programming whiz, that you're this professionally trained programmer, there's a degree in computer
science, and you've been making apps since you were six.
But actually, not an extra, what's the story behind how you learned to code?
My first contact with something close to programming is probably through flash, I was playing with
flash in middle school when a cousin of mine showed it and I was like, wow, this is cool.
So I started with playing with flash a lot.
But at that time, the most common thing that I did was just copy pasting all these little
scripts that I found on the internet into the things I was building, I didn't really
understand any sort of serious programming patterns until later in college, I took one
computer science class, which was introduction to programming with Java.
And I actually didn't didn't like it that much.
I thought Java was pretty verbose.
And it kind of made it very difficult for me to just directly jump from start to getting
something on the screen.
So I kept playing with flash and actually bought a book on action script three to teach
myself how to make more user programming concepts inside of flash.
And later on, I went to a master's program called design technology.
It's a master's of fine arts program.
So it taught you both a bit of programming and a lot more design stuff.
That was the time I actually started to seriously learn JavaScript, because I noticed that you
can do a lot of interesting things directly in the browser, and it made it very easy to
share with people.
So that's how I actually started to say I want to learn program properly so that I can
build more complex and advanced stuff.
What was driving you to learn all this stuff?
I think most people, when they encounter that first sort of hurdle, when they take that
programming class in college, and it's not fun, they just quit there.
Why did you keep programming?
Was it something you love doing or was there something else that you wanted to achieve
through programming?
Sure.
I think mostly I wanted to build things.
I had this urge to create all the time, although the things I wanted to create kind of changed
over time.
Initially, I thought I was going to become a designer, because I was designing some websites
for friends.
And then I started trying to build these websites myself, because I couldn't find anyone to
build it for me.
And in that process, I kind of have to force myself to learn all the necessary little things
to learn how to deploy a website, learn how to properly use JavaScript, and actually how
to manage the state in your application, which gets into more complex territories over time.
Mostly I'm self-taught, just because I was trying to learn the necessary things that
allows me to build the things I want to build.
You got an MFA, a Master of Fine Arts degree.
I'm curious why you went that route, instead of getting a traditional CS degree, when you
knew that you wanted to be a builder of things.
You knew that there was this sort of golden path out there that would teach you what you
needed to know.
Right.
So the kind of things I wanted to build was always leaning more towards the creative side.
The things that I looked like most was websites like FWA.
I don't know if anyone know about it, but it's like favorite website awards.
It was mostly super flashy, super fancy, like heavy animation sites, flash sites back in
the days.
And that's what got me into, say, I want to build things on the web, although that kind
of website is kind of – most of those websites are just marketing, one-off marketing sites.
But a lot of them consisted of these really interesting interactive bits, like things
you don't typically do in serious applications.
And I was actually interested more in that area of stuff, which led me to study design
technology programs, which is, in fact, very closely connected to this creative marketing
side of things.
But later on, it deviated a little bit because when I was building some kind of those experiments,
I was trying to abstract all the reusable parts, which eventually turned into my little
set of libraries.
That kind of was the – I guess leading into what I did with Vue is essentially taking
all those learnings and abstracting it into something called a framework.
So let's talk about Vue.
Today you're working on Vue, and the way you make money is primarily through donations
on Patreon.
So I can open up your Patreon page right now, and I see that you have 232 people who are
donating a total of $16,547 to you every month, so you'll keep working on Vue.
That's a lot of money to make on your own, on your own project.
When you first set out to work on Vue, was it your goal to achieve something like this?
Definitely not.
When I first started working on Vue, it was completely an experiment.
There were already other frameworks out there like Angular 1, and I think React came out
actually earlier than Vue as well, but there were a few people who knew about it back then.
When I started working on Vue, it was mostly an experiment saying, hey, there are these
frameworks out there.
Can I make my own?
Because it looked fun, and there were also some very lower-level technical stuff I wanted
to try out in my own framework.
That was the primary motivation when I started the project, but it kind of grew organically
later on when more users started actually using it in their applications, and they told
me they liked it.
I heard this over and over, and I was like, there must be something to it.
There must be something in this little thing that I created, and I should probably spend
some more time on it to try to make it better, see where the full potential is, and eventually
it got big enough that I realized I could probably try to monetize it in some way.
Patreon seemed like the way that it requires the least maintenance on having to think about
it, because I set it up, people donate money, and they charge automatically, so I don't
need to worry too much about it, so that I can keep focusing on creating instead of just
trying to think about monetizing it all the time.
It's fascinating that you started this as a hobby with no real goal of making any money
from it whatsoever, and yet it's resulted in this massive business win for yourself.
I know a lot of people who start out on day one trying to make money and never get to
that amount of revenue every month.
Do you think that if it had been your goal for you to be a business from day one, if
you had set out to make $10,000 or $20,000 a month, that you would have done things differently
from the start?
I would probably done it very differently.
I think one of the biggest advantages of starting out without thinking about monetization is
that I only focused on just making it good, because I had a day job when I started working
on it, so I wasn't really pressured to say I need to monetize as fast as possible, so
I had a long time to just slowly think about what's the best way forward and polish all
the little technical details, write very lengthy documentations.
All of these little things add up, and when I eventually wanted to say work on it full
time, it was already solid enough that people are willing to say this is something worthy
of paying money for, although they're not paying for it directly.
These companies are saying this is something with momentum, so we're willing to sponsor
it.
Let's walk through the beginning of your journey here.
When you're working your day job, you've got, I suppose, free time on the side or maybe
time at your day job to work on this, how did you decide that view was a thing that
you wanted to build, and did you have ideas for other projects that were competing for
your attention?
Well, yeah.
View was just one of many little experiments I had back then, because when I started View,
I was working at Google as a creative technologist.
My job at Google involved very fast iterations on these interactive experiments, prototypes.
I worked at a place called Google Creative Lab, where it's a very versatile team.
We had programmers, creative technologists, designers, copywriters, just purely creative
strategists.
We keep cranking out these crazy little ideas all the time, and we had to have very fast
turnaround time.
We got some interesting idea coming in.
I need to just start on it and build something really quick.
In that process, I also never had interesting little technical ideas.
I would just build a little library, publish it on NPM, or just try to make a little open
source project.
It was kind of like a mini portfolio for a creative technologist.
How quick is quick when you say you're iterating through these projects?
You're taking weeks or months or days or how long does it take you to get out one of these
things?
I think average is like two to three weeks per project.
Okay, so you're going super quick.
From start to finish.
Wow.
Yeah, because those projects are not like we're not trying to ship a complete product
to the users.
It's more like we start from an idea, then we finish at something that's deliverable
to a real product team where they can evaluate this and maybe iterate on top of it to make
it a real product.
So that's cool.
You're at this big business, Google, but you're kind of getting almost startup practice where
they're like, you need to iterate and build these things quickly.
And so you're getting in the habit of launching things without wasting tons of time.
Exactly.
So it was a really good experience, definitely.
Was Vue one of these projects that you worked on for Google or was it a project that you
decided to work on for yourself while you were a creative technologist?
That was completely for myself.
We weren't doing a bunch of things.
A few of those projects actually required something more like a proper UI framework.
And a few of those projects actually used Angular 1.
But the decision was made by some of my co-workers who introduced Angular 1 into those projects,
which I happened to collaborate on.
And I was using Angular and there are bits of it that I liked, bits of it that I didn't.
And I felt like this feels really useful and I could completely just like have something
like this just for myself that I could use in my personal projects.
And because creating myself allows me to just throw over the things I didn't like about
Angular.
And also it was a good practice.
I wanted to, I was curious as a technologist, I was curious how it was done.
And I wanted to just find out whether I could do it.
It started as a really, really simple experiment, proof of concept almost.
And it actually set in my drawer for a good six months before I decided to open source.
You mentioned that you guys were using Angular, which is another one of these front-end JavaScript
frameworks just like Vue.
And it was actually created at Google.
So I can only imagine that every team at Google was also using Angular.
And also around the same time there was React, which you talked about earlier, another front-end
JavaScript framework created by Facebook.
And both of these companies, Google and Facebook, are known for having some of the best programming
talent in the world.
And I think that would be enough to stop most people in their tracks and discourage them
from having to build their own JavaScript framework.
Why didn't that stop you?
When it began, I think one of the, I didn't really think about competing with them.
That was a blessing because I didn't have to pressure myself about, oh, these bigger
libraries can do these things, but mine can't.
These bigger libraries had these backing, but I don't.
I didn't have to think about it because I wasn't trying to compete with them.
So I just focused on making the library itself good enough that I would feel like technically
it would be on the same level.
And then naturally some people discovered that, hey, there's this independent thing,
but it's as good in some way.
And on the other hand, when we were trying to say we built a library, it's interesting
because React, England, Vue have some different sort of flavor in terms of the API design.
So programmers naturally have different tastes in the programming tools that they want to
use.
For example, some people like dynamic languages like JavaScript, Ruby, Python.
Some people like more lower level languages like C or Rust.
Some people like strongly typed languages, very complex type system.
People have different tastes.
So do front-end developers when they are picking a library or a framework.
Vue started off from my personal taste of what I would like as a framework.
And I think that happened to coincide with a lot of other developers' tastes, which allowed
it to sort of naturally attract developers that had a similar mindset with me.
And I think there are a lot of front-end developers, especially in these creative agencies, little
companies, small business, small teams, compared those with, say, a huge enterprise, huge corporation.
They actually have very different development models and mindset team set up and also their
own technical backgrounds, right?
It's very diverse.
So Vue kind of captured the group of developers that there is this, I would say, a market
fit that's unique to Vue, which I didn't realize when I started.
But looking back, I think that's what actually made Vue succeed nationally over time.
Yeah, that's really fascinating that you sort of built this perfect, I want to say niche
product that appealed to a very small subset of programmers.
Maybe not that small after all, but at the time you didn't know that you were doing that.
But you said that you were focused on making Vue good.
What did good mean to you in the absence of a target audience?
That means it provides a good development experience, because I am a developer myself.
So before I built Vue, I was a consumer of such libraries and frameworks.
And when I'm building apps, I would come up with a list of things that I like and don't
like about these tools that I was using.
So when I built Vue, I tried to hit all the boxes that I like about those previous tools.
Like when I use the library, I'm like, oh, wow, this is a cool idea.
If I were to build a framework myself, I would definitely do this.
And sometimes when I'm doing something, I wish there could be a tool that allows me
to do this.
And if I were to build it myself, yeah, I would definitely do it.
All of these little things that accumulate over time as a consumer of other tools sort
of cognate it into this.
When I finally get the chance to create something for my own, I just pour all of these little
things into the thing I am creating.
And I think that resonates with a lot of other developers as well.
I wonder how much Vue changed as a result of Vue eventually opening it up for other
people to use.
Because it sounds like in the beginning, you had your own personal checklist of what you
wanted to see in a tool.
And on one hand, it's true that other people might be just like you.
But when you first started showing it to people, was it the case that they're all just like
you?
Or did you have to go back to the drawing board and sort of, you know, reevaluate some
of your assumptions and make changes to Vue in order to make it better for other people
to use as well?
Definitely.
Well, the good thing is when I first open sourced Vue, it didn't...
It was more like, hey, I made something cool.
Like, if you like it, just use it.
If you don't, I don't really care.
That was really my attitude when I first open sourced it.
Later on, we actually had a proper community.
We had a decent group amount of users.
And when we were, say, trying to do the 1.0 release, and 1.0 is something special when
you're releasing a software because there is this convention called semantic versioning,
which means once you release a major version, you're not supposed to make any breaking changes
until the next major version.
So 1.0 really meant something and we want to really get it right.
And that was the first time we actually had to say, I am proposing that we make these
changes and let people voice their opinions on whether this looks like a good idea or
not.
And we actually had really lengthy debates and discussions on what should and should
not be done before we finally released 1.0.
And that actually was, I think, marked the point where it transitioned from a completely
personal project to something that's more or less a community product, where users actually
had a voice in the decisions being made.
There's so much there that I want to talk to you about, especially this 1.0 launch,
this process of taking what was previously this private personal project and making it
something public is really interesting.
But first, let's go back to the days before that.
A lot of people that I talked to are in a situation that you're in, where they have
a passion project of sorts, but they also have a full-time job and it's difficult to
navigate doing both of those at the same time.
How did you find the motivation and the time and the energy to complete such an ambitious
side project while working a full-time job?
Well, I guess I was lucky because I started the project when I was young and didn't have
kids.
So I had a ton of free time outside of my day job.
I remember working on Vue late at night on weekends.
I really did spend a lot of time just outside of my regular job.
So that was...
And the motivation part, I think, was because I just wanted to create something cool and
good.
It was kind of like proving myself as a competent developer or a competent technologist.
I think at some point, initially, it was an experiment, right?
But at some point, when people actually started using it, I started to look at it more as
a product and I want to build something that makes myself proud.
I want to build something that when people mention it, they're like, oh, that is a cool
project, right?
That was the thing I was aiming for when I was spending those weekends just working on.
It was almost like a hobby to some extent because I remember there was a period of time
when I just didn't know what to do.
I would just crack open the editor and start working on Vue.
Obviously, it's getting more difficult to do that today, but I think in the early stages,
this kind of mode is kind of what made it tick.
How long did it take you to actually get Vue from the point where it was just an idea to
a real thing that other people could start using?
I think the first commit was in June or July 2013.
And the first public release was in February 2014.
So that's like six to eight months, I think.
Now, was it just you working on it by yourself that entire time or were you showing it to
people and collaborating?
I think it was mostly just me.
It was just like this completely random folder in my laptop.
I just kept working on it over time.
I think that early eight months, it wasn't as intensive as it was later.
It was mostly whenever I had spare time I felt I wanted to play with something, I would
work on it a little bit.
The more intensive part was before the 1.0 release, I was working really hard on it.
So yeah, let's talk about that process of getting ready for this 1.0 release.
You mentioned that you open sourced Vue.
A lot of people listening don't even know what open source is and aren't sure what that
process is like.
How did you open source Vue and how did you get your very first Vue users?
I think a typical way for developers to open source something is first you put it on GitHub.
GitHub is the place where you can share your code, share the source code of your project.
So everyone can just look at every line of code you wrote and understand what you're
doing.
The first thing you do is I put the source code of Vue onto GitHub.
You want to make sure that the repository is actually public so everyone can see it.
Then I posted the link to Hacker News, which is kind of the place where a lot of developers
actually show off the new cool stuff they built on.
It's kind of like product hunt, but only for hackers, right?
I also submitted to some of the blogs back then.
There were a few blogs that just showcase new jobs for projects every week.
The one that got the most attention was the Hacker News post where I think I got 200-ish
upvotes.
It got upvoted to the front page, which is actually quite difficult for something that's
completely new because Hacker News has some really weird algorithm in determining whether
your post can stay on the front page.
You have to, say, get really anonymous upvotes, decentralized upvotes.
Basically, if they detect anything you're trying to say, ask a bunch of friends to upvote
your post, they'll actually deprioritize it, but somehow the post got upvoted and stayed
on the front page for quite a few hours.
So that's all the first batch of traffic.
I think that was how I got the first group of users they discovered on Hacker News.
I didn't know that you launched at Hacker News.
I also launched Indie Hackers on Hacker News a couple years after you launched Vue, but
I'm reading this Hacker News thread right now and it's funny looking at the comments.
One person said, I do very little front-end development, but I really like this.
It seems much more lightweight than Angular or Ember, but similarly powerful.
How much were you learning from finally revealing what you were working on to the world and
seeing feedback like this?
I actually wrote a blog post about it.
It's on my blog called First Week of Launching UJS.
I actually did a little postmortem where I summarized the things I did.
I submitted to Hacker News, Reddit, EchoJS, DailyJS.
These are just these sub-communities that focused on JavaScript and took a look at the
business stats and all that. I think the takeaway was that you have to think about it as a product
more than just a technical library because when people try to evaluate a technical solution,
they not only look at the code and what it achieves, they also look at the overall presentation.
Did you have a good readme that explains what problems you're trying to solve and how you
can compare with other similar solutions?
They also read your code to evaluate whether it's solid enough.
A lot of these little details would add together when you launch something that is open source.
Let's talk about this process of growing an open source JavaScript framework.
Open source is fascinating in that I can't readily think of an analogous phenomenon in
any other industry where the people will toil and sweat and work and then put all the results
of their work online free for everybody else to use and copy whenever they want.
What are some of the strategies you've used and the challenges you've overcome to succeed
in a space like this?
There are several different types. There are many different types of open source projects,
actually. If you think about companies that's built on top of open source, there are quite
a few examples like Red Hat, which was acquired for billions of dollars. It's built on top
of adding services on top of Linux, which is pretty much free. Then there are MongoDB
or Oracle, which a lot of these huge corporations actually started building on top of open source
libraries.
Here, Vue is probably, compared to them, it's a completely different scale. Vue is a completely
independent open source project that started out as a hobby project. Something I think
that would be along the lines of Vue would be things like Laravel. If you take a look
back, Linux actually started out as a one-man project as well.
I think there are two parts of this. The first is you need to have someone who is passionate
enough about it to invest their own time into it in the beginning. Then when it gets momentum,
it gets big enough that there could be potentially some business opportunities. You would build
actually a traditional business around it. In many more cases, most of the time, these
individual open source projects would fall in the chasm where it's big enough that it
has a consistent group of users with enough demand. However, it's not big enough to be
properly monetized in order to support its maintainers to work on it full-time.
I think that's actually the most difficult thing for open source projects to get over.
I call it the chasm. You're big enough that it takes up so much of your time, but it's
not big enough that it will pay you to work on it full-time.
How did you know that you weren't in that chasm? At what point did you come to that
realization that, oh, I can make money from this and actually quit my job?
I actually wasn't even sure when I quit my job. When I quit, I think I had the patience
set up. Before I quit, I was pondering the idea. I wasn't entirely sure whether I would
be able to actually survive just out of this. Then I had a company, China, a startup. I'm
actually a good friend with its CTO. We knew each other and was telling him that I'm thinking
of working on this thing full-time. He was like, hey, we have this little fund in our
company where we just use it to support open source projects. I can actually arrange so
that we are supporting you for $2,000 a month for six months straight.
That really gave me the boost needed. I was like, okay. Actually, I would actually get
some bit of money to work on this now.
That's so helpful.
Yeah, that would definitely help a lot. Then I started my Patreon. Combined with that,
money I got from the startup plus the other money that I got from Patreon, I think. Shortly
after I started working on a full-time, I reached $4,000 a month. That was the point
when I felt less intimidated. I was like, this is actually generating income and it's
actually growing over time. That was the point where I was like, I could actually keep doing
this for a bit longer because when I quit, I have some savings. I was really just thinking
like I would try this maybe for a few months and if it doesn't work out, I would actually
just look for a new job. I actually had a few resumes sent out at the same time I quit.
Were you thinking about quitting your job for a long time before you quit or was it
suddenly you got the $2,000 a month in your bank account and you just went for it?
I think I thought about it for quite a bit. Before I quit, I was already feeling the pull
between this project versus my day job. To be honest, the feeling I got was I felt more
fulfilled working on view versus my day job. That was one of the primary reasons to quit.
Working on something that I'm genuinely passionate about is such a big bonus that I'm willing
to just take a pay cut so that I can work on it because it makes me feel more fulfilled
and makes me happy about what I do. It turns out it worked out better than I hoped. I'm
working on something that I like and I'm making more money than before. That's really good.
Did you try anything else before quitting your job to guarantee that you would get revenue
or was this conversation that you had with your friend and his business your first attempt
at trying to secure some funding for view?
When I was quitting, my first primary goal was so that I can focus on making view better.
I wasn't thinking about building a company around it. I wasn't really aiming at building
business that would generate as much revenue as possible. It was more like a lifestyle
decision. In fact, since I started working on a full-time, the first thing I did was
I dropped everything and started rewriting view from the ground up. That was the start
of View 2.0.
How worried were you after you quit that you might eventually get to a position where you
weren't making several thousand dollars a month and that your business wouldn't eventually
work out for you?
I definitely worried about it to some extent, but I think the reason I went with something
like Patreon was I deliberately set up the whole sponsorship deal so that I don't have
to actually do anything in return other than working on view.
A lot of the things I saw some other open source projects do is they set up these sponsored
tiers. Typically, when you set up a Patreon campaign, people expect to get something in
return specifically for the amount of money they pledged. If you pledged, say, $20 a month,
you would give some little swag stickers in return, or if they spent $500 a month, you
would have to, say, give them exclusive updates or something special.
But I didn't set up anything like that. I was pretty much just saying, if you pledge
enough money, you'll get a bigger logo on the website, and that's it. You get some exposure
through our website, but I wouldn't actually do anything special just because you give
us more money.
We take the money so that we can spend our time working on view to make it better.
What's ended for these people and these companies who are sponsoring view, especially at the
beginning, when you didn't really have that much to offer? How are you convincing them
to support your project?
I think in the beginning, the first initial sponsors or donors mostly was supporting view
because they were using it and they liked it. They didn't want the project to die as
simple as that. On the Patreon, I made it clear that this is my primary income source,
and I need to make enough money from this so that I can dedicate my time on view.
For them, it was pretty much like they were building their product on top of view, so
it's in their best interest that view is continued to be maintained and be made better.
For them, it's almost like an investment. The return is not so directly reflected the
moment you spend the money, but then putting down the money gives them a better chance
of view being relevant and maintained and stable for the long run.
I think that's a wise decision on their part.
Yeah, it really is. This is not pay for view and I'll provide you some theoretical value
in the future. Your entire company's product is built on top of this framework and if it
goes away, it's going to cost you many hundreds of thousands if not millions of dollars to
rewrite your product from scratch and so it's worth them contributing a few hundred or thousand
dollars a month.
Yeah, and also it's funny because I realized a lot of companies say that when they build
something and they realize in the end the thing they built on top of is dead or gone,
they would have to hire someone to completely rewrite the thing. The cost of rewriting an
existing product is huge. It's like you're just paying an insurance so that you don't
have to rewrite your app in two years.
What's interesting is that there are lots of open source projects that big companies
really depend on that are crucial to their success and yet that haven't been able to
successfully garner the kinds of donations that you've gotten for view. Why do you think
that is? What's hindering them and what is it that's helping you?
I think there are two aspects of this. The first is the type of projects that we're seeing.
View is as a front-end framework. It interacts very directly with the developers using it.
Say if a company is building a product using view, their developers interact with view
almost every single day. Almost for all the code they write, they are interacting with
views API. They're reading views documentation on a database. This high exposure made it
easier for people to justify the decisions. Say we are sponsoring this high exposure project
and indirectly our brand recognition is probably getting better return given the money we're
donating.
I think that's part of it. If you were to look at a project like Babbel, which is also
mostly maintained by volunteers, actually the only person working on a full-time I know
is Harry Joo, who I actually talk with a lot. He's actually having quite a bit of a hard
time trying to secure enough funding for him to work on full-time.
But Babbel is huge as well. For those of you who are not familiar with Babbel, it's a library
that allows you to compile your JavaScript that's written in a future syntax. The syntax
that's not in the browsers yet. Babbel can help you compile those into JavaScript that
works in the browsers today. It's a very important project in the JavaScript ecosystem used by
millions of people.
Yeah, I use it for indie hackers.
Yeah. Yet it's very difficult for it to monetize in a way that Vue does because it's so invisible
in your infrastructure. You set it up once and you're pretty much done with it. This
makes it more difficult for these businesses to say, this is something we want to get associated
with as a sponsor because sponsorship is naturally, the name entails that these sponsors want
exposure through the partnership. This model works best when you have a project that has
a very high exposure and interaction ratio with the developers.
It's interesting. You've got all this competition. That almost helps you in that developers are
so vocal about what their favorite front-end JavaScript framework is. People like to say
that they're a fan of Vue or a fan of React or Ember or something. They just talk about
it a ton. Or something like Babbel, it's just sort of invisibly hums along in the background
and it does its job well, but I don't know very many Babbel fans. What else is there
to be a fan of instead of Babbel?
It's almost like... Yeah, I think it's funny because the framework competition, sometimes
it turns into more like a sport-fanship kind of things. People are just like, I like this
versus that. I personally don't mind a little fun and such when you're comparing frameworks,
but the thing I'm less fond of is some people like to compare it as a war metaphor where
we're just like trying to kill each other. I don't think it's the case. Most of the time,
these different frameworks actually exist to cater to slightly different tastes and
needs for developers in different situations. But this kind of friendly competition, I would
say, actually does help in terms of exposure.
There's got to be 1,000 articles written online about Vue.js versus React or this is Angular,
etc. You mentioned earlier that open source businesses are different. And different businesses
have to have different business models, different projects have to have different ways that
they try to grow if they want to succeed and make money. I talked to Mike Parham, for example,
of Sidekick. And Sidekick is an open source project that does live sort of invisibly in
the background, you set it up once and then it kind of works. And yet he's able to monetize
it and also make like, I think he's making something like a million dollars a year, something
crazy off of it. And what he's doing is I think charging money for special features
and for customer support.
My question for you is, how do you look at something like that and reconcile what you're
doing with Vue? Why did you decide to go the donations route rather than doing something
where you're charging customers directly for extra customer support or extra features?
There's a few different ways you can monetize open source. And one of the easiest thing
that people can think about is like you charge money for support. Some companies are using
my project and if they want to get specialized support, they give me money and I help with
them. I thought about this when I was first setting out, but I realized this is actually
nothing different from say just doing consulting full time. I essentially have to trade my
time for money. And if I do that, in order to earn more money, I'm actually cutting my
hours that I can work to be spent on Vue itself. So I realized that very early on that this
wouldn't work for me. And this is not the thing I want.
And another type of open source is you would have a free version, essentially what Sidekick
is doing. You have this open source community edition, which is completely free, but you
charge money for some additional features, which I realized doesn't really make sense
for something like Vue because what Vue excel says is we have this enormous reach. We want
to lower the value, want to make front end programming accessible to as many developers
as possible. Charging for premium features just goes completely against what Vue is made
for. So that didn't really work for us either. Plus, a donation is probably the most worry-free
way of income generation because it's almost passive to some extent. Although I definitely
need to keep working on Vue, but that's what I enjoy doing, right? So for me, I don't need
to do too much additional work in making sure everyone pays money on time, for example.
That's handled by a patron for me. That's why they take a cut. And if they can do that
for me, then I can focus more time on just working on the things I want to work on. Another
aspect of this is because Vue is a front end library. Most of the time, it's really hard
to charge licensing for libraries that people just use in the front end, especially when
you have competitions like React and Angular, which are completely free, right? So the existence
of React and Angular pretty much means that it's impossible to charge a license fee and
compete with them at the same time. You would have to be orders of magnitude better in every
way for people to justify that position.
Yeah, that's a really good point. We discussed the advantages of competition, but one of
the disadvantages is that they kind of affect the price point. And while your competitors
are free, then you have to be free yourself. But I also really like what you said earlier,
which is that your business model is a reflection of the way that you want to live your life.
This is your project that you created from the ground up. Why would you structure it
in such a way where you end up having to do support work or consulting when that's not
how you want to live your life?
Yeah, I think that was the point. Because like Indie Hackers is all about people doing
these little ventures where it has a strong correlation to the lifestyle you bought, right?
And I think I actually read The Four Hours Workweek by Tim Ferriss, which was a pretty
influential book on me because I realized I was doing the day job and working on something
that I really wanted to work on in my spare time, and I wasn't really happy because it's
taking up all my free time.
And I realized if this thing I'm so passionate about, I work on it, and I can make money
from it, I'm getting such a huge bonus in quality of life. I would get all the time
I would usually spend on my day job that I can actually spend with family and do the
other things in life that I want to enjoy. So that was really, really important revelation
for me.
Yeah, you're basically living the dream and maximizing your freedom as a person to do
whatever it is that you want. Let me ask you about Patreon. So Patreon allows people to
make donations in sort of a recurring fashion. So you mentioned that you don't have to reach
out to these sponsors every month to make sure they're going to pay, they just automatically
get charged.
Patreon takes a cut, and you don't have to worry about it. So that recurring part is
all taken care of. But how did you get people to become sponsors in the first place? How
much are you doing sales? And how much are you just letting people sort of trickle in
on their own?
Believe it or not, it's completely organic. I do put links to the Patreon page on our
website. There is a section on views website called support views development. And when
they go to their website, they will see first, obviously, they will see a list of existing
patrons who sent in the logos. So they see a wall of logos. And they're like, Hey, cool,
I want you want to get our logos on there. So what can we do? Then they get the link
to the Patreon page, where you get a just an explanation of the benefits of different
tiers like the more money you donate, the bigger logo you get. And that's pretty much
it. So I don't actually do active reach out to any companies. I think all the patrons
currently on our website is entirely organically generated.
That's amazing. And that's really a testament to just how popular and well known view is.
It's not something that could happen otherwise. Yeah, there's this maxim that often gets repeated
in the startup world, that the only thing that matters is your product. As long as you
build the best product, then it doesn't matter if you second sales, it doesn't matter if
you neglect marketing, it doesn't matter if you don't find any distribution channels,
your product is still going to win. I'm pretty skeptical of that. I don't think that's true
for the 99% of businesses. But it seems like for view, it kind of has been true. What would
you say? How much of view success is due to the quality of view as a framework itself,
versus you making all the right decisions about how to grow it and get into more people's
hands?
I think I would attribute most of it to just keep working on view itself, making sure it's
good. So far, I try to spend as much time working on view itself compared to the time
I actually need to manage things. And in fact, I think I spend very, very little time trying
to actively increase the patron base or reach out to sponsors. I don't actually do that.
Because most of the time, I feel like if you make the base big enough, then these people
who are interested in sponsoring it naturally tickle in. I could probably squeeze out more
donations if I actually try to get more sponsors. But I also need to think about the invest
of time required to do that. The same amount of time I invest in trying to secure one more
sponsor, this is the time I could just spend on cranking out a new feature. For me, the
latter is more satisfying. And also, it probably works for the long term better as well. Because
the feature you add in there, it's in there. It makes your whole thing better and makes
it more relevant and stay there longer and gives you more chance to get new sponsors
for the long term.
That's really cool. And I think for many businesses, it doesn't quite work that way. Especially
if you're a fledgling startup and you haven't quite built the right product yet, you can
add feature after feature all day every day and never get any more users. You mentioned
this blog post you wrote, the postmortem of your first week after launching Vue. And I'm
looking at it right now, you kind of talk about how many users you have, how many visits
your website, how many stars you got on GitHub. And you're around the low thousands mark or
low hundreds mark where you had 615 GitHub stars at the end of day seven. Today Vue has
something like 119,000 stars on GitHub. What was the path like to go from that small number
to where you are now?
It's actually quite a long journey. If you think about it, let me... The blog post was
published in 2014, February 2014. It's four years, eight months now. Actually four years,
nine months, almost five years considering the time that led to that moment. And that's
a very long process. There were a few pivot points in between where I realized, oh, this
is actually the next stage. But I think for the very long time in the beginning, I was
completely on the top position where I didn't really think about how big I could become.
I was just trying to say, I want to make this thing better. And I was actually genuinely
excited when we reached 30,000 stars on GitHub. That was kind of the moment where I felt,
oh, we're actually big. But I think just a few months later, we crossed 50,000. I was
like, that was fast. Then I just stopped caring about GitHub stars. I don't even check it
out. What was driving all this growth? I mean, Vue was great as a framework, but we mentioned
earlier, you're going up against React, you're going up against Angular. These are two frameworks
created by very well-funded companies with endless marketing budgets. And yet today you
have more stars on GitHub than both of them. And that's crazy. I mean, you're working with
volunteers and you started this thing all by yourself. What are some of the strategies
you use to achieve this outsized result besides just working on Vue? I mean, you mentioned
posting on Hacker News in the beginning and writing blog posts. Is that something that
you continue to do?
So I don't write posts about the operations side of Vue much. Mostly, when we release
posts on Medium, it's about the technical stuff that we worked on. The new features
we launched, the new projects we launched. I think over time, what allowed us to compete
with these big company black frameworks is just, I think, consistency. And we were pretty
much always... We still are in this underdog mindset where there's a higher goal up there
we can work towards. And I think that's good because there's always these new ideas. React
today is still coming out with a lot of new ideas. Actually, I have a huge amount of respect
to the React team because they are pretty much coming up with all these leading new
ideas that make everything different. And Vue learned a lot from these competitions
in order to get where it is today. In terms of starting as an individual project, it's
really important that you just have this consistency. And I think there was a period of time where
I felt the pressure was like, they have all these teams, all these money and resources
to work on these things. Why would I keep working on Vue? It's never going to get as
popular as theirs. But then I realized I wasn't really trying to build this thing to compete
with them. I was trying to build this thing to fulfill a need of the developers that are
using my library. They are happy using my library. And my goal of working on it is not
to say I want to get all the React users to use Vue. My goal is to get people who already
like Vue like it better and get those people who are not using any framework to potentially
use Vue. I realized the whole tie for all this web ecosystem is huge. There are still
a lot of developers who have not used a single framework. And these are still big opportunities
for all these frameworks out there. And our job is to make sure you can capture these
developers, make their lives easier, allow them to build the stuff they want to build
easier. And if we can achieve that goal, I don't really care about whether Vue is bigger
than React or is bigger than Angular. That's not my goal.
What is your goal? I mean, how do you measure the impact that Vue is having on the world?
Do you count how many people are using it? Do you count the number of downloads? Do you
look at you said you stopped looking at your stars on GitHub? How do you know if you're
doing a good job?
There are some metrics that you look at. So npm downloads is very inaccurate. GitHub stars
is actually a very inaccurate metric as well, because it doesn't directly correlate to how
many people are actually using it in your product. That's more like an expressive interest
of people who may not even have used it. They will start it so that one day they will come
back and look at it. So the more relevant metrics that I look at
personally is the amount of people using our developer tools extension. It's a Chrome extension
that you install in Chrome. And when you develop a Vue application, you can use that extension
to debug your application. So this is a tool any... If you are using this tool, it likely
means you're actually using Vue to build real stuff.
So I look at that and conveniently, the Chrome Web Store actually gives you the number of
users that's the weekly active users using it, which is really nice. So I think currently
we're around like 690,000 users around the globe, which is approximately half of reactive
tool users.
That's huge.
Yeah, this number is the one that I personally use as a reference when we're gauging overall
growth. Actually, there was just recently a... There is a project called State of JS,
which is an annual project where they do a big survey every year and publish a lot of
statistics. That actually provides a good reference as well, because we're seeing Vue's
user a percentage. They actually do the statistics by counting users who have used it and would
continue using it. Users who have used it but will not use it anymore. And users who
have not used it but wanted to learn and users who not use it but don't want to learn about
it.
So you have all of these categories and Vue's stats is growing over time. And we get the...
I think we just hit the highest satisfaction ratio in this year's edition, which is something
really encouraging to us.
I'm curious how Vue's success has impacted you on a more personal level. And I'm sure
your life is way different now than it was when you first released Vue. What are some
of the changes that you like the most and what do you like the least?
The best part is being able to just work on something you like on a daily basis. And I
get to also completely determine my own schedule. I can work at the pace that I like. If I feel
that I'm less productive this week, I can take it slow. But if I'm in the zone, I could
just keep working 12 hours a few days straight. I can sort of adjust to my own pace instead
of always having to hit a deadline that's arbitrarily decided by someone higher up.
And another aspect is because I now work from home, I think I enjoy a much better work-life
balance. When I get off work, I walk downstairs. I work in my office upstairs. When I'm done
for the day, I just walk downstairs and work with family instantly. Before that, when I
worked in New York City and I lived in Jersey, I had to commute, spend close to three hours
every day on a bus, which is just terrible. So these are a lot of little perks.
And the worst part about it is probably just the overall constant pressure because now
everything is in your own hands. So if you slack off, you're risking to fail. Whereas
in a big company, you feel a bit more comfortable. Just like, this company is too big to fail.
I can just work slowly and not really worry too much. But when you're working for yourself,
this is just like any indie developer would have to have this constant pressure. Just
want to make sure you're doing enough work. You're constantly making sure your business
model is still valid, validating your ideas. Think about how your product was standing
the next three to four years. You just have to constantly be thinking about these things
all the time.
Yeah, exactly. It's like all the weight is on your shoulders. And there's really no excuse
if it doesn't work out. There's nobody else to blame. It's just you.
Yeah, yeah, exactly.
So a lot of people listening in are perhaps developers who are considering getting into
open source and building a project that they can somehow monetize or maybe building a tool
for other developers to use. What's your advice for somebody just starting out in this position
and what mistakes should they avoid making?
So when I built Vue, I didn't really think about monetization. But if you are building
something with the goal of monetization from day one, I'm not saying that it doesn't work.
It definitely could work. It's just that the monetization model that you have in mind must
have a good fit with the product that you're building, with the software you're building.
As I discussed before, things like Sidekick naturally fits better with a freemium model
because it's a server-side component, which these companies, it's easy to build for when
you have something running on their servers. Whereas a front-end framework like Vue is
a bit harder to do in that mode. But due to Vue's high exposure, we can go to a crowdsource
page, a sponsorship route, which doesn't necessarily work for a server-side project.
So you need to sort of find these... It's best if you have a close reference project
that you can sort of model after. But a lot of times, it also takes a bit of trial and
error. So there's definitely risk involved when you say you want to start out from day
one and do an open source.
So in fact, if your goal is to, say, have a successful business, I would consider treat
it as a product first and consider open source as something that complements your strategy
instead of, say, I want to do open source and make money at the same time.
That's really great advice. And I think it's advice that could be applied more broadly
to pretty much anyone building a business. There is no one single playbook that's going
to tell you exactly how you should monetize for your product. It really depends on what
you're building. And all of these different pieces of your business are connected. So
you really have to think about what am I building? Who's my audience when you're deciding how
much you're going to charge and what your business model is going to be.
Anyway, thank you, Evan, so much for coming on the podcast. I wish I could have you for
longer. Can you tell people listening where they can go to learn more about you and view
and the things that you're up to?
Sure. So I don't actually update my personal website anymore. But you can follow me on
Twitter. My handle is Yoyushi. That's my spelling of my Chinese name. Y-O-U-Y-U-X-I. And Vue.js,
our website is at Vue.js.org. That's where our documentation and all the information.
If your company is interested in sponsoring this, please do.
All right. Thanks again, Evan.
Thank you.
If you enjoyed listening to this conversation and you want a really easy way to support
the podcast, why don't you head over to iTunes and leave us a quick rating or even a review.
If you're looking for an easy way to get there, just go to ndhackers.com slash review and
that should open up iTunes on your computer. I read pretty much all the reviews that you
guys leave over there and it really helps other people to discover the show. So your
support is very much appreciated.
In addition, if you are running your own internet business or if that's something you hope to
do someday, you should join me and a whole bunch of other founders on the ndhackers.com
website. It's a great place to get feedback on pretty much any problem or question that
you might have while running your business. If you listen to the show, you know that I
am a huge proponent of getting help from other founders rather than trying to build your
business all by yourself. So you'll see me on the forum for sure, as well as more than
a handful of some of the guests that I've had on the podcast.
If you're looking for inspiration, we've also got a huge directory full of hundreds
of products built by other indie hackers, every one of which includes revenue numbers
and some of the behind the scenes strategies for how they grew their products from nothing.
As always, thanks so much for listening, and I'll see you next time.