The Future of ColdFusion: Part 4 - Whither ColdFusion

In this fourth and final posting I want to look at some of the different ways this could play out.

The Rise of Frameworks
As I mentioned in the first posting, full stack frameworks like Rails or Django are another approach to making hard things easy and while they'll never be as simple as getting started with CFML, if you're writing OO applications, they make some of ColdFusions traditional benefits less compelling (cfquery, cfoutput, cfmail, etc). At some point we need a compelling full stack framework in ColdFusion that breaks the rules in the same way as Django, Rails, Waves and Seaside have done in Python, Ruby and Smalltalk respectively.

Scripting the JVM
I don't know if all ColdFusion developers realized how big a deal CF moving to Java really was. I certainly didn't get it at the time, but while CF was ahead of the curve, Groovy, JRuby and a bunch of other scripting languages thanks to JSR-223 now allow you to get the productivity benefits of dynamic typing with the deployment benefits of running on the JVM. This makes the object instantiation penalty in CF and the lack of easy integration with industry standard tools like Hibernate to be an issue that needs to be addressed. There was already some interest in the outer reaches of the CF community in using Groovy or Java for the model and CF for the controller and view and I'd like to see a compelling reason for most developers NOT to want to leave CF for their model most of the time.

RIA Halo Effect
Adobe is clearly going to affect the ColdFusion market with its success in the RIA space. I see Flex, AIR and LCDS as some of the most interesting changes in the business of developing applications. Suddenly a generation of web developers can develop rich desktop applications using technologies they already know, and as we migrate more of our data to the cloud, I think a seamless online/offline story is going to become increasingly compelling.

Of course, there is no guarantee that Flex will drive ColdFusion adoption, but the more that the ColdFusion team can do to make Flex, AIR and LCSD integration and deployment easier using ColdFusion the more chance there is that CF will be used as the back end for an increasing number of projects. And with the JBoss announcement, that could help with the credibility story in the Java community. After all, if JBoss (who are now part of Redhat) are making a ColdFusion engine one of their projects, maybe it's worth taking a second look at!

Railo and JBoss
I'm really interested to see how the Railo/JBoss announcement will play out in the Java community. I've never even considered pitching CF presentations to QCon or Java One or JAOO. Will the relationship with JBoss help Gert to take a compelling CF story to the Java world and beyond? I don't really know but I'm certainly excited to see how it'll play out.

Adobe and Railo
While there are always challenges that any programming language faces in continuing to grow market share, I think that a combination of the RIA push from Adobe and the JBoss announcement from Railo will create a real opportunity for the size of the ColdFusion community to grow substantially. However, that will depend on how Adobe and Railo interact. As I mentioned previously, the most important factor (great people on both teams and good relationships between them) is already in place. But it still leaves the question - what will Adobe and Railo do next?

Adobe could just decide to open source their server or (at the opposite extreme) offer to buy out Railo to either avoid having a credible open source alternative or to cripple the open source version offered.

I don't think it would be in anyones interest for Adobe to open source the ColdFusion server in the forseeable future as the more money they make, the more cool new features and marketing budget we have supporting the community.

As far as a buyout, if it was to take advantage of the engineering talent and/or elements of the code base while still genuinely supporting the open source version it could be a real win all round. I doubt Adobe would try to just buy and suppress the code base as the only winners from that would be New Atlanta and Adobe are way too savvy about open source to do something that silly.

The above options are possible but I'm guessing fairly unlikely. The question then is the nature of the competition/coopetition between Adobe and Railo.

A lot of this will come down to the commercial considerations within Adobe. As the "new kids on the block", it's obviously in Railo's best interests to co-operate. For Adobe the best approach is a little less obvious.

As a ColdFusion developer, I'd love to see at the least a W3C style committee where Adobe, Railo and community representatives could agree a CFML standard that we could all code to, with the ability for specific vendors to add custom extensions if they so desired.

Personally I'd love to see key new features like Hibernate and clustering/caching solutions added ASAP if both vendors are planning to implement them as for me those are a compelling reason to continue to choose CF over Groovy for the model part of my applications, but I understand that for the majority of the community those tags probably aren't as urgent. That said, if ColdFusion wants to compete in the Java world against Groovy (quick way of throwing together apps using a dynamic typed scripting language) it's going to have to have an interesting Hibernate/Caching/Clustering story ASAP. Otherwise at most CF will be considered a possible replacement for jsp's when developing views (which isn't horrible, but I wonder if there is a one time chance to persuade some Java devs to choose CF over Groovy/JRuby for quickly developing RIA back ends - especially if Adobe and Railo are able to finish out cfscript).

It's also going to be important to clarify any implications for people involved with (say) Adobe alpha/beta programs or the Adobe Community Expert program of getting involved with any Railo initiatives. The initial impression I got was that there would not be any problems, but depending on how open Adobe wants to be about any proprietary tags it wants to be able to add to their engine, we're going to have to be clear about whether there would be any potential conflicts of interest and how they should be handled.

Finally, in the long run we also need to start to develop a clear story about where and when to choose Adobe ColdFusion vs. Railo. Right now it makes sense for pretty much all CF devs to do all of their commercial development using the Adobe product, but it is clear that over time there may be some projects which ColdFusion developers would choose Railo for. It is in all of our interests to minimize the confusion and develop a generally agreed set of heuristics for which engine to choose for what classes of applications and to ensure that the structure is good for both building the community and ensuring that Adobe continues to have a compelling commercial incentive to invest strongly in continuing to "wow" us with new features with every release.

While I know that it wouldn't replace the server revenue, I'm also hoping that Adobe has been far-sighted enough to consider finally creating a best of breed IDE for ColdFusion which offers the kind of dynamic runtime introspection that Smalltalk engines and the Netbeans Ruby IDE provides so we can get the benefits of code completion without the overhead of having to statically type everything. That would be another revenue stream for Adobe which is consistent with its position as a developer of premier tools for designers and developers.

Looking forward to finding out more at CF United this week.