Why Book Corners won't sync contributions back to OpenStreetMap

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,