Hi Grant, If you read Serge's post, he is quite clear on what his preferred solution to this resourcing problem. Our tiles and Nominatim services should have terms of services that include paid higher levels that support the foundation, which in turn pays for the infrastructure. When somebody is using too many tiles, or using too much of Nominatim resources, or wants Nominatim to work better, etc, before chasing them away, the foundation should ask them for money to support the requested services.
There is plenty of money around this space to pay for a full time system administrator staff and some developers. Pokémon Go netted 600 million dollars in the first three months. Mapbox just go $164 million dollar investment. I don't understand why you, Tom, lonvia are not paid, full time employees of OSMF by now. Mapbox is doing a great job with ID development, but obviously they are not going to seriously fund our tiles and geocoding. There is a great need for what OSM does, we just need to ask for money, rather than acting like a charity, begging for handouts. Jason > Nominatim effectively only has 1 maintainer / primary contributor: > https://github.com/openstreetmap/Nominatim/graphs/contributors > lonvia spends a significant amount of her volunteered time defending > the service again abusers. > https://operations.osmfoundation.org/policies/nominatim/ > Single users can overload nominatim by sending 1000s of automated > requests per second, the same holds true for the tile servers we run: > https://operations.osmfoundation.org/policies/tiles/ > > Nearly as bad contribution wise is the server infrastructure code: > https://github.com/openstreetmap/chef/graphs/contributors > > What we badly need is more help from developers and chef operations people. > > How about someone in the community organises a Beauty Parade / Cross > Comparison of different open OpenStreetMap GeoCoders? > > The OpenStreetMap Operations team prefers to be able to self-host the > infrastructure required to run OpenStreetMap.org. Reasons: Privacy / > Maintainability / Availability. We don't go this route for a > navigation / router as they seem to be under constant flux, without a > clear "winner" and system their requirements keep climbing. > > Kind regards, > > Grant > > _______________________________________________ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk _______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
