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 . . .