My project got 10,000 Github stars within two weeks of open-sourcing, here are my tips for a successful launch

Nariman Jelveh

I recently open-sourced Puter "the Internet OS" and within the first 2 weeks it hit 10,000 stars, 500 forks, and 80 merged PRs. It even managed to become the #1 post on Hacker News for almost a day with more than 1,200 upvotes! I was truly blown away by the response and caught off guard by the amount of interest and support we received but thinking back, I think there were a few things that we may have done right that helped us get there.

Over the past few weeks, a lot of people have asked me for tips on how to launch an open-source project, so I decided to write this article to share my experience with an actionable list of tips that might help you launch your project successfully.

Have a well-written README.md

This is your "landing page" and the first thing people see when they visit your project. Make sure it's well-written, concise, and informative. Avoid fluff and buzzwords. Include a clear link to the demo, a brief description of the project, installation instructions, usage examples, and a list of features. Make sure to include screenshots and gifs to make it more visually appealing. It's also important to include links to social media, documentation, and other resources. Feel free to use our README.md as a template.

Puter's README.md, the full extent of my design skills!

Have a demo that "Just Works™"

Create a working demo of your project that people can try out, preferably without having to install/sign up for anything. If your demo is a site, provide a clear, prominent link in the README.

Add an FAQ section

Include a FAQ section in your README.md to answer common questions that people might have about your project. This was particularly helpful for Puter because it's a new concept and historically I knew that a lot of people had questions about its use cases and architecture ("Why we used jQuery?").

LICENSE

Make sure to include a LICENSE file in your project. I strongly recommend using a well-known open-source license like MIT, AGPL,... Using less-known licenses can make it harder for people to contribute to your project mostly because there is typically an "understanding tax" (term coined by [Heather Meeker](https://www.techlawpartners.com/heather)) that comes with less-known licenses where contributors need to read and understand the license before they can contribute. This can be a huge barrier to entry for new contributors, whereas individuals and companies are typically familiar with the implications of well-known licenses and can start contributing right away.

CONTRIBUTING.md

This will help guide contributors on how to contribute to your project. Include information on how to create issues, and how to submit a PR, ... Make sure to be welcoming and encouraging to new contributors. We have a simple CONTRIBUTING.md that you could use as a template.

SECURITY.md

if applicable, create a SECURITY.md file in your project. This will help guide users on how to report security vulnerabilities in your project. You may need to create a dedicated email address for security researchers to contact you. Feel free to use our SECURITY.md as a template.

SECURITY-ACKNOWLEDGEMENTS.md

if applicable, create a SECURITY-ACKNOWLEDGEMENTS.md file in your project. It's essential to acknowledge responsible disclosure and thank security researchers who report vulnerabilities in your project. This will help build trust with the security community and encourage more people to report vulnerabilities. It also signals to the community that you are a professional maintainer and take security seriously.

Make installation/usage easy

Make sure to include clear and concise installation instructions in your README.md. Ideally, you should have a one-liner that users can copy and paste to install your project. If your project has dependencies, make sure to include instructions on how to install them. You want developers to immediately see the value of your project and start using it. For Puter, I went to great lengths to make sure that you can get started with just a simple `npm install`.

Implement CI/CD

Implement Continuous Integration and Continuous Deployment (CI/CD) for your project. This will help automate the testing and deployment process and make it easier for contributors to submit PRs. We use Github Actions for Puter and it has been a game-changer. Even though we did not have this in place when we launched, it was one of the first things the community contributed and it has been a huge help.

Take the Github sidebar seriously

Make sure to fill out the "About" section and use relevant tags for the "Topics" section. This will help people discover your project and increase its visibility on GitHub. This really helps with discoverability. Do you have a website? Make sure to add it to the "Website" section. This will help people find more information about your project and stay up to date with the latest news.

The sidebar provides a quick summary of the project.

Create "First good issue" issues

You want to make it super easy for people to get started contributing to your project. Create a "First good issue" label and tag some easy issues with it. These issues should ideally take only a few minutes to fix and require minimal knowledge of the codebase. This will help attract new contributors and make them feel welcome. Making sense of somebody else's codebase is hard, make it easy for them.

Discord/Slack community

Create a Discord or Slack community for your project and make sure to link it in your README.md. This will help foster a sense of community and make it easier for contributors to communicate with each other. It's also a great way to get feedback and suggestions from users.

Do a soft launch first

Before you officially open-source your project, do a soft launch with a small group of people. I did this mostly for 2 reasons: 1) to make sure the README.md is clear enough and 2) to make sure that Puter is easy enough to get started with within seconds. Sometimes your description of the project might be too long or not be clear enough, the screenshot may be too small and you haven't noticed because you didn't test on mobile, the installation process might break on windows because you only tested on Mac,... Doing a soft launch will help you identify a lot of these issues and iron out the kinks before the official launch.

Promote your project but don't spam (duh)

Once you've open-sourced your project, make sure to post it on social media, Reddit, Hacker News, and other platforms. DO NOT spam or be annoying, developers and the OSS community are super smart and can smell BS from a mile away. Be genuine and share your project with the world. If your project resonates with people, they will share it with others and help spread the word. I think you should avoid buzzwords like the plague, they suck in general but they are particularly bad in the OSS community.

Let your users know you're open-source

If you have an existing user base, make sure to let them know that you've open-sourced your project. An open-source announcement is typically going to have a much better open rate than a regular "marketing" email and it's a great way to get your users excited about the project.

Be responsive

Make sure to respond to chats, issues and PRs in a timely manner. This will show that you care about your project and are actively maintaining it. It's also a great way to build trust with your contributors and users. When we open-sourced Puter, we barely got any sleep for the first two weeks because we were responding to emails, chats, issues, and PRs almost 24/7. It was exhausting but 100% made a difference.

Good luck!

I hope these tips help you launch your project successfully. If you have any questions or need help, feel free to reach out to me on X/Twitter or via email at nj@puter.com