Railo: The Security of Alternatives

I remember (too) many years ago when I started my first business. All my college friends thought I was so brave to take the risk of starting my own company. I saw things differently. Pretty soon I had 20 clients, no one of which made up more than 15% of my income. I thought *they* were braver to depend completely for their income on a single company that might fire them, close their department or go into bankruptcy at any time - irrespective of their job performance!

I think it's time we critically reviewed the relationship between what is best for Adobe and what is best for CFML developers. I'm not sure that the two are always exactly the same . . .

Adobe Rocks
Let me start by saying that I love what the Adobe team has done for ColdFusion. I'm particularly excited about Centaur (CF 9) which I believe is going to be the best developer release ever, and I'm incredibly glad to have someone as passionate as Adam heading up the charge. I know that he is aware of the true risks to the language and the community (alternatives like Groovy - not other CFML engines like Railo or OpenBD) and is working hard to make Centaur an awesome release.

Adobe has continually invested in ColdFusion, it makes them real money, and they have been very supportive of the community - from sponsoring conferences through to setting up the CFML language committee from which I'm looking forward to great things.

But . . .
That doesn't mean that Adobes interests and our interests as CFML developers are perfectly aligned. ColdFusion is a cash cow. The classic business theory for management of cash cows is to invest modestly in them (engineering team in India, not Boston, sponsoring community events but not spending heavily on advertising outside of the community) and to maximize the return for as long as possible, using the profits to invest in stars - like platform adoption for Flash and Flex (here's an overview of the BCG matrix for anyone interested).

ColdFusion - and Crank . . .
I think ColdFusion is a bit like Jason Statham in Crank (for anyone who hasn't seen it, the tag line for Crank 2 is "He Was Dead. But He Got Better" :-) ). The rumours of ColdFusions death (in the illustrious company of Mark Twain) have been greatly exaggerated.

That said, one day Adobe will End of Life ColdFusion. I guarantee it. Whether it'll be in five years, fifty or (implausibly) five hundred or five thousand, one day there will no longer be sufficient ROI for Adobe to invest in ColdFusion and they'll either sell it off to Computer Associates (where old enterprise software goes to die) or will just EoL it and focus on their other business opportunities.

If nothing else, Railo and OpenBD are an insurance policy - like having vendor code in escrow. Whatever Adobe does strategically, there will always be an open source CFML engine so you can continue to run and support your CFML applications - whether or not Adobe will support you.

However, I think there are a number of extra benefits that Railo brings to the CFML world (OpenBD also brings benefits to the CFML community and blazed the path in terms of offering an open source CFML engine, but I'll leave those for the OpenBD team to talk about).

To me, there are three key benefits that Railo brings to the CFML world: innovative features, a developer focus and a true open source platform with a responsive release cycle.

Innovative Features
I'm going to spend most of next week blogging about these, but I genuinely believe that Railo is a superior CFML engine to the Adobe ColdFusion product - at least in terms of the features that I use. The really elegant interface driven approach, the better integration with java and jsps and the fact that it was written for developers by developers means that we have a CFML engine that (for me) allows developers to build better applications more quickly than in CF. (That's OK, hopefully they'll copy our best features so that everyone can take advantage of what we're doing for the community!)

I know that Mark, Gert, Michael and myself all have additional features we are committed to adding to the product for 3.2 and beyond, and I think we're going to be able to out innovate Adobe and hopefully to start to get closer to some of the cool selling points of Groovy while still "making hard things easy" for newer developers. But honestly, I also hope they out innovate us! If we have multiple vendors competing that is a *good-thing*. Whoever does better, the community is bound to win from the increased focus on developer features that will help us to be more productive - whatever our experience levels.

A Developer Focus
It's great that CF makes hard things easy and Railo will continue to add all of the CF tags that make sense. But despite their well regarded alpha and beta programs, developers don't decide what makes it into CF - Adobe management does. Often that is not a problem, but with Railo we're adding features for developers by developers and if there is a feature you want, come join us. You can add it in and if it's popular we can add it to the core. We also have a very powerful extension manager which will make it easy for various people (including Adobe - or you) to offer free or paid extensions to Railo CFML.

A Responsive Release Cycle
With ColdFusion there isn't a publicly available Bleeding Edge Release (BER) version and unless you get an explicit release from Adobe you can't run alpha or beta code in production. This is a real impediment for ColdFusion compared to all of the open source languages on the JVM that it'll have to compete with going forwards. With Railo we are working on making it easy to use the latest version with plenty of point releases so we can quickly get you the improvements you need.

So, with innovative features, a developer focus and a responsive release cycle, I think that Railo will add a lot of value to the CFML community as a whole. Oh, yeah, and there are a couple of things I don't want to *focus* on as I don't think they are the big story, but I need to mention performance and price as they will be relevant in some cases.

Faster performance
I've been complaining about Adobe CF performance for a long time, and I'm not the only one. I'm not talking about optimizing the implementation of cfset statements or shaving a fraction of a millisecond off of the parser operation. However, historically with Adobe CF we have been unable to write truly object oriented applications because of a substantial object creation penalty. The whole reason that I coined the term and promoted the idea of Iterating Business Objects was as a hack around for this performance problem. For experienced developers writing applications with real business logic, we need to be able to use objects as we would in Groovy or JRuby to encapsulate our business logic and to make it easier to unit test. Until Adobe CF is comparable to other dynamic languages on the JVM (even when the objects being instantiated have a bunch of methods) we're going to lose mind share to Groovy amongst the very developers who could make the most out of new features like Hibernate integration.

Cutting the Cost
Although it may appear implausible to those of you in enterprise land, there *are* projects where a $1300 standard license is a decent percentage of (say) a $4500 web project and the client wants to self host or needs a VPS. Having a free to use alternative allows CFML developers to pitch CFML for *all* of the projects that it makes technical sense for without having to worry about the cost of the server license.

So, my believe is that Railo is a *really-good-thing* for CFML developers. But what about Adobe? Is Railo going to hurt them financially? Are we sworn enemies? Will this end Adobes investment in the community? I don't think so. There will clearly be pluses and minuses for Adobe but I believe that on balance Railo will be good for Adobe. Why? Well, this post is getting a little long, so I'll have to post my thoughts on that in an hour or so . . .