import { Callout } from '@/components/Callout';

2 years ago I released an open-source Javascript library. Little did I know it would grow to be extremely popular with **190+ github stars** and **60,000+ downloads**. It was the "unofficial" sdk for the Whatsapp Business API in Javascript.

<img src="/images/content/articles/60k-downloads-lessons-learned-in-open-source-development/monthly downloads.png" className="mx-auto" /> 
Monthly downloads

<img src="/images/content/articles/60k-downloads-lessons-learned-in-open-source-development/total downloads.png" className="mx-auto" /> 
Total downloads

<img src="/images/content/articles/60k-downloads-lessons-learned-in-open-source-development/github stats.png" className="mx-auto max-w-xs md:max-w-md" /> 
Github stats

I archived the repo earlier this year because I became too busy to maintain it. However I'd love to share some lessons I learned along the way about Open-Source Development.

## Lessons learned in open-source development

### 1. Your open-source users are your customers

Treat them like so. *"But they are not paying me so why should I care?"* Because someone desperately relies on your code to run their business. Resolve issues fast. If you're too busy, delegate, delegate. I will admit I failed in this at first. 

The faster you acknowledge and address issues, the more users will prefer & freely share your library.

### 2. High code quality

Semver, tags, releases, CI/CD for testing each PR and releasing new builds, good documentation, API docs, etc. If a user has to ask you how to use a function, you have failed. A user should see all possible ways to consume a function without having to ask you. 

I've often seen this happen in companies: someone asks, "What does X do?" - but the person who knows has either left or is too senior to respond or never bothered to document it. Please don't do this in open source.

### 3. If your product is good enough, you may never need to market it.

I never published an ad. I was surprised to get emails from people in countries I've never been to, saying thank you. I came across blogs written by strangers on how to use the library, and saw Stack Overflow answers linking the library. Facebook later built their own package in Javascript but for some weird reason I cannot explain, people preferred to use my package more. Mine had more downloads and more github stars. 

This is a lesson I'll carry with me even beyond open source development: 

<Callout type="tip">
 If your product solves an important problem well enough, you may never need to spend a cent in marketing.
</Callout>

### 4. You cannot test enough

Don't just import functions & test them. I learned this the hard way. For testing, create a virtual env, build the npm package, install it & then test the functions. Do this in CI/CD to ensure your package never has breaking changes that you never knew about.

### 5. Move first and move fast

But above all, execution matters more than moving first.

### 6. Naming matters

I aptly named my library `whatsapp-cloud-api`. When people googled this, it was the first thing they saw. That helped a lot in getting more downloads.

{/* 1. **Your open-source users are your customers.** Treat them like so. "But they are not paying me so why should I care?" Because someone desperately relies on your code to run their business. Resolve issues fast. If you're too busy, delegate, delegate. I will admit I failed in this at first. The faster you acknowledge and address issues, the more users prefer & freely share your library.
2. **High code quality** - semver, tags, releases, CI/CD for testing each PR and releasing new builds, good documentation, API docs, etc. If a user has to ask you how to use a function, you have failed. A user should see all possible ways to consume a function without having to ask you. I see this in companies: "what does x do?" Someone has left the company or is too high up to answer you. Please don't do this in open source.
3. **If your product is good enough, you may never need to market it.** I never published an ad. I was surprised to get emails from people in countries I've never been to saying thank you. I came across blogs written by strangers on how to use the library, and saw Stack Overflow answers linking the library. Facebook later built their own package in Javascript but for some weird reason I cannot explain, people preferred to use my package more. Mine had more downloads and more github stars. This is a lesson I'll carry with me even beyond open source development: if your product solves a particular problem well enough, you may never need to spend a cent in marketing.
4. **You cannot test enough** - don't just import functions & test them. I learned this the hard way. For testing, create a virtual env, build the npm package, install it & then test the functions. Do this in CI/CD to ensure your package never has breaking changes that you never knew about.
5. **Move first and move fast.** But above all, execution matters more than moving first.
6. **Naming matters.** I aptly named my library `whatsapp-cloud-api`. When people googled this, it was the first thing they saw. */}

{/* Delegate, delegate, delegate. Have good communication, templates, docs on how to contribute, etc. Lead. You cannot build it alone. */}

## How to get the library

If you use node.js, you can <a href="https://www.npmjs.com/package/whatsapp-cloud-api" target="_blank" rel="noopener noreferrer">install the npm package</a> as follows:

```sh
npm i whatsapp-cloud-api
```

Lessons learned from building an Open-Source Javascript library from scratch.

60,000+ Downloads: Lessons Learned in Open-Source Development