CFML has come a long way in over a decade. Over the years the language has evolved, sometimes gradually and thoughtfully, other times less so, but evolved it has. And Allaire/Macromedia/Adobe have, understandably, been the primary stewards of the language, fueling that evolution based on customer feedback, industry trends, as well as our own innovation. We’ve not always been successful (I have my own long list of CFML inconsistencies, gotchas, and the like, and others do too), but in general we’ve always tried to do the right thing, an almost impossible task. What is right for language purity is often not right for the masses, and what is right for the top tier of CFers is often not right for beginners, and what is right for our engineering teams sometimes is at odds with what is right in the expectations of our developer base. Still, all in all, I believe we’ve been phenomenally successful in creating a language that is easily learned and readily usable by beginners, while being powerful and flexible enough to meet the needs of the most technical experts.
But times have changed. For starters, as ColdFusion has grown more all encompassing (starting in CFMX), so have the demands on the language – new features need new language elements, and thus language proliferation. In addition, there are other engines that execute CFML code, engines that perhaps do things that ColdFusion does not do or does differently, and vice-versa. And while every vendor and player in this space should have the luxury to innovate as they see fit, the more they do so, the greater the risk of further fragmentation and inconsistencies within the language.
Which is why there has been talk for several years now of transferring stewardship of the language from any single vendor to a committee or consortium. In fact, I remember being asked about just this while on a panel at CFUnited (or CFUN as it was known back then) quite a few years ago. But that never happened, for two reasons. One reason is purely one of economics. Simply put, could the ColdFusion team afford to spend precious engineering time on an effort that would take resources time away from core development, while essentially only helping competitors? And back then the answer was no, not at all. After all, which feature in CF7 or CF8 should we have sacrificed in order to do so? That’s not an answer many want to hear, but it’s the truth, and it’s how I answered that question all those years ago.
But there is another answer too, and this is the answer I did not give because, well, frankly it would have opened up a Pandora’s box that I just did not want to have to deal with at the time. For different organizations to work together on a project that less directly helps their own interests while at the same time requiring a degree of cooperation that could legitimately further the interests of the others parties, one important ingredient is required. It’s called trust, and without it any collaboration between competitors is doomed, despite the best of intentions. And let’s be honest, there has been little trust between the various players in this space. No, I am not going to get sucked into gossip or mudslinging or a he-says-she-says, that’s beyond irrelevant. The only thing that is relevant is that if we are truly honest with ourselves we’ll have no choice but to acknowledge that trust between the various players has been nonexistent. And no trust equals no cooperation, it’s that simple.
So what’s changed? Why is now the right time to truly start cooperating in the bests interests of the language and community that loves it and relies on it, putting those interests above those of individual organizations and products?
What’s changed is that there are now players who truly do get along (as I noted in a previous post). Not that they did not get along previously, the relationships was always a very professional albeit neutral one. And that’s a good thing. It’s allowed for trust which has allowed for open communication which has allowed for the types of discussions that have not been possible previously.
And so at CFUnited this week we announced the creation of the “CFML Language Advisory Committee”, a small group who hopefully will come up with the guidelines and standards and recommendations that will ensure the long term viability and integrity of CFML. The committee is a work in progress, and the details of its objectives and mandate and workings still need to be hammered out. But it’s an important first step, and one that all involved are enthusiastically committed to.
In the interests of openness, and to ensure that no committee representation drowns out the voice of any other constituents, we were careful to not stack the deck in any way. The initial group of six is made up of two Adobe representatives, a Railo representative, and three community representatives.
And yes, there are stakeholders who are conspicuously absent from the initial committee. And as expected, that point was made by one of the first questioners after the announcement who wanted to know how the interests of other players would be represented. I answered the question bluntly and honestly, and tried to be as professional and measured as possible in doing so. And basically what I explained was what I already said above. Right now we’ve included those who respect the business requirements and necessities of the other players in the space, and those who have demonstrated a clear commitment to the community, looking out for its best interests. Of course, by inference I was saying that others are not meeting those prerequisite requirements, and understandably this has upset some.
But as I said before, the trust factor is critical. Here’s an example. Yesterday, during the keynote, Adam Lehman demonstrated some of what we are planning around Hibernate-based ORM support in ColdFusion “Centaur”. And as it so happens, Gert Franz of Railo has already stated that his team is working on Hibernate integration as well. Obviously, we need to work together. There is no requirement that we solve the same problems the same way, nor is there a requirement that the solutions be compatible. At the end of the day product teams should do what they believe is correct and in the best interests of their respective products and businesses. But we do need to work together as much as possible, doing so benefits the community and hopefully both of our eventual feature implementations. And that’s just the one public example, there are many others.
And that’s where the trust comes in. Not inviting some of the stakeholders initially is less about taking stands or punishing indiscretions or playing politics. It’s about trust and the reality that where there is a history of distrust the frank and open discussion that this endeavor requires will be utterly impossible.
That’s not to say that things can’t change. They can, and hopefully will. For example, when one of the players in this space spins off a standalone community driven open source initiative, that represents an opportunity to start over, to divorce from prior ill-feelings and built up distrust. Has that opportunity been realized? That’s debatable, and many have strong feelings on this one. And who’s right and who’s wrong is unimportant. What is important is that the fact that this is so hotly debated, the reality is that the trust is still not there. Not yet.
So, for now we have a new small and very focused “CFML Language Advisory Committee”, one that will hopefully start to contribute in earnest immediately, one that will start to realize benefits for all involved, including the community. And as I explained yesterday, the committee is deliberately and intentionally not stacked or biased in any majority direction, and so the ability to invite and include other stakeholders in the future is a definite possibility.
Yesterday’s announcement is an important first step, and one that I hope marks the beginning of a new era for CFML and for the community that has supported it for so long.
by Ben Forta