When you build an app that runs on someone else’s machine, trust becomes a very practical issue.

It is not just about branding, positioning, or saying the right things on a landing page. The user is allowing your software to run in their local environment. Depending on what the app does, that environment may include files, terminal commands, configuration, credentials, or work projects.

So the question becomes simple: how can a user know that the app is doing only what it is supposed to do?

For Adal CLI, I decided that the answer should not be “just trust me.”

It should be verifiable.

Local apps need a different level of trust

A web app usually runs on infrastructure controlled by the product team. A local app is different. It runs directly on the user’s device.

That changes the trust model.

If a CLI tool reads files, sends requests, modifies configuration, or interacts with local projects, users have every right to ask:

• What exactly does it read?
• What does it send over the network?
• Does it collect anything unnecessary?
• Can I build it myself instead of downloading a binary?
• What happens if the project stops being maintained?

These are fair questions. And for developer tools, they are especially important.

Open Source makes trust verifiable

This is one of the main reasons I made Adal CLI open source.

Open source does not magically make a project secure or trustworthy. But it changes the relationship between the developer and the user.

Instead of asking people to believe a claim, it gives them a way to verify it.

Anyone can inspect the code and see what the app actually does. If someone does not want to use a prebuilt binary, they can build the project from source. If a developer wants to review how data is handled, they can do that. If someone finds a problem, they can open an issue or submit a pull request.

That possibility matters, even if most users never read the source code themselves.

It also makes development more transparent

Another benefit of open source is that people can see how the project evolves.

They can look at the changelog, commits, issues, and pull requests. They can see which bugs were fixed, which features were added, and how decisions were made over time.

For me, that transparency is important. A local tool should not feel like a black box.

This is especially true for CLI tools, because they often operate close to the developer’s actual work: repositories, config files, scripts, and terminal workflows.

Open Source is not a shortcut

There is one important caveat: publishing the code is not enough.

Open source is not a substitute for responsibility. A project can be open and still be confusing, insecure, poorly documented, or hard to build.

So if open source is meant to support trust, it should come with the basics:

• clear documentation;
• reproducible builds;
• a changelog;
• a license;
• instructions for building from source;
• an explanation of what data the app uses and why.

Without those things, “the code is open” can become more of a slogan than a real advantage.

Reducing dependency on one maintainer

There is another reason I care about this: sustainability.

If a tool becomes useful to people, they should not be completely dependent on one person maintaining it forever.

With an open source project, the community can fork it, fix critical issues, adapt it to specific needs, or continue development if the original maintainer slows down or moves on.

That does not guarantee anything, of course. But it gives the project a better chance to survive beyond a single author.

Final thought

Not every app has to be open source.

But if you are building something that runs locally, touches files, works with terminal commands, reads configuration, or handles sensitive data, openness can become one of the strongest arguments for trust.

Trust is hard to earn through promises.

It is much easier to build through transparency, verifiability, and respect for the user.

That is why Adal CLI is open source.