The ColdFusion/CFML Discussion: We’re Finally Getting Somewhere

I’m sure by now you’ve seen Joe Rinehart’s “Dear John” video to ColdFusion, and Mike Henke has a funny and I think (as I’ll explain in detail below) very pertinent response video.

I won’t rehash everything that’s been said there as well as in the various discussion outlets the past few days, but I did want to comment on the situation by saying this: after years of tiptoeing around I think we’re finally getting somewhere.

For me, I saw the writing on the wall for Adobe ColdFusion about 5 years ago, and I was already planning to jump ship at that point for numerous reasons. Many of my reasons were technical ones (and sadly haven’t changed in ColdFusion in 5 years), but another major reason was due to my firm belief in using free software whenever possible. All that combined with me doing a lot of open source work for a closed, proprietary platform led to cognitive dissonance I could no longer ignore.

Then in 2008 OpenBD was announced as a GPLv3-licensed fork of BlueDragon. This came at exactly the right moment for me because it meant I could keep using CFML but run it on a completely free software stack.

The release of OpenBD also addressed one of the other major issues I had with ColdFusion: After seeing how free software projects are run, the level of interaction between users and developers, the ability for community members to contribute and have a direct impact on the future of the project … none of that was true with ColdFusion. I simply couldn’t keeping using and supporting something that didn’t work this way.

I quickly switched over to OpenBD and haven’t looked back. We have a couple of ColdFusion 8 servers running some apps that don’t need much attention, but we moved the majority of our applications to OpenBD (99% without issue, despite anything you’ve heard about switching engines being difficult). As our legacy (and I do mean legacy — some of these apps are 10+ years old) ColdFusion apps need updates they’re moved to OpenBD, and all of our new development is done on OpenBD. We deploy our projects as WARs to Tomcat and life as a CFML developer has never been better.

I give you that background simply to point out that in my world, Adobe ColdFusion hasn’t had anything to do with my CFML development for a many years now, and I haven’t missed a thing. In fact I’ve gained a great deal, not just a faster engine with really compelling features Adobe CF still doesn’t have, but I’ve also been able to contribute directly to OpenBD in concrete ways with patches to the engine and building the admin console, not to mention the fantastic discussions on the OpenBD mailing list that lead directly to new features in the engine that are implemented in days, not years.

When I saw Joe’s video I realized I was watching it with the perspective of a disinterested bystander. He made some valid points, though as far as the installer goes “who cares” was my reaction since I think we’d all do very well to stop treating CF as if it’s an application server and treat it as what it is, which is a Java web application.

But honestly 99% of Joe’s complaints with CFML as a language are addressed in OpenBD and Railo. My reaction in a lot of cases was “they haven’t fixed that in CF yet?” but again, since I haven’t used the product for years now, it doesn’t impact me.

The major point I think Joe makes (and the one that Mike’s video makes at the end) that is tremendously pertinent to this discussion is the constant battle between “more stuff” — meaning new marquee features that demo well but don’t work for crap in the real world, or features no one cares about — vs. more, less marketing-friendly features like improved language syntax, removing the dead weight (which is hugely important), and other improvements the actual users of the product (i.e. the developers) want.

I’m glad this came up in this way because it gets to what I think is the heart of the matter: ColdFusion is a commercial product. How do you keep people buying commercial products year after year? By adding more “features.” We developers may think of better language syntax as a feature, but we’re not typically the ones with the checkbook, and == instead of eq doesn’t demo well to the suits with the money.

This is why ColdFusion is in the state it’s in, and is a great illustration of why when there’s a profit motive behind a software product of this type, you wind up with “features” that are bright and shiny and demo well to the people who don’t know any better, and you continue release after release after release to not get much in the way of the actual improvements developers need in order to keep using ColdFusion.

To be blunt, for a commercial product that’s been around for years ColdFusion should be much, much better than it is. The fact that it isn’t speaks volumes.

There’s a reason there are no other commercial products along the lines of ColdFusion in the world: because the market can’t support them. Allaire/Macromedia/Adobe got in early with enough customers to keep this going for a while longer, but there is a definite sense that they’re de-emphasizing CF as a product (I’ll stop short of saying they’re putting it out to pasture).

Based on discussions with other developers as well as my own recent experience, this “de-emphasis” is the story more and more people are hearing from Gartner these days. ColdFusion hasn’t fallen into the “Migrate” bucket of their “Invest/Maintain/Migrate” spectrum, but it’s getting there, and Gartner flat-out said on a call I was on just last week that they do not recommend starting new development on ColdFusion if you know it’s a strategic product you’re going to be maintaining long-term.

The bigger problem here is the increasing frustration of CFML developers. Once the community starts bleeding developers, impressing the suits or anything Gartner shows on a chart or graph won’t matter. If the suits can’t find anyone who knows the technology, and they’re hearing from analysts it’s not the way to go, they’ll move to something else. All the shiny new features in the world won’t fix that.

How this relates to the free software engines is also interesting, because the other engines have the albatross of Adobe CF compatibility around their necks. In many, many cases on the OpenBD side we look at how something works in Adobe CF and the only reaction a logical person could possibly have is “WTF,” and in other cases we have ideas for changes that would mean vast improvements in speed or functionality, but we’re saddled with remaining compatible with Adobe CF. It’s a continually frustrating fine line, and given the state of ColdFusion it’s one I’m personally seeing as less important to continue to walk.

I didn’t wind up where I thought I was going to when I started writing this, but my main point as I state in the title of this post is this: we’re finally getting somewhere with the discussions. For far too many years there’s been nothing but infighting, people forming camps, alliances, cliques, etc. and getting behind one engine or another, all to our collective detriment. Ultimately that’s counterproductive and wastes the incredibly limited resources we have as a community.

We also need to stop beating around the bush. I’m as guilty of this as anyone simply because of the vitriol I’ve had thrown my way over the years, particularly immediately after I quit as an Adobe Community Professional and joined the OpenBD Steering Committee. You start asking yourself if it’s worth the hassle to say anything.

But if I can’t state my opinion on things as truthfully and hopefully respectfully (without watering things down to the point of being meaningless) without getting a purely emotional reaction from people who choose to stick their heads in the sand, that’s their problem, not mine. Just because I don’t share your opinion doesn’t mean I’m spreading FUD, or being nasty, or anything along those lines. We all need to realize that unless we can have these sorts of discussions without screaming at each other irrationally we aren’t going to make any progress.

Regardless of our engine of choice we can all benefit from improvements to the CFML language and the underlying and supporting technologies, and I’ll say flat-out here that I don’t see any of those sorts of innovations — the kinds of innovations we as developers need — coming from Adobe. They by definition have completely different motivations and to keep CF going they need to make decisions for what from my perspective are all the wrong reasons. You don’t wind up with something that’s good for developers that way.

Look around the development world. There is not a single product remaining in the world in the same basic category as ColdFusion that you have to buy. Prior to the free software engines coming along, unless you count .NET (which is a completely different, possibly more subtle argument), CFML was the only pay-to-play language out there. (And please don’t say “Websphere” or anything along those lines — that’s not the same type of product at all. Adobe convinced us for years that CF is an app server. It’s not, and they’ve been trying to fool people into thinking it is for far too long.)

I’ve been in the CFML world now for a very long time. I’ve been hearing the “but CF pays for itself!” arguments for 15 years now. I even believed those arguments at one point and you know what? It doesn’t matter. We lost. That ship has sailed. We would do ourselves and our community a huge favor by not pretending those tired old arguments are still worth the breath it takes to utter them.

People don’t pay for this stuff anymore, nor should they. There are far, far too many excellent free software solutions in the world — many of which are rolled right into Adobe ColdFusion, by the way — for us to keep thinking we have some sort of lock on productivity or amazing features or whatever the hell other arguments we used to use to try and convince the naysayers. If we’re still talking that same old crap, it’s quite clear we’re only trying to convince ourselves at this point.

That’s not to say it’s all doom and gloom. I wouldn’t still be here if I didn’t think CFML was a great technology. I wouldn’t be writing this blog post, or be spending time on the Open CFML Foundation, OpenBD, Open CF Summit, and all the other CFML-related things I do if I didn’t think the language was worth perpetuating (OK, saving).

The bottom line is this: painful as all of this may be to hear for some people, we’re finally — after years and years of ignoring our problems — getting somewhere. Regardless of the outcome of all these discussions and any casualties that may occur along the way, that’s only a good thing.

If you’re thinking about “leaving” CFML as Joe did I can’t say I blame you. There are a lot of great tools out there and it’s in your best interest as a developer to try them. Adding more tools to your toolbox only makes you more aware of the broader scope of the technology world which is a great way to expand your skills and your mind, not to mention make yourself more marketable.

I love Groovy and Grails, and still use Grails from time to time. I’d be lying if I said I hadn’t thought about switching to Grails full time. There’s a lot of great technologies out there and a lot of very compelling reasons to jump ship. Some days sticking with CFML seems downright irrational in the face of all the arguments to the contrary.

But, something keeps us in the CFML world. Any one of us is more than capable of learning another technology, but we stick around for some reason, and for me that reason is even after all I’ve seen in the technology world, CFML is still after all these years a great technology for web development, and it still stands up pretty respectably against anything that’s come along in the interim.

Could it use improvement? Sure. What couldn’t? And that’s kind of my point.

Rather than dumping CFML for another technology, I’d hope people would get fired up and start asking how they can help improve CFML. If you have ideas about what you’d like to see in CFML the free software engines would love to hear them, and you’ll be surprised at how quickly many of these ideas would happen. If you’re happy with Adobe CF, great. Keep using it. But if Adobe CF isn’t giving you what you need, you don’t need to wait for Adobe to make things happen.

There’s no technical reason why anything that’s done in any other technology (within reason of course) couldn’t be done with CFML. All we need are the voices to guide CFML’s future and the will to make it happen.

Indexed GIFs Cannot Be Displayed by Browsers

To save everyone else from wasting a day of their life on this, if you're getting "the image cannot be displayed because it contains errors" messages in Firefox, don't spend hours of your life trying to figure out what's wrong with your code. Check the images first.

I'm working on an application that displays images (GIFs) from a document scanning system, and due to where the images are located in relation to the webapp, I'm using CFCONTENT to display them. No matter what I tried, I could not get the images to display properly.

After much head bashing (my poor wall) I decided to grab some of the images directly. To my surprise, they couldn't even be displayed in the default image viewer in Ubuntu.

The GIMP to the rescue. I opened one of the GIFs in GIMP and they're all indexed GIFs. I changed the mode from indexed to grayscale and saved the GIF, and voila, all is right with the world. So my very hard learned lesson of today is that indexed GIFs cannot be displayed by browsers.

Good thing it's a long weekend and Open Source Bridge is next week, because clearly I need a break.