Since Adam doesn’t have comments open on this post (what’s up with that?), I feel compelled to clear the air and discuss the probable ending of the CFML Advisory Committee from my perspective. (And yes, all are welcome to comment on this post.)

I really regret having to spend the time writing this since in a lot of ways it will be airing dirty laundry. But since Adam is grossly misrepresenting a great deal of what went on during the effort of the CFML Advisory Committee and what led to its eventual demise, I think it’s only fair that people don’t take Adam’s version of the story as gospel. It’s far from it.

Preamble

First, I’d like to get some semantics out of the way. I can’t bring myself to refer to this now-defunct effort as “Open CFML” because it’s such a huge misnomer. Frankly, we never referred to the committee as “Open CFML” so I suspect the use of that term in Adam’s blog post is merely FUD/scare tactics that suit his purpose. (Saying Open CFML is dead sure has impact, don’t it?)

The CFML Advisory Committee was anything but open. There was no communication with the CFML community as to what was going on with the effort, there was no way for the community at large to participate, and suggestions by myself and others to update the wiki regularly with our progress and have an open mailing list that anyone in the community could at least read were continually shot down. Given all this it’s not surprising the effort ultimately failed, because openness always wins in the end.

Now for the timeline of the CFML Advisory Committee and why things went wrong from my perspective.

In the beginning …

When I was invited to join the CFML Advisory Committee I was excited because I originally thought the effort was important for the future of CFML. The CFML landscape changed dramatically with the introduction of two open source CFML engines, so it seemed logical that the interested parties would want to get together and discuss a certain level of standards for the language. It’s also something that the CFML community was clamoring for, at least initially, because of concerns over code portability between the various engines.

After getting up to speed on things and having discussions via the closed mailing list as well as a couple of conference calls, it became quite clear to me that the effort wouldn’t be able to survive the politics. Even given my valid pessimism, I decided to continue on in earnest, hoping for the best but expecting the worst.

Here comes a bit of dirty laundry, but I think it’s necessary for people to understand what was really going on behind the scenes. Adobe’s participation and level of effort during their involvement with the committee was incredibly lackluster. The committee had conference calls monthly in the beginning, but after Adam didn’t show up for three calls in a row, it seemed rather pointless to continue to schedule them. The email traffic on the closed mailing list would go in fits and starts, and in many cases months would go by with no traffic at all.

To cite but one example of Adobe’s lack of effort, the way the committee was attempting to organize the language was to use a Google spreadsheet, with columns for the CFML tags and functions on the left, and then a column for each engine indicating whether or not it had the tag or function. There were then columns for each member of the committee to indicate if they thought the particular tag or function should be “core,” “extended core,” or “vendor specific” as far as the eventual language specification was concerned.

As you can imagine simply organizing the spreadsheet took a great deal of time and effort, to which many members of the committee contributed. Each vendor was tasked with entering their engine’s tags and functions. OpenBD and Railo provided their information quite promptly, and I think it was Rob who did the Lion’s share of getting things organized initially, but Adobe’s column was incomplete for weeks. Finally I took a day or so and added/corrected all the Adobe functions and tags. That at least got things to the point where we could vote.

When it came to voting, Adobe failed to complete this effort as well. To put things in perspective voting took about an hour, but Adobe couldn’t seem to find that hour to input their votes. First it was the CF 9 release, then it was MAX, then … who knows. Bottom line is it never got done. Everyone involved with this effort is incredibly busy, yet everyone but Adobe made the time to vote.

Lack of Accountability Means Lack of Commitment

After weeks turned into months and the voting was still waiting on Adobe, I believe it was Peter who made the modest proposal of setting deadlines for votes. If someone didn’t meet the deadline then we’d simply indicate the person didn’t vote and proceed with the votes we had. Everyone paid lip service to having deadlines, but even while discussing deadlines Adobe reserved the right to ignore the deadlines if they were “busy.” Again, we’re all busy. Either the effort is worth your time or it isn’t.

I also suggested repeatedly that the whole specification and voting process be open to the public. The members of the committee were selected to represent the CFML engines and the CFML community, but we don’t necessarily have all the best answers, and at a minimum the community at large should have been able to see the process as it unfolded. But that would have meant both commitment and accountability on the part of everyone involved, and in the case of certain members of the committee the commitment clearly wasn’t there. Having accountability–let alone public accountability–wouldn’t work in their favor.

In the end the incredible lack of progress led everyone to agree to simply codify what was in Adobe CF 8/9 so we could get past the voting roadblock and move on. (Keep that decision in mind; it backs up an important point I’ll make later.)

Conspiracy Theories Debunked

Here’s where things get really bizarre, so please don your tin foil hats and try to stay with me.
Adam mentions the CFML Conventional Wisdom group in his post, which is an effort Alan Williamson started in order to foster public discussion of the CFML language. Personally I think an open discussion list should have been an arm of the CFML Advisory Committee from the start.

To quote Adam’s post, “At the very least, this explained why Peter so abruptly resigned.” I’m not going to speak for Peter, but this is not why he resigned, and his resignation wasn’t exactly abrupt. He debated it for a long time, but to call it abrupt reminds me of a scene from “Fletch“:

Why Adam chose not to take Peter’s eloquent resignation email at face value, but instead drums up yet another conspiracy, only serves to further his agenda.

Back to our story. So why didn’t I mention the CFML Conventional Wisdom list to the committee?
Two reasons.

First, it’s a public mailing list, and I found out about it like everyone else did, on a blog post or Twitter or who even remembers where. Alan may have even sent me an email directly to make sure I was aware of it, but it wasn’t a big secret. There were no back-room dealings on any of this. Alan saw a need, created the group, and then announced it publicly. Simple as that.

Second, and more importantly, I saw this as a completely separate effort from what the committee was doing. The committee never had a public forum to discuss CFML, and the powers that be on the committee didn’t want one. So this provided something the committee didn’t, and giving the community a voice in helping to define the language they use is something vitally important in my opinion.

Ultimately the Conventional Wisdom list could even serve as a benefit to the committee. Loose ideas could be hashed out, sample code usage could be created, and the results could be submitted to the ivory tower that was the committee.

And a bonus reason: at the time when the Conventional Wisdom list started, the committee was in no way, shape, or form in the business of discussing enhancements to the language. We weren’t even able to codify what was already in the language, so for Sean, Peter, or me to bring a CFLOOP enhancement discussion to the committee wouldn’t have made sense. The committee wasn’t the time (or the place, frankly) to have those sorts of discussions.

The way Adam phrased all of this makes it sound like Alan, Peter, Sean, and I got together and were all conspiring against the committee, and maybe Adam even believes against him personally. Nothing could be further from the truth. Sean, Peter, and I found out about the Conventional Wisdom group when everyone else did, and since people on the committee are supposedly aware of what’s going on in the CFML community, I assumed everyone on the committee would have seen it as well. The implication that we were keeping a publicly announced, publicly available list hidden from the committee simply doesn’t hold water.

As for my better mouse trap header above, ultimately I think having an open discussion group is the way things should have been from the start. Why not seek input from the community at large? Why not have the discussions out in the open? Seems like a no-brainer to me. If Adobe wants to have enhancement discussions with their customers and among the members of their private programs that’s great for Adobe, but that doesn’t let the legions of CFML developers in the wild participate in the process.

Again, openness always wins.


Where I Agree
Adam did make a couple of points with which I agree.


“In the end, the community isn’t losing much at all with the demise of the OpenCFML board.”

I completely agree with this statement. Though I was honored to be a part of it I questioned the effort from the beginning because at the end of the day, Adobe ColdFusion sets the de facto standard for the language. I made that point in my last email to the committee list (which for a very long time was the final email on the committee list), and I don’t think anyone would disagree.

I take issue with Adam’s follow-up to this statement, but life’s too short to nitpick every last detail of what he said. The real beneficiary of this effort was supposed to be CFML developers, but somehow that ideal got lost along the way.

Bottom line here is that CFML developers don’t have anything to fear due to the loss of the committee, because the practical value of the end goals were rather dubious from the start. It’s in the best interest of the open source engines to be largely compatible with Adobe CF, which they are. We haven’t had an official CFML standard before and the world hasn’t come to an end, so the cf_apocalypse won’t come now.

“Innovation and progress in CFML is driven exclusively by the ColdFusion community.”

I suspect Adam and I have very different ideas of what constitutes the “community” and what community really means, but ultimately this is correct. The odd thing here is that before the Conventional Wisdom list was started, there was no single public forum where members of the community at large could discuss what they want to see in the CFML language. So if innovation and progress in CFML is truly driven by the community, they now finally have an outlet.

Setting the Record Straight

Now, for the corrections.


“Matt claimed the OpenBD team was too unorganized to submit tags like CFJAVASCRIPT and CFSTYLESHEET (tags I had hope to include in CF9).”
Pure FUD on multiple levels. I may have said something along the lines of “These tags were added on a whim last week,” but that’s how open source projects work. If Alan or Andy get an idea, or need something for a project they’re working on, they’ll create the tags and release them in a nightly build. We then get feedback from people actually using the new features and refine as needed. That in no way means the OpenBD team is disorganized. It differs from proprietary software development, sure, but calling that process “disorganized” would be the equivalent of me calling Adobe “lazy” because they only have a new release every two years. Apples and oranges.

CFJAVASCRIPT and CFSTYLESHEET were added to OpenBD, and Adam’s response when he found this out was apparently to take it as an affront because we didn’t run the idea by the committee first. Adam seemed to continually and conveniently ignore the fact that OpenBD is an open source project, so Adobe or anyone else can see what we’re doing every step of the way.

Furthermore, it was agreed upon by all members of the committee that tags and functions developed in specific engines would be brought to the committee only if their creators wanted the language enhancements to be considered as “core” in the CFML specification. We didn’t consider CFJAVASCRIPT, CFSTYLESHEET, and some of the other innovations in OpenBD as “core” CFML, so we didn’t officially submit them. But again, the source code is open. If Adobe saw something in OpenBD they thought made sense to be core to CFML or to add to ColdFusion, they could have brought it up and we could have discussed it.

And let’s talk about what “submitting a tag” to the committee even means. I’m not sure what exactly I was even supposed to “submit”–the tags were out there in the OpenBD source along with documentation as to how they are used, so wouldn’t it make sense that if Adobe was interested in considering those tags for ColdFusion they could read the docs and ask about it on the committee list? If you get the sense from Adam’s post that there was some rigorous formal process that OpenBD was somehow subverting, don’t. There was no such defined submission process in place.

Finally, the “tags I had hope[sic] to include in CF 9” bit is completely bogus. Yes, Adobe did make some changes to CF 9 (specifically CFSCRIPT if I remember correctly) based on the committee’s recommendations, and I applaud them for that, particularly given that CF 9 was nearing the end of development at that point. They ignored plenty of other recommendations, and the reason for that–the real bottom line here–is that CF 9 was largely baked by the time the committee was even having these discussions. So to point a finger and say CFJAVASCRIPT and CFSTYLESHEET didn’t make it into CF 9 because I failed to make an official submission to the committee is false on numerous levels. We didn’t consider them to be core to the language, the code and spec were available from day one, and adding this new functionality to CF so late in the development process likely wasn’t going to happen anyway.

“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.”
Again, this is how open source projects work. Did Adobe expect that the open source engines will stop following the process that is best for their projects and users, and hit the brakes on the rapid pace with which new features are added, to ask the committee’s permission before making enhancements to their engines? Does it not make sense–and ultimately benefit Adobe–if the open source projects introduce new features to CFML and let the community kick the tires before finalizing the feature? That saves Adobe time in the future if they decide to implement these features, because a lot of the questions surrounding the new features and how they should work will already have been answered.

I’m at a loss to see what the real issue is here. OpenBD and Railo are both open source, both have nightly releases, both have public roadmaps … everything’s always available for anyone to view. I think ultimately this comes down to a culture clash between open source projects and proprietary products, which was probably partially to blame for the failure of the committee’s efforts.

“As a community, we never needed the OpenCFML board to guide or document feedback.”

I give this one a “thumbs sideways.” We didn’t need the CFML Advisory Committee specifically to serve this function, but I don’t see Adobe doing anything to foster open language discussions in a public forum either. Perhaps that isn’t their job; they focus on finding out what their paying customers want, and no one can fault them for that. In similar fashion the open source projects get continual feedback from their users and make changes accordingly.

I do think it’s important that there be some avenue for people to discuss CFML as a language in an engine-agnostic way, however, but that was as simple as creating a Google Group. It’s a much better solution and will yield far better results than the committee ever would have.

“I really want to thank Ben, Rob and Ray for the work they put into the OpenCFML.”

… but no one else. Not Sean for making valiant efforts to keep things going even when the committee was at its lowest points, and not any of the rest of the people who participated far more than anyone from Adobe, and particularly Adam, ever did. If anyone questioned Adam’s real attitude towards the committee that statement pretty much sums it up for me. He was never interested in setting politics aside and working collaboratively to create a CFML language spec, and apparently the only efforts that matter are the ones made by the people in his camp. “You’re either with us or you’re against us” has been proven to be a very divisive attitude, and it’s one that ultimately isn’t good for the community as a whole.

“As far as I am concerned, the ColdFusion ACPs will be the CFML Advisory Panel for ColdFusion X and beyond. We’ll be asking them to review and sign-off on all of our language enhancements (very soon).”


So this at least defines what “community” means to Adobe, and helps to illustrate that they never had any interest in helping to define CFML as a language outside of their own product. That’s fine, and makes perfect sense coming from a proprietary software company, but leads me to the conclusion that the CFML Advisory Committee was a PR stunt to begin with. Adobe’s heart was never in it, they were just trying to get out in front of the open source CFML revolution.

In Summary …

The goal of Adam’s post is patently obvious: to blame everyone but himself and Adobe for the failure of the CFML Advisory Committee. His rhetoric sounds almost McCarthy-esque. Get people focused on a common enemy–real or imaginary–and they’ll become oblivious to little things like logic and the truth.

Let me be clear: Adobe’s lack of participation and paranoia over the supposed malfeasance of Railo and OpenBD are, from my perspective, a massive part of what killed the CFML Advisory Committee. I’d have a lot more respect for everyone involved if we could have collectively decided to end the effort, made a joint statement, and parted ways amicably. But for Adam to post a truth-challenged version of events out of the blue, while not surprising, is in very poor form.

And That’s All I Have to Say About That
I’ve said my peace and then some at this point. Feel free to comment, and if you have any specific questions you think I can answer, I’ll be happy to do so. If, however, your comment is of a “he said/she said” nature or intended solely to inflame the situation further, don’t be surprised if I don’t respond. Adam gave his version of the story, I’ve given mine in abundant detail, and everyone can continue to speculate on what went on behind the closed doors of the committee. If you care to, anyway. I’d certainly hope you have much, much better ways to spend your time. 😉

To me, it’s not worth dwelling on all of this. The CFML Advisory Committee will go down as an interesting side-note in the annals of CFML history, and people looking back will wonder why we even tried in the first place. I’ve been asking myself that very question for quite some time.