一个听起来显然是好主意的功能 在我介绍 Book Corners 时，我解释说其初始数据大部分来自 OpenStreetMap。OSM 为该项目提供了一个有用的起点，世界各地已经映射了成千上万个公共书架。Book Corners 还接受用户直接提交的新图书馆。人们可以提交地点和照片，经过审核后，这一贡献将成为公开信息。似乎很公平，当 OSN 中缺少其中一个提交时，Book Corners 应该能够将其贡献回来。这个想法并不是创建一个不受控制的后台同步进程。我想到的工作流程是故意谨慎的：提交图书馆的人会明确允许贡献。管理员会首先审核图书馆。Book Corners 会在 OSM 中搜索可能的重复项。管理员会预览正在发送的确切数据。在管理员确认之前，不会写入任何内容。从软件开发的角度来看，这看起来像是一个可管理的集成：添加同意，追踪贡献状态，构建预览，与 OSM 进行身份验证，并通过其 API 创建新功能。代码并不是难点。贡献数据不仅仅是一个 API 调用 一旦我开始认真研究实施，就发现向 API 写入只是工作的一小部分。因为信息将来自 Book Corners 数据库，OSM 可以将其视为外部数据导入。由于软件将准备并提交变更，它也可能受到脚本辅助或自动编辑规则的约束，尽管管理员会审核每个独立的库。遵循 OSM 导入指南和自动编辑行为守则的保守解释，要求的不仅仅是一个专用账户和 OAuth 令牌。在第一次生产贡献之前，我需要：创建并维护一个专用的 OSM 导入账户；在 OSM Wiki 上发布详细的导入计划；记录数据源、许可、字段映射、重复检测、软件、质量检查、变更集政策和回滚程序；在 OSM 社区论坛上发起提案；联系受贡献影响的相关地方社区；等待审查期并解决任何问题；保持导入账户、计划、讨论和变更集之间的永久链接；维护联系和选择退出路线以便处理未来的问题或投诉。关于许可还有重要的问题。用户向 OSM 提交图书馆的 permissions 并不自动等于有充分明确的权利以 OSM 兼容的条款发布该事实信息。面向用户的说明和同意需要涵盖这一区别，包括确认信息并非来自不兼容的源。这些要求并不是一次性完成后就可以遗忘的表单。它们在账户、记录过程、社区反馈、失败和潜在回退方面创造了持续的责任。我理解这些规则存在的原因 OpenStreetMap 是一个共享的全球数据库。一个糟糕的导入可以产生数千个重复项，覆盖更好的本地知识，或引入难以清除的错误，一旦其他人编辑了相同的对象。从这个角度看，要求文档、许可明确性、重复处理、负责任的操作员和社区讨论是合理的。OSM 社区必须保护地图的质量，良好的意图并不保证良好的数据。Book Corners 本身也受益于数据的质量。如果期望 OSM 在没有保障的情况下接受来自外部服务的更改，那就是虚伪。与此同时，这一过程确实有实际成本。它要求一个小项目不仅要成为一个 API 客户端，还要成为一个文档化的导入程序的操作员。这可能适合导入大数据集的组织，但对于一个低量特性的项目而言，它是一个相当可观的承诺，其唯一目的是将一些经过仔细审核的公共书架贡献回公共资源。运营工作超过 Book Corners 的价值 Book Corners 有一个简单的目的：帮助人们发现小型免费图书馆，并与他人分享新图书馆。运营 OSM 贡献管道并不是这一目标的核心。这将增加凭证、生产保障、审计和对账代码、社区流程、许可工作以及长期支持义务。每一部分都有其合理性，但加起来使这个特性比我最初设想的要大得多。还有机会成本。用于运营这一集成的时间就是投入于改善图书馆发现、审核、照片、可访问性、翻译或移动体验的时间。这些改进直接帮助 Book Corners 用户，更容易被小项目维持下去。我最初是从贡献回来的感觉出发