Trust is not an abstract issue here. If an app runs locally, the user is effectively allowing it into their environment: files, terminal, configuration, and sometimes work projects. When privacy matters, saying so is not enough. It has to be verifiable.
One of the most direct ways to make that possible is to open source the code.
This is the approach behind Adal CLI, an app that runs on the user’s machine. For this kind of tool, open source is not just a technical detail. It is part of the relationship between the product and the user.
First, it builds trust. Anyone can inspect the code and understand what the app actually does. And if there are still doubts, users do not have to download a prebuilt binary. They can build the app from source themselves.
Second, it makes improvement possible. If a user is missing a feature or sees a way to make the app better, they can open an issue, suggest a change, or submit a pull request. Even if most users never do this, the possibility itself changes how the project is perceived.
Third, it makes development more transparent. In an open project, people can see not only the current code, but also the history of changes: which bugs were fixed, which decisions were made, and which features were added. The app stops being a black box.
Fourth, it allows independent review. Most users probably will not read the source code themselves. But other developers, security specialists, or technically experienced members of the community can. For an app that runs locally on a user’s device, that matters a lot.
Fifth, it reduces dependency on a single maintainer. If the tool becomes useful to people, open source gives them additional confidence that the project will not completely disappear if active development slows down. The community can fork the repository, continue support, fix critical issues, or adapt the app to its own needs.
Of course, open source does not create trust automatically. Publishing the code does not guarantee that a project is secure, usable, or well maintained. It is an invitation to inspect and collaborate, not a replacement for developer responsibility.
That is why opening the source code should go together with the basics: clear documentation, reproducible builds, an open changelog, a description of what data the app uses and why, instructions for building it manually, and a license that clearly explains how the code can be used.
Adal CLI follows this approach because it runs on the user’s machine. Users should be able to verify what gets executed, which files are read, which requests are sent, and whether any requests are sent at all.
In this context, open source is not just a way to show the code. It is a way to say: trust does not have to be blind. The behavior of the app can be checked.
Not every app has to be open source. But if a product works with a user’s local environment, files, terminal, configuration, or sensitive data, openness can become one of the strongest arguments for trust.
Trust is hard to earn through promises. It is easier to build through transparency, verifiability, and respect for the user.
Open source is one of the most honest ways to do that.