The Lucee General Session at dev.Objective() 2015 in Minneapolis was a great overview of the philosophy behind the Lucee platform, the recent fork from Railo code base, the community custodian Lucee Association Switzerland and a roadmap for the future. Geoff Bowers (@modius), the acting LAS Secretary, took up the challenge of delivering the keynote.
Its rare for a thriving community to emerge around any open source project; Lucee is special. Japanese mummies are special; you had to be there 
One of the fundamental principles of open source is the creation of derivative works or forks. Lucee is a fork of the Railo 4.2 code base.
Geoff took the crowd on a personal journey about why he and his company chooses to develop in CFML, why supporting Railo was an important decision after years of loyalty to Adobe (nee Macromedia, nee Allaire), and finally why it was time to back the Lucee movement.
Is this a big "fork you" to the Railo community? Not at all.
The current custodian of the Railo code base has been unable to come to a consensus about the future of Railo. This has resulted in a paralysis of the code base; Railo 4.2 was released in Dec 2013 and despite ongoing minor patches there has been no significant contribution to the code base since that time.
Is it legit? Absolutely! The terms of the LGPL license the Railo source is released under allows anyone at all to create a derivative work. All of the original Railo contributors have already moved to the Lucee fork.
Will there be a Railo or Lucee commercial license of the server? No, it's not possible.
Everything in the Railo code base, and all the new commits in the Lucee fork are "early binding"; they must fall under the LGPL license. There is no enforced contributor agreement in place for the Railo code base, so the copyright associated with everyones commits is fractured. We would need the consent of all the individual contributors in order to re-distribute the code base under a commercial license, or even a different open source license.
It's not an act of bastardry or a Machiavellian plot. This fork is a labour of love; this is a rescue mission to bring the code base under a new custodian, better suited to our community's open source ideals.
Lucee Association Switzerland (LAS) is a Swiss Verein where member rights are enshrined in the Swiss Civil Code. LAS is a not for profit organisation run purely to further the development and promotion of the Lucee Server.
LAS Members are equals.
Each Corporate Member pays the same dues, and has a single vote on critical matters such as the Management Board and language development. Most contribute a considerable amount of resources over and above their Membership fees – but that's not necessary. LAS welcomes Members who just want to be a bigger part of the Lucee movement, even supporting anonymous Members.
The first six months has been a monumental effort to get the code base re-launched, the administration procedures in place, and the community back on track. It's exciting to be working with an ever growing list of members, enthusiastic about the future of CFML and the newly minted Lucee Language.
We're ready for new Members, and we're reaching out to any company building their business on CFML to lend a hand.
For LAS is all about the code. We want Lucee Server to be a modern day language of choice for web development. It's not about competing with Adobe, its about going head to head with the smorgasbord of web application languages available to developers.
Lucee 4.5 is already released and production ready. Many teams are rolling out onto Lucee 4.5 as a long awaited update to their underlying Railo 4.2 code bases. Anyone moving from another CFML engine, or starting CFML development for the first time should look to Lucee 4.5.
Lucee 4.5 is the engine that makes CommandBox 2.0 possible. The CommandBox CLI running Lucee is so compelling, there's talk it may become the promoted distribution mechanism for developer downloads. The range of installation options will always remain a feature of Lucee.
A lot of effort has gone into cleaning up the build process for Lucee, compared to the old Railo code base from which it has been forked. Building Lucee on a typical developer workstation is three lines in the terminal; clone it, check out your branch, and build it with ant.
Heroku build packs are now available for Lucee 4.5 and up. Push button Heroku deploys will follow shortly.
It's part of our overall focus on making Lucee more inclusive; making it easier for people to hack on the server and contribute at all levels.
For the most part it's business as usual. Upgrading to Lucee 4.5 from Railo in most cases is little more than a JAR change and a service restart.
The next generation Lucee Server (tentatively called Lucee 5) is in beta and under active development. We have a long ways to go until we're done, but already the results are impressive. Regular stable releases are being distributed to the developer community for review (or you can always build your own from the head of the branch at any time).
A lot of energy is being spent rewriting Lucee's underlying engine to build a foundation for future generations of Lucee releases. Critical to this strategy is the implementation of the JSR223 and OSGi standards.
JSR223 will give us options for running CFML and Lucee Language everywhere under the JVM; a templating architecture that will allow seamless integration at the CLI, and within other Java frameworks. Write shell and ant scripts, build out the view of your Play app, and more – all in CFML.
OSGi the de facto standard for the enterprise Java market; build extensions with versioned JAR dependencies, load/unload and hot deploy Java at run time. OSGi is the platform for giving true extensibility to the Lucee Server environment.
All these efforts serve to decrease the overall footprint of the Lucee server, improve its performance, and make it more universally deployable. Lucee is fast, lightweight and scriptable. The future of Lucee is not just on the server but in the cloud, pushed to your PaaS and on the command line.
Language improvements are not about dazzling the marketing department with reasons to upgrade. LAS means to persist with the constant modernisation of the CFML language. And where that is not appropriate, innovating within the context of the Lucee Language. For Lucee, performance is a feature that needs to be constantly improved.
CFML compatibility is a critical part of the LAS mission. Lucee 4.5 is the most compatible release to date. The next generation Lucee beta is already approaching the same levels of compatibility as Lucee 4.5.
CFML compatibility is about how Adobe ColdFusion defines CFML; nothing else. We're no longer going to try and evolve the CFML language that Adobe defines; we're focused on making existing CFML work and work well.
For the sake of clarity, we will never remove something from the Lucee CFML compatibility layer that will decrease our compatibility with Adobe's latest offering. Even if we choose to "deprecate" something, we mean simply that a better alternative exists.
Lucee Language will be the home for providing a modern web application development language in the JVM based on the principles of CFML.
If you are a CFML developer you will be right at home with Lucee Language. Its got the same fundamental principles as CFML but with modern best practices, and language improvements built in.
For example, full null support, sensible and performant variable scope cascades, variables local to functions by default and so much more. It's CFML minus the baggage of over a decade of backward compatibility, mistakes corrected, and modern approaches implemented.
Looks familiar!
Lucee Language already has the full range of CFML tags and scripting options – in most instances just replace the CF prefix with a ":" (colon) namespace. Lucee Language is in its infancy in the most recent beta releases, but its still very workable. We even have a release of the popular FW/1 framework up and running, written purely in Lucee Language.
Expect to hear much more in this space as the next generation Lucee Server nears release.