Book Corners отказался синхронизировать данные с OpenStreetMap

Book Corners, приложение, которое помогает находить буккроссинг-шкафы (little free libraries) и делиться новыми находками. Часть исходных данных сервис изначально взял из OpenStreetMap (OSM), которая уже содержит тысячи размеченных по миру публичных книжных шкафов. Пользователи Book Corners также могут добавлять свои точки: указать местоположение, приложить фото, после модерации запись публикуется.

Разработчику показалось логичным сделать и обратный путь: если пользовательская запись отсутствует в OSM, отправлять её туда же. Задумывался осторожный процесс с явным согласием автора записи, ручной проверкой администратором, поиском дублей в OSM и предпросмотром точных данных перед отправкой, ничего не должно было уходить в базу без подтверждения человеком. С точки зрения кода такая интеграция выглядела посильной: согласие, отслеживание статуса вклада, предпросмотр, аутентификация и запись через API OSM.

При более внимательном изучении выяснилось, что запись в API, лишь малая часть работы. Поскольку данные шли бы из базы Book Corners, OSM классифицирует это как внешний импорт данных, а поскольку правки готовит и отправляет программа, на них распространяются ещё и правила для автоматизированных и скриптовых правок, даже при том, что каждую запись вручную проверяет администратор. Строгое следование Import Guidelines и Automated Edits Code of Conduct потребовало бы от разработчика: завести и вести отдельный аккаунт для импорта, опубликовать подробный план импорта на вики OSM (источник данных, лицензирование, сопоставление полей, поиск дублей, программное обеспечение, проверки качества, политику чейнджсетов, процедуру отката), открыть предложение на форуме сообщества OSM, связаться с локальными сообществами, которых касаются правки, дождаться периода обсуждения и снять все возражения, постоянно поддерживать связь между аккаунтом, планом, обсуждениями и чейнджсетами, а также держать открытым канал для вопросов и жалоб. Отдельно вставал лицензионный вопрос: согласие пользователя отправить свою запись в OSM, не то же самое, что достаточное право публиковать эти данные на условиях, совместимых с лицензией OSM; нужно было отдельно подтверждать, что информация не скопирована из несовместимого источника. Всё это не разовая анкета, а постоянная ответственность за аккаунт, документированный процесс, обратную связь сообщества и возможные откаты правок.

Разработчик признаёт, что требования OSM обоснованы: это общая глобальная база, и один неудачный импорт может создать тысячи дублей, затереть более точные локальные данные или внести ошибки, которые трудно убрать после того, как объект уже правили другие люди. Сам Book Corners выигрывает именно от такого контроля качества, поэтому было бы лицемерно ждать от OSM принятия правок без гарантий. Но у процесса есть реальная цена: он превращает небольшой проект не просто в клиента API, а в оператора полноценной документированной программы импорта, оправданно для организаций, которые заливают большие массивы данных, но тяжело для функции с низким объёмом, единственная цель которой, вернуть в общее пользование горстку тщательно проверенных публичных книжных шкафов. Время и силы, которые ушли бы на поддержку этой интеграции, не пойдут на то, что напрямую полезно пользователям Book Corners: поиск библиотек, модерацию, фото, доступность, переводы, мобильный опыт.

В итоге разработчик решил бессрочно приостановить реализацию обратной записи в OSM. Book Corners по-прежнему будет указывать OpenStreetMap как источник для записей, импортированных оттуда, и никогда не станет отправлять такие импортированные записи обратно как будто это новые находки. Но библиотеки, добавленные пользователями напрямую в Book Corners, останутся только в Book Corners: сервис не будет ни автоматически, ни вручную создавать для них соответствующие объекты в OSM. Поскольку в продакшене ничего и так не писало из Book Corners в OSM, приостановка не требует отключения или переноса уже работающей интеграции. Разработчик допускает, что вернётся к решению, если появится по-настоящему лёгкий вариант рабочего процесса или если масштаб и ценность вклада Book Corners со временем оправдают всю эту процедуру; также рассматривает вариант, при котором сам пользователь открывал бы предложенный объект в одном из штатных редакторов OSM, но и это потребовало бы отдельного обсуждения с сообществом, а не было бы обходом правил.

Общий вывод автора: внешние интеграции с общими открытыми проектами несут не только техническую, но и организационную и социальную нагрузку, и иногда эта нагрузка обходится дороже, чем сам код. Для Book Corners на его нынешнем масштабе баланс между пользой и ответственностью не сходится, поэтому это осознанное решение не выпускать функцию.

Ключевые факты

Book Corners, приложение для поиска буккроссинг-шкафов, часть исходных данных взял из OpenStreetMap (OSM) и хотел отправлять новые пользовательские точки обратно в OSM
Задуманный процесс был осторожным: согласие пользователя, ручная модерация, поиск дублей и предпросмотр перед отправкой, но правила OSM классифицируют такую отправку как внешний импорт данных и автоматизированную правку
Строгое соблюдение OSM Import Guidelines и Automated Edits Code of Conduct потребовало бы отдельного аккаунта, публичного плана импорта на вики, предложения на форуме сообщества, согласования с локальными группами и постоянной поддержки процесса, а не только кода
Разработчик решил бессрочно приостановить обратную запись в OSM: операционная нагрузка перевешивает пользу для небольшого низкообъёмного проекта
Импортированные из OSM записи по-прежнему не будут отправляться туда обратно как новые; пользовательские записи остаются только в Book Corners, но решение может пересмотреть в будущем при появлении более лёгкого процесса

Почему это важно

История показывает скрытую цену интеграции с общими открытыми базами данных вроде OpenStreetMap: то, что выглядит как одна API-функция, на практике требует от небольшого проекта взять на себя роль оператора документированной программы импорта, с публичным планом, обсуждением в сообществе и постоянной ответственностью за качество данных. Это частный, но показательный пример того, как организационные и социальные обязательства открытых экосистем могут перевешивать чисто техническую сложность задачи.

Кому это важно

В первую очередь, разработчикам небольших проектов и инди-мейкерам, которые пользуются данными OpenStreetMap или подобных открытых баз и рассматривают возможность писать в них в ответ. Также полезно мейнтейнерам open-source проектов и сообществу OSM как иллюстрация того, как воспринимаются их правила импорта со стороны внешнего разработчика.

Как это применить

Прежде чем проектировать запись в общий открытый датасет, стоит заранее изучить правила соответствующего сообщества (для OSM, Import Guidelines и Automated Edits Code of Conduct) и оценить не только код, но и постоянные операционные обязательства: выделенный аккаунт, документацию, публичное обсуждение, период ожидания реакции сообщества, канал для жалоб. Если объём и ценность вклада малы, разумной альтернативой может быть временный отказ от синхронизации в обе стороны с возможностью вернуться к идее позже, когда появится более лёгкий путь или вырастет масштаб проекта.

Можно ли доверять

Это личный пост разработчика Book Corners в его блоге, пересказывающий собственный опыт и решение; обсуждение на Hacker News набрало 68 баллов и 39 комментариев. Заявления в тексте, это описание требований OSM и последовавшее решение автора, а не независимо проверяемые внешние факты; явных числовых данных или цитат третьих лиц, которые стоило бы перепроверять, в источнике нет.

Риски и подводные камни

Материал отражает точку зрения одного разработчика и не означает, что OSM формально отклонила его предложение или изменила политику, интеграция была приостановлена по собственной инициативе автора ещё до того, как её предложили сообществу. Не стоит путать это решение с универсальным правилом: для проектов с другим масштабом или готовностью нести операционную нагрузку баланс пользы и затрат может сложиться иначе.