Foundation/AGM21/Election to Board/Answers and manifestos/Q10 Technology Gaps

From OpenStreetMap Wiki
Jump to navigation Jump to search

Technology Gaps

What do you consider to be the key technology gap areas in the OpenStreetMap ecosystem that the community should tackle over the next 2-3 years, and what role do you feel the OSMF has in addressing those gaps?

Guillaume Rischard

The major answer to those gaps is the freshly reactivated Engineering Working Group, which will be given a budget to solve these gaps.

One commonly cited gap is vector tiles; the community survey, however, was not definitive in telling us that the OSMF should support their creation. OWG is currently working on creating a vector tile playground, hoping to encourage further work on them. I’m impatient to try it out.

My pet gap area is providing a live database replica for developers. Maybe that’s something that we can have on the upcoming new dev server.

Some of our communication tools are unmaintained antiques. I’m excited to see work progressing on hosting a Discourse server to eventually merge forums, OSQA and mailing lists.

Double work is extra work, and I’d like to see technical solutions to the various imagery, preset and QA rule indexes we have.

Our website needs work. Andy and Tom are doing good work on it, but they’d need more help if we want to update, say, the History tab, or find a way of including a News section that doesn’t break the layout. I’d like to ask the community for ideas on how best to improve the website, and hope that EWG will pay particular attention to it.

Some of the 2020 microgrants have helped closed some gaps, and maybe future microgrant budgets can be earmarked for some of the areas we’d like to improve the most.

Michal Migurski

Core platform accessibility for new project contributors is OSM’s critical technology gap. OSM’s infrastructure is appropriately structured as a nested set of concerns with a stable core database at its center. This is good. However, the operation and maintenance of this core falls to a small working group of administrators whose numbers have fallen over the years. This is a crisis. We know that OSMF seeks to hire a full-time Senior Site Reliability Engineer to plug this gap. I also believe that the board should more directly encourage our core platform to offer learning and participation opportunities for newcomers. I’ve worked on aspects of making contributions technically easier over the past year, and hope to encourage more (

Amanda McCann

  • The OSM website hasn't changed much in years, and should have some nicer features.
  • Vector Tiles are still a bit of a mess. As a technological approach they could solve so many issues, and here we are years later and we're still not using them. I've had to install & maintain some nodejs hacky vector tile software that doesn't work on recent versions of Linux and it's all a pain. I wish OSMers could use this software more.
  • I think focused editing apps like StreetComplete are a great way to improve the strengths of OSM. OSM will always be horrible at “machine learning computer vision imports”, because we'll always have less resources than GAFAM, but they don't have volunteer mappers.

OSMF can help by giving some money to fund development. Part of this was done in the last OSMF Microgrants round. As a programmer, I could practically help by submitting patches. As a board member, I would have a duty to encourage people to contribute to those projects.

Mikel Maron

My view is that the OpenStreetMap technical ecosystem is broadly strong and covers many needs well. The greatest technological gap is in the integration and discoverability of services. There are many powerful tools for analyzing OSM data, monitoring quality, understanding users, connecting with community, etc. But these are dispersed among many sites and are hard to find and use together. is a natural hub for these various tools.

The challenge then becomes twofold. One is enabling an effective developer community on the core website. Second is developing a collective product vision for the site that addresses needs of all stakeholders. I think that targetted support to bring more long term contributors to focus on specific needs of the OSM website is one way the OSMF could help address these gaps.

Additionally, there's a more social than technology gap in our ecosystem. Many of our core software tools have a minimal number of maintainers and contributors. The OSMF has recently revived the Engineering Working Group, which will serve as both a hub for development across the ecosystem, and a provider of grants for needed development work.

Roland Olbricht

This is out of scope for the board. I suggest that you contact the Engineering Working Group of the OSMF, join them or read at least their minutes.

Bryan Housel

Our operations team is doing a great job and I am still in awe of what they are able to accomplish with a small team of volunteers. I follow their work here:

I see our biggest technology gap as Core System Stability - for example, we commonly see:

  • Gaps in the production of weekly planet files and replication diffs
  • Downtime on support services like the Overpass API
  • “Website under heavy load” errors

Issues like these represent threats to OpenStreetMap’s “Technical Core” (to borrow a phrase from the Strategic Plan Outline: “without which OpenStreetMap disappears”).

I know that I’m not alone in my concern about this issue. Respondents of the 2021 OSMF community survey Question S1 on board priorities overwhelmingly listed “stability of the core infrastructure” as the top priority for the OSMF board.

The OSMF can do several things to address these gaps:

  • Hire a SRE (Site Reliability Engineer). This needs to be a top priority above all other hiring. (At the time of this writing it seems like a candidate has been chosen in closed board sessions but not yet announced or hired).
  • Ensure that our core services have the redundancy needed that they can fail over to a backup, and test this sometimes.
  • Establish monitoring for the core outputs of the project (planet and replication files)
  • Encourage a “culture of testing” [1]. This would involve making the dev and staging environments more functional. Currently it is possible to add test data to the dev server, but there are limitations (for example staging server currently displays production tiles). In an ideal situation, developers and community members could always preview next versions of tile styles with real data, and test software against the next version of API / Rails / cgimap, etc.


OSM Foundation's board election 2021: official questions

All board candidates' manifestos

OSM Foundation's board election 2021 - OSM Foundation's Annual General Meeting 2021: information and agenda