An Architect's View

CFML, Clojure, Software Design, Frameworks and more...

An Architect's View

The demise of OpenCFML

July 22, 2010 ·

By now, many of you will have read Adam Lehman's blog post that Adobe is no longer part of the CFML Advisory Committee. Adam had initially disabled comments (but now he's opened things up) on that post and folks have been asking me all morning for my take on this so, as chair of the committee, I'm going to post my thoughts - and leave comments open so the community can provide feedback.

First off, I think we always knew this would be a difficult job. CFML is actually a pretty big language that has grown in a fairly haphazard way over more than a decade, mostly without a steady hand that understands programming language design. There were a few internal Allaire / Macromedia / Adobe groups over the years before Adam Lehman joined the ColdFusion team that tried to steward development of the language but for a variety of reasons they never really got much traction. Two years ago, Adobe announced the CFML Advisory Committee and made me chair of it. It came hot on the heels of my resignation from the Open BlueDragon steering committee and it was quite a surprise (the announcement at CFUnited 2008 was actually the first time I knew of my role on the committee).

Over the next six months, we worked hard - Adobe, Railo and community members - to map out the tags and functions in CFML and categorize them as 'core', 'extended core' or 'vendor-specific'. We used a Google spreadsheet with the lion's share of the early work being done by Gert Franz and Rob Brooks-Bilson to provide a framework for us to vote. We got the CFML Advisory Committee web site up and the initial cut of tag/function categorization published (kudos to Rob Brooks-Bilson for all his hard work on the wiki content). We'd agreed early on that "all" CFSCRIPT would be core language so we didn't focus much on defining what was "CFSCRIPT".

At the beginning of February 2009, Ben Forta announced that Adam Lehman would join the committee, taking over from Sanjeev Kumar to represent Adobe. Ben also said the time was right to invite OpenBD to join the committee and we quickly agreed on Matt Woodward as the best choice. Matt quickly came up to speed, added his votes to the spreadsheet and added all the OpenBD-specific tags and functions to the mix, just as Gert had done six months earlier.

At the beginning of April 2009, Adam shared the CFSCRIPT enhancements that Adobe were considering adding in ColdFusion 9, then under the codename Centaur and in private alpha testing. Round about that time, we also made the decision to tackle tag attributes and function arguments and categorize those. In hindsight, that was a mistake. It was too big a task and it bogged us down.

In mid-April, I joined Railo and Gert stepped down from the committee so that Railo would continue to have a single representative on the committee. Since I was previously a 'community' rep on the committee, we needed a replacement and selected Peter Farrell by unanimous vote.

We continued to review and discuss the CFSCRIPT enhancements and found that consensus on the committee for certain features didn't always match what Adobe was already implementing in ColdFusion 9 - and that some features were contentious enough that we couldn't reach consensus at all. I reached out to the community on my blog to help us resolve a few issues but that input didn't actually move us closer to consensus. These were hard issues.

Unfortunately, the gargantuan task of categorizing the tag attributes and function attributes, combined with the lack of clear consensus on a number of key features in CFSCRIPT seemed to sap the will of the committee. Voting became slower and slower, Ben and Adam became very focused on the upcoming launch of ColdFusion and it became harder and harder to get their input (and understandably so - Ben continued to vote as and when he was able but Adam pretty much stopped voting on issues completely). By the end of August, progress had completely stalled and discussions stopped.

There was a flurry of discussion at the end of November, spurred by a comment made by Alan Williamson (OpenBD) questioning whether the committee was even relevant. Then things went quiet again.

I tried to get the discussions going again in early February. We'd clearly missed the "CFML2009" opportunity but I felt we could pull together a reasonable "CFML2010" and I recommended the following approach for a specification (quoting here from my email to the committee):

  • "Retains the core / extended core / vendor specific partition of tags and functions that we've already agreed.
  • Does not dig deep into attributes and/or arguments.
  • Incorporates most of the CFSCRIPT document we already created.
  • Simply omits CFSCRIPT recommendations where we had trouble reaching consensus.
  • Adopts the existing Adobe CF9 syntax for CFSCRIPT constructs where "CFML2009" differs in core details (lock, transaction etc).
  • Adds a clear, concise description of expressions (this is new work - but it is necessary)."

Ben, Matt, Ray and Rob all agreed and offered to help.

A few days later, Peter Farrell resigned. Adam says, in his blog post, "Peter Farrell quietly resigned stating he was too busy to keep up with the day-to-day activities of the board". Peter's actual words were "The demands on my time have increased in the past year and it has become increasingly difficult for me to contribute sufficiently to the CFML specification process." I took Peter to mean that he simply felt he couldn't do the committee justice in terms of providing input on the voting and process etc. As we'd seen over the previous eighteen months, it was a lot of hard work!

Adam picks up the story well at that point, writing on February 25th, 2010:

"Yesterday, the topic of a replacement was brought up and Sean Corfield and Matt Woodward both offered up worthy nominations. I chimed in and recommend we add Alan Williamson. The fact that this particular nomination came from me might shock you since he's the driving force behind OpenBD. But let me digress... a few months ago Alan and I got on the phone to sort out some differences. We talked for 45-60 minutes about some of our perceptions of each other, our projects and our goals. It seemed as if we had really misunderstood each other and that we shared a ton of middle-ground. During this conversation I shared some of my frustration with the OpenCFML board and proclaimed he would be a great addition to the board. So fast forward to today, when the opportunity arose, I nominated him. I also made the recommendation to expand the group to include more community members. While it wouldn't be prudent for an expanded group to have full voting rights, I wanted to increase the amount of friendly voices and visibility into the project."

Before we could get into any real discussion on that, as Adam said, he withdrew from the committee with Alan Williamson's "Conventional CFML Wisdom" group as the catalyst. Someone had alerted me to the group about a week earlier (the group had been created on February 15th, 2010) and I'd joined to explain the committee thinking on certain decisions. Adam joined that group the day he withdrew from the CFML Advisory Committee. The group has had just a dozen fairly brief discussions since it was formed, so whilst it is nice to have an open, public discussion group for CFML features, I wouldn't consider it very significant or representative (there are under 100 members). Perhaps that will change over time? I hope so.

Where is the CFML Advisory Committee right now? Well, we'd had no discussions since Adam's departure until two weeks ago when I tried to resurrect the CFSCRIPT spec. Per committee agreement based on my recommendations in February, I'd taken a copy of the committee's voting document and removed all the votes and the open questions, in an attempt to get an actual spec that we could publish at CFUnited. I'd also adjusted the spec to match Adobe ColdFusion 9's implementation, as we'd agreed in February. Ray and Rob helped me with wording, to better reflect a spec rather than the discussion document it grew from. I'd hoped that we could publish it for CFUnited and reignite interest in the committee and begin to move forward again. After all, when Adam withdrew, Ben said that our "initial objective is still valid and perhaps even more compelling than ever" and suggested we try to tighten our mission, in order to move forward.

I don't know when Adam actually unsubscribed from the CFML Advisory Committee mailing list so I don't know whether he'd seen my latest attempt to get the committee going again. Certainly the timing of his blog post means that publishing a spec at CFUnited is now a moot point.

What about the committee mailing list? I suggested a couple of times that we should open up the list archives to the community - including at the start of the process. Adobe expressed the concern that they were sharing future plans with the committee which they felt would be inappropriate to speak about publicly. It's a difficult position for a corporation that has to be very careful about future disclosures. Whilst the committee was never under NDA with Adobe, it was made clear that there was a certain expectation of privacy.

Lessons learned? Well, specifying a language is inherently difficult. I spent eight years on the ANSI C++ Committee (three as X3J16 Secretary) and I represented the UK on the ISO C++ Committee for most of that time as well. There were a lot of vendors on the committee and discussions could get very contentious and even heated at times. That's the nature of cross-vendor standardization. I think I was perhaps the only member of the CFML committee that really understood how difficult a true cross-vendor specification might be for CFML. For years, there was clearly no value to Allaire / Macromedia / Adobe in having a public specification (it came up several times over the years - and I was always a big advocate for such a spec while I worked there) but I had high hopes for the effort when it started in 2008. Adam says "The real beneficiaries were Railo and OpenBD who wanted a CFML standard that would allow ColdFusion customers to easily switch to their clone engines." and that's the reason the process had never been attempted before. Given that half of the people who fill out the information form on the Railo download page are not existing CFML users, that's a disappointing attitude, in my opinion.

Adam says "Sean claimed that Railo wanted to wait a version (or two) to see how new Railo tags were accepted by the community before making a formal recommendation." Here's what I said to the committee in November: "Adobe have released ColdFusion 9 now and, due to schedule / timing issues, it includes syntax that is at odds with what the committee agreed as core CFSCRIPT. Railo have been holding off implementing the new syntax until we can get a clear sense of what is really going to happen around the committee." ... "Railo has been very conservative about core language changes, trying to follow Adobe's lead as much as possible on details, whilst adding clearly non-core language features." ... "Railo believes the only sensible approach is to support Adobe's syntax since that is what developers will expect. Supporting only the CFML2009 syntax lowers portability. Supporting both syntaxes only makes sense if Adobe are committed to adding the CFML2009 syntax as well - which won't happen for at least a year." More recently we've talked about adding closures to Railo and proposing that to the committee. I indicated that we wanted some experience with implementation and some community feedback on the feature before making a formal proposal. Given my experience with language standardization in the 90's this seemed the most sensible approach to take - and it was usually how features were tested before being baked into the C++ standard. It's not like we can't change our implementation to match the committee's consensus later - as we just did recently with for-in loops over arrays in CFSCRIPT.

Is the committee dead? Officially, no, but the lack of Adobe's involvement makes it somewhat pointless - as several committee members had opined when Adam first withdrew in February. So, for all intents and purposes, it might as well be officially dead.

What happens next? Adam has said ColdFusion will be driven by the Adobe ColdFusion community and that the Adobe Community Professionals will act as their advisory committee. Railo and OpenBD will continue to be driven by the overall CFML community and will track Adobe's developments for cross-engine compatibility. In other words, pretty much the status quo that we've had all along.

In closing, I'll echo Adam's words and "thank Ben, Rob and Ray for the work they put into the OpenCFML. Rob and Ray specifically donated a large amount of time to this effort". I'll also thank Gert, Matt and Peter for their contributions - as I've indicated above, Gert and Matt in particular helped pull together the working documents we used as a basis for voting. I'll also thank Ben specifically for having the vision to get this started and for the encouragement he gave us all when things weren't going well. As chair of the committee over the past two years, it's been an interesting challenge but, ultimately, a disappointment that we weren't able to move forward together with a public, open specification for the language we all love!

Tags: cfml-advisory · coldfusion · openbd · railo

23 responses

  • 1 Adam Tuttle // Jul 22, 2010 at 4:01 PM

    Adam's post has had comments enabled since at least 3pm (eastern). I guess he had a change of heart on that, but it's at least worth pointing out that they are open now.
  • 2 Andy Jarrett // Jul 22, 2010 at 4:12 PM

    Its a shame that the committee has come to this. Having a standard specification meaning we chose the engine based on 'extended core' or 'vendor-specific' features would of only benefitted everyone in the long run. The problem lays with ACF and their need keep the share holders + interested parties happy first before the community. Its not a dig at Adobe thats just business. I hope this is not the end though and via the community and the CFML vendors something still comes together.
  • 3 Russ S. // Jul 22, 2010 at 4:15 PM

    That is a disappointment. Thanks for trying though Sean!
  • 4 Mark // Jul 22, 2010 at 4:26 PM

    Interesting. I'm thinking this might actually open up one of the open source engines to actually move *away* from Adobe CFML and create a sort of CFML 2.0 designed from the ground up to be internally consistent with a tag/script duality that actually works together instead of against each other, etc.

    But that's probably an even bigger job than the original OpenCFML task. If you lose Adobe CFML compatibility, you have to generate quite a lot of support on your own. Probably just a pipe dream.
  • 5 Grant Shepert // Jul 22, 2010 at 5:08 PM

    "May you live in interesting times."

    I'm sure this (and Adam's, and Matt's and undoubtedly the rest of the cast's) post will spawn all sorts of rampant forecasts of doom and despair (and, yes, even death). The fact is, there's just so much Agenda in an effort like this, and such an imbalance in the business models, history and investment by the respective players that it was a fight uphill from the start.

    The sad truth of it, though, is probably much more common and predictable than just a difference in opinion. Obviously the timing of Adam's announcement is no coincidence (Adam giving a State of the Union ... I think I'd rather have Hal Helms do it now, thanks), and is bound to distract from what would (should) have been a community celebration.

    In the end CFML *is* owned by the community, and we will choose the company(s) that lead it's direction by the way they treat us and the language we love. The IT battleground is littered with companies who believed otherwise.
  • 6 Dave Ferguson // Jul 22, 2010 at 6:56 PM

    A long, but worthwhile read. I have now read the posts from Adam, Sean, and Matt. My fear now is that this is going to turn into a war of words. It is going to turn into a he said she said thing and the overarching issue will be lost.

    I hope that in the end we can all get along and move forward. I think that the CFML Advisory Committee was a great idea. However, after reading, it had some internal issues that was its ultimate demise.

    (same comment posted on Matt Woodwards's blog)

  • 7 Brad B // Jul 22, 2010 at 7:07 PM

    It is nice that Adam has enabled comments.

    Just remember he is notorious for deleting comments that are perceived as negative by Adobe or himself. So take whatever you read there with a singular grain of salt.

    Perhaps my comments aren't as valuable as some that are or will be posted, but I will say with sound body that I could care less about Adobe's Coldfusion or quitter for that matter.
  • 8 Adam Lehman // Jul 22, 2010 at 9:16 PM

    @Brad B: I'm notorious for deleting comments? Care to quantify an actual case where that has happened? My blog doesn't even have comment moderation and is riddled with critical and hurtful comments.
  • 9 Sami Hoda // Jul 22, 2010 at 10:05 PM

    The part I found interesting was when Adam said that ACPs will play a bigger role. I know several people who became ACPs this year who really don't have Adobe's best interests in mind. For the past year, I've been finding more and more bugs in Adobe ColdFusion and working directly with CF dev team members directly to get this resolved. I don't know how much ACPs can lead when its hard to get responses on critical bugs. For once, it would be nice to take a couple months to solely focus on squashing bugs and opening up the bug tracker further, than continuing to build new features that takes each of the engines farther apart. Sigh.
  • 10 Grant Straker // Jul 22, 2010 at 10:56 PM

    Just my couple of cents on this.

    As much as I am a Railo fan and love the product and the team, as a businessman I would have to agree with Adam on this one. Nobody gains commercially from OpenCFML except Railo and BD. If it was my business I would not enable others to see what I was investing in building and then give them a head start to copy the concepts and then give it away, marketing to my client base and start undermining my business.

    To start with I'm sure they thought "keep your friends close and your enemies closer" but now the battles gone up a gear and fair enough they need to address it.

    The bottom line for companies like ours is that we make more money using Railo than we do using CF. It's easier to deploy(for what we do) and less complex in the sales process without licenses additional costs. Often we have to convince people to use a CFML engine rather than them knocking on the door asking us and its the features of our product that enable us to get clients using it, not the features of CFML or the Adobe brand, and certainly not the Railo brand, which isn't exactly a household name as yet!

    The one thing I find strange about this whole affair is that I find my competitors are often the people I get on with the best. Given we have to overcome similar issues and attend the same events etc. I think at CFunited everyone should agree to differ, understand it's a tough world and you have to fight for your corner sometimes, get blind drunk and then kiss and make up. Don't get too friendly tho in case you wake up the next morning next to someone with a beard :)
  • 11 Michael Offner-Streit (CTO Railo Technologies) // Jul 22, 2010 at 11:27 PM

    I thank all people that have spend time for the CAC. Even it is not in a good shape it was always a help for me an I hope we can find a way to keep things going in this direction

  • 12 Jack Ketch // Jul 23, 2010 at 4:25 AM

    Wow. That's a lot if double talk to say "Not my fault, it's Adam's". This post has done nothing but confirm my prior assessment of you: a self-aggrandizing douchebag. You've done nothing but work against ColdFusion since you left Adobe. Hopefully this post helps people realize what a fraud you are, finally.

    I guess like Broadchoice and your other startups, the OpenCFML committee got the "Corfield Kiss of Death".
  • 13 phill.nacelli // Jul 23, 2010 at 7:19 AM

    "Is the committee dead? Officially, no, but the lack of Adobe's involvement makes it somewhat pointless"

    Sean, I think you have an opportunity here to make the committee even better and more relevant by opening up some of the discussions to the public and get direct feedback from the community.
    Although it sucks to see Adobe out of the picture, it now allows you guys to be more open without the presence of corporate future disclosures.
    I feel that Adobe would still "listen" since the community voice would be helping shape the language under the guardianship of the committee members.
    This committee still has a great value to the CFML community, the announcement of its creation was received with much enthusiasm by the community and we do appreciate all the hard work and burden it puts on all of its members.
  • 14 Rob // Jul 23, 2010 at 8:33 AM

    I have used CFML for 4 years now (Adobe, BD, OpenBD, & Railo). For the first 2 years I had hope it was going somewhere. After that, I gave up.
    ...since then everything I hear about what is going on (both the semi-good & the bad) make me realize I was right 2 years ago, and should abandon the language completely.
    It's not worth the headache. There are enough good alternatives out there.
  • 15 Sean Corfield // Jul 23, 2010 at 11:02 AM

    @Jack Ketch - the 17th century executioner? How appropriate :)
  • 16 Kevin Benore // Jul 23, 2010 at 12:43 PM

    @Sean - thank you for a very reasoned, lengthly post on all of the in workings of the CFML Advisory Committee. I don't know Adam Lehman from ... well Adam ... but I must admit the tenor and tone of his post seemed more accusatory than it needed to be. When he posted the bit about the mail list, I had to read it a few times because I failed to see the relevance. I am not sure if your group's bi-laws required you to disclose every mail-list you joined, but it really seemed that there was more to it than that.

    As a professional from Adobe, I guess I expect a little more professionalism from Mr. Lehman. If Adobe wanted to bow out of the CFML Advisory Committee, then just tell us that and why. Don't go into perceived personal failing or misdeeds of other committee members. It's childish and creates a sense of disharmony in the community. It's also hurts the brand of Adobe when their employees spout off at a group of community members that are volunteering their time to make CFML as a whole better and standardized.
  • 17 Paul Klinkenberg // Jul 23, 2010 at 7:27 PM

    OMG, it's a shame that this didn't work out right.
    All the efforts, and then one man accusing the committee in public like they didn't do anyhthing... I should have actually written an angry post on Adam's blog, but that ranting blog isn't worthy of any reply.
    Thanks to (almost) all the committee members for the work they did; it was appreciated!
  • 18 Andy K // Jul 23, 2010 at 8:06 PM

    @Adam - well I know that you removed one of my comments from your blog and then closed comments right afterward.

    Ironically, it was in reference to another one of your smarmy, baiting posts against OpenBD and Railo.

    The dripping irony was that you yanked comments on a post that talks about "free as in speech" throughout the post!
  • 19 Peter J. Farrell // Jul 24, 2010 at 12:48 AM

    My only thoughts on the subject:
  • 20 Kai Tischler // Jul 26, 2010 at 8:04 AM

    @Rob: "There are enough good (CFML) alternatives out there." Which CFML alternatives are You thinking/speaking of in July 2010 ?
  • 21 Chris Dawes // Jul 27, 2010 at 9:22 PM

    I hope your post doesn't disolve relationships, rather allows you all to come to a new consensus about how to approach the issue of determining core/extended functionality. It's just not feasible (in my opinion) for a commercial unit to be sharing secrets that can be copied by a free open source alternative.

    I've been a fan of giving an administrator the option to turn on or off all extensions to the core/extended core of the lanugage.

    This way it doesn't matter what each vendor does (just like firefox/ie/webkit) because you use the core/extended core for cross-engine apps and use custom code wherever required.

    All the same. Please keep working to _A_ standard and we'll all be happy. Of course this doesn't mean the open source engines can't put pressure on Adobe to implement a feature (like CFVIDEO)...

    Just remember you are all competitors. ;-)
  • 22 SpliFF // Mar 8, 2011 at 10:07 PM

    To my mind this committee was as important to the future of CFML as W3C/WHATWG is to HTML/CSS. While it's easy to think of the issue in terms of Adobe vs. Railo/BD the issue is actually CFML vs. PHP/Java/Python/Ruby. Undoubtedly Adobe realised this when they joined OpenCFML in the first place.

    As a web developer I've watched how Microsoft have shifted their stance from deliberately breaking standards in IE4-7 to (mostly) embracing them in IE8-9. They may not take part in the WHATWG or W3C directly but they have come to realise they can no longer act like the 20 ton gorilla and still keep developer mindshare.

    What I'm saying is that if history is any guide there isn't really any requirement for Adobe to participate in the development of an open CFML specification. As long as Railo/OpenBD can develop a clear specification it may eventually come to pass that Adobe have no option except to join the party or abandon the language altogether. As someone who migrated from CFMX to Railo some time ago I'm hard pressed to find any argument for going back. Therefore, the future direction of Adobe's CFML implementation is only of passing interest. The future of "Open CFML" on the other hand is of great importance and I would hope some effort is made to rebuild this committee - perhaps initially with a less ambitious agenda and a formal process for resolving deadlocks.
  • 23 Sean Corfield // Mar 19, 2011 at 11:46 AM

    @SpliFF and others, I think the consensus is that the mailing list will be where future language issues are debated by all parties - and the community - but whether there will ever be a public specification of CFML remains in doubt.