So its been a little over a week since I got back from devobjective and my mind is still processing everything I learned there. I like the new direction the conference is going, expanding to include other technologies. For far too long the trend with cfml dev's has been to ignore the rest of the world. Well I'm glad that the conference organizers realized that we can't keep our heads in the sand forever.

With that said, I actually dont feel a need to discuss all the new things I saw, instead somewhat ironically I want to focus on cfml today.

Adobe ColdFusion

Lets start with the elephant in the room, or in this case not in the room. Adobe was conspicuous in their absence at the conference this year. Not only did they not sponsor it, they had no stand, in fact they did not even send a single representative (that I ever saw anyway). Now I know that they have started their own cf dedicated conference cfsummit so maybe funds were tight...but to not even send one person?

Not only that, but I've been hearing of emails beings sent from adobe to some user groups saying that adobe was withdrawing support for them. Now what this means I have no idea since from what I've heard "support" meant an email every year to say keep up the good work, but it still makes me pause.

Now ColdFusion is not going away, I have no doubt about that. It is too big a cash cow for Adobe to walk away from, but that does not mean that its going to grow significantly either. Like cobol there will always be jobs in it, but I wouldnt count on Adobe pushing the language to new heights of popularity anytime soon.

Railo

Then we have Railo. For a long time development of Railo had stagnated with only minor patch releases for the past two years until a surprise fork this year created Lucee which I will talk about in a minute.

Staying on Railo for a minute though, everyone had thought that the fork had killed Railo until a blog post just a week before devobjective -message-from-the-majority-shareholder-of-the-railo-company . To say this post is controversial would be an understatement. Now everyone has an opinion on it, but for me three things are clear.

1. This post was made by a single shareholder who represents 1 third of the votes in the railo company without it seems the support of the other two.
2. Since then nobody has made any official followup to any of the questions posed in the comments.
3. A careful reading of the post implies a lot without ever actually stating anything actionable.

At this stage it appears to me that Railo is dead in the water and that despite this post nothing is likely going to be done to resurrect that project.

Lucee

Now to the new kid on the block, Lucee. Well it really is not the new kid. For all intents and purposes Lucee is just a continuation of Railo. It has the same developers that Railo had, it was forked from the Railo code base. Switching to it is a case of swapping out a single jar file. For all intents and purposes Lucee is the same product we have used for years.

So is anything different, is this really a big deal? Well the answer from my perspective is, it depends...

Technical Perspective

If you are a manager or a developer and are wondering if you should be worried about compatibility between your existing railo install and lucee 4.5 then the answer is no. Lucee 4.5 in technical terms is just a point release change from railo 4.2. Except for some extensions needing to be reworked it should get no more or less attention then any other railo update.

Contributor

If though you are someone who wants to contribute to open source, or simply is worried about the future of cfml then the answer is that yes Lucee is a big deal.

For me one issue I have always had with Railo was that despite technically being an open source project, it really was not run as an open source project. Contributing was possible, but nothing was done to really encourage it. Most (virtually all) of us were simply followers, waiting for the next release knowing it would bring great things but not really having a say in what the next features would be or how they would be implemented.

Railo development was limited to the resources of their small team and supported by the consulting business. This I believe was one of the biggest failings in how the project was managed because it was self limiting. With the best of intentions Railo could never truly grow because it could never get enough resources to do everything that was needed.

If you dont believe me just look at its documentation. With Lucee though the team has taken a much sounder track with the establishment of the Lucee Association.

Finally it is possible to directly support the development of Lucee, either financially as an individual or a company. Or as a contributor as a lot of work has gone into the build process so that now anyone can get up and running contributing to the code.

Growing a community

Finally for the first time in a long time we have a cfml engine that is not just something we license, but is an actual platform on which to grow the community. We can actually get involved and have a say in our future not just sit on the sidelines and hope that someone will get it right.

And its not just me who thinks like this. The whole conference had this buzz of excitement around Lucee. People were getting engaged and I know of at least 2 companies signing up to support it while at the conference. In fact there are currently 8 companies signed up as corporate sponsors and 5 as full members. That means Lucee has solid financial support so that its developers can focus on actually developing the language without splitting their focus.

The Future

Now its not all sunshine and butterflies, there is still a lot of work to be done. Which is why I am encouraging anyone and everyone who wants to to contribute. Its not just coders who are needed, testing and documentation is just as valuable if not more so. In fact in my opinion the biggest weaknesses that need to be addressed is documentation.

Railo always suffered from this problem that they would introduce a great feature but never document it adequately so something that needs to be worked on is getting the existing version of lucee documented with good examples. But again this is where anyone can now contribute with the newly released Lucee Docs.

Other Languages Help

It might seem odd but an other great way to help out Lucee is to go and learn a different language. Not only will you make yourself more employable, you will then be able to bring back that knowledge of how other languages accomplish things to Lucee. I don't see any reason we can't pick and choose good parts of other languages to put into Lucee.

So in conclusion, Lucee is here and now is the time for us all to get involved and support it. In the end its in our own best interests.