February 24th, 2009
OpenGeo has embarked on a company-wide retreat this week. Since the members of our team work in six different countries on three continents and across ten time zones, we are quite used to working together remotely. With OpenGeo growing in size, however, it is worthwhile for all of us to meet in one physical location for the first time to articulate our roadmap and goals for the future.
So we’ve alighted at a small farm in upstate New York, spending the next few days working hard and playing hard. While we are not coding much (we’ll be code sprinting this upcoming weekend), we are meeting together to decide how we can most effectively pursue our mission in our world. We will detail the results of this meeting in the weeks and months to come.
February 17th, 2009
Decision makers find many aspects of open source software counter-intuitive, because they have gotten used to being the weaker member in relationships with powerful vendors. You don’t tell Oracle what features will be in Oracle 12p (the “p” is for “pfooey”), Oracle tells you. You don’t talk to the developers of Oracle, they are kept in a locked room in Redwood Shores. If you find a bug in Oracle that is in your application’s critical path, you wait until Oracle releases a patch, if they decide to.
Some of the power relationship problems are a function of enterprise size. The Department of Defense probably has no difficulty getting Oracle’s attention. But smaller customers might as well not even try. Critical bug? How critical, and please state that in terms of revenue implications to Oracle.
Open source projects break the logjam, because there is no monopoly on access to the code. That means that enterprises of all sizes – from large companies to independent developers – can provide service to users. So, no matter what your enterprise size is, you can find a service provider small enough that your problems are important to them.
For larger organizations, the problem is finding an open source service provider big enough to provide credible support for their chosen products. We are building OpenGeo into an organization with the scale to provide that support, for a range of open source geospatial tools.
February 5th, 2009
James Fee is thinking about building a new application, and wondering what kind of geostack to use.
As I begin to prepare to kickoff a project next week with a client, I’m thinking tonight about what I’m working with; ArcSDE 9.2, Apache withTomcat and Oracle 10g. Beyond that I’m free to work with whatever solution best meets the customers needs. Do we go with ArcGIS Server 9.2 or 9.3? Do we go with the Java Web ADF or the ESRI REST API? Do we go with GeoServer or MapServer? Do we go with the ArcGIS JavaScript API or OpenLayers?
Proprietary stacks tend to bind each layer tightly to the layers above and below it, so that choosing a middleware dictates the best user interface layer, and so on. This makes solid business sense in the proprietary world: keep your friends close and your customers closer.
In the open source world, loose coupling is the norm. The flexibility to mix and match parts, without worrying about the licensing implications of deploying parts of the system on multiple servers, gives teams more latitude in creating designs. You shouldn’t have to ask your vendor for permission to deploy software on the systems you want, in the combinations you want.
An example of the loose coupling principle in action is the nascent GeoExt project. A collaboration between OpenGeo and Camptocamp, GeoExt is binding OpenLayers and spatial smarts into ExtJS Javascript widgets. OpenGeo plans to sit our GeoExt implementations on top of Geoserver middleware. Camptocamp is targeting Mapserver/Pylons as their middleware. Because we are designing for loose coupling from the start, we can work together to build something useful for both of us.