Stay Connected with the Boundless Blog

Washington GIS conference Discusses Open Source In Deployed Projects

I spent three days at the Washington GIS conference last week, and it was a useful reminder about the real world. That is, the world where technology is a means and not an end.

The comparison with an event like Where 2.0 is pretty stark: the metric of evaluation is decidedly not “is it cool”, but rather “is it useful”.

It was gratifying therefore to see “open source” moving into the “useful” column in such practical organizations. A surprising number of presentations were about the use of open source in deployed projects.

Even so, most of the organizations there were still at the “intrigued but interested in learning more stage”. And being practical people, they asked practical questions like “what is the first thing I should do to start experimenting with open source?

That question put me back on my heels. There’s lots of things one can do to start with open source, but what is the logical very first thing?

The self-serving answer would have been “download the OpenGeo Suite and get to it!”. But the question came from a GIS Manager, so it was not a matter of personal enlightenment, but organizational direction. What can he ask his subordinates to do that will make this new technology option available to his organization?

Fortunately, there is a success story right in the area, Pierce County. A big chunk of the talks about use of open source were from Pierce County employees. Back in 2007, the GIS Manager sent a group of her best technical staff up to Victoria, BC, for the FOSS4G conference to “look for some options” in solving some nagging technology issues they had.

And they came back with lots of options.

So then she empowered them to pick some and try them on pilot projects, which they did. And the ideas that worked found their way into core standards of the county. And now GeoServer is used for some of the map rendering, and OpenLayers is the new standard web map component. And they haven’t thrown out their old infrastructure, much of it is still there: they’ve just improved on it and provided a more diverse road map for the future.

So, here is a draft program for curious managers:

  • Decide whether you have a problem. Change will always cost a bit, in terms of convenience and time and learning new ways of doing thing at least. So if you are happy the way you are, maybe change isn’t for you. It might be a good idea to talk to your technical team and see if they are happy too.
  • Select a technical core team to learn about the options and empower them to do so. That might mean bringing in training, or just providing “free time” to learn about and report on options, or if you’re lucky sending them to a conference like FOSS4G.
  • Encourage the team to learn not just the technology but also the culture of open source. Sign on to mailing lists, attend local user group meetings, get to know how open source is actually developed and by whom. That soft knowledge will be incredible valuable if you start to depend more on open source. (Why? Questions like “will that feature be in the next release?”, “how can I get that bug fixed by Wednesday?”, “does it work (well) with component X?” are all easier to answer for people with the soft knowledge of community interaction and resources.)
  • Give that team some problems to solve. Pilot projects, one-time projects, etc. At the same time, ask them to integrate their solutions into the existing infrastructure as much as they can. You want your team to develop knowledge in integration because you’ll never change your whole infrastructure in one go. Having your team learn to build silo’ed all-open-source stacks won’t help in the long run.

The organizational reality of most counties and cities in Washington, and presumably in most of North America, is that their GIS technology is provided overwhelmingly by ESRI. That means that new solutions have to integrate with that stack. Fortunately, there are a number of integration points: at the database level, below the database level, at the user interface level.

Have a look at the OpenGeo architecture for a generic discussion of heterogeneous technology integration. We’ll be publishing a white paper about the specifics of integration with ESRI this spring, based on the many useful things I learned from talking with the good folks at Pierce County!