Everyone freshly stuffed from their various dinners and socializing, we all waited in anticipation for the start of this evening's Birds Of a Feather session entitled "The Future of CFML". The zeal and comaraderie of the group was alive and well in the room (as are all such meetings involving members of this community) when the three panelists/moderators seated themselves in front of the room. On the left was seated Gert from Railo; in the center was Matt from OpenBD, and on the right was Sean Corfield. I couldn't help but wonder amusedly if the shirt Sean was wearing was prophetic in its short, simple statement: "I See Dead Code". Not so much that CFML could ever go extinct, but I wondered in myself whether or not the mother of all CFML, Adobe herself, might one day become a matter of history regarding the evolution of our language.

Just prior to formally beginning the discussion there was a brief but loud bump at the room's emergency exit. Upon inspecting the source of the noise, we happily found it to be a man bearing a large smile and at least two cases of Shiner Bock and other miscellaneous recreational beverages, no doubt just exactly the elixir needed to facilitate this discussion and keep it well lubricated. After the initial distribution of holy water, Gert formally got the dialogue rolling.

He began by giving us a short, general list of what he hoped to accomplish with the meeting, primary of which was to receive input from the rest of us as to what features and/or changes we felt the open source CFML engines needed to incorporate. He laughingly also allowed us the benefit of airing any grievances we may be harboring as well, the implied subject being Adobe and her less than friendly stance towards the open source engines. Speaking of whom, it was shared with us that the conference hosts had spoken with Adobe and extended an invitation to participate in whatever manner they saw fit. They saw fit not to participate at all, their motivation being (sadly so) that they had no place at an open source conference.

At Gert's checkered flag, the conversation was immediately off and racing full speed ahead. With courtesy abounding and caring moderation conducting this orchestra, nearly everyone had at least one thing to share with the group. In between listening, considering, and sharing, I was busy taking notes on how this dialogue flowed. What follows is a very paraphrased approximation of how it all played out, with my occasional commentary interspersed and annotated as such.

Upon the news that Adobe had declined to be represented among us, I couldn't help but feel a very strong sense of apathy towards her, looking into the future and feeling quite confident that, with the open source engines maintaining such a tight bond with the community who symbiotically supports them, nobody would shed a tear or be left in any kind of a lurch if Adobe should disappear from the CFML landscape tomorrow. Gert was sincerely gracious in reiterating to me at one point that, in its present state, CFML could not survive as a language if it weren't for Adobe's continued participation in its evolution. Despite his kindness towards Adobe, I could still envision the day when Railo and OpenBD would be leading the way for Adobe rather than the Adobe setting the standards for the open source engines.

The first topic was introduced by Sean, and addressed the fact that, the way CFML is currently architected, one basically has EVERY available tag and function living within the same namespace; that is, at any place and at any time in any CF app, you can execute ANY CFML tag or function. When you think about this, it seems like a lot of overkill to have EVERYTHING imported, especially when the model of other languages is that you only import what it is you need. Thus, Sean suggested that perhaps functionality be segregated into importable packages or modules.

Noting that, given any length of time when someone wasn't audibly speaking, the topic was subject to sudden and immediate change, the next tangent embarked upon was converting some functions to objects. For instance, there are currently 80 separate functions that you can use to manipulate spreadsheets in CFML; but it was suggested that it might make more sense if those functions were part of a single spreadsheet object that a developer could simply create an instance of and then call the needed methods in a more object oriented manner. It would remove those functions from the global namespace, alow those objects to be used within CFSCRIPT, and it would give developers a more "sensible" and compact syntax for writing code.

Someone then spoke of ways to measure the success of an open source engine's progress, and the popular response to that question was "the more hostile Adobe gets, the more successful that engine is becoming". Indeed.

Being able to execute different languages within CFML has been a topic of discussion off and on over the years, and we all took the time to hash it out tonight as a group. Languages such as PHP, Groovy, ActionScript...wouldn't it be useful to be able to execute their code directly within a CFML template? Well, it is definitely do-able, and has been demonstrated time and time again. Sometimes it is of use, with specific use cases; but the real question is, would end users truly find this a useful thing to have? How often would one really want to suddenly switch up and run a few lines of PHP within a CFML page? Just because we CAN do this thing, SHOULD we? Looking to the example of Adobe, who, in wanting to help attract more Flash developer to CFML, invested the effort into making it possible to execute Action Script on the server side. And did their effort succeed in attaining their goals? Did a million plus Flash developers fall in love with CFML? No. In fact, many of the Adobe Flash applications and demos are embedded in PHP pages. The overall conclusion to the debate led to a pretty clear "no, we do not need to make this feature part of the core engine". When such needs do arise, CFCs can be written to wrap up and provide this functionality, such as has been done with CFGroovy.

This discussion necessarily led to discussing OTHER tags that have been made part of the core that probably aren't appropriate as well. Tags such as CFMap, CFAjax, CFSharePoint, CFForm, CFTable were mentioned by name, though the list is much longer. Quite frankly, most developers do not and will not use these tags. Due to the fact that so many legacy apps exist, one person suggested that perhaps these "smelly" tags could be moved out of the core and into a "grandpa" library that could be imported as needed to support backwards compatibility. The nay sayers of this, though, brought up the subject of simple deprecation (or defecation, as one of my peers shared) of certain tags and functions. As with many languages and projects, there comes a time in their evolution when backwards compatibility can and should only go so far. So, rather than worry about legacy apps breaking if one were to upgrade to a more current engine, put the onus back on the developers to weigh out whether or not they're willing to simply rewrite the affected portions of their code to be compatible with the engine version they desire. It's not a new thing at all, and it makes perfect sense in the natural order of things. The now deprecated CFML advisory committee was nearly unanimous on this idea, with the exception of one member who tended to oppose sound suggestions on a rather frequent basis to suit their own needs.

A developer who is fairly new to CFML shared her perspective on the language, conferences, and what it is she does and does not look for from the community with regards to help. She was very pleasant and candid, and was interested in having access to a resource where she could get information and help with the kinds of projects she is specifically working on. This led the discussion into a debate on some kind of centralized wiki for CFML. There are those who feel that the current landscape dotted with blogs whose content tends to be very ecclectic in nature just wasn't sufficient to act as a solid resource for those who are just getting started with CFML. I personally thought contrary and, though I am all for a "central repository" of knowledge, feel that a virtual one is just as good as a tangible one. In over 13 years of CFML development, I have worked primarily as a lone developer and as such have had to seek out the information I needed as I went along. Google, ah my good friend Google, HAS been my single virtual "central repository", helping me locate exactly what I needed from among the multitude of knowledge out there, and helping me to make some good friends in the community along the way. This debate then evolved into discussing ways to assist one another. It was said that if you find there is only one person in an organization that everybody else goes to for help, it is possible for this to become a source for the propogation of poor coding habits. It is healthier for the community as a whole, therefore, if every individual makes a conscious effort to seek out assistance from different people, whether a local peer or a virtual one. The idea of what appropriate help is was also explored. In a nutshell, if you're doing it for them, you're not helping them. Give them the clues they need to figure it out for themselves...teach 'em to fish, don't catch it for them!

Ah, and speaking of educating people about CFML, a healthy discussion on ways to incorporate more of the other languages' communities also took place. In a nutshell, CFML has had a bad rap pretty much since its beginnings due almost completely to the fact that it never had an open source engine and required major financial investment to use. Now that this is no longer an issue, it's time the world became aware. How can we do this? By doing what I interpreted from the conversation to be an ethical bait and switch. Two key areas stood out to me during this dialogue: blogging and code sharing.

Regarding blogging, Sean put it best when he said that as long as you only blog about CFML, then only CFML developers will be reading your blog. The point therefore being to get developers of other languages reading your blog and thus "discovering" or even rediscovering CFML, it is important to do a couple of things. One, do more to genericize your blog. Rather than name your site something CFML-specific, like "BestColdFusionSiteInTheWorld.com", try "codeMonkey" or something else that speaks as well to a PHP developer as a CFML developer. Rather than title your posts with something CFML specific, try to come up with more generic approaches to sharing the information in your post. It's okay to mention CFML in the post, but get their attention first with your vast knowledge of ORMs, MVC, object oriented principles, and THEN utilize CFML to illustrate what you're talking about. Also, take the time once in a while to learn about and blog about other languages or technologies. On my own site, for instance, I get a LOT of traffic to posts I've done on Oracle, CSS, Javascript, and PHP. Sean shared an example of how he has gotten increased traffic via his posts on Clojure and how some of those readers have actually commented to the affect that they discovered or rediscovered CFML via his site.

Many community members share projects they've created. Custom tags, CFCs, entire apps. Applying the same mentality described with blogging, Sean suggests that rather than simply host your shared code on RIAForge or other CFML-specific sites, share it on Github! That way, EVERYBODY will see it. The more visitors to Github see CFML projects rising on the list, the more attention it will gain.

Lastly regarding attracting outside developers is the idea of participating in technical forums that are language agnostic, specifically StackOverflow. As other language developers frequent that site and see CFML questions being posted and responded to, it will undoubtedly pique their curiosity!

In a nutshell, all of us can facilitate the CFML Rennaissance by simply making a few simple changes to our online habits.

We wrapped up the session by actually talking about the main topic that Gert had mentioned to begin with: feature suggestions. Some of those shared were the incorporation of closures, proper collections and enumerables, and heredoc syntax.

Lastly, we were all given the reminder to take the time to share our ideas, needs, and desires for the open source CFML engines. The open source community, as it always has been and always will be, considers themselves to be one with the community who utilizes them. They recognize and embrace the symbiosis that makes both we and they great: mutual evolution.

Oh, I mentioned the CFML Advisory committee that had been formed to help all of the CFML engines evolve with some kind of standardization. Since Adobe refused to participate and exercised a lot more vetoing than concurrence, the new unofficial yet very functional CFML advisory committee exists in the form of a Google group to which ALL are invited to participate and be heard. If you have any input, ideas, or rainbow and lollipop dreams for either Railo or OpenBD, feel free to interact with those who guide them at CFML-CONVENTIONAL-WISDOM (http://groups.google.com/group/cfml-conventional-wisdom?pli=1)

Doug out! :)

P.S. Notice that not one time (with one exception when referring to what not to do on your blog) did I ever refer to our language as ColdFusion. As I believe that Adobe will one day in the near future no longer be leading the pack of engines, I prefer to think of ourlanguage in a more generic, open source fashion. This necessitates the cutting of all ties, and thus I will, on most every occasion from here on out, refer to it only as CFML. Might as well get used to changing your mindset to something more open source as well! :)