Making Open Source GIS Easier

How can we make getting started in Open Source GIS easier? To begin with, it needs to be easier to

  1. Discover

  2. Install

  1. Use

Discovery

This is probably the least of the problems, but you would be surprised how many people “stumble” on OS GIS each day. Things are improving as more exposure is gained through books, blogs, conferences, and the media. The more we talk about it, the more well known it becomes.

Install

One of the first hurdles a user faces is getting through the install process. To make it easier, a user should never have to compile anything. I know there are those that will take exception to that statement but I think its fair. Most users aren’t C, C++, Python, or Automake experts and they don’t want to be. They just want to use the software. As soon as compilation is required they have to install a build environment, tools, and so forth. Get the version of one of these tools wrong and then dependency issues quickly bring the whole process to a grinding halt.

Whats the answer? – provide ready to install packages for the users operating system. This is easier said than done as it represents a lot of work. How many Linux packages do you have to make? Just to cover the major distributions we are talking about 8 or 10. That number quickly multiplies if you want to support previous versions. Then we have *BSD, Windows, OS X, and probably others.

To succeed, this requires a dedicated group of packagers beyond the core developers. Some projects are lucky to have such folks on board. In others the task falls to the developers that are already busy (read overworked) fixing bugs and torturing the code into submission for the next release. Building up a strong cadre of packagers is key to lowering the barrier to entry.

Ease of Use

This is really the core issue. If its not easy to use people won’t use it. Whats make OS GIS easy to use? Consider these factors:

  1. Cross platform support

  2. Intuitive interface

  3. Support for standard formats

  4. Good documentation

Face it – users love their operating system (well sometimes its a love/hate relationship). Expecting users to convert to a new, unknown operating system to use OS GIS may be a goal of some, but often its not realistic. Look at the successful Open Source projects out there and most of them are cross platform (window managers aside). Cross platform support is important to reach a broad audience.For desktop or web applications, an intuitive and standard user interface (UI) is important. Software that provides a new user with an immediate level of comfort will encourage persistence compared to a UI that is non-standard and confusing. While trying to change the world through a new UI may be an admirable goal you are swimming upstream (anybody remember the 3D cube web browser?).

Supporting standard formats makes it easier for a new user to get started and see some success immediately. Most OS GIS applications do a pretty good job of this already. Early on in the QGIS project there was discussion about creating a “format” for storing spatial data. This was rejected for the very reasons mentioned here. Forcing a user to convert their data before it could be used was an action that would significantly raise the barrier to entry. I’m not saying there isn’t a place for new formats, just don’t abandon the long standing mainstays of the discipline.

Good documentation is essential. I don’t think anybody would argue with that point but frankly its one of the shortcomings in many areas of OS GIS. There isn’t a lack of information, its just difficult to navigate. Documentation, like packaging, is a big job. Most developers aren’t technical writers – no shame in that – but it can affect the quality of documentation from a newcomers standpoint. In a perfect world the OS GIS community would:

  1. Create consolidated, concise, and clearly written documentation

  2. Enlist the aid of those with writing experience (I know this can be hard to come by)

  3. Include lots of examples.

The last item is important. Some people learn by reading specifications, API’s, and general descriptions while others learn by example. Seeing a clear example of a concept or process can be incredibly helpful. We as developers probably shouldn’t write our own user documentation any more than we should test our own code. I guess I’m sensitive to this since today I spent an hour or more reading multiple web pages, FAQs, and other documentation to solve a problem when a simple example would have done the trick. Turns out this was for a non-GIS application so the problem isn’t specific to any type of software.

Of course item 4 thats not on the list is to get the users to read the documentation. But thats a topic for another day.