ColdFusion 8 includes LiveCycle Data Services 2.5, and the instructions we've provided on getting CF to use the about-to-be-released LCDS 2.6 leave much to be desired. Joshua Rodgers has written a superb step-by-step post on getting this all working. [Via Ryan Stewart].

Luis Majano has announced that he has partnered with two other companies to offer ColdBox Platform Official Training Seminars - 16+ hours of intensive hands-on training.

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 ever 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.

Charlie Griefer has written an article for Packt Publishing entitled ColdFusion 8-Enhancements You May Have Missed. Lots of nice little goodies in this one.

This morning, during the CFUnited keynote, we announced that ColdFusion would be made freely available for educational use (including students and faculty). The program is modeled on the Adobe Flex Builder 3 Pro for Education program, and will use similar distribution and similar eligibility and verification requirements. This is a really important program for ColdFusion. For starters, there is real interest in teaching ColdFusion, and we definitely need new to be training new developers. But additionally, there is significant interest in teaching RIA development in colleges and universities, and by making both ColdFusion and Flex Builder freely available for educational use, both ColdFusion and Flex benefit. We had hoped to be able to announce the immediate availability of this program, but the process is taking longer than we had hoped, and is not available yet. So, bear with us a bit longer, and watch for an announcement within the next few weeks.

I am in hiding in my hotel room here in Washington, D.C., working on tomorrow's CFUnited opening keynote. If you're attending, don't be late. We have a couple of really important and exciting announcements to make, and some really cool demos too (assuming we can actually get them working by then). And shortly, with any luck, I'll head down to the bar to look for familiar faces.

In recent years the U.K. has become home to an impressive array of ColdFusion related events and conferences, and among the list is CFDevCon 2008 in Brighton, England,on September 25th and 26th. I am not going to be able to attend this one myself, but seeing the agenda and speaker lineup I wish I could. Check out the CFDevCon 2008 website for yourself.

cflib.org has long been one of the premier ColdFusion resources, a vast collection of all sorts of user contributed CFML user defined functions. And Ray Camden has just relaunched cflib.org with a new sleek look, and a great and snappy UI.

Last year we introduced dedicated ColdFusion account managers in the U.S., and they have been so successful that we've been working on doing the same for other regions. And Europe is at the top of that list. In fact, last year, at MAX in Barcelona, we hosted a ColdFusion BOF, and the lack of local ColdFusion presence and understanding (within Adobe Europe) was identified as the single biggest concern for local ColdFusion users. So, after much searching, we have finally brought our first European dedicated ColdFusion representative on board. Please join me in welcoming Claude Englebert to the ColdFusion team. Many of you already know Claude, he's been part of the ColdFusion community for many years, and some of you met him in Edinburgh last week. For any question and concerns ColdFusion related, Claude is your man in EMEA. His e-mail address is cenglebe@adobe.com, and he is blogging at http://www.englebert.be/blog/.

Last week Gert Franz, CEO of Railo, announced that Railo 3.1 will be open sourced, that the new LPGL2 licensed project will be hosted at JBoss.org, and that the JBoss community will be contributing to the enhancement of core functionality. I've known Gert for a long time. We first met in Zurich back in 2001, and out paths have crossed repeatedly over the years. Gert has always been professional, respectful, and forthright, despite the fact that he had created a ColdFusion clone (and thus was a competitor). Gert has repeatedly demonstrated his commitment to the ColdFusion community, and has made a point to never be antagonistic or divisive, and to always be open and honest, despite us being competitors. In fact, before he made the announcement last week, he requested a meeting with the ColdFusion team leaders to give them advanced notice and to chat about positioning and the future. He even asked me to eyeball the joint JBoss Railo press release, just to make sure that it contained nothing objectionable or unnecessarily divisive. I'm not a fool, and I know that Gert's actions are not entirely altruistic - at the end of the day he has a business to run and needs to do what is in his business' best interests. But at the same time, he has gone out of his way to balance those interests with those of the community in general. He has never badmouthed ColdFusion or the community, he has never tried to sell his product by putting down ours, he has never actively tried to drive our developers away from the core platform, and he's always tried to sell his product on its strengths, playing fairly and honestly. And that's not something that I can say about all of the players in this space. Could the JBoss Railo relationship impact ColdFusion sales? Yes, of course it could. So why am I not worried about Railo's new announcement and direction? Why do I think that this is actually a very positive direction? Because unlike some other relationships, this one does indeed have the best interests of the community at heart. Neither Railo nor JBoss see ColdFusion apps as legacy, and they don't see their only business model as in converting ColdFusion developers to Java or to .NET. Rather, they see the value that is CFML and the ColdFusion community, and they want to enhance it and expose it to the wider Java community. Which means that very realistically this relationship could significantly raise ColdFusion and CFML awareness, and could enhance ColdFusion's reputation and visibility, and could even help grow the size of the community and the number of deployments. And at the end of the day, if that were to occur, then the entire community would benefit, including ColdFusion and its customers and users. So Gert, I wish you and your team much luck on this new endeavor. And I am looking forward to working together with you to further the interests of our respective companies, while at the same time ensuring a thriving future for ColdFusion and the ColdFusion community.

Simon Bailey has posted an example of how to communicate with ColdFusion from a PureMVC Flex client, performing a query against a remote CFC.

At Scotch on the Rocks this week, Adam Lehman and I chatted about ColdFusion, Flex, and LiveCycle Data Services (LCDS for short). We spent quite a bit of time on the latter because when I polled the crowd of 150 or so, only 3 raised their hands when asked who'd looked at LCDS. That's a shame, as LCDS is tightly integrated with ColdFusion 8 and can even be seamlessly installed along with ColdFusion 8, and few ColdFusion developers have taken the time to figure out the value that LCDS bring to the table, and especially the value of the Data Management Services. Which is why we spent time on the subject in Edinburgh, and why I focused on it in recent presentations in D.C., Toronto, Atlanta, and more. So I was really pleased to see that Adobe TV posted my Understanding Data Management Services session today, it's not ColdFusion specific, but it does explain the basics.

Steve Drucker has posted a recorded Connect session showing how to create a PDF form (using LiveCycle Designer) containing controls which are powered by a ColdFusion backend.

I just arrived in Edinburgh for Scotch on the Rocks 2008. Adam Lehman and I are presenting an opening session in the morning. And as soon as he gets here we'll figure out what we're talking about! ;-)

Over the years there has been infrequent but ongoing discussion about ColdFusion pricing. Some feel that the price is too high and that lowering it would increase product use. Others believe that the product has been priced far too low, and that raising it would increase respect among analysts and industry experts. Some want it given away, free or open source. Others have asked for changing versioning, and including a free option. There are lots of suggestions, and lots of opinions. And contrary to what some seem to believe, we actually do spend a considerable amount of time trying to figure all of this out. I have my own opinions on the subject, but am not going to share them here. Rather, because this subject has come up again recently (along with the assertion that the ColdFusion product team just does not get it and is making all sorts of terrible mistakes), I thought I'd share with you some of the debate and thinking that goes into this discussion. Creating software is expensive. Companies spend hundreds of thousands of dollars, often many millions of dollars, creating and maintaining software products. So what would possess a company to take all of that time, effort, and money, and slash the price or just give it all away? There are lots of reasons for doing so, and a long list of companies and products who have indeed done so (with varying degrees of success). But in general, the decision to give away a product falls into one of three categories:

• A company may become uninterested in continuing to create or maintain a product. This may be because of changes in company strategy and direction, or it may be because of market changes and evolution, or it may be because the product was failing, or it may be because the product had simply outlived its usefulness. There are lots of reasons and motivations. But, at the end of the day, if a company is no longer interested in marketing a product, they may opt to just give it away (or perhaps open source it) as opposed to just dropping support for it. Doing so can help the company save face, and perhaps the product could actually thrive and be granted a new lease on life (although history has shown that in reality this seldom works). A perfect (or perhaps imperfect) example of this is Allaire Spectra, a product that started off life with one set of goals, but which then morphed into a product that was poorly positioned, terribly misunderstood, and not overly successful. When Macromedia acquired Allaire the entire product line was scrutinized, and Spectra was dropped as a product. But, there were (and still are) some customers using Spectra, and so rather than just abandon the product, Macromedia open sourced it (and then promptly totally ignored it).
• Sometimes company and product strategy necessitates product realignment, and that often includes positioning and pricing changes. At times this is planned, other times this is in reaction to market and trend changes. Product pricing is a tough balancing act, underpricing a product can be as damaging to the product as overpricing, and so companies constantly revisit and refine pricing decisions. A great example of this is Flex which was originally created as a server and priced accordingly. And then Flex 2 was reinvented as a compiler, with supporting tooling and an optional server, and pricing and packaging changed accordingly. And pricing has been tweaked some more since then. Flex 1 was targeted at a few large organizations, and the pricing and packaging reflected that. Flex 2 became a developer centric product, targeted at the masses, and so the revised pricing and packaging changed to reflect this new strategy. Whether the original Flex strategy was correct or not can be freely debated, but is rather irrelevant. What is more relevant is that the product team made the changes that they thought necessary, changes that appear to have been exactly what was required.
• And sometimes pricing decisions are less driven by the product itself, and more by some larger consideration. Does anyone remember Allaire ColdFusion Studio? Many do, and many still use that product. But what many don't know is that product never made money. So why was it created and sold? Because it helped sell ColdFusion. The tool was a loss-leader, sold at a loss to help drive greater revenues in total. In the case of ColdFusion Studio, financial success of the primary product drove pricing considerations pertaining to a lesser value supporting product. Another example is BlazeDS. Previously Flash Remoting had been sold or included in other commercial products. But increased used of Flash Remoting is critical to the ongoing success of Flash as a platform, and so Flash Remoting and core messaging functionality was open sourced as BlazeDS. Here previously sold software is being given away to better solidify the core platform. And open sourcing the codebase has an additional benefit in that it helps developers better understand communication internals, and may also help in porting the code to support other back-ends. Similarly, the decision to open source Flex SDK but to charge for tooling represents a strategic decision that dictated packaging and pricing thinking. In other words, pricing can sometimes be driven by high-level strategic thinking, including completely rethinking revenue generation models.

So, everything from company direction to market trends to product strategy and more all can, and do, impact product pricing and pricing changes. (And before I get accused of open source bashing, let me make it quite clear that I am not talking about projects or products that start life as community or open source initiatives. Those have a very different motivation, a very different life cycle, and a very different definition of success. Both open source software and commercial software have their place and legitimacy. There is value both, and I respect the right of developer communities to build and manage their own destinies as much as respect the right for commercial software vendors to profit from their endeavors. My comments here are not about open source itself or the open source movement. What this is about is making the shift, transitioning from commercially sold product to unpaid or dramatically reduced product, including becoming open source.) Now back to ColdFusion. Do any of the pricing motivations enumerated above apply to ColdFusion? Let's see. ColdFusion remains a critical product, and is a core component of Adobe's development and RIA platforms. In fact, Adobe has demonstrated a far greater commitment to ColdFusion than Macromedia ever did! No abandonment at all here. So the first category does not apply. But what about strategic pricing changes? Do current trends or market situations warrant price changes, either up or down? Is there a strategy change that is needed that could help the state of the business? Adobe has strict policies that prohibit the sharing of actual product specific numbers. But we have stated repeatedly that the ColdFusion numbers are really good. And former Adobe CEO, Bruce Chizen, was quoted in an interview as saying that the ColdFusion numbers are the best they've been since Adobe took over the product. When product sales remain solid and predictable and reliable, then pricing changes are extremely risky, and must only be considered if there is overwhelming evidence that doing so would improve the business, and not hurt it. This involves determining perhaps, as an example, whether a 50% drop in product price would result in a 100% increase in product sold, which is what would be required to match existing revenue. And both priced drops and increases must be scrutinized. Sometimes the market and environment preclude pricing changes even when they might be necessitated. As an example, ColdFusion MX cost us more to build than any other version of ColdFusion to date, but we did not raise the price then (even though we truly needed to) because the market and environment would not have tolerated the change. It works both ways. But at the end of the day, particularly in regards to lowering prices, if a product is not selling well, then pricing changes become more appealing. But ColdFusion remains a highly successful product, and so while all strategic and growth options are up for consideration, there really is not an overwhelming necessity to immediately slash ColdFusion pricing. Which brings us to the third category, changing pricing models or high-level strategy. For example, one suggestion that has come up occasionally is to give away ColdFusion and sell an IDE. This is a compelling idea, but one that thus far has been impossible to cost justify. Assuming that a tool would sell for a 10th of the price of ColdFusion Professional (and perhaps a 50th of the price of ColdFusion Enterprise), we'd need to sell a massive number of tools to not massively harm revenue. And our research (yes, we do research this thoroughly and extensively) does not in any way suggest that this could work. At least not now. Is it an option in the future? Perhaps. As already noted, market and environment changes can absolutely impact product pricing decisions and options. There are no shortage of options. Do we create a free entry level version of ColdFusion, and if so what would the impact on the business be (both positive and negative)? What about giving away ColdFusion Professional and making up for the revenue shortfall by raising the price of ColdFusion Enterprise? Should we do away with those two editions and create one that is priced somewhere in the middle? What about giving copies away free for education (as Flex Builder does), what would be the revenue implications of such a decision? Should the product be open sourced, and if so how would revenue be generated to be able to sustain a development team? What about the cost of the OEM technologies in ColdFusion, can they be removed to lower the cost while still maintaining product value? Can that tooling strategy be made to work? What can we do for ISVs who want build products on top of ColdFusion, what can we do to make them successful? Lots of options. And few are inherently right or wrong, they all have pros and cons and these must be evaluated and debated clearly and unemotionally, while keeping the state of the business in mind. And yes, I did say while keeping the business in mind. For those of us who've been involved in ColdFusion since the early days, there is a lot of history and emotion and passion involved. And that's wonderful, it's what makes the ColdFusion community such a, well, community. And part of my job has always been to create and support that community. But at the end of the day, the domain name is adobe.com, not adobe.org. And at the risk of sounding like a pro business capitalist pig, the other part of my job is to ensure that the ColdFusion business is a healthy one. Because if it were not so, we'd not be having this discussion at all. No shortage of opinions. And you are free to share your opinions too. But keep these facts in mind ... It costs a lot of money to create and maintain ColdFusion. Slashing product generated revenue, or giving the product away, would likely mean that we'd not be able to afford to pay a team to build new features. Could the community take over? Perhaps, and that has to be part of any discussion. There are individuals who are very price conscious, for whom ColdFusion's price point becomes a real obstacle. But these individuals are a minority. Truly. Talk to our sales reps, those who actually sell ColdFusion every day, and they'll tell you that price is just not an issue. They don't lose sales over price, not anymore (ironically, it was more of an issue years ago). For what it's worth, the biggest issue is when some CTO or outside "expert" mandates some new policy or decision that excludes ColdFusion. I am not dismissing those who find the price prohibitive, but they truly are the minority. And the proof of that is, as already stated, that ColdFusion is selling really well. Having said that, there are indeed smaller organization, or contract developers who worry about the costs they pass on to their clients, who do worry more about initial cost (as opposed to total ongoing cost). Many of these are the ones advocating that we give ColdFusion away for free. Although when I ask them if they give away the work they do that is built on ColdFusion, my question is usually met with an incredulous glare. Still, we do need to accommodate these individuals. Which is why we do have the less expensive edition, and which is why we made sure that per CPU pricing allows multiple cores and multiple virtual machines, and why we've been providing hosting companies with very aggressive pricing options so that they can afford to offer ColdFusion at competitive prices. Although, one hosting company recently told me that even if we cut their prices they'd still charge more for ColdFusion than they do other options because they have found that they can indeed charge more and that ColdFusion customers will pay more. It's the free market at work. The bottom line is that all options are on the table and always are. We make price changes when appropriate, both up and down. What made sense in the past may or may not make sense in the future. And we constantly reevaluate the options available to us. And as we work our way towards "Centaur", you can be sure that we're having this debate all over again.

Remember the ColdFusion Exchange? It's been languishing and suffering from neglect for a while. But ColdFusion team member Ahamad Patan has taken over Exchange moderation and is committed to reinvigorating this resource.

UK based Software Editorial magazine has published a detailed review on ColdFusion 8, and concludes "Companies choose ColdFusion to create complex and robust mission-critical applications for internal and external access. While there are a number of ways to integrate web content with relational data, it is a simple task with ColdFusion, and the support for modern technology (Ajax, .NET and Java) is a valid reason to consider using this product." The review wraps by saying the product has "So many positives" and as for negatives, "None I could see. While the price seems steep, even small companies shouldn't have an issue with the price when considering the tools and functionality that the product offers." I couldn't have said it better myself!

The winners of the 23rd Annual SIIA Codie Awards have been announced, and ColdFusion 8 has won the award for "Best Web Services Solution". Other Adobe winners are Connect for "Best Collaboration Solution" and Captivate for "Best Collaboration Solution".

Yesterday evening I presented a session on data services at a Flex Camp in Toronto. I ran through a series of demos (and run over time, of course) and several attendees asked (repeatedly, both during the session and afterwards) for me to clarify which needed Data Services and which didn't, as well as which needed LiveCycle Data Services versus those which could use the free open-source BlazeDS. And so, in the order that they were presented:

1. Basic HTTP calls via <mx:HTTPService> - nothing special needed on the back-end, any server or app that can respond to HTTP calls can be invoked this way, and this is definitely the crudest (and generally least preferred) form of integration.
2. Web Service calls via <mx:WebService> - nothing special needed on the back-end, if you have code that is exposed as a Web Service, then the Flash Player can invoke it (although this generally does not perform as well as the next option).
3. Flash Remoting via <mx:RemoteObject> - this obviously requires a back-end that can respond to AMF requests, if you are a ColdFusion user than you have Flash Remoting built-in and so nothing more is needed, if you are a Java user then you'll want to install data services to give you this functionality (either BlazeDS or LiveCycle DS will do), and if you are using some other back-end then you'll want to look at community and 3rd party offerings (as a rule, use this option over Web Services).
4. Messaging via <mx:Consumer> and <mx:Producer> - this is what powered the chat apps and real-data push updates, and this does require data services on the back-end, and either BlazeDS or LiveCycle DS (including the LiveCycle integrated into ColdFusion 8) will do.
5. Data management and synchronization via <mx:DataService> - this is what powered the synchronized data editing screens (including pushing updates, conflict resolution, auto-commits, and more) and this requires LiveCycle DS on the back-end (sorry, BlazeDS won't do for this one).

Long time ColdFusion developer and community member John Farrar has written ColdFusion 8 Developer Tutorial which is due to be published in August 2008. Congratulations John, it's great to see another ColdFusion title, and I can't wait to see a copy.