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!
