Strategic working group/Suggestion review

From OpenStreetMap Wiki
Jump to navigation Jump to search

This is an exercise by the Strategic working group to compile suggestions/comments made by the OSM community as to the future direction of the project.

We are looking to collate suggestions about OSM future strategy (e.g. "OSM should grow the mapper base", "OSM should make special efforts to reach out to the developing world", "OSM should develop into a consumer-facing map site to rival Google Maps"). We're not looking for operational suggestions (e.g. "OSM should rewrite the editor in HTML5" :)).

We're not making any judgments about the suggestions: just collating them. At a future date, SWG can begin to assess the suggestions against OSMF's stated mission; consider feasibility; and start to make recommendations as to whether any strategy should be taken forward by OSMF or indeed pursued outside the organisation. But that's a way off yet.

Any eventual suggestion that something could become a strategic priority does not mean “the OSMF board/working groups do it personally”. Rather, “the OSMF works with the community to get it done in the most sustainable way".

From US talk

  • Questions raised about the status of local chapters, organisation, mission and charitable status in different jurisdictions (Sept 2009, I know this may have been partly resolved subsequently). How to create a set of Bye-Laws (Mar 2010).
  • Discussion about flamewars and the "right" way to edit may imply a need to have a mechanism for achieving consensus and then ensuring that agreements are adhered to (Feb 2010).
  • Declaration of potential conflicts of interest. Should this be mandatory for all OSM chapters and groups? (Feb 2010).
  • Should there be a channel for "professionals" to communicate with OSM? (e.g. Public Sector who might be alienated/discouraged by the tone of the main mailing lists).
  • The debate about the license change (some contributors deleting their data) points at a need to review the relationship between OSMF and the wider community (May 2010).

From (international) talk@ list and wiki

Scope of data services (API and tile)

  • Available to all-comers vs mappers only?
  • Providing data in more user-friendly formats (e.g. extracts vs full planet, thematic subsets)
  • Helping others to set up commercial/co-operative third-party services/mirrors

Scope of website

  • Making the richness of the data more apparent (e.g. via tile layers, dynamic POIs).
  • Providing more tools for mappers (see below).
  • Providing tools for end-users (e.g. routing) to encourage take-up and awareness.

Helping new people to become mappers

  • Encouraging/supporting provision of tools where we’re lacking (e.g. mobile editors, bug UI, ‘please review’).
  • Providing resources for learning OSM (e.g. sandbox).
  • User hierarchy/status, edit quality ratings etc. (very very very controversial!).
  • Strongly advocate and enforce 'community standards' on mapping (import guidelines, etc.).
  • Documenting and encouraging consensus (e.g. on tagging) to reduce barrier to entry.
  • Outreach to attract new mappers, perhaps targeted to particular demographics.
  • Research to identify barriers to entry and (perhaps more crucially) to retention.
  • Consider new approaches to contribution (e.g. 'gamification').
  • Consider retaining barriers to entry that tend to keep mapping quality high (the "some barriers are good" principle).

Providing resources for existing mappers

  • Negotiating for and acquiring imagery/other sources.
  • Identifying missing tools and encouraging their development (e.g. tackling vandalism, routing views).
  • Integrating worthwhile tools into (e.g. quality assurance).

Encouraging the development of the map

  • Providing tools and support for particular coverage goals, whether thematic (e.g. addressing) or localised (e.g. humanitarian, or lagging countries esp. US) - perhaps by expanding/integrating the Project of the Week/leaderboard concept).
  • Setting goals (and bounds) on what should be mapped.
  • Provide tools and support for map review as well as creation.

Encouraging the OSM community

  • Encouraging/celebrating ‘local knowledge’ mapping, discouraging/forbidding ‘seagull mapping’.
  • Bring local mappers together (with appropriate tools/feeds on the site).
  • Bringing national OSM communities together.
  • Encouraging shared community (e.g. SotM streaming).
  • Actively working for a more harmonious community (e.g. mailing list moderation, firmer guidelines on worthwhile edits/imports/community cohesion - see OpenSeaMap counter-example).
  • Encourage and support social events (replicating successes in Germany, London, etc.)
  • Provide greater appreciation/visibility of developers’ work to encourage more.
  • Resolve and develop Local Chapters issues.

Encouraging the OSM ecosystem

  • Finding ways for other services/sites to use OSM (e.g. id linking).
  • Actively market to, and provide documentation and services for, third-party developers.

Improving the public profile of the map

  • Co-ordinating design issues (website and cartography).
  • More actively enforcing licence violations.
  • Outward-facing comms where publicity opportunities arise.
  • Actively marketing to, and developing partnerships with, other organisations who can bring visibility and users.
  • Organizing stalls and booths at conferences and trade shows.
  • Provide information flyers to make more people aware.

OSMF scope and priorities

  • Provide consumer-facing services, possibly paid-for (very controversial).
  • Concentrate on small number of core services.
  • Recruit more developers/other volunteers for core services.
  • Seek corporate donations to OSM.

From HOT list

  • Better support for right to left reading languages.
  • Ability to link OSM data to data from other systems.
  • Support for introducing OSM to new people at events.

Old favourites

Showcase OSM capabilities by including on main site

  • Routing engine.
  • Public Transport Layer.

Include end-user functionality on main site

Traditionally resisted by many mappers. The arguments in favour generally involve ease of converting users from other maps.

  • Push pins.


  • Use >1 database for performance.
  • Use >1 database for redundancy and resilience.


  • Free ponies for everybody.
    • With glitter!