运营成本超功能价值！“图书角”为何放弃将贡献同步回开放街图？
安德里亚·格兰迪（Andrea Grandi）——软件开发工程师
1. GitHub
2. Mastodon
3. 领英（LinkedIn）
4. RSS
1. 主页
2. 关于
3. 履历
在ko-fi.com上请我喝杯咖啡
开发 社区 个人观点
为何“图书角（Book Corners）”不会将贡献同步回开放街图（OpenStreetMap）
原本希望“图书角”能将新提交的公共书架信息反馈给开放街图，但研究运营和社区要求后，决定不实施该功能。
2026年7月31日
一个看似不错的功能
介绍 图书角 时提到，其初始数据大多来自 开放街图，开放街图为项目提供了很好的起点，全球已有数千个公共书架被标注在上面。
“图书角”接受用户直接提交新的图书馆信息，用户提交位置和照片，经审核后贡献会公开。所以，当开放街图缺少这些提交信息时，“图书角”将其反馈回去看似理所应当。
设想的工作流程很谨慎：
- 提交图书馆信息的用户需明确同意进行反馈。
- 管理员首先对图书馆信息进行审核。
- “图书角”会在开放街图中搜索可能的重复信息。
- 管理员会预览要发送的确切数据。
- 直到管理员确认后才会进行写入操作。
从软件开发角度看，这似乎是易于管理的集成：添加用户同意选项、跟踪贡献状态、构建预览、与开放街图进行身份验证，并通过其API创建新的地理特征。其实，编写代码并非最困难的部分。
贡献数据并非仅仅调用API那么简单
认真研究具体实现时发现，调用API写入数据只是工作的一小部分。
由于信息来自“图书角”数据库，开放街图可能将其视为外部数据导入。而且，尽管每个图书馆信息都要经过管理员审核，但因是软件准备和提交更改，也可能符合脚本辅助或自动编辑的规则。
严格遵循 开放街图导入指南 和 自动编辑行为准则，所需不止一个专用账户和OAuth令牌。
首次正式贡献前，需要：
- 创建并维护一个专用的开放街图导入账户。
- 在开放街图维基上发布详细的导入计划。
- 记录数据源、许可协议、字段映射、重复检测、使用的软件、质量检查、变更集策略以及回滚程序。
- 在开放街图社区论坛上提出提案。
- 联系受这些贡献影响的相关本地社区。
- 等待审核期结束并解决所有问题。
- 保留导入账户、计划、讨论和变更集之间的永久链接。
- 为未来的问题或投诉提供联系方式和退出途径。
此外，还有重要的许可问题。用户同意将图书馆信息发送到开放街图，不意味着就自动拥有以符合开放街图要求的条款发布这些事实信息的明确权利。面向用户的说明和同意书需要涵盖这一区别，包括确认信息并非来自不兼容的数据源。
这些要求并非一次性表格填写后就可置之不理，意味着要对账户、记录的流程、社区反馈、失败情况以及可能的回滚操作承担持续的责任。
理解规则存在的原因
开放街图是共享的全球数据库，一次糟糕的导入可能造成数千个重复信息，覆盖更准确的本地知识，或引入一旦被其他人编辑就难以消除的错误。
从这个角度看，要求提供文档、明确许可协议、处理重复信息、明确责任人和进行社区讨论是合理的。开放街图社区必须保护地图数据的质量，良好的意愿并不能保证数据的质量。
“图书角”本身也受益于这种数据质量。如果期望开放街图在没有保障措施的情况下接受外部服务的更改，那将是虚伪的。
与此同时，这个过程确实需要付出成本。它要求一个小项目不仅要成为API客户端，还要成为有文档记录的导入项目的运营者。这对于导入大型数据集的组织来说可能合适，但对于仅旨在将少数经过仔细审核的公共书架信息反馈给公共数据库的低流量功能来说，是相当大的承诺。
运营成本超过了功能价值
“图书角”的目标很简单：帮助人们发现小型免费图书馆，并与他人分享新的图书馆信息。
运营一个向开放街图贡献数据的流程并非其核心目标。这将需要添加凭证管理、生产保障措施、审计和对账代码、社区流程、许可工作以及长期支持义务。虽然每个部分单独看都有合理性，但综合起来，这个功能比最初设想的要复杂得多。
此外，还有机会成本。花在运营这个集成上的时间，就不能用于改进图书馆发现功能、审核流程、照片展示、可访问性、翻译或移动应用体验。这些改进能直接帮助“图书角”的用户，而且对于一个小项目来说更容易维持。
起初，认为将数据反馈回去是既友好又公平的事情。但深入研究后，意识到仅凭善意不足以承担一个无期限的运营责任。
最终决策
决定无限期搁置向开放街图写回数据功能的开发。
“图书角”将继续注明从开放街图导入的记录来源，并且不会将从开放街图导入的图书馆信息当作新信息再次提交。但用户直接贡献给“图书角”的图书馆信息将保留在“图书角”中，该服务不会自动或手动在开放街图中创建对应的地理特征。
目前“图书角”没有向开放街图正式环境写入数据的功能，因此暂停这项工作无需禁用或迁移现有的集成。
如果未来有真正轻量级的工作流程出现，或者“图书角”的贡献规模和价值最终能够证明这个流程的合理性，可能会重新考虑这个决定。另一种可能是采用用户驱动的工作流程，在现有的开放街图编辑器中打开提议的地理特征，但这仍需要与社区进行讨论，而不能将其视为绕过规则的方法。
目前，负责任的选择是不开发和运营一个没有信心能够妥善支持的功能。
有时，不做功能才是正确的选择
人们往往容易将实现决策单纯视为技术问题：API能否实现、应用程序能否进行身份验证、代码能否避免重复等。
这次经历提醒，外部集成还涉及组织和社会契约。有时候，这些契约的成本比代码本身还要高。在部署之前发现这一点是有价值的，尽管结果可能令人失望。
仍然认为将数据反馈给共享的开源项目是有价值的，也理解开放街图为何如此谨慎地保护其数据库。但就目前的“图书角”而言，收益和责任之间的平衡并不理想。
所以，这是选择不推出的一个功能。
如果你喜欢这篇文章并想表达支持，可以点击下面的按钮请我喝杯咖啡。你的支持，哪怕只是一个小小的举动，都意义重大，会激励我继续在博客上撰写和分享更多文章 ❤️
在ko-fi.com上请我喝杯咖啡 图书角（Book - Corners） 开放街图（Openstreetmap） 开放数据（Open - Data） 开源（Open - Source） 社区（Community） 产品决策（Product - Decisions）
相关内容
- 图书角 - 发现并分享全球小型免费图书馆
- 发布支持代理技能的Obsidian会议记录同步工具
- 宣布mcp - wire 0.3.0版本发布
- 为何要为已有上下文命令的CLI添加代理技能？
- 发布mb - cli 0.3.0：用于Metabase API的只读CLI工具