Why I made Adal CLI Open Source

When you build a tool that runs on someone else’s machine, trust becomes part of the product.

Adal CLI is a local app. It runs in the user’s environment, which means the trust bar is naturally higher than for many other types of software.

Users have a right to ask:
- What does this app actually do?
- What files does it read?
- Does it send anything over the network?
- Can I build it myself instead of downloading a binary?
- What happens if the project is no longer actively maintained?

For Adal CLI, I did not want the answer to be “just trust me.”

That is one of the reasons I made it open source.

Open source does not automatically make a product trustworthy. It does not replace good documentation, clear communication, reproducible builds, or responsible maintenance.

But it does make trust more verifiable.

Anyone can inspect the code, review how the app works, build it from source, open an issue, suggest an improvement, or fork the project if they need to. Even if most users never read the source code themselves, the possibility matters.

For a local developer tool, that transparency feels important.

There is also a sustainability angle. If a small independent tool becomes useful to people, it should not depend entirely on one person forever. Open source gives the community a way to continue, adapt, or fix the project if needed.

Not every product needs to be open source. But when a product runs locally, touches files, works with terminal commands, or handles sensitive data, openness can become one of the strongest arguments for trust.

That is the bet behind Adal CLI.

Trust is hard to earn through promises. It is easier to build through transparency, verifiability, and respect for the user.

Curious how other indie hackers think about this:

Would you open source a local-first developer tool from day one, or wait until the product is more mature?