Why Book Corners won't sync contributions back to OpenStreetMap

Fri, 31 Jul 2026 00:00:00 +0000

A feature that sounded obviously good

When I introduced Book Corners, I explained that much of its initial data came from OpenStreetMap. OSM gave the project a useful starting point, with thousands of public bookcases already mapped around the world.

Book Corners also accepts new libraries directly from its users. People can submit a location and a photo, and the contribution becomes public after moderation. It seemed only fair that, when one of those submissions was missing from OSM, Book Corners should be able to contribute it back.

The idea was not to create an uncontrolled background synchronisation process. The workflow I had in mind was deliberately cautious:

The person submitting the library would explicitly allow the contribution.
An administrator would review the library first.
Book Corners would search OSM for possible duplicates.
The administrator would preview the exact data being sent.
Nothing would be written until the administrator confirmed it.

From a software-development perspective, this looked like a manageable integration: add consent, track contribution state, build a preview, authenticate with OSM, and create the new feature through its API.

The code was not the difficult part.

Contributing data is not just an API call

Once I started researching the implementation properly, I discovered that writing to the API was only a small part of the work.

Because the information would come from the Book Corners database, OSM could consider it an external-data import. Because software would prepare and submit the changes, it could also fall under the rules for script-assisted or automated edits, even though an administrator would review each individual library.

Following the conservative interpretation of the OSM Import Guidelines and the Automated Edits code of conduct would require more than a dedicated account and an OAuth token.

Before the first production contribution, I would need to:

Create and maintain a dedicated OSM import account.
Publish a detailed import plan on the OSM Wiki.
Document 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 relevant local communities affected by the contributions.
Wait through the review period and resolve any concerns.
Keep permanent links between the import account, plan, discussions, and changesets.
Maintain a contact and opt-out route for future questions or complaints.

There are also important licensing questions. A user’s permission to send a library to OSM is not automatically the same as having a sufficiently clear right to release that factual information under terms compatible with OSM. The user-facing explanation and consent would need to cover that distinction, including confirming that the information was not copied from an incompatible source.

These requirements are not a one-time form to complete and forget. They create an ongoing responsibility around the account, the documented process, community feedback, failures, and potential reversions.

I understand why these rules exist

OpenStreetMap is a shared global database. A bad import can create thousands of duplicates, overwrite better local knowledge, or introduce errors that are difficult to remove once other people have edited the same objects.

From that perspective, requiring documentation, licensing clarity, duplicate handling, accountable operators, and community discussion is reasonable. The OSM community has to protect the quality of the map, and good intentions do not guarantee good data.

Book Corners itself benefited from that data quality. It would be hypocritical to expect OSM to accept changes from an external service without safeguards.

At the same time, the process has a real cost. It asks a small project to become not only an API client, but also the operator of a documented import programme. That may be appropriate for organisations importing large datasets, but it is a considerable commitment for a low-volume feature whose only purpose was to contribute a few carefully reviewed public bookcases back to the commons.

The operational work outweighs the value

Book Corners has a simple purpose: help people discover little free libraries and share new ones with others.

Operating an OSM contribution pipeline is not central to that purpose. It would add credentials, production safeguards, audit and reconciliation code, community processes, licensing work, and a long-term support obligation. Every part is individually defensible, but together they make this a much larger feature than I initially intended.

There is also an opportunity cost. Time spent operating this integration is time not spent improving library discovery, moderation, photos, accessibility, translations, or the mobile experience. Those improvements directly help Book Corners users and are much easier for a small project to sustain.

I started from the feeling that contributing back was simply the nice and fair thing to do. After investigating it, I no longer think goodwill alone is enough reason to accept an open-ended operational responsibility.

The decision

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

Book Corners will continue to acknowledge OpenStreetMap as the source of records imported from it, and OSM-imported libraries will never be submitted back as if they were new. But libraries contributed directly to Book Corners will remain in Book Corners; the service will not automatically or manually create matching OSM objects.

Nothing currently writes from Book Corners to production OSM, so suspending the work does not require disabling or migrating an existing integration.

I may reconsider the decision if a genuinely lightweight workflow becomes available, or if the scale and value of Book Corners contributions eventually justify the process. Another possibility would be a user-driven workflow that opens a proposed feature in an existing OSM editor, although that would still need to be discussed with the community rather than treated as a way around the rules.

For now, the responsible choice is not to build and operate a feature I am not confident I can support properly.

Sometimes the right feature is no feature

It is easy to think of implementation decisions as purely technical: can the API do it, can the application authenticate, and can the code avoid duplicates?

This experience was a reminder that external integrations also come with organisational and social contracts. Sometimes those contracts are more expensive than the code. Discovering that before deployment is useful, even when the result is disappointing.

I still believe contributing data back to shared open projects is valuable. I also understand why OSM protects its database so carefully. But for Book Corners, at its current scale, the balance between benefit and responsibility does not work.

So this is one feature I am choosing not to ship.