Я не думаю, что проект с открытым исходным кодом действительно нуждается в аналитике использования, потому что пользователи уже могут связаться с вами и рассказать, что им нравится/не нравится в вашем продукте и каких изменений они ожидают.
Разработка проекта с открытым исходным кодом на ранней стадии похожа на блуждание в темноте: вы, вероятно, единственный пользователь, дающий честный отзыв о болевых точках и о том, почему проект отстой. С помощью стартапов SaaS вы можете поставить Google Analytics на первое место и получить подсказку о том, где ваш типичный пользователь выходит из себя и уходит.
Мы разрабатываем сервис под названием Metarank, инструмент с открытым исходным кодом для персонализации поиска, категорий, объявлений и рекомендаций. Это автономный серверный сервис без пользовательского интерфейса и версии SaaS, и отзывы, которые мы обычно наблюдаем, выглядят следующим образом:
Что делали другие пользователи 990 Metarank? Довольны ли они пользователями и у них нет проблем? Или, может быть, они заметили ошибку и больше никогда не пытались использовать сервис? Мы понятия не имеем и слишком много вопросов:
- На каком географическом рынке нам следует сосредоточиться? Мы находимся в ЕС, поэтому должны ли мы обращаться к другим компаниям из ЕС?
- Используют ли люди редкие функции? Какую часть сервиса нам следует полировать больше всего?
- Какое последнее действие совершается перед тем, как пользователь выбросит Metarank из окна?
(Не)баланс конфиденциальности и бизнеса
Обычный способ понять, что делают эти пользователи shadow 990, — это отслеживание использования. Приложение периодически звонит домой и сообщает, как идут дела, с разным уровнем детализации и вмешательства в конфиденциальность:
- Графана: анонимная статистика использованных функций, отказ от подписки.
- Gitlab: неанонимная статистика, отказ от подписки.
- Конг: анонимные отчеты об ошибках, отказ.
- gcloud cli: анонимные данные об использовании, подписка.
- варп: неанонимный, с отказом.
Общественные проекты обычно мало заботятся об обратной связи; крупные предприятия уже знают, что делают и чего хотят пользователи, но у малых компаний нет другого способа собрать отзывы.
Как часто вы лично предоставляете отзывы специалистам по сопровождению проектов с открытым исходным кодом?
Отслеживание без отслеживания
- Почему X отправляет полезную нагрузку размером 1 Мб на китайский IP-адрес каждую минуту?
- О, это просто проверка обновления версии!
(Мудрость HN)
Есть и другие сомнительные варианты реализации отслеживания, но без четкого указания на то, что отслеживание существует:
- Проверка обновления версии при каждом запуске: то же отслеживание, но с другим официальным названием и причиной.
- Отслеживание стека и сбор исключений в стиле Sentry в случае ошибок и предупреждений. При достаточном количестве сработавших предупреждений по всему коду (которые регистрируются только в Sentry, а не в stdout) он может предоставить тот же объем аналитической информации, что и обычное отслеживание.
Хотя скрытые методы отслеживания работают, будьте готовы получить неудобные вопросы от ваших пользователей.
Отслеживание использования в Metarank
В Метаранке мы стараемся быть максимально любезными с этим деликатным вопросом:
- Мы отслеживаем как аналитику использования, так и отчеты об ошибках, и это можно отдельно переключать в файле конфигурации и иметь отдельную главу в документах:
- Аналитическая полезная нагрузка не имеет IP и личной информации:
- API, принимающий полезные нагрузки, является открытым и не хранит IP-адреса.
Если у вас есть другое мнение по отслеживанию использования в open-source проектах (и особенно в Metarank), милости просим в наши slack и github issue :)