How to Build Your Own Open Source Project

Hello my friend, did you enjoy Read Advanced so far? I love it, and in this talk, I wanna share with you how to build your own open source project. But first, let me ask you a question. Have you contributed to any open source projects? If yes, it's great. But if no, I hope you will after my talk.

Hello, my name is Hung, I'm a creator of JestPreview, a library that gives you a visual debugging experience when testing a front-end app. I'm also a co-member of BestOfJay.org, a website that helps you to follow the growth of JavaScript ecosystem. I'm also on Twitter, let's connect!

In this talk, I wanna share with you what is JestPreview and why build it, the struggle I have to overcome when build an open source software project, what did I receive from the community, and some tips if you want to build your own. First what is JestPreview and why build it? The problem is that if you are an engineer, and if you are a front-end engineer and you write test, you have to work with Node terminal a lot. If you encounter a bug, you have to look at the long HTML in the terminal and it's very hard for you to debug and fix this. You don't even know what your app look like when your test is running. Have you ever tried to click a button but there is no button, it's just a spinner is loading in your test? So I asked myself that question, if Jest can print out the HTML, can we render it on a real browser? And till now, the answer is yes we can. As you can see, this is a test case written in React Testing Library, the user interaction is controlled by user-event. And instead of using screen.debug, we use preview.debug to see the actual UI on our app in the browser. And whenever you hit save, the browser updates the UI almost immediately. It brings a lot of benefits. First one is you can debug a fail test much much easier. You can know what your apps look like. So you can very easily writing your next testing step. So you can run your test faster. And even though you are writing unit or integration test, you can still see the UI. So it tries to close the gap between unit test and integration test with end to end test. In my personal experience, I write 2 to 3 times faster thanks to JustPreview. I wanna show you some demo. As you can see This is a normal app that written in testing library. In the right side, you can see that this is a UI JustPreview shows you. Let me just command 1 step, and the test will re-run again. And you can see the count number decrease from 6 to 5. Let me just decrease it again. You can see it from 5, it's gonna turn to 4. And that's JustPreview.

And now I want to share some struggles I have to overcome when building an open source software project. First, it's difficult because when you use a framework and you do not need to understand it deeply, but when you build an open source software project, it's likely that you need to understand it in very, very detail. So sometimes you want to ask a question, but it's likely that you cannot find an answer on Google or Stackoverflow.

For example, this is how CDF module works, but when I build JustPreview to support CDF module, I have to dig into the source code of CDF module, and this is the code I have to work with, to make JustPreview work with CDF module. But it's a good chance for us to learn, because whenever we overcome a hard problem, we learn a lot.

Next is time. Open source software takes a lot of time, especially if you have a full time job, so you have to manage your time well, and my advice is always have a plan, and this is my favorite quote is a good plan today is better than a perfect plan tomorrow. Next, I also think that since it's an open source project, many people will come to help you but actually not true for a small open source project. You might be the only maintainer. Sometimes you just want to give up or archive the project. But that time, please remember why you start it in the first place. Success is financially. If you just do it for fun, it's ok. But if you are serious about working on open source, you may consider GitHub sponsors, Open Collective, or even some freemium model.

I want to share what I receive from doing open source. First is knowledge. A lot of knowledge. I know how Bundler works under the hood. I know how to process CSS in modern web applications. I have to read open source code a lot so my code reading and developing skills improve. I understand how the tool works under the hood. It makes me a better programmer. Next is opportunity. I receive a lot of opportunities from doing open source. My project, Jazz Preview, got nominated for the Most Exciting Use of Technology, React Open Source Awards in React Summit. It's just very exciting and I haven't ever think of that before. For jobs, I receive a lot of invitations to apply and it's just crazy because you do not need to find jobs but it will find you. And next is the conference and tech event, I have chance to join that. Next is I have a chance to chat with many great engineers, authors of open source software library that I use every day. Before doing open source, I have never thought that I can discuss technical with them.

But great that I met some of them in person. You might recognize some of them here. And next is that I receive a lot of things randomly in a day, that I receive something like thank you for making this, it makes my life so much easier. And that really motivates me to keep doing it. I never experienced that before when I'm just doing a 9-to-5 work job.

So how to do that? Now I want to share some tips to build your own open source project. First is, how to choose an open source project to work on? The answer is very easy, it should be a project you use every day. If you want to build your own open source project, your future project should solve your own problems. It's very difficult to contribute to a project that you don't have context, just pick one project that you use every day and contribute to it. And you know that, in a daily job, we spend a lot of time on a particular problem, and there's a high chance that other people have the same problem. So just open source it, and it does not need to be something very big.

Next start simple. No projects are complicated when it's work-related. Just start simple, just make a MVP or proof of concept first, and improve it over time, and it's okay if the code is not clean in the starting phase. And if you ever get lost, it's okay, that's a sign that you are going to learn a lot. Next is the file maintainer. You know, building an open source project is hard and stressful. So it would be so much easier for you to have someone to discuss technical and motivate you to continue the project. And do not start at v1, because a new project is full of proof-of-concept and experiments. v1, that means your software must be backward compatible, when you release a new version. And in semantic versions, the term in major version ratio is zero. It's for initial development. And anything may change, and the public API should not be considered stable. There, you can move fast. Next is that when you start a project to solve a particular issue, but when you use it as a normal user, you know if it's good enough, or if you need to adjust it or add more features to make it more usable. For example, when I build Jest preview, all I want is to preview the UI in Jest to Chrome, period. But the more I use it, the more features I add to make it easier to use, like auto-reload on save, proceed CSS, and image, and adding a new automatic mode, etc. Next, you have a project, but it can be subjective. Let ask your friends, your colleagues, and your network what project should change to be more usable. After a while, when your project gets more attention, watch out for the issue and discussion tab.

And you know, your software is being used when people start to report issues and send I see it as magic how you just put something on GitHub and people from around the world come to you and find issues or send a pull request. And it's very important to guide people how to categorize and find issues efficiently. And reproduction is the most important one. Because without reproduction it's very difficult for maintainer to fix bugs. And there are many other features from GitHub to make you work with open source so much easier like labels, milestones, and GitHub actions.

Next advice is let's learn from other. There are famous quote like good artist copy great artist steal. So do not reinvent the wheel, there are much good software out there that already solve your problem, learn from them, read their source code to see how they do. Next, you should write documentation. It's very easy for you to use your own software, but people around the world have different and special use case, so that's why what's problem your projects trying to solve. Installation uses and some caveats they might encounter clearly in the document. If you prefer React, you can use DocuSource. If you prefer Vue, you can use Vitepress. Both of them help you to make documentation effortlessly.

And next, share it with the world. Shared it on Twitter, write some blog posts, and share your project in a take-event. And last but not least, contribute to Open Source today. I hope you will have a lot of fun and learn a ton doing open source software. So thanks for your attention. If you write, find and test, try just preview. And if you like it, please give it a star to support me. And the slides are available and open source at redadvance.hung.dev.