14 Feb 2008
Out of left field:
- Compatibility: This problem reaches across the board but when it comes to open source vs. closed source; from what you’ve seen is it a wash? I must admit that I’m inclined to stick with the devil that I and everyone else knows. Additionally doesn’t the nature of open source introduce opportunities for proprietary stovepipes?
This one I frankly do not understand, but perhaps it is in the nature of the word “compatibility”.
In general, open source software is wildly more interoperable and therefore “compatible” with different proprietary stovepipes than the proprietary alternatives. 
Mapserver, for example, can pull data out of dozens of file formats, as well as SDE, Oracle, geodatabase, and the usual open source suspects like PostGIS. Because open source development priorities are “scratch the itch” and people in real offices need to do real work, one of the first features requested and funded is almost always “connect to my proprietary database X”.
(This is not just about Mapserver either: Geoserver, uDig, gvSIG, QGIS, even good old GRASS all have better multi-format connectivity than leading proprietary brands. Note the word “leading”… the non-leading proprietary brands tend to have good connectivity too, but the market leader uses lack of interoperability as a means to protect their lead.)
If “compatibility” is really a synonym for “does it work with ArcMap”, then indeed there is a problem, but it is not on the open source side. ESRI ties ArcMap tightly to their own stovepipe for very good (to them) reasons of competitiveness and market protection. ArcMap sells ArcSDE licenses, not vice versa. (How many times have you heard someone say “this SDE stuff is great! if only I had a mapping tool to work with the data…”)
I’m open to suggestions as to what part of open source “nature” actually lends itself to proprietary stovepipes. That part I don’t get at all.
13 Feb 2008
Neither rain nor sleet nor dark of night will stop me:
- Sociology / Psychology: There is so much more to pitching a solution to those who control the purse strings than technical logic. Selling open source to the powers that be is… well it’s tough. Are there consultants that can be hired to answer the hard questions and make the decision makers feel comfortable? I would love to see more real world business cases for comprehensive GIS environments that must cater to diverse requirements.
25 years ago, selling anything that wasn’t IBM to the powers-that-be was tough. I expect selling open source to remain tough, but get easier and easier over time as people with Internet-centric mindsets percolate up into decision making positions for larger organizations.
Sure, there are consultants, as in any field. Real-world business cases are available, but few and far between. When you ask people to write their own case studies, generally the folks with interesting studies are too busy to do it, so you end up with a bunch of academic stuff. And going out to gather the things is a lot of work. And often some of the most compelling studies are found by accident!
I compile case studies for PostGIS, and every 12 months I ask on the postgis-users mailing list (1500 subscribers) for folks to volunteer for case studies. I’ll do the writing and editing, they just need to talk to me on the phone or on email. I don’t get many responses!
When I was at FOSS4G 2006 two years ago, it was mentioned in passing to me that “oh yes, IGN is using PostGIS now”. So I asked for a contact name, tracked the guy down, and extracted the story from him. It’s a great case study! But getting it required a curious combination of persistence and luck. Same with the North Dakota study, which I got via friend-of-a-friend referral.
The request for information about “comprehensive GIS environments” feels like trolling for someone to say “just drop ESRI”! And that would be silly. Open source has lots of solutions that do things that ESRI products do, but there is no comprehensive drop-in replacement solution. Even if there were, the switching costs alone would probably make in uneconomic.
So here is what to say to the powers-that-be. Don’t foam at the mouth, don’t wear jams and a backwards baseball cap. Recognize that change is slow, and there are sound financial reasons for that:
For an organization just getting started with open source, it provides advantages at the margins: not in reworking your existing systems, but giving you flexible options when building new ones. The existing systems should be left running until they hit a natural end-of-life, either when they become out of date, or so expensive to run/pay maintenance on that the switching cost actually becomes acceptable. Evaluate the cost of change regularly. Sometimes not changing is the more expensive option, and it is important to know what that time arrives.
12 Feb 2008
It has been a bit over ten years since I started Refractions Research, and in that time most everything that has happened has been unanticipated. The best laid plans rarely yielded what was expected, though they often brought good surprises.
For a founder, one of the side effects of success in a company is that your role is constantly changing. In a company of two, your job is radically different than in a company of twenty. This is both good, in that it provides lots of variety, and bad, in that it can result in being “promoted” into a role that might not be a good fit.
And so it is with me. I have moved from being someone who works on software and problem solving to someone who pays other people to work on software and problem solving. This has not, as it turns out, been a recipe for job satisfaction in the long run.
Back when I had no wife/house/child/child I was able to balance out my role by just working more – spent all day on meetings and email? no problem, play with technology at night.
But that doesn’t work any more. I don’t feel like I have the leadership focus I used to, nor do I get to spend enough time on technology and problem solving. Since I am doing neither job well right now, I am going to pick the one I like more, and do that for a bit.
So I have decided to make a big change. I am going to leave the company I started, and return whence I came, to independent consulting. Solo consulting is tricky, because the work is “gappy”, but it has a good rhythm: in the gaps, you learn new things; in the peaks, you apply those things.
I don’t know what other opportunities might come along (best laid plans and all) but in the meanwhile some quality time with my computer and some concrete problems sounds great. I am looking forward to getting my hands dirty in the guts of the many open source projects I have thus far only experienced as a user.
Refractions is a big (relatively, 25 people) company now, and has momentum – good institutional clients, great delivery skills, stable business processes. I have ensured over the last six months that I am not in the critical path for any of our projects. The leadership team has been operating independently of me for a number of months, and can keep building the company into the future. The staff are an excellent group of folks, the best collection of geospatial smarts in the Pacific North-west.
I will miss spending regular time with the folks at the office, but will continue to do occasional work with Refractions as an associate, so there will be lots of opportunities to keep in touch, have lunches and beers, and keep the creative juices flowing.
Thanks everyone, it has been an amazing experience, I look forward to working with you again in my next incarnation(s).
12 Feb 2008
Moving on:
- Risk: Our landscape is changing so fast there is an extreme amount of exposure to dumping resources into a solution that isn’t supported. If any one component of the enterprise stack changes you’re vulnerable and I trust those I’m paying to cover my maintenance than I do an ethereal community. When it comes to supporting my clientele I need tangible support resources. How good are the support resources for open source solutions? Is there comprehensive up to date documentation? Can I call someone in an a oh $*!&% moment?
I think this article at InformationWeek (number three in the Google search for “open source support”) sums it up well. There is not one answer, there are a number of answers, and you need to choose the one(s) that make sense for your needs.
- Product support, from specialist companies with expertise in particular components (Refractions for PostGIS, DM Solutions for Mapserver, TOPP for Geoserver)
- Stack support, from generalist companies putting together mixes of components (Wheregroup)
- Community support, much maligned, but better than the technical support provided with most proprietary packages
- Training, from folks like the companies above, or specialist trainers like Open Technology Group
- Hiring project developers, an often unappreciated source of top notch trouble shooting and knowledge,
- Consultants, who have to know the tools they use
For me, the money quote is:
CIOs would be well-advised not to buck the open-source trend. On the contrary, they should assume responsibility for open-source initiatives and ensure that their companies have the right support structures in place… They’ll find the more mature an open-source software project, the more mature support options its users enjoy.
Open source requires you to assume responsibility, which is hard for an organization man, with years of CYA behind him, to do. In exchange for taking responsibility for your own infrastructure, you are rewarded with a software ecosystem where there is more than one source of support.
What do open source organizations do when their support provider isn’t up to snuff? They get a new support provider.
What do ESRI customers do when ESRI support isn’t up to snuff? They bitch about it on James Fee’s blog.
11 Feb 2008
So, addressing Timmy’s concerns about open source geospatial:
- Staffing: The specialized skills necessary to build and maintain an open source app are hard to come by. There is a premium on any specialization, is the talent pool to build and support these open source solutions deep enough to maintain continuity in staff skills?
There is, as with any great argument, a kernel of truth in this item, but it is wrapped in a thick, low-calorie, blanket of misdirection, like a corndog at a state fair.
So, should you be concerned about staffing your open source application? You should, to the extent that:
- the skills required to understand and maintain it take a long time to learn, and
- the skills required to understand and maintain it are in short supply.
- Note that you have reason for concern only if both conditions occur: the skill must be both difficult to learn and in short supply.
Timmy sees that, compared to proprietary toolsets, people with prior experience with open source tool sets are fewer and farther between, and leaps to the conclusion that there is a skills provision risk.
However, the skills necessary to work with open source geospatial applications are either easy to pick up quickly, or transferable from other domains.
- PostGIS: Already worked with Oracle Spatial or ArcSDE’s “new” spatial SQL feature? You already know PostGIS.
- Mapserver: Learn the .map file and you are good to go. No harder than picking up enough AXL to be useful. Budget a couple days of learning time.
- OpenLayers: Already worked with Google Maps? You’ve got the concepts down pat. You’d better know Javascript, but that’s a transferable skill and you’ll need that for any non-trivial application.
- Geoserver: Point and click through the interface. Do you known enough to deploy a WAR into production? If you installed ArcIMS, you already do.
The slight disadvantage open source has in providing decent tutorial-level guides for new users is offset by the advantage in access to a very helpful user community and direct access to the development community.
Summary: No matter whether you’re building on ESRI or open source, if you are building something complex your staff will have to learn a few new skills. Their prior experience with core concepts like programming and IT will serve them well in both domains, and the learning curve will be no worse either way.
Caveat: It’s possible Timmy is talking about people who will only learn a new skill if force fed it through a training course, and even then will only retain 50% of what they are taught, who write point-and-click recipes and stick them up on their cubicle walls, who think that “re-boot the server” is a genuine solution. If those are the people whose “skills” he is worrying about, I can only say “go with God, Timmy, peace be unto you, you have larger problems than proprietary vendor lock-in”.
