proprietary systems, vendor lock-in, developer frustation

Sometimes you just end up frustrated beyond belief: Being into software development / architecture, reading and keeping yourself up-to-date is an essential part of your work. Likewise, you generally tend to be (maybe a little too) enthusiastic about new technologies, as in most cases, while stumbling across new technology, new approaches and concepts, you might see new solutions that might provide an elegant, powerful, or maybe simply more sane way for you to help your customers, users, … getting their work done. This is a good and healthy process… if it works out. Because on the other side, it also can be a source of extreme frustration, if your given infrastructure and IT environment is not up for that. That’s when you get to work highly motivated in the morning, and the outcome is all the same virtually every day:

  • System integration using open standards, web services and SOAP? Oh please, we don’t even support generation of valid XML (based upon some schema or DTD) right now.
  • Quick scripting integration of backend services using JSON and REST? Not out of the box, you have to do that manually, and you can’t do it bidirectionally as our current HTTP client implementation doesn’t support anything else but GET.
  • Usable, AJAX enriched web client? No. Our web client architecture relies upon a whole block of code containing hundreds of lines of inline HTML/CSS/JavaScript, and we don’t intend to change that.
  • CORBA integration as a technology at least somewhat open? Oh no. We do have rudimentary CORBA support, but just for our very own internal purposes, unsupported, untested and unmaintained outside our own use cases.
  • Asynchronous communication, ESB or business orchestration even? Well no, by now you should have learned that our system doesn’t need an outside world to exist.
  • Mashups, Web 2.0, portal integration, widgets, all these technologies which aren’t really useful in itself but maybe a good thing to provide end users with some eye candy? No. Not now, not tomorrow, probably never.

Being in kind of a rant mode, I could continue this list forever, but it is of no real help. What’s the bottom line? Well, despite my personal (political) attitudes, I have become a little more pragmatic the last couple of years as far as it concerns the use of “open source” software or even “software libre” in a business context, as I have figured out that, though I think it’s generally an important matter from a long term point of view, there are more important short term aspects to deal with: Open standards. Open connectivity. The ability to integrate applications, to make them seamlessly go together without too much ado. Ask your vendors to support open, industry-adopted interfaces and agreed-upon communication standards, and don’t accept “data” or “logic silos” to lock up part of your business data / functionality. Show your vendors that this matters to you, and support those who make a change here, no matter whether open source or not. It’ll make things more difficult during project startup, especially as it will be more expensive and provide value you can’t immediately “see”, but as soon as you will need it, you know why you did it initially… or, maybe worse: You know why you should have cared, initially.