Hobu, Inc.

… we’re making excellent, industrial software too. Jeff seems to dismiss the notion that self-organized software development can provide the same level of quality or standing that closed-source, cathedral-style software can. Readers of my weblog should be able to fill in my arguments against this idea without me even having to write them

Speaking of beer and pizza, if ESRI ever wants developers to go out and sell their products for them, they need to quit charging for EDN. As ESRI moves to selling server-focussed software, they need to realize that *developers* are the people they should be marketing to. Yes, the developers don’t hold the purse strings, but if you give the developers the ability to build out a one-off that demonstrates specific organizational functionality, your sales job is done. As it stands now, I think developers are one-off’ing in OpenLayers, MapServer, FeatureServer, GeoServer, and PostGIS. My evidence is completely anecdotal, but I’ve noticed a continuing stream of curious developers showing up and asking very basic questions how to get going. ESRI’s missing these folks, and in my opinion should be taking the same tact with developers that Oracle does. Otherwise, a day or two of fiddling with OpenLayers doesn’t cost $1500 like an EDN seat does…

Even having EDN doesn’t get you much. One fairly serious security-related bug has been stuck in my craw for over a year, and even though I have an EDN seat, I don’t have “support” and I’m not allowed to file bugs. This is completely ridiculous. I wasn’t asking to have my hand held through installing ArcGIS Server. Instead, I was filing a very clear and easy to demonstrate bug. Had this been an Open Source project, I would have filed the bug *with* the patch to fix it as well. Currently, my only hope is to make enough noise on places like this weblog in the hopes of guilting or shaming someone to notice and fix it

OSGeo is a member supported organization, and its entire operating budget comes from sponsorship. One thing that I think is critically important to ensuring continuing sponsorship is to report back to them annually with a “here’s what we did because of your support” report.

We’ve had an Executive Director for over a year, and we’ve been in operation for almost two, but we’ve yet to have an annual report of OSGeo’s activities. I think an annual report is extremely important to help reduce the opacity of OSGeo, show sponsors how their support has actually helped, and give potential volunteers a window into the organization so they can see where to start. Without it, the whole thing’s just a giant black box. In this case, we do need to know how the sausage is made…

The OpenLayers developers and project are probably such rock stars that this fact has little consequence for them, but under my limited tutelage as their incubation mentor, OpenLayers recently graduated the OSGeo incubation process, and it was approved by the board.

Congrats guys!
Update: I see Slashgeo picked up the news.

I do most of my development on OS X, but I do have parallels instances for both Ubuntu and Windows. One thing I really miss on OS X and Windows is valgrind. It is the savior of dumb C/C++ programmers like myself everywhere. Apple ships a couple of tools that are close to approaching the utility of valgrind.

• Chris Hanson’s nice description of how to use the leaks command on OS X.
• ‘man malloc’ on OS X describes a number of environment variables you can use for malloc tracing on OS X.

Still not as good as valgrind, but close enough for a lot of cases…

Hello again. My Plone site got trashed by the spammers, and I’m so sick of Plone that I just grabbed an RSS feed of my posts and plopped them into this Wordpress site. Yes, I know this is PHP. Weblogging in Python sucks.

Everyone’s reimplementing Python bindings to GDAL these days. Sean’s got one or two attempts, and the GeoDjango wrote ctypes bindings for OGR and GEOS. Neither of these efforts are as complete as gdal.py/ogr.py in the standard GDAL distribution, but they are going off and writing new stuff anyway. Why?

GDAL’s Python bindings are really C/C++ in Python form

The API in GDAL’s Python bindings is not at all pleasant to program with if you are a true blue Python coder. There are some gotchas because resource management is foisted on the Python developer who is not used to it, TheNamesOfThingsAreHardToReadSometimes, and the APIs don’t map to other standard Python ways of doing things.

I have been reacting to this by adding more sugar to GDAL’s bindings. Specifically, you will be able to call feature.items() and feature.keys() instead of manually fetching them in the upcoming GDAL 1.5 release. You can also do for ‘feature in layer’ and it will iterate for you. These minor improvements should make things a little better. If anyone has more suggestions for sugar that won’t impact backwards compatibility, let me know.

GDAL’s Python bindings are hard to deploy

GDAL’s deployment story in the past was miserable. Most people depended on pre-packaged Python binaries because it was so difficult to get them built, they didn’t install in a standard (setup.py/disutils) way, depended on external data (the GDAL_DATA directory), and polluted your site-packages. For GDAL 1.5, this story will be improved significantly:

• Setuptools/distutils is now used by default to build and deploy the bindings. I will be registering the GDAL bindings with the CheeseShop, and once available, you should be able to easily build your own bindings if you have the GDAL base library (and headers) installed.
• I am expecting to include the scripts/utilities and GDAL_DATA files *with* the Python package for distributions such as the CheeseShop one and the download.osgeo.org Windows binaries.
• The bindings are now in the ‘osgeo’ namespace, so you can do ‘from osgeo import ogr’ instead of just ‘import ogr’. Note that the old method will continue to work for a while as we deprecate things, but we’re moving in the right direction.

The reimplementers hate SWIG.

SWIG sucks. “Simplified” my ass. SWIG is a complex ball of stuff. If you only have one language to support, SWIG is the worst possible way you could choose to write bindings. If you have five or six languages to support, SWIG is the *only* way you can choose to write bindings and hope to not have to manually maintain thousands and thousands of lines of native interface code. SWIG does indeed suck, but without it GDAL would likely only have Python bindings… not Python, Java, C#, and Perl.