The post has been translated automatically. Original language: Russian
Imagine that you are developing an application that runs not on your server, but directly on the user's device. How can we show that it does only what it was created for: it does not collect unnecessary data, access unnecessary files, or perform hidden actions?
The issue of trust here is not at all abstract. If the application is running locally, the user actually runs it in their environment: to files, terminal, configurations, and sometimes to work projects. Therefore, phrases like "we respect your privacy" are no longer enough. It is important not only to say this, but also to make it verifiable.
One of the most direct ways to achieve this verifiability is to open the source code.
That's exactly what I decided to do with the Adal CLI, an application that runs on the user's device. For such a tool, open source is not just a technical detail, but part of the relationship to the user.
First of all, it's trust. Anyone can study the code and understand what the application actually does. And if there are doubts, you can not download the finished binary, but build the application yourself from the source code.
Secondly, it is an opportunity to participate. If the user lacks a feature or sees how to improve the app, they can open an issue, suggest a change, or send a pull request. Even if not everyone uses it, the very possibility of participation changes the perception of the project.
Thirdly, it is the transparency of development. In an open project, you can see not only the current code, but also the history of changes: which errors were fixed, which decisions were made, and which functions were added. The app is no longer a black box.
Fourth, it is an independent verification. Most users probably won't read the source code on their own. But this can be done by other developers, security experts, or tech-savvy community members. For an application that runs locally, this feature is especially important.
Fifth, it is the sustainability of the project. If the tool turns out to be useful, the open source gives users additional confidence: the project will not disappear completely, even if the author stops actively developing it. The community will be able to fork the repository, fix critical bugs, or adapt the application to their needs.
Of course, open source by itself does not automatically create trust. Open source does not guarantee that a project is secure, convenient, or well-maintained. This is not a substitute for the developer's responsibility, but an invitation to review and cooperate.
Therefore, along with the publication of the source code, it is important to take care of the basic things: clear documentation, reproducible assembly, an open list of changes, instructions for self-assembly, a description of what data the application uses and why, as well as a license that clearly explains the rules for using the code.
In the case of the Adal CLI, it is important to me that the user can not just take a word for it, but, if desired, check everything on his own.: what is running, which files are being read, which requests are being sent, and whether they are being sent at all.
For me, open source in this case is not just a way to show the code. This is a way to tell the user: you don't need to trust blindly, and the app's behavior can be verified.
Not every application needs to be open source. But if the product works with the user's local environment, files, terminal, configurations, or sensitive data, openness can be one of the strongest arguments in favor of trust.
Trust is difficult to gain with promises. It is easier to build it through transparency, verifiability, and respect for the user.
Open source is one of the most honest ways to do this.
Представьте, что вы разрабатываете приложение, которое запускается не на вашем сервере, а прямо на устройстве пользователя. Как показать, что оно делает только то, для чего создано: не собирает лишние данные, не обращается к ненужным файлам и не выполняет скрытые действия?
Вопрос доверия здесь совсем не абстрактный. Если приложение работает локально, пользователь фактически пускает его в свою среду: к файлам, терминалу, конфигурациям, а иногда и к рабочим проектам. Поэтому фразы вроде «мы уважаем вашу приватность» уже недостаточно. Это важно не только сказать, но и сделать проверяемым.
Один из самых прямых способов добиться такой проверяемости — открыть исходный код.
Именно так я решил поступить с Adal CLI, приложением, которое запускается на устройстве пользователя. Для такого инструмента открытый код — не просто техническая деталь, а часть отношения к пользователю.
Во-первых, это доверие. Любой человек может изучить код и понять, что приложение делает на самом деле. А если остаются сомнения, можно не скачивать готовый бинарник, а собрать приложение самостоятельно из исходников.
Во-вторых, это возможность участия. Если пользователю не хватает функции или он видит, как улучшить приложение, он может открыть issue, предложить изменение или отправить pull request. Даже если этим воспользуются не все, сама возможность участия меняет восприятие проекта.
В-третьих, это прозрачность развития. В открытом проекте виден не только текущий код, но и история изменений: какие ошибки исправлялись, какие решения принимались, какие функции добавлялись. Приложение перестаёт быть чёрным ящиком.
В-четвёртых, это независимая проверка. Большинство пользователей, скорее всего, не будет читать исходный код самостоятельно. Но это могут сделать другие разработчики, специалисты по безопасности или технически подкованные участники сообщества. Для приложения, которое работает локально, такая возможность особенно важна.
В-пятых, это устойчивость проекта. Если инструмент оказывается полезным, открытый код даёт пользователям дополнительную уверенность: проект не исчезнет полностью, даже если автор перестанет активно его развивать. Сообщество сможет форкнуть репозиторий, исправить критические ошибки или адаптировать приложение под свои задачи.
Конечно, open source сам по себе не создаёт доверие автоматически. Открытый код не гарантирует, что проект безопасен, удобен или хорошо поддерживается. Это не замена ответственности разработчика, а приглашение к проверке и сотрудничеству.
Поэтому вместе с публикацией исходников важно позаботиться о базовых вещах: понятной документации, воспроизводимой сборке, открытом списке изменений, инструкции по самостоятельной сборке, описании того, какие данные использует приложение и зачем, а также лицензии, которая ясно объясняет правила использования кода.
В случае с Adal CLI мне важно, чтобы пользователь мог не просто поверить на слово, а при желании проверить всё самостоятельно: что запускается, какие файлы читаются, какие запросы отправляются и отправляются ли вообще.
Для меня open source в этом случае — не просто способ показать код. Это способ сказать пользователю: вам не нужно доверять вслепую, а поведение приложения можно проверить.
Не каждому приложению обязательно быть open source. Но если продукт работает с локальной средой пользователя, файлами, терминалом, конфигурациями или чувствительными данными, открытость может стать одним из самых сильных аргументов в пользу доверия.
Доверие сложно получить обещаниями. Его проще строить через прозрачность, проверяемость и уважение к пользователю.
Открытый исходный код — один из самых честных способов это сделать.
Share
