Book Corners developer shelves plan to write bookcase data back to OpenStreetMap

Book Corners is an app that helps people find little free libraries, and it originally seeded much of its map from OpenStreetMap, which already had thousands of public bookcases catalogued worldwide. Because Book Corners also lets its own users submit new libraries with a photo, which go public after moderation, the developer wanted to contribute those user submissions back to OSM whenever OSM was missing them. He designed a cautious workflow for this: the submitter would have to explicitly consent, an administrator would review the library, the app would search OSM for possible duplicates, the administrator would preview the exact data before it went out, and nothing would be written until that administrator confirmed it. Writing the code for that workflow, he says, was not the hard part.

The hard part turned out to be OSM's own rules. Because the data would originate in an external database and be prepared and submitted by software, the conservative reading of OSM's Import Guidelines and its Automated Edits code of conduct treats this as an import and an automated edit, even though a human administrator reviews every single library beforehand. Complying with that conservative reading, he found, would take far more than a dedicated account and an OAuth token. Before sending a single production contribution, he would need to create and maintain a dedicated OSM import account, publish a detailed import plan on the OSM Wiki covering the data source, licensing, field mapping, duplicate detection, software, quality checks, changeset policy and rollback procedure, open a proposal on the OSM Community Forum, contact the local communities affected, wait out a review period and resolve any objections, keep permanent links between the account, the plan, the discussions and the changesets, and maintain an ongoing contact and opt-out channel. On top of that, a user's consent to send their library to OSM is not automatically the same as holding a clear enough right to release that information under OSM-compatible terms, so the app's own consent language would have to address that distinction too. None of this is a one-time form: it creates a standing responsibility around the account, the documentation, community feedback and any future corrections or reversions.

The developer says he understands why the rules are this strict. OSM is a shared global database, and a bad import can create thousands of duplicates, overwrite better local knowledge, or introduce errors that are hard to undo once other editors have built on the same objects. Book Corners itself benefited from OSM's existing data quality, so he argues it would be hypocritical to expect OSM to accept his contributions without the same safeguards it demands of everyone else. Still, he concluded that operating a documented import programme is a reasonable ask for organisations moving large datasets, but a heavy commitment for a low-volume feature whose only job was to send back a handful of carefully reviewed bookcases. Running that pipeline would mean adding credentials, production safeguards, audit and reconciliation code, community processes and licensing work, on top of time that could instead go into library discovery, moderation, photos, accessibility, translations or the mobile app, improvements he considers both more central to the product and easier for a small project to sustain.

He has decided to suspend the OSM write-back implementation indefinitely, rather than cancel it outright. Book Corners will keep crediting OpenStreetMap as the source for libraries imported from it, and it will never submit those OSM-derived libraries back as if they were newly discovered; libraries that users contribute directly to Book Corners will simply stay in Book Corners, with no automatic or manual creation of matching OSM objects. Since nothing currently writes from Book Corners into production OSM, the suspension does not require unwinding or migrating any live integration. He leaves the door open to revisiting the decision if a genuinely lighter-weight workflow appears, or if the scale and value of Book Corners' contributions eventually justify the overhead; he also floats a possible user-driven alternative, opening a proposed feature inside an existing OSM editor, though he notes that would still need to go through the OSM community rather than function as a way around the rules. His closing point is that external integrations carry organisational and social contracts as well as technical ones, and that discovering those contracts are more expensive than the code, before shipping, is a useful, if disappointing, thing to learn.

Key facts

Book Corners, an app for finding little free libraries, originally seeded its map with thousands of public bookcases already catalogued on OpenStreetMap.
The developer designed a consent-and-review workflow to send user-submitted libraries back to OSM, but found the code itself was the easy part.
OSM's Import Guidelines and Automated Edits code of conduct, read conservatively, require a dedicated import account, a published import plan on the OSM Wiki, a Community Forum proposal, outreach to local communities, and a permanent record linking the account, plan, discussions and changesets, plus ongoing licensing checks on user consent.
He has suspended the write-back feature indefinitely rather than cancelling it outright; OSM-imported libraries will never be resubmitted to OSM as new, and directly contributed libraries stay only in Book Corners.
He may reconsider if a lighter-weight workflow appears or if Book Corners' scale eventually justifies the process, and floats a user-driven alternative through an existing OSM editor as one possibility.

Why it matters

The story is a concrete illustration of a cost that rarely shows up in project planning: contributing data back to a shared open commons is not just an API integration, it is joining an accountable operator programme. OSM's import and automated-edit rules exist because a single careless import can pollute a global, collaboratively maintained database with duplicates or errors that are hard to reverse once other people have built on top of them. For a small project, the gap between 'call an API' and 'run a documented, community-reviewed import programme' can be the difference between shipping a feature and shelving it.

Who it affects

It is most directly relevant to developers of any app or service that ingests data from OpenStreetMap and considers writing improvements or new records back, from mapping side-projects to larger commercial products built on OSM data. It also matters to the OSM community itself, whose import and automated-edits rules are built to protect map quality from exactly this kind of well-intentioned but under-resourced contribution.

How to use it

There is no product or pricing change here: no code ships, and no OSM integration currently runs in production for Book Corners. The practical takeaway for other developers is to research an open-data platform's import and automated-edit policies before designing the integration, since the operational commitments, dedicated accounts, public documentation, community proposals, ongoing licensing and opt-out obligations, can outweigh the engineering work by a wide margin, especially for a low-volume feature.

How solid is it

This is a first-person account from the Book Corners developer describing his own research and decision, not a claim being fact-checked against outside sources. The specific list of OSM requirements he lays out, dedicated import account, Wiki plan, Community Forum proposal, local outreach, review period, and the licensing distinction around user consent, is presented as his reading of OSM's Import Guidelines and Automated Edits code of conduct rather than a quote from those documents. The source does not say OSM rejected or blocked anything: the suspension was his own decision before any production contribution was attempted, and no specific OSM moderator or community response is described.

Risks and caveats

The account is one developer's interpretation of OSM policy, described as the 'conservative reading,' so a different or more lenient reading might exist. No timeline is given for when, if ever, the feature might be revisited, and no figures are provided for how many libraries Book Corners itself holds or how many users it has, only OSM's starting dataset is described, as 'thousands' of bookcases, an approximate figure rather than an exact count. The piece does not name the author or state their role.

“I have decided to suspend the OSM write-back implementation indefinitely.”

— Book Corners developer