REST without RESOURCES

So, I’m busily evangelizing REST in my company, because it “just feels right” to me, but… there are practical problems to solve!

For example, what would a REST geocoder look like? The application is bascially all service, no resources.

Green Fields

One of the points I make repeatedly when talking to people about how open source GIS and open source in general are penetrating the marketplace is that open source thrives in “green fields” environments.

“Green fields development” is a real estate term, referring to brand new housing build on previously un-developed land. I use it to refer to systems that are built fresh without having to fit into pre-existing technology infrastructure. Usually, green fields developments are undertaken by start-up companies, but sometimes larger companies will allow new developments to choose their own technology baseline.

Linux/Apache really took off as start-ups built out their web serving infrastructure. A whole new application category with no incumbent vendor. When they evaluated their technology options, start-ups could see Solaris/SunOne as one expensive option, and Windows/IIS as another less expensive option, and Linux/Apache as the least expensive option. Given approximate technical parity (80/20 rule) the choice is clear.

The same thing is happening now with the geo-start-ups. I found very interesting the technology list that Peter Batty laid out in his musings on a geo-start-up. PostgreSQL, PostGIS, Ruby, Python, web services. All very open, most open source. And this is an individual with an intimate knowledge of the various technology options available in the geospatial market-place.

We see the same thing in the kinds of people contracting us for work on PostGIS and Mapserver and web mapping apps. They are start-ups. They don’t have any built-in vendor biases. They are just choosing the infrastructure with the best price/performance, and open source is what they are choosing.

Board Bound

The results are in, and I am now a freshly minted member of the OSGeo Board of Directors. Last time out, I plead time constraints and did not stand, but this time I decided to take the plunge.

I think over the last year, OSGeo has proved out some of its promise, most clearly in providing a “voice for the community”. So many organizations – business, governments, conferences, etc – require a single point of contact. Being able to say “we’re the point of contact” opens so many doors that would otherwise remain closed. So I’m looking forward to pushing that aspect of OSGeo forward over the next year.

Decisions, Decisions...

One of the things I told the rest of the committee when starting organizing for FOSS4G 2007 was that I wanted a “narrower” conference. The 2006 event had run 8 tracks wide, which meant that, no matter which room you chose, there were always two other rooms that had something else you wanted to see at the same time.

So I lobbied hard to shrink down a little, and got folks to agree to a presentation program that was “only” 5 tracks wide. But then the Call for Workshops was flooded, and we couldn’t bear to say no to 80% of the submissions, so we ended up tacking two labs tracks onto the side of the main program, and voila, we are back at seven tracks wide.

All this means that there are no easy decisions in figuring out what parts of FOSS4G to see this year, sorry, I tried! Here’s the tentative schedule grid:

Biggest. FOSS4G. Ever.

With 450 registered as the early bird deadline passes, the 2007 edition of FOSS4G is now well positioned for attendance in the 600 to 700 range, easily besting last year’s total of 535. Previous conferences registered up to 50% of their attendees in the last month before the conference, so attendance could go even higher.

Biggest. FOSS4G. Ever.

Many of the workshops are now at capacity, but there are still a couple left. Not for long though. All I need now is Comic Book Guy, or Juan Antonio Samaranch to declare FOSS4G 2007 the “biggest FOSS4G ever!”.