Book Corners是个帮人找街头“图书角”的小应用,数据一部分来自OpenStreetMap(OSM)。开发者Andrea Grandi原本想加一个功能:用户提交的新书角,审核通过后,顺手回写进OSM这个公共地图数据库。他觉得这只是多写一段调用API的代码。真去查规则才发现,这根本不是技术问题,而是要不要接下一整套治理责任的问题——最后他选择无限期搁置,不做了。
谨慎设计,照样撞墙
他设计的流程其实很克制:用户明确同意、管理员先审核、系统搜索OSM里有没有重复、管理员预览要写入的具体数据、管理员确认后才提交。同意、状态追踪、预览、OAuth认证、调用API创建对象——从工程角度看,这就是个普通的第三方集成,代码不是难点。
难点在于,OSM把这类操作分成两条判定线,而Book Corners同时踩中了两条。数据来自Book Corners自己的数据库,这符合Import Guidelines里“外部数据导入”的定义;写入过程是软件准备、软件提交,这又落进Automated Edits code of conduct管的“自动化/脚本辅助编辑”范畴。哪怕每一条都有管理员盯着看过,规则依然认定:发起和提交的是程序,不是人在逐条实地测绘。
一旦落进这两条线,OAuth token和专属账号都不能当挡箭牌。要合规上线,他得先建一个专用的导入账号,在OSM Wiki公示一份完整的导入计划,写清数据来源、许可、字段映射、查重方法、质量检查、changeset策略和回滚方案,再去社区论坛发提案、联系相关本地测绘社区、走完评审期、解决社区提出的疑虑,并且长期维护账号和联系渠道。
不是他一个人想多了
Grandi的判断听起来像小项目的过度谨慎,但OSM社区论坛上有过一个几乎同构的先例——第三方App代第三方提交编辑的讨论(“Drivers Against Flock”)。当时社区反复提的条件,和Grandi列出的清单几乎一模一样:要有具名的人类联系人,要人工审核而不是达阈值自动批准,要查重,要能追溯到原始提交,并且建议尽量让贡献者用自己的OSM账号通过OAuth编辑。
社区的共识很直白:如果测绘者对每个对象的解释只是“数据源就是这么写的”,而不是本人核实过,那就是import,得先拿到社区台面上讨论,不能当成个人手动编辑豁免。历史上文档不全、来源不清的导入被回滚过,这也是为什么规则宁可繁琐也要先问清楚。
- 风险.许可问题比想象中隐蔽——用户同意把书角信息发给Book Corners,不等于这段事实性信息本身就有权按OSM兼容条款开放,尤其当信息可能抄自不兼容来源时。
同类工具也没做到
横向看一圈成熟的OSM生态工具会发现,连它们都没解决这个问题。Every Door、Organic Maps都止步于“下载—编辑—上传changeset”这套标准流程;Mapillary做的是影像单向上传。没有一个工具实现了Grandi想要的“自动查重+人工确认+回写”闭环。
这说明Grandi碰到的不是一个小项目独有的倒霉事,而是整个行业还没啃下来的难题——想让第三方软件自动、可信地往OSM这种共享数据库里写数据,目前根本没有轻量解法。
我更在意的是这笔账怎么算
Grandi自己说得很清楚:他认这套规则合理。OSM是任何人都能编辑的全球数据库,一次糟糕的导入能造出成千上万个重复对象,或者覆盖掉本地测绘者更准确的记录,而且一旦别人在这基础上又编辑过,想撤都难撤干净。Book Corners本身正是吃了OSM开放数据的红利,再反过来要求人家不设防地接收自己的数据,说不过去。
但账不能只算一半。为了回写几个经过人工审核的书角,一个小项目要维护专用账号、写年度级别的文档、跑社区提案、承担长期的变更集和撤销责任——这套操作成本,配得上大批量自动导入的机构,配不上一个低频功能。时间花在这上面,就不能花在图书角发现体验、审核流程、无障碍、翻译这些真正贴近用户的地方上。
Import Guidelines 页面写得明白:重点从来不是“你有没有权限调用API”,而是“你有没有资格代表一批数据对整个社区负责”。这和古人说“君子爱人以德”有点像——真想对一个公共项目好,有时候恰恰是别急着往里面塞东西。
Grandi最后的决定是:OSM导入来的书角继续标注来源,不会被反向当成“新提交”回写;但用户直接提交给Book Corners的书角,就留在Book Corners自己的数据库里,不再自动或手动同步进OSM。他没有关掉什么已有集成,因为这功能压根没上线过——发现这道坎,恰好是在部署之前。
这件事对其他想“回馈开放数据commons”的小开发者是个提醒:治理成本不会因为你的意图良善而打折。想清楚这笔账,比急着写第一行API调用代码重要得多。