Railo: What Will Railo do for Adobe?
With Railo, Adobe gets (in no particular order):
- A story that whatever happens to Adobe support for CFML, you'll always be able to run your code on a CFML engine
- Free R&D as they look at how we implement features and decide whether to replicate rather than having to re-envision every feature from scratch
- A way companies can try CFML in production without *having* to pay for a license for the smaller projects
- A way companies can standardize on CFML - even for the projects that don't justify a license fee
- A way companies can create their own improvements to CFML giving them the ability to stay with CFML even if they need an open source solution instead of losing them to PHP or Groovy
- A reason to focus Adobe management attention on developer features - to keep up with the open source CFML engines
- A shot at getting CFML shared hosting to be almost as cheap as PHP
- Credibility in the Java world through integration of a CFML engine into the JBoss stack
- An expanded developer community
- Less CFML dev attrition to "cooler", "OSS" and/or free languages
- A way that enterprises can deploy CFML on the cloud today - without having to call up their sales rep to figure it out
- A way to keep the "true believer" CFML devs that truly get and love open source to stay with the language
In return they'll probably lose some standard license sales and perhaps a few enterprise licenses.
The CFML community needs to worry about attrition (losing devs) and attraction (gaining them). In terms of attrition, with Railo the "server cost" story disappears, we have the credibility of being part of JBoss.org, there is an open source project which can be enhanced or extended easily and an independent option for getting language support (having multiple vendor options is always a prudent choice - as car companies are currently discovering).
In terms of attraction, it is fast, integrates well with other JVM technologies and is already bringing innovations that will continue to make the language a competitive dynamic scripting option on the JVM. We're firmly focused on getting the "good parts" of Groovy and hope to expand the market for CFML development beyond traditional CFML developers by positioning Railo as a real alternative to both JSPs and Groovy for the right use cases.
Also, while I think that Adobe has continued to do a good job of enhancing CFML, competition is a good thing and *will* speed the development of the features that developers care about. In the long run, managers care about developers writing code quickly (and ideally maintainably), so I believe that giving the developers the best tools to do that will also keep the managers on board.
I'm excited to see how Adobe, Railo and OpenBD work together to grow the CFML community and I'll be posting a little more about that shortly . . .



You mention JBoss as obviously Railo has teamed up with JBoss to offer the two in tandem, but I'm curious as I've also read about others running Railo over top of Tomcat and/or other J2EE Application Servers.
Is JBoss the J2EE App server officially recommended by Railo, or are you all of the mindset of "go with whatever works" ? Would there be any specific reason for someone setting up a new server not to use JBoss and use another app server instead?
Thanks,
Brian
I think you need to discuss whether you see Railo trying to race ahead of Adobe, or focusing on compatibility with Adobe as everyone has preached in the past. If you race ahead obviously that has implications, especially competitive ones vis-vis Adobe, even if you make them add-ons to a compatible base.
I'd like first of all to see a much easier install process. Then a friendly online documentation system like for the jquery api or for the new Ext-Core that just came out.
Personally, I don't see it going well with Adobe in the end. They'll just look at lost sales as various enterprises start to trust a good or better OS solution. The better Railo is, the worse it is for Adobe. No way around that.