10 Years of Independent OSS: A Retrospective

Hello, everyone. Really excited to be here. This is in fact my seventh or eighth time in Amsterdam. But I want to get into the talk quick because it was really late until I realised I only have 20 minutes and I have 40 slides or something. I'm going to try to go quick, otherwise I won't be able to finish in time.

This talk is about a ten-year retrospective into the ten years of work in open source. About me, I'm an independent open source developer, and I've been independent since 2016, so that's a bit over eight years, but my first foray into open source was releasing Vue.js back in 2014. This year marks a ten-year of working on open source and building in the open. I'm now based in Singapore and works full-time on Vue, Vite, and a bunch of other related open source projects. Before going full-time, I briefly worked at Google, and then at a start-up called Meteor.js. That's enough about me.

Things I work on. I work on two things, mostly. One is Vue, which is a front-end JavaScript framework created in 2014. How many of you have heard about it? Thank you. The other tool is a front-end build tool called Vite. How many of you are using Vite? Wow. Okay, great. So Vite was created in 2020, about four years ago. So let's talk about Vue first. It's a ten-year-old project. It took a long time to get there. But if we take a brief snapshot of Vue today, we have two repositories on GitHub, one for Vue 2 and one for Vue 3. Combine these two repositories, we have over 9,000 commits, 500-plus releases, 250,000-plus GitHub stars, 5 million weekly npm downloads, and 2.2 million users worldwide. This is statistics from our dev tool extension. It has over 1 billion-plus monthly CDN requests on JSDeliver. Every year, I look at these numbers and marvel at the scale that Vue has grown into, and I think it's probably, people have asked me the same question so many times. Did you expect this to happen when you first started working on Vue? And the obvious answer is no. I had no idea what it's going to be like. No expectations whatsoever.

Even when I decided I want to start working on it full-time. So it is a pretty amazing journey. But let's take a step back and think about, talk a bit about the early days. I won't dig into too much of the small stories of how it all started, why I got the idea. But the humble beginning in the early phases when I first launched Vue in February 2014, the result was I got a few hundred GitHub stars and I was over the moon about it. I was really excited. But that was just the beginning, so the excitement really didn't last that long, to be honest.

But let's take a look at the brief timeline. First release, with the name Vue.js was actually in 2013. It was private. I only put it on NPM but didn't tell anyone. The first public announcement is February 2014. It reached 1.0 in October 2015. 2.0 in 2016, 3.0 started in September 2018. And sublaunch, September 2020. 3.0 finally became the default in January 2020. And December 2023, we finally declared Vue 2 to be end of life. So that's a very, very quick overview, right? But I don't really want to spend this talk talking about all the little changes that happened over time about Vue. Because I want this talk to be more about the journey, the feeling, you know, the sort of how things have changed for me over the course of working on a project that grew beyond my expectations. So there were a lot of ups and downs.

A very obvious thing, if you look, dig into my GitHub profile and see, there is a graph here. So that's February 2014 when I first released Vue. And there were quite a few months right after that I didn't write any code on GitHub at all because I was quite burned out, right? So this happens quite a lot. How many of you here maintain an open source project? Not a lot of you. But if you've maintained an open source project over time, you probably experience some form of burnout, right? Because the expectation that open source users place on you, especially when you have a project that's grown bigger than you expected, is tremendous, right? So I like to make an analogy to this technology adoption cycle that many of you have probably seen. Usually when new technology comes out, there's this peak of inflated expectations. And then it just falls hard into this disillusionment phase where you're like, this is crap. And then you need to kind of just like get across that chasm to be able to go back to the slope of enlightenment and plateau of productivity at the end. So I make an analogy of that to open source involvement. When you get into open source, and this is personally for me, when I first got into open source, there is a peak of excitement and output.

I was like, wow, my thing is getting attention on Hacker News, it's getting GitHub stars, all these people using my software, and I'm trying to answer every single issue on GitHub, trying to fix every single bug. And then, you know, as your user base starts to grow, more flaws get revealed in the thing you thought that was perfect. And you realize, okay, maybe I could improve here, maybe I could improve there. Oh, wait, this other project has been doing this all this time, which I never thought about. Oh, I should maybe just close this project and ask people to use the other thing. Right? So there is very common for open source developers to go through this phase of burnout and self-doubt. And it's the same for me. And there have been multiple times that I have been going through this kind of thinking whether I should continue working on this, does it even make sense? Is it still worthy of pursuing and putting in all the time? And just the sheer amount of pressure you get, every day you wake up, you get 20 issues of people finding your software just does not work. That's tough, okay? So over time, I've learned to adjust, readjust. Over time, I've learned to just find peace with myself, and acknowledging that things cannot be perfect. And I think for most open source projects and for most open source maintainers, there is this process of once you get into this sort of burnout phase, a lot of them just never get out of it. They just stop there, they abandon the project. And that's why we see all the churn of different solutions coming up and go. Right?

If you can get past that chasm, and you find peace with yourself, and you're like you find a good balance of understanding your responsibility, and the limit of your capabilities, and drawing a good line between how much you want to put into your projects and how much you want to get out of in life, right, you need to find that balance to be able to keep working on open source productively. And that is not an easy thing to do, right? So, this is when I first released Vue, and there are multiple other phases in my career where I just stopped writing code for a few months. I'm like, I'm done with this. I don't want to do it anymore. But then I come back. Eventually, right? So even today, sometimes, you know, like I pulled the whole graph of like all the way from 2014 to 2022. And there are just multiple life events, right? Open source maintainers also have all these things going on in life, having babies, moving to new places, having COVID. So my whole point here is when people think about someone who's like me who's been working open source for ten years, it's not always smooth sailing. We have to just like go through a lot of challenges and just finding what is meaningful to us to keep ourselves motivated in working on these things. So my hope is when you're using an open source project, not necessarily from me, but from any other person who kindly shared their work with you for free, think about what they have gone through in the time that you don't see, the effort they put into it, maybe the burnouts they've struggled through. And just appreciate it a bit more. And think about giving back. Think about supporting them. Think about, you know, contributing, helping them fix issues, or donating, sponsoring them. So many ways you can help. And for me personally, a lot of the struggle comes from also handling the growing scope of the projects, right? Vue as a framework, you started as a very simple script that you can include your script tag on a page and it will just work. Over time, the scope just expanded so much.

Outside of Vue core, we also have the documentation which we have like hundreds of pages of all these detailed information, right? And need to be kept up to date. We have the official router, we have official state management libraries, we have the build tool chain, which somehow I ended up building a build tool myself because I wanted to improve Vue's tool chain. And then there's IDE support, which is trying to get all the typescript and CSS, embedded language, working nicely in Vue single file components. It's very complicated. It's a lot of work. And then there's the browser dev tools. We need to keep the whole ecosystem in sync. When we did Vue 3, it took us two years to get all these things up to date with Vue 3. So, you know, handling the grown scope was extremely challenging.

And then we also need to deal with a lot of tough decisions, right? The Vue 2 to Vue 3 transition, if you are a Vue user, you probably know it was not smooth. There were lots of mistakes made and lots of lessons learned. We also had pretty much reinvented the framework with composition API which opened up a new paradigm but also created fragmentation. Some Vue users prefer the old APIs. We have to go through lengthy discussions in RFCs and debates, trying to convince people that this is actually a good thing that can help you in certain ways.

A realisation eventually that I got from all these struggles is that I'm just one person. I can't write all the code. I can't answer all your questions. I cannot fix all your bugs. And that is fine, because the project is no longer just me. It's a community. So I will be like Steve Ballmer and repeat this as many times as I want, because this is just so important, because this is what made Vue possible. You see, I struggle as a single person, but we pulled it through because it's not just me, it's a whole team, a whole community. So, Vue wouldn't have been where it is today without the people around it, right? That's why we say open source is about people. So here's my deepest gratitude to our team members, contributors, ecosystem library maintainers, sponsors, conference meet-up organisers, community partners, advocates, all these people, not just contributing in forms of code, but just contributing in making people connect around the project, and helping it improve in every aspect possible, right? In the same time, my role kind of started to transition from just writing code. Sometimes I do wish I could just focus on writing code, but nowadays, there's just a lot of work outside of code that's about mentoring people in the ecosystem, helping team members grow into bigger roles. Technical direction, just like trying to making sure all these projects are moving cohesively. Community management, pretty much tweeting. Sponsor relationships. We actually had to make the project sustainable, and that's a part of Vue that I'm pretty proud of, and then there are commercial partnerships. There are companies building on top of Vue, building in the Vue ecosystem, and they want to collaborate and give back to Vue, and so all these kind of relationships that we have to manage just outside of work.

It's kind of like a full-time project management outside of just writing code. Something I'm really proud of is we actually distribute a very fair amount of money to Vue and Vue contributors in our ecosystems. Every year, we actually distribute more than $270,000 to our contributors in the ecosystem. Plus full position and sponsorships our contributors receive due to involvement in the projects. Sometimes, we would, you know, some contributors, for example, to Vue or Vue would land a job because a company wants to hire a core contributor or want them to keep working on these open-source projects. So opportunities created.

On the technical front, I just want to mention a few things. Despite being a ten-year-old framework, we are still shipping very significant internal improvements. We just recently had a 2x faster rewritten parser, we had 3.9x improvements in SSR benchmarks, and we had a new upcoming release in 3.5 that reduces the reactivity system memory usage by 56 per cent and improves dealing with large reactive arrays by up to ten times. So we're still well alive and shipping very significant internal changes. And then there are more ambitious stuff going on like Vapor Mode, this is a solid-inspired compilation strategy that takes the same Vue component syntax and outputs something that is more performant. Currently, it is still a work in progress, but we're almost done with the components, and the next stage is really trying to be able to allow users to invent Vapor components in today's Vue applications. We have a new dev tool that is coming up that just have better UX, more features, more performance, and smoother.

Another thing I want to mention about the Vue ecosystem is the collaborative mindset. The Vue community has been the source of multiple efforts that benefited the entire JS ecosystem beyond just Vue, right? So V to be the primary example, and then there is Volar which is the underlying framework for our IDE support but it is actually now also being used to support other embedded languages like Astral, or MDX, and JetBrains is in fact using Volar to support, trying to use that to support Angular language server as well. So cross-framework utilities like in the unjs section, if you've never checked it out, search for it. It has a lot of nice stuff that you can reuse. They come from the Nux team, but they are framework agnostic, and Nitro is a server-side framework that allows you to more easily build a full stack framework combined with Vite. I have only three minutes left so I have to go really fast into the Vite part.

Let's talk about Vite. How it started, April 20, 2020, as I was going to bed, I just had this, it just clicked how to do hot module replacement over an ADBSN. It did it and it became Vite. This is how it is going.

We just recently crossed 13 million weekly downloads. That is, how much is that? More than 15 million per month? We have a huge ecosystem of all the tools that either is built on top of Vite, or supports Vite, or leverages Vite to some extent for some of its features. You probably see a lot of familiar logos here. So, yes, in perspective, we are probably now at half of webpacks. Hopefully we can see that gap shrink further later this year.

The philosophy of Vite is we want to build a build tool that is lean and extensible, push for the modern web, we take a pragmatic approach to performance, and we want to support higher-level frameworks. We want to build a collaborative cross-framework ecosystem that everyone is trying to build something better for the web, and everyone can focus on innovations that matter instead of reinventing the wheel, because Vite has become the shared infrastructure layer.

Along with the technical side, Vite has grown a very amazing cross-framework community. This is a picture from the Vite team panel at Vue.js Amsterdam last year, also in Amsterdam, which is really cool. We have contributors from all over the world, from different frameworks.

What's next for Vite? We want to do two things. The first is Vite internally in the current Vite release line, 5.3 and Vite 6, we want to do environment API which is focused on better supporting meta-frameworks that we have today. On the other hand, we want to improve Vite from the very bottom up. We're building a native one on top of native JavaScript toolchain called OXC. to better support frameworks that run in multiple environments, browser, Node.js, workers, and it's currently experimental in Vite 6 alpha. This is more framework author-oriented, so I won't dig too much into the details, but the idea is we are actively listening to the needs of people building on top of Vite and trying to come up with better abstractions so that all these different frameworks can reuse the same primitives to better support their high-level needs.

Rowdown is a Rust-based bundler designed for Vite. It is created, the project is started to address a few problems in Rowdown, namely we need better dev and prod consistency, better production build performance, and we need better production build asset quality. To achieve these goals, we essentially are trying to build a bundler that stands on the shoulders of giants, right? So, we want the speed of VS build. We want the plugin ecosystem of Vite and Rollup. We also want the production assets control of Webpack, right? There are nice things about these existing bundlers that we want to put them together and tailored for the needs of Vite, and that is Rowdown. So Rowdown right now is in a working progress. Milestone one library bundling is complete, and the next step we are working on are Vite and Rollup plugin compatibility and advanced chunk control for app-oriented output, so advanced chunk splitting and model federation in the future.

We also want the production assets control of Webpack, right? There are nice things about these existing bundlers that we want to put them together and tailored for the needs of Vite, and that is Rowdown.

So Rowdown right now is in a working progress. Milestone one library bundling is complete, and the next step we are working on are Vite and Rollup plugin compatibility and advanced chunk control for app-oriented output, so advanced chunk splitting and model federation in the future.

LXC is the foundation Rowdown is built on top of. Author Boston has another talk that is later going to be streamed remotely about LXC, but, in general, it is a language tool chain for JavaScript written in Rust that includes a parser, a transformer, a resolver, a linker, a formatter, and a minifier.

Our end vision for this is to have the V team, the Rodan team, and the LXC team work together to create this unified runtime agnostic toolchain for JavaScript and the web. The meaning, the value of a unified toolchain is now we can have a consistent AST format that handles everything. Pretty much the vision that Rome was originally created for, but somehow never achieved. I think now we have a much better chance to actually have it realised because we already have many of these parts built, and many people are already using this, and we do see a really good opportunity to build this foundation for more exciting future possibilities, right? These things don't necessarily have to be built by us. It could be built by you on top of the stack that we provide, so efficient interop between Rust and JS plugins, code instrumentation, advanced asset optimisations, and the reason we focus so much on performance is because you do need extreme performance to unlock the budget for you to actually do these advanced things. Otherwise, we are focusing on getting our builds fast enough to save CI minutes, right? Join us if you're passionate about the future of JS tooling, check out these projects on GitHub, and we welcome any form of contribution and involvement. Thank you. APPLAUSE.

Pretty much the vision that Rome was originally created for, but somehow never achieved. I think now we have a much better chance to actually have it realised because we already have many of these parts built, and many people are already using this, and we do see a really good opportunity to build this foundation for more exciting future possibilities, right?

These things don't necessarily have to be built by us. It could be built by you on top of the stack that we provide, so efficient interop between Rust and JS plugins, code instrumentation, advanced asset optimisations, and the reason we focus so much on performance is because you do need extreme performance to unlock the budget for you to actually do these advanced things. Otherwise, we are focusing on getting our builds fast enough to save CI minutes, right? Join us if you're passionate about the future of JS tooling, check out these projects on GitHub, and we welcome any form of contribution and involvement.

Thank you. APPLAUSE. We have gotten some of your questions. You can still send all of your questions to Slido, please. We've gotten quite a few, so I hope you're ready. First off, people want to know how do you make a living as an open source dev? You mentioned sponsorships a little bit, but how did you do it in the early days? It's mostly sponsorships. In the early days, there was a friend who was a CTO at a company called Strikingly, and they're a big Ruby shop and they've been involved in open source for a long time. When the CTO was my friend, and when he heard about my plan of doing more open source, he decided that the company would put their open source support fund to support me for six months, so that really helped in the early days, but then I started to get, I think, when I decided to do it full time, I had about $1,500 a month from Patreon. And, luckily, it just kept growing over time, so now we have a pretty stable source of donations from sponsors and we also have partnerships with people who create paid content for Vue, and then we collaborate with some companies who are building commercial products on top of Vue, so there are combined different sources of these. Multiple sources.

Great, thank you for that. The next highest rated question was, where can I get this awesome hoodie that you're wearing? This one? Unfortunately, it was made in small batch only for the team members, but if people want it, we can maybe ... Contribute a little bit more and maybe ... We will probably make it, yes. Another important question. At the beginning, how did you make sure that you could raise awareness about your open source projects? Tweet a lot. Tweet a lot! I don't tweet as much as I did in the early days, but I think when I just first started out on Vue, I would just jump into every Hacker News discussion or Reddit discussion about front end stuff and try to get myself seen, but I no longer do that, but in the early days that's probably the lowest cost of way to doing it. Right, thank you. Then, we've recently seen bad actors embedding themselves into open source community to deliver malware. What is your view on this problem? Sorry, what is the question? To deliver malware. I think this is definitely a concerning problem. There are a lot of things in open source that's built on top of goodwill, and we just assume people are nice, so that kind of opens up loopholes for bad actors. It's unfortunate because people will abuse the goodwill of the open source community and force us to be more cautious, and then corrupt the trust that we have built along the ecosystem. It's sad, but I think, since that has already happened, people have just to be more vigilant. We've actually gotten outreach from the JS Foundation about some things that's related to Vue in the past as well. I think, as maintainers, we just have to be more vigilant, and as users, you can also help by reporting whatever you think is suspicious.

Thank you. Definitely a concern. Let's see, which one? Right, let's do this one. Isn't testing missing in your vision? I didn't include VTest in the graph, and I apologise to Vladimir, who's the lead maintainer of VTest. But VTest is a very important piece of the toolchain as well, and it'll be able to leverage the same underlying parts that we're building for VT, because VTest is built on top of VT. Yes. All right, perfect, so shoutout to them.

With a growing community, sponsors and other stakeholders, how do you align on new ideas and determine the direction that Vue is heading towards? We mostly focus on the needs of the community. The thing about Vue's sponsorships is, we don't have these single big sponsors that would be able to dictate the technical direction of Vue. The source of sponsorships we get is very evenly distributed, so no single sponsor actually has a say on what we should do next. It's pretty much no strings attached, and we're very explicit about it, so if you sponsor the Vue project, we won't really do anything special just for your needs. We want to be mostly focused on what the users need, and trying to also gauge what the general trend of where the ecosystem is moving towards, so we want to make Vue stay modern, stay competitive, but also focus on the real problems that are reported by the users.

How difficult was it to let go and accept that other people have opinions and also want to contribute to your projects? I think in the early days, definitely when I first started out, you tend to think, of course my framework is the best, and anyone who thinks it's not the case is wrong, and I will debate them on the internet, but, you know, after a few years, you realise the web is very huge, the ecosystem is huge, it's very diverse, people have different opinions, people have different preferences. Some people come from a Java background and they just like things that look like Java. Some people coming from a functional programming background, and they just want to have functional components, and some people starting with simple HTML CSS will find Vue more familiar and more friendly to get into, right? So I think it's really futile to try to convince people who are just not your target audience to agree with you, and I think that's pointless. The goal for all these frameworks to co-exist is for each of them to find their happy audience, so that their users will be on a happy path with their chosen framework, and everyone gets more productive. I think that's the good outcome we want to see, right? So it's not about converting people who doesn't even like your stuff to become a user. That's pointless.

How do you see the future of Vue? Do you have any web assembly inside? Unfortunately, no web assembly. I think people have asked about would you allow people to write Rust and let it run in the browser. I think in general, the performance scale that we've seen from all the experiments just doesn't really justify the complexity added on top, especially when you think about Rust compiled to or other languages compiled to web assembly, it's already slower than actual native binaries and it's also not really comparable to the real native level performance you'd want. And then there's the overhead of communicating between web assembly and the DOM because the DOM is always going to be there and it's always going to be a major bottleneck. And then, for example, if you run virtual DOM diffing in the web assembly thread, there's a lot of data you will need to pass between web assembly and the JavaScript main thread, and that's the realisation of the cost offsets a lot of the performance gains, and now you're left with a lot of extra complexity in your build set-up and distribution, but not really noticeable performance gains for probably the most day-to-day use cases. There are good places where, for example, you want to do video encoding in the browser, you probably should, you know, leverage something like web assembly, but using it to write your day-to-day component code? I don't think that's a good idea.

Thank you so much for answering all of these questions, and thanks, everyone, for asking questions. Please keep asking everyone questions throughout the event. This is great.