After last month’s great news, we had finally the time for a team huddle to hash out our fall schedule and create concrete plans for improving OpenStreetMap. I’d like to share our initial priorities, the principles we’d like to work by, and how you can get involved.

The proposal for the Knight grant is intentionally broad, but it aims to:

  1. Improve editing of OpenStreetMap data
  2. Make the OpenStreetMap experience more social
  3. Make it easier to get data out of OpenStreetMap

While these goals are pretty general, they coincide very much with longstanding feature requests in the community (1). The process over the next couple of months will be to put meat onto these bones. Before I get more specific, I’d like to outline the principles we’d like to work by.

  • Build in the open - to allow anybody in the OpenStreetMap community to engage and to facilitate a transparent process, we’ll be doing all development work in the open and coordinate on public issue trackers.
  • Open source - it should go without saying, but in the interest of the sustainability of this project and the maximum benefit for the OpenStreetMap community, all code produced under this grant will be open source from the beginning. Just like any code that powers OpenStreetMap’s infrastructure should be open source.
  • Small pieces loosely joined - One of the amazing things about OpenStreetMap is how prolific its community is when it comes to tools that improve our common map. Whatever we are going to build under the Knight grant, it needs to take this into account and favor small building blocks over monolithic solutions.
  • Build agile and iterate - Rather than spending time in coming up with the perfect master plan, we’re going to embrace the unknown, get to write code fast and deploy often, making adjustments far easier.

Improved editor infrastructure

With that said, the place where we’d like to start work is making it easier to build OpenStreetMap editors. This won’t be a ‘Brand New Editor’ in any of the early stages, but changes that lay the ground for more and better editors - namely API improvements.

The basic idea is to improve the OpenStreetMap API so that it is easier to write editor-type JavaScript applications against it, and to write libraries to make it even easier to create these applications. Specifically, this will mean supporting a native JSON exchange format, CORS requests, ironing out authentication and writing dependency-light libraries that make it easy to talk to OpenStreetMap.

Ideally, these efforts should make it easier to create OpenStreetMap editors, and should make existing editors faster and simpler in their dealings with OpenStreetMap data.

Tom has posted an initial backlog on osm-dev and opened several tickets on openstreetmap-website (a), (b), (c). Please join the conversation there.

Soon to come

We’ll start with a light team - the next few weeks will just be Tom and myself getting familiar with the problem area and pushing on the API. Beyond that stage, there’s a lot more to do - figuring out targeted ways to improve the user experience of the website, improve social features, and scope out editor needs.

Stay tuned and get involved

  • Get involved: Chime in on code and reviews on the relevant issue queues. Right now for upcoming API work, this is going to be openstreetmap-website.
  • We will be posting regular updates here on http://mapbox.com/, follow the the blog for an overview as to where development stands.
  • Join us for a Birds of a Feather session in Portland for some more in-depth conversations around improving OpenStreetMap.
  • If you’d like to get in touch personally, drop a note at any time to tom@mapbox.com or alex@mapbox.com. You can also just get in touch on IRC: tmcw or alexbarth in #osm or #osm-dev on irc.oftc.net.

Footnotes: