Anthony's Roads to Open Source - The Set Theory

And it's a great honor to be here and thanks for having me. And yeah, just for me to introduce myself a little bit, I guess I'm a kind of new face to React. So my name is Anthony Fu and I'm the creator of Vitesse, LightDate, Unocss, and also the coordinating member of Vite, Vue, and Nuxt. I also maintain a few projects and I'm currently working at Nuxt lab on the framework team, so you can also find me with the links below.

And as you can see, at front-end level, like a front-end framework level, I'm pretty much from the Vue community. And this is actually my second time attending a React event. And this event is awesome and really make me feel home because here we have the React with a color of Vue. Yeah. So thanks everyone to make this event possible and it's my great honor to speak and share my perspective with you here. So as I don't really know a lot about React to talk about, so here's the deal. So I will talk about something you might find interesting outside of React and you're gonna teach me how to properly use use-effect hooks later on, all right?

Okay, so as you can see, I'm working on multiple open source and also create a few projects that you might already using, like for example, Vitesse, a unique testing framework. And as someone who has been working on open source for a while and made a living, I have to say that open source is so much fun and rewarding. And I believe that many of you want to contribute to open source already doing so. So however, there's like so many factors that to say if an open source project becomes popular or successful depends on how you define it. Like for example, the quality of code, the documentations, the communities, the marketing and so on. All of them are important and they're related to each other and there isn't a really like a golden rule to say how you can make an open source project successful. And so here, I'd like to share some of my experience and ideas of creating and maintaining open source project and combining with some observation I have learned from the community. So hope it can give you some, hope it can help you to start your own open source journey or find some new ideas to improve your existing project.

So open source is quite a big topic and I couldn't really cover everything in one talk. So this I'm trying to break down into like talk about different aspect of open source in each talk and make them a series. So this is the first one and this is the first part and talk is the set series. I know it might sound a bit random and you might wonder what that means and I will try to explain. So, let's say we already having an open source project or planning to create one. And like to be a little bit practical, say we want to gain us a certain amount of users, a certain amount of adoptions or we just want people to enjoy using it and to enjoy our hard work. So, one thing to consider is how we're picturing our target users. Like, for example, is my tool for end users or for developers or is that for view developers or for react, etc? So we know that's a fact, that's amongst all of our target users. Only a portion of them will become our actual users and also depends on a lot of things, right? And depends how you're marketing it. And in order to get more users to our project, we could try to convert more potential users to the actual users, like maybe by doing more marketing or polishing it. In that case, the amount of target users you have, the bigger circles, actually becomes the upper limit of how many actual users you could possibly have. And on the other hand, we can also try to find a way to expand our target users to include more people.

So naturally, you will also have a more converted actual users from it. So under these ideas, let's take a look at some examples of how we can do that. The first example I'm going to show you is actually my first open source project back in 2019 and the repo is called VS Code-View-I18-LA. It's a VS Code extension that helps view developers to deal with I18, with so-called internationalization, like preview the translation in your code or manage the keys for each language, etc. And here's a screenshot of the extension that shows you the basic feature and hopefully can give you a basic idea of what it is. And the extension is not the main topic today. But at the beginning of this project, I'm eager to kind of see that I want to make this project popular, as I really want to prove myself in open source. I'm super happy when I got the first 100 and 200 stars. And then I received an appreciation from the community. But after that, you kind of started to seek for higher goals. Back then I was dreaming to work in full-time open source, like for example, like even you, the creator of Vue. So my ambition was to create something as popular as Vue. And then suddenly saw the, like, there is a fundamental difference between my project and Vue. And there actually directly reflects on the project name. So you look into the name, it's actually quite long and composed by multiple words, while that's Vue, it's only Vue, right? So let's break down it part by part. So first, that is a VS Code extension. So that basically means that only VS Code user will ever use this extension. So we can draw a circle to indicating the VS Code users here. And then we have Vue, because it's built on top of my need, I use Vue, so we could also have a Vue, like a Vue user circle. And then finally, it's a helper for internationalization. That means it's not all Vue users will ever try this extension, because not every app needs internationalization. So we can draw a circle for I18 as well. And then we find out that our target users are actually inside intersections of those three sets, meaning that only Vue developers who is working on editing app that happen to choose VS Code as their editors would ever try our extensions. This sounds quite limited. And this is, like, a phenomena called the set intersections. So before diving into the solution, let's also look into this graph to see what the others' intersection means. And then we soon realized that the intersection between VS Code and Vue are actually Vola's or Vita's at that time, is the VS Code IDE support for Vue. So as a result, we knew that both Vita and Vola has a huge user base, because both Vue and VS Code have huge enough community to make the intersection large enough. Similarly, we also had the intersection between Vue and I18, a project like Vue-I18-Ally, which is super popular. And then when it comes to the intersection between VS Code and I18, we see there seems to be not such a project at that time.

So straightforward thinking, like, how about we can do that? We can be that one, right? So in practice, we can try to make the extensions decoupled from Vue. So that means it can be used for the other framework as well. So in short, we might be able to make things more universal by breaking the set of circles and expanding intersections. And that's how I did it. I took some time to do a huge refactors, a plugin interface, and make the core feature universal. So like the version 1.0, I renamed the project from Vue-I18-Ally to I18-Ally. And from a Vue-only extension to a universal I18 helper for VS Code that can support a wider range of framework. And also even including backend framework like Ravel, Ruby on Rails, and even native targeting frameworks. And then it's also customizable and expandable. You can build your own framework integrations with a config file.

So when it comes to numbers, we can see a steep increase on the stars at that time when we're doing the release. And the stars almost doubled within a month. And at that time, that really means a lot to me. Especially for me, that's when I just getting started into open source. And the thinking of making things universal really changed the way I work in open source later on.

And then let's talk about another example, Vite. So Vite initially was an experiment of a development tool, tooling for Vue when Evan first started. And then ideas seemed to be working quite well. Evan decided to make it as a framework agnostic by extracting the Vue handling into a plugins and polishing the API. And then we have the Vite we know today, the shared infrastructures under so many frameworks. So I'd say that Vite's success turns out to be far beyond our imaginations. It now has an incredible huge community and ecosystem. And basically, all modern meta-framework are built on top of it. We have Svelte, Storybook, Astro, Solstice, Nuxt, Quickcd, and many more. And we're also very glad to welcome Remix to join the party recently. Oh, it's a Vue React router, right? And the collaboration across multiple frameworks and the community is really impressive. Vite becomes the shared core logic for web toolings. And so many meta-frameworks now don't need to worry about those underlying details and can focus more on the features and capabilities of the frameworks it can provide. And then any improvements made in Vite will also benefit all these downstream frameworks, and that is truly making the web better together. And here are many factors that Vite reached out what it is today, but I would say that's been extendable and agnostic, really within the door for the community to join and contribute.

So one example I can think of is React Query. They started with a query for React and then also provided a Vue version called Vue Query. And as most of the front-end frameworks like Svelte and Solid come into the game, I believe they realized there can be something more generalized. At some point, we see that Vue Query has been merged into React Queries into a single repo and widen the scope and rename it to TensorLite Query. And having a more universal solution that works for many other projects, other frameworks as well, and according to their documentation. And today, we see that Solid, Svelte, and Angular are also supported. So TensorLite seems to be trying to expand the ideas even further to providing more universal building blocks like routing, like routers or headless components. So kudos to them. So we know that by making our project more universal, meaning we could reach out a larger user base. And also naturally, we will have more contributors to join the force and work together. And trying to refactor things becomes universal and also helps us to revise our design and abstractions. This often could end up with a more maintainable and extendable architecture. And finally, if your project starts to gain more usage from various needs, making improvements to our project will also end up benefiting everyone in the ecosystem. With that, I really encourage library authors to think more about that way and try to seek for collaborations even across ecosystems. So we know that being universal has a lot of great benefits. Well, actually, I want to say that it's like being specific is not a bad thing. It allows us to provide a tighter integration and a better developer experience, but how can we balance that?

And let's take a NUX, a view meta framework that I have been working on as an example. So other than self-host Node.js server, we also want to... There's also many hosting services out there, like for example, Cloudflare, Vercel, Netlify, etc. In NUX, we don't want our users to be stuck on a single platform. By writing, we want to offer the choice for our users to pick based on their need. To leverage the full potential of each provider, we want to utilize the edge rendering and serverless function based on what each platform offers.

And one thing to note is each platform, they actually have their own format, and some of them might come with specific tooling you might need to use. That means NUX would need to support as many platforms as possible built-in. So we made the integrations and even support autodetection, so with the app, it can read in an isomorphic way and deploy to various platforms without changing any configuration. And then we realized this is a problem probably every meta framework has to deal with, and it doesn't have to be NUX-specific. So we extract this to be a standalone tool called Nitrome. It's a universal server builder, and it's pretty much like Vite, but for servers.

And with Nitrome taking care of the details of dealing with servers, it actually allows Nux to have a more clear architecture and to only handle those about like view-specific server-side renders and APIs. And also, since Nitrome is a general-purpose server tool, we see there's more and more framework starting to use it and collaborate with us. We have Angular, a popular Angular. We have Analog, a popular Angular meta framework that's migrated to Nitrome. And then, last month, they announced 1.0 release. And Stack's a fantastic meta framework, and we also have SolidStack. The meta framework comes from the Solid team. And even without a framework, I also find Nitrome to be very handy to build pure API servers. So I'm looking forward to see there's more framework joining it and work with us.

And, similarly, in terms of bundling tools, Nux 2 was built on top of Webpack. And in Nux 3, we want to keep the support Webpack for compatibility and easier migration for existing users. While that's we also love the innovations and developer experience on Vite. So we try to support both tools interchangeably, and it will provide first-party integration to both Webpack and Vite, and pre-configure it so ideally a Nux app could work the same with both tools and depends on your tooling needs. However, we know that in that architecture, that means, as well as the plugin systems are quite actually different from Webpack and Vite. For example, if we need to add some transformations to some modules in our pipeline, we should mean to implement this logic twice in each plugin format. So this basically doubles our work, as well as the effort for the community module to support the both build tools. Then, this is the initial motivation we create Unpluggin, and unified plugin interface for both Webpack and Vite. With that, we are able to save a lot of efforts to dig into the details of the misalignments of each tool.

With that, we are able to save a lot of efforts to dig into the details of the misalignments of each tool. And since Unpluggin get extracted as a standalone tool, it also form its own community and its band scope to support more build tools like Rollup, ESView, RSPack, Rolldown, Fon, Bung plugins, and possibly more in the future. With the work done by the Unpluggin community, it also opens the door for a meta framework like Nuq to support more build tools and a wider community. So those are just two examples. And we also have like onjs community that providing many high-quality tools throughout the JavaScript ecosystem, and actually Nitrome and Unpluggin are part of the onjs community. And we also have vidnode, made from Nuq's server-side code executors and later becomes a core engine of Vitest and made it possible. These tools are created by Nuq's- it's created from Nuq's need, but later we extracted them to make them universal. And since then, we have formed their own community and ecosystem that can benefit a wider range of users in scenario. And Nuq can still be opinionated and view specific framework that providing better developer experience while the underlying tool can share and collaborate with the other framework and community. And that's where it makes open source amazing, isn't it? So different from set intersection we were talking about, I would call these things- I would call it the set union, which draw the universal part, expand the scope, and grow the community, which eventually will benefit back to ourself.

So to give another more- to give another example more related to React, I picked ChakraUI. I got pleasure to chat with Sage about a more deep inside of a story behind it. So back in 2019, ChakraUI was created as a React component libraries, and soon, like someone from Vue ecosystem made a Vue version, and they decide to have that Vue version as official as ChakraUI Vue. And over time, they find that maintaining two frameworks support are basically duplicating their work, and it requires a lot of effort to keep them in sync. So in 2021, they come up with ZEC, a universal state machine library to extract the shared core logic for components across frameworks, which works with Valina JavaScript and also providing binding for React, Vue, and Solid. And then in 2022, they come up with- they come up with Pandas CSS to extract their CSS in JS solution to a compiled time universal that has first-class integration to basic every meta-framework out there. With those building blocks, later they make RQI, a headless components libraries built on top of ZEC. It's providing more user-facing component interface, and it also support React, Solid, and Vue. And this year, they are migrating the next major version of ChakraUI to use ARC and Pandas under the hood. So once it's done, it makes Chakra a more solid foundation inherent from ZEC and ARC, and also can- it becomes much more easy to maintain across frameworks. And in this case, Chakra could still be in the specific, and to be a styled opinionated libraries while- but with- has a better core. While the tools they build along with it could serve a wider community that becomes a general solution. So it will be much more easier to add new framework support later on, and especially it will be good for a new racing framework to gain a better ecosystem without too much effort.

To wrap up with this topic, I'll bring up this idea called the Set Theory I composed with two sections, Sets Intersection and Set Union. In intersection, we learned that we shouldn't limit our project to only be a niche spot. We should proactively seeking for the possibility to make the projects more universal by breaking the circles and enlarge our scope. And in the unions, we learned that even sometimes we have to be specific in order to achieve something great, we could still seek for the potential union from our underlying tools to expand the community and benefit the whole ecosystem. It's all about collaborations and communities, and I have a strong belief in open source, and this is a way for us to build a better world. I'm looking forward to see more and more open source with building to a similar mindset and find a better way to collaborate. So that's all for my talk.

Thank you, and you can find my slide at ntfu.me. And then we'll jump into the first question, and that's from, well, there's actually two people that want to ask if you use SlideDev. Yes, I do. Yeah, yeah, yeah. So big shout out to SlideDev. I think out of the 10 presentations I've seen today, like, 9 have probably been SlideDev, and it's looking pretty sharp. Oh, good to hear. All right. Next question. Do you think making the library more agnostic requires deeper and interdisciplinary knowledge? I think it does. I mean, when it becomes agnostic, it becomes more challenging than, like, you hardcore everything, right? Like, if you take it very extreme, you're hard-coded, and you're kind of providing a loose, like, there's a transition between hard-coded and very agnostic, and you have loose integrations or more coupled integrations. And I think that, in the agnostic way, is way harder to achieve, where I think I would recommend to go with a progressive approach, is that you can first do something that works, and then you can later, based on the feedback from the community or based on the feedback on the usage, and you have, like, a better foundation to see what can be better unified, and then you can progressively go into that approach to have a wider audience. Yeah, that's really hard to do, to make anything for a framework you don't know by heart, yeah. So, yeah, really hard to do, but if you have the community helping, that helps. Helping open source. A question from Anonymous. Any thoughts on Node.js versus other runtimes? If you had to bet on a single runtime, which one would it be? Ah, that's a very interesting thing, because in ARM.js, what we do is we try to build libraries that works for every runtime. So, because we all follow the same, like, IcecreamWinterCG, and also the same efforts to have a standardized JavaScript runtime interface, so we could have libraries that are working on multiple runtimes, and supposedly, they should work together as well. So I would say as a library author's perspective, I would serve a larger audience as possible, so I want my tools to work on any runtime. So everyone with a different opinion, with different specific needs, they can still benefit from the work we've done. Yeah, but you're trying to make tools for everyone, but it's open source and there's no financial incentive for doing that, right? It's just your own desire. I mean, it really depends, like, how do you connect with the financial incentive. I would say that's... I mean, I mostly build things with passion, and I don't really care about the business side, because I think... I would consider that that's another job, you know. It's not a part of it. But I mean, as a... For Nuxt, it's like, our incentive is Nuxt is a company, but we sell product on top of Nuxt. But we want to keep Nuxt as a neutral, as an open source project. And as Nuxt get a more stronger community, and also including the downstream, like Vue and Vite, they will all benefit back to the company, their product.

That's our incentive. It's like, we want to make JavaScript, or the web better in any way, and then we have a bigger market, and that makes, kind of, align with the company's vision. Yeah. Yeah, I mentioned the financial incentive more because you need to eat, right? That's why... At the end of the day, we can all be as good for the world as we want to, but at the end of the day, you need to eat.

Drawing on the XZ backdoor fiasco to highlight how fickle open source maintenance modules are, how freely do you think we should expand the scope of our projects? The XZ backdoor fiasco. That doesn't mean anything to me. Not directly, yeah. I think my perspective is, if you look into a license, it's the bare minimum to say that open source is provided by free, without any guarantee. That means if you have a bug, and the maintainer is not really responsible to fix it, that's the license, right? But in reality, it's not working that way. If you create issues, or if you're helping with the community... Actually, a lot of open source communities are very active and actually very willing to help and improve the things for everyone. But on the other hand, it is like... I would say that open source is not free, while the maintenance is not without guarantee. We guarantee the project working at some extent, while we also would require some financial support in some extent to make things sustainable. So yeah, I think the XZ things is something that we see that, when it's going to down to the dependencies, they don't really get recognized, and they don't get enough support from the community, because no one knows they are actually using it. So what I see is as an open source project, I would encourage the project to work helping with each other. So what do we do in Vite? We also see ES linked, and I'm also doing my own. We were forwarding our sponsorship to our dependencies and make sure those... Even if they are not front-facing, but they still get some support from the community financially.

Okay, to piggyback on that. Who here works at a multi-million dollar company? A few hands. Okay, a million dollar company. Big company. All right. Who uses also open source, if you're at a big company? Who supports, or whose company supports open source also? Okay, okay. Nice, nice, nice. Okay, that's good.

Nice, nice, nice. Okay, that's good. That's good to see. Thank you.

All right, next question. How do you find time to work on open source? Does your company pay you to work on most projects? Yeah, for me personally, yes. So I'm on the framework chain. So I'm mainly on the Nuxt framework, and Nuxt is open source. So in a way, they are kind of supporting me for time to working on open source. And also maintaining the ecosystem, like working on Vite, or improving Vue, is also part of my job because they are all related to each other. That's a very nice job to have.

Next question is from Costas. What is your advice to someone that wants to switch from a software company to an open source product? Switch from? So they want to start making a living as an open source maintainer, I guess? So to be completely honest, I wouldn't recommend you to set your goal to be working full-time open source. It's something you could, by chance, happen. But I would say that it's all down to the expectation. You shouldn't set your goal to be working full-time because open source is really hard financially. And it's only when you have enough free time, then you can try. But I would say you don't set this expectation. You don't have any promise on this. It will be better mentally, and it's actually easier for you to achieve that by accident or by luck. I mean, it requires a lot of luck, I would say. I'm surprisingly lucky and privileged, and I appreciate all the community to give me the chance. But on the other hand, we do want more people to come into open source. But you also need to know that there is problems on open source, and those are things that we are consistently trying different solutions and trying to figure out if there's a better way to support open source and get companies to aware these situations more so we can have more fun to continue doing that. But in a way, I think open source is super meaningful, it's super useful. So that's why I will just keep doing this, and that's my passion aligned with it. Yeah, nice. Thank you.

Next question. How will people start contributing into existing open source projects? Yeah.

I think you should be the users of libraries first. I wouldn't recommend you to say, I'm looking for a project to contribute, but rather I use this project, and I find there's something potentially could be improved, or there's some bug I could fix. Like you encounter something, and that becomes your pinpoint, and then actually you have the incentive to improve it because if you fix it, eventually you get a benefit. If you're being blocked by it, you fix it, you can move on, something like that.

So I think in that case, you can more proactively seeking for these things, like if you find a bug, you can more proactively report it, or give it a try to see the solutions. And of course when you read the documentation, you find a typo, you send a PR for fixing the typo. That's totally valid contribution, and we appreciate that. And also it can be a way for you to get into open source, because you need to also be familiar with the workflow on GitHub, send PRs, but later I would encourage you to contribute based on your need, and as you use it more, as you go into deep more, you will know the project better, and then you can contribute more, or maybe become a team member.

I think it was the React issues on GitHub, they have a label called First Good issue, right? Yeah. Is that something that's only for React? Or is that like an open source global thing? It's actually a GitHub, if you create a new repo, the label is actually added by GitHub by default. So it's a common practice like libraries, like some libraries would do. And I would actually use another library called PR Welcome. But I mean, each project would have something like that. But I mean, if you enjoy helping the others, and that would be great as well. And yeah, as I said, I would encourage you more to come with your own need. Yeah, fix your own problems, basically.

And I think I'm a big practical person. I really, at the beginning, I really care about stars, and I really want to seek for like success on numbers. I mean, you shouldn't care, in a way, but I mean, I do. And like, I mean, just human nature, right? So at first, I kind of tried to think a way like how can I share my solutions or... I made something cool, I want to share it, and that's open source. And so I tried to send it like a Reddit. Like I made an extension, and I sent a Reddit to the Vue Reddit, and also I joined some Discord server and I shared my things there. And then actually, the author of Vue, IA Qing, he got me the first star, and then the traffic comes in.

I mean, you shouldn't care, in a way, but I mean, I do. And like, I mean, just human nature, right? So at first, I kind of tried to think a way like how can I share my solutions or... I made something cool, I want to share it, and that's open source. And so I tried to send it like a Reddit. Like I made an extension, and I sent a Reddit to the Vue Reddit, and also I joined some Discord server and I shared my things there. And then actually, the author of Vue, IA Qing, he got me the first star, and then the traffic comes in.

Yeah. So that actually encouraged me a lot to say, okay, I got the kind of like recognized by the author that's who I admire, and then I just naturally goes to become like that. Yeah. Very nice. Very nice. We're going to steal one more question, or do you need to go? No, I can stay here. Cool. How do you find any ideas for new open source projects? Oh yeah, that's a very interesting topic. Actually, this is a series of talk, on the third one I'm going to talk about that, but I haven't started anyway. But the point is like, I usually start from my own need. As I said, it's like if you saw my talk yesterday about ESLint, there's something that I tried ESLint, and I find, damn, there's something not efficient, or there's something I could be better. Then I started thinking about if I, I mean I'm a lazy guy. I don't want to repeat my code. So if you want to have a better way to extract it, or like if you can make a better experience for users to save a few like boiler plates, I'm happy to do it. So I started to create something like utilities, something on top of that. So basically every project I do is basically from that. It's like I find my own pinpoint. I surround it and solutions, and sometimes the solution doesn't work because it's not always have the, it makes sense for the others. But I think the expectation is also important. I don't set any expectation. I just share. I just share my solutions. And when people find that it's useful, you will gather feedback. You will see issues coming, PLs coming, and you know that project is being used by the others, and it's important to others, then that means that you, it's worth your time to keep maintaining it. And on the other hand, I have a lot of that projects under my name. So that's totally fine. Yeah. But you still learn something from that, right? Yeah. Right. That's all the time we have. So thanks a lot for being here.