This is a proposed roadmap for OSM core software projects through 2026 and into 2027, based on conversations with a number of OSM community members. A lot is already going on day to day, but with the structure of a roadmap, prospective contributors and the broader community can have more clarity on priorities and expectations.
The roadmap is divided into four high-level themes. Under each theme are more specific focus areas, and under those are some representative examples of individual features we hope to land. Some items are well-defined and already discussed in their respective issue tracker, or even underway, while others will need refinement over time.
The roadmap focuses on what we can realistically accomplish if we can interest and/or pay people to work on these tasks. If an item is listed here, you can at least expect maintainers to take the matter seriously. On the other hand, this is not set in stone: if you know of something else we really should accomplish in this timeframe, please make a case for it so we can evaluate any tradeoffs. Question marks indicate features that need further discussion with stakeholders or that would be dependent on factors outside the scope of this project, but are still listed in order to give a full picture of the roadmapping discussions that have taken place.
Table of Contents
The main website is essential to OSM. It mediates many interactions between community members and strongly influences overall community health. It focuses on basic functionality, leaving more advanced derivative tools to the broader ecosystem.
Unfortunately, perceived shortcomings in functionality or user experience have led the community to rely too heavily on third-party platforms for communication and coordination. Second-party tools now work around some missing features, but these tools aren't discoverable enough for the vast majority of users.
With the recent launch of vector tiles, we're giving users another reason to give the main site another look. Let's bring the center of attention back here and help mappers contribute more productively.
- Integrate vector tiles into the website beyond the initial Leaflet-based launch
- Migrate from Leaflet to MapLibre
- Take advantage of vector capabilities (e.g., togglable layers, live data inspector, globe view, translations, larger text for accessibility, dark mode)
- Facilitate communication among users
- Notifications about changeset, diary comments (thanks?)
- Further community index integration (chip away at Microcosms concept)
- Integrate diaries and the forum?
- Antispam/moderation tools to reduce operations team workload
- Review and revise spam score metrics
- Make user list accessible beyond admins?
- Activity logs
- More robust history view
- Filtering history by more criteria
- Augmented diff generation that doesn't depend on external DB mirror
- Visualize tag and geometry changes
- Note management
- Metadata on notes
- Filtering notes by more than geography (age/date, tags, search terms?)
- Notes near home
- Integrate third-party tools
- Expose more search, routing, querying capabilities
- Overlays from QA tools
- Link out to more advanced third-party tools for history, extracts, raw tag editing, etc.
- Link to applications on mobile platforms
- Engaging user content
- CTAs to contribute when logged out (on element detail pages, notes, etc.), possibly informed by Piwik stats
- User profile widgets
- Markdown in more places
- Avoid duplicate uploads
This is a mix of development and operations work. There are several areas that could become urgent and costly for the operations team if we don't pay down technical debt.
- Speed up planet dumps
- Change compression setting during database backup (expected halving of processing time; requires Postgres upgrade)
- Improve resilience of diff generation
- Synchronize timestamp across machines (possibly in the cloud)
- Automate failover including edge cases
- Replace osm-logical with something more mainstream
- Improve large relation performance on Rails
- More efficient API queries for GPX traces (potential breaking change)
- Allow cleanup of GPX traces to reclaim storage space (requires outside help)
- Reconstitute source ZIP files
- Modernize website architecture
- Migrate frontend to use latest Rails conventions to handle assets as well as to work with Javascript.
- Pull in iD and other dependencies via NPM
- Migrate authentication to third-party library (e.g., devise)
- Streamline contributor setup
This theme is purposely light on actual technical changes. There is a consensus that the longstanding dream of data model evolution and API v0.7 is still out of reach given current funding levels and timeframe. The biggest impact we can have is to explain the project to developers on our terms instead of allowing competing platforms to define us.
- Communicate with developers running instances, forks, data consumers
- Identify stakeholders for any future breaking API change
- Convenient tracking of security incidents and other reports
- Improve documentation
- Modernize and translate switch2osm and welcome mat
- Machine readable API and documentation, self-documenting API code (Swagger etc.)
- Recipes for orchestrating low-level tools
- Guides for developers coming from traditional GIS, proprietary map platforms, Overture (understanding data model, how we think about persistent identifiers, etc.)
- More output formats, extracts?
The legal landscape for open data projects has gotten more complex in recent years. Changes in this area have real tradeoffs and will not be popular with parts of the community. Nevertheless, as OSM grows in popularity and influence, we need to manage our legal risk. Any move of the OSMF to a different country may significantly affect the requirements in this space.
- Terms of service acceptance
- Options for showing aggregated content on user profiles
- Filter PII out of certain API calls, planet dumps for GDPR compliance
- Any other items needed for OSA and DSA compliance as they come up