FOSS4G Community Program Review

It’s that time of year again! The Community Program Review for FOSS4G has begun!

If you’re going to FOSS4G, or seriously thinking about going, the review is a way to ensure that the program includes topics you are interested in. You scroll through a list of all the abstracts the conference has received, and select the ones that are of interest to you. The conference committee tabulates all the results and uses that data to help build the program and to slot talks into rooms of appropriate size.

The number of abstracts is a good deal larger than the number of slots this year, so taking the time to do the review is a good idea if you’re planning to attend this year!

Lazyweb: SDE requirements for PostGIS

Oh, lazyweb, I beseach thee!

Can you tell me, for each version of ArcSDE, what version(s) of PostGIS is/are supported? I’m at the Washington GIS conference, and folks are using SDE on PostGIS, and some of them are using old versions of PostGIS, so I need to know how far back we have to apply patches in order to fully support users who have deployed SDE on PostGIS.

Update: The lazyweb responds, with ArcSDE 10 requirements, ArcSDE 9.3.x requirements and recap: PostGIS 1.4.0 for ArcSDE 10, PostGIS 1.3.2 for ArcSDE 9.3/9.3.1

Also, from Cort Daniel of Pierce County I hear that minor releases as late as PostGIS 1.3.7 and PostgreSQL 8.3.5 work (unofficially) for ArcSDE 9.3.

Update2: Cort also said that while PostgreSQL 8.3.5 worked with ArcSDE 9.3, 8.3.7 did not (date fields stopped working right), which is really really odd. Not sure if anyone else could confirm that.

Surveyor's Sermon

Last month I had an opportunity to give a 5-minute “Ignite” talk at Where 2.0 in San Jose. I chose my topic because I fear one of the things missing in the technologist enthusiasm for geolocation, particularly in the population of technically astute but non-geo people, is a respect for how locations are actually derived, and knowledge of the provenance of the data that undergirds our new mapping tools.

</param></param></param></embed>

FOSS4G 2010 Going to be Big

The presentation abstract deadline has passed for FOSS4G 2010 and there have been 354 abstracts submitted! I’m not sure the exact number of session slots in the planned program, but for comparison 2007 had 120 slots and subsequent events have been similar – that’s about how many 30 minute talks you can fit into two days in a five-track format. In 2007, the biggest FOSS4G so far, we had around 240 submissions for our 120 slots. So, with three submissions for every slot, 2010 is looking like it is going to be gangbusters! Everyone wants to go to Barcelona, I guess they heard about the escudella i carn d’olla.

On the road to Damascus... GPL to BSD

In response to a Twitter comment I made about my change in attitude towards the BSD and GPL open source licenses, Martin Daly asks:

Blog post on the Damascene (or otherwise) conversion from GPL-ish to BSD-ish please. In your own time.

The reason I was even mentioning the license issue is because I was watching a panel discussion at Where 2.0, in which Steve Coast, in defending the GPL-ish license used for OpenStreetMap, said (paraphrase) that the rationale was keeping a third party from taking the open data, closing it, and working from there. And that rationale pretty closely mirrors how we were thinking when choosing the GPL license for PostGIS, back in 2001.

I have experienced no spectral presence or flashing lights.

However, over the years, I have spent far too much time talking to various corporate folks about how the PostGIS GPL license wouldn’t affect their plans to use PostGIS as a database component in their systems. For everyone who came and asked, I am sure many didn’t. But in general the license was an impediment to some organizations engaging with the project. So there was a downside to the GPL. And was there an upside? Did the license protect us from privatized forks?

Well, yes, insofar is as it legally prevented them from happening. But it is worth questioning the implicit assumption that such forks are actually harmful to the project.

And here my experience watching the MapServer community (working with the BSD MIT license) was useful. Because over those same years, I watched the MapServer project chug healthily along, even as some third parties did in fact take the code and work on closed forks from time to time.

The lesson I have taken from my observation is that the strength of open source projects resides not in the licenses or the code, but in the communities arrayed about them. Copying the code of MapServer and doing your own thing with it does not stop MapServer developers from working, and in the long run you’ll probably be better off working within the community than outside it, to gain from the efforts of others. Trying to maintain a private parallel branch and patch in the changes from the open development will quickly become more effort than it is worth. At the same time, because the BSD license is so permissive, there are no legal impediments for companies to engage with the community.

Look at any healthy open source project and ask yourself: what is more valuable, the code or the community? You could take all the code away from a healthy project, and it would start right up again from scratch and probably do a better job the second time. The value is in the human relationships and the aggregation of cooperating talent.

The GPL tends to keep corporate actors out of the community (for good reasons or bad, that’s a separate discussion, but it does). That slows down the development of the project by reducing size of the development pool. Which, counterintuitively, makes forking or ignoring the open project more attractive. Because a slow moving project is easy to beat. A fast moving project is risky to fork, because it is likely that your (relatively understaffed) fork will be left behind by the open project.

So, back to what originally made me delve into license wankery, the question of OpenStreetMap license: the value of the OSM community and philosophy and infrastructure is way higher than the data at this point. And bringing corporate actors into the OSM community would only increase the relative advantage of the open project over any equivalent closed effort.

But changing licenses is a brutally hard thing to do, and it gets harder the longer a license is in place. PostGIS will never change licenses, for example. There are too many developers who contributed in the past under the GPL, and changing license would require the assent of all of them.

But if I ever start a new project, it will definitely be under the BSD.