Honest Software
Software that is honest about what it is doing, what it costs, and what it cannot do is rarer than it should be. A few notes on what that looks like in practice.
Honest software tells you what it is doing.
Not with a wall of legal text that nobody reads. Not with a toggle buried four screens deep in settings. By being legible in the ordinary course of using it. By making its behavior visible enough that you do not need to wonder.
This sounds simple. It is harder to build than it looks.
What dishonest software looks like
Dishonest software is not usually lying in an obvious way. It is more often just unclear. An app that sends usage data home because “improving the product” is the default, with opt-out as a checkbox in a menu labeled “Advanced.” A service that stores your files in a format that cannot be exported. An installer that adds three startup items without disclosing them.
Each of these is technically permitted by terms most users agreed to without reading. But they create a gap between what the user believes is happening and what is actually happening. That gap is a kind of dishonesty, even when no individual statement is false.
The cost of opacity
When software is opaque about what it does, users have to defend themselves. They install blockers. They read privacy policies. They avoid features they might otherwise value because they do not know what those features are doing in the background.
This is a tax on trust. And because software is untrustworthy on average, every new piece of software starts with a deficit. It has to earn back the trust that the rest of the category spent.
Honest software does not impose this tax. It does not require the user to be vigilant. It behaves consistently whether or not someone is watching. There is nothing to discover later that changes how the relationship feels.
What honesty requires
In practice, honest software does a small number of things.
It is explicit about what data it collects and why. Not “we may share information with partners,” but “this feature sends your search terms to our servers to return results.” The specificity matters. Vague language lets the software behave in ways the user would not approve of if they understood them.
It stores data in formats the user can access independently. A note-taking app that stores notes as SQLite that you can open in any SQLite browser is honest about your relationship to your own data. An app that stores everything in a proprietary format that cannot be exported is not.
It does what it says it does. Features with names like “focus mode” or “private browsing” should match their plain-language descriptions in behavior, not just in marketing. When there is a gap between the name and the reality, that gap is the problem.
The business case
There is a version of this argument that stops at ethics. Honest software is the right thing to do, and that should be enough.
It often is not enough. So here is the practical version.
Users who understand what software does are more likely to trust it, and users who trust software are more likely to keep using it, recommend it, and pay for it. Opacity might produce short-term engagement numbers (because exiting the app is annoying and leaving your data behind is costly), but it tends to produce users who resent the software and leave the moment something better appears.
Honest software builds the kind of trust that compounds. Users give it more access because they understand what that access is for. They extend more benefit of the doubt when something breaks. They tell people about it.
What I try to build
The site you are reading right now stores exactly two things in your browser: your theme preference (dark or light), and graph layout data if you have moved any nodes around. There are no analytics scripts, no tracking pixels, no third-party requests. Nothing phones home.
This is not a technical achievement. It is a choice. The same choice is available to most software, most of the time. It is just less common than it should be.