The Day 1 afternoon panel was titled Gaps and Voids in Open Source Geo Technology. The idea was to have those in the know highlight what was “still” missing in open source geospatial offerings, offer some insights into why and even offer solutions.
The panel included the following folks who were expertly questioned by Sophia Parafina.
- Howard Butler, Hobu Inc.
- Nathaniel Kelso, Stamen Design
- Tom MacWright, MapBox
- Juan Marin, OpenGeo
- Schuyler Erle, Entropy Free LLC
What follows are the key ideas I took away. My apologies to the speakers for not assigning ideas to individuals; I treated you as a collective. : )
Why do open source geospatial software interfaces “suck”?
- Expectations for interfaces change. At first a command line is fine, because you are writing for yourself or for other techies. When people get frustrated and angry, they build more elegant an accessible user interfaces.
- We live at the intersection of bad open source user interfaces and bad GIS interfaces. That’s in part because there is a belief that programmers can build good interfaces. They can’t. Organizations need to hire actual interface design professionals.
- A user interface indicates the maturation of a programmer(s)’ project (meant to scratch an itch, that is quickly solve a problem for an individual or group) to a the development of a product.
Development Seed requested $1 million to fund development of a simple to use user interface for editing OpenStreetMap. Is that too much money?
- No, the user of OSM is changing; this is not too much. Map users are (and should be) data creators and editors, too.
What is the state of project communities? Should they be large with players from many organizations? Focused around a single organization (such as a company)? Which size grows best?
- More control via a smaller group can mean more steady progress. Larger groups of input and more committers can mean more “pulling in different directions.” Either way can work.
- The smaller the bits of code, the more likely they are to be used in more projects; there is more commonality. That breeds better and more active collaboration and less competition.
- Big commercially funding projects are ok, but giving money for smaller enhancement to core functionality is valuable and necessary. Don’t overlook such contributions.
- As projects mature, organizations are likely to pay for “add-on” type features. It’s hard to draw funding pay for core enhancements, such as restructuring the core when/if needed.
Should shapefiles be replaced with Spatialite?
- The source code open the development of that source code is not. I’m not comfortable with this option.
What are the trends in open source licensing?
- The more liberal licenses are becoming more popular. Why? The cost of internal forking (splitting off from the core development effort and “doing your own thing”) is higher than working on the actual project.
- Licenses are cultural - some organization/industries/geography prefer one type over another. Richard Stallman (of GPL and LGPL fame) says use what works for your project.
How do we make money? Do we follow the beekeeper model? (Developers are bees who sell their services to those who sell their output, aka honey/wax.)
- The real business model is making things work. There are some 400 online galleries to store and share photo galleries, but the vast majority use just two: Flickr and Facebook. Why? They scale and folks stay up at night to keep them running.
- Another model is to be a data integrator. Google is one.
What are your wishes to fill gaps that you see?
- Use same PRJ files
- Geojson growth; institutional support for open source not just GIS, support for basic research
- Software and data need to be more literate and archival - metadata should include what’ what’s wrong with datasets
- A Real-time Game-like Modeling System for the World - real time “what if” modeler
- More cross project collaboration will create superior output
- more coverage of FOSS4GNA