Just thinking about the issues of generating exposure for the Lucee platform and possibly attracting new devs. There should be a concerted effort to cross-link - people/orgs linking to the Lucee homepage, docs, etc. Links from Lucee wiki, etc. to blog posts with relevant information, etc. Cross-linking will drive search rankings and help generate traffic.
That’s a good start but not necessarily enough on its own, but we could all help generate more awareness about Lucee through content generation that breaks out from just Lucee. I have been writing blog posts lately about Lucee and various other things. One of them in particular, about my shell script to stop and start Lucee and Nginx:
has generated over 50,000 views since I originally posted it in late February, and it is still generating a lot of traffic everyday. I figure some of that traffic is related to people looking for Nginx scripts, but I don’t know how much is Nginx-related and how much is Lucee-related. I am going to continue blogging in that vein - mixing subject matter like Nginx and Lucee, jQuery on the client with Lucee on the server, etc.
As for why Lucee, that’s my entire point about pushing performance. A new Lucee dialect is a positive move. Add better tooling - IDE, text editor plugins ( good to see that in motion already ), and you have a good case for Lucee, but not quite a compelling case. Rev up performance and I believe you have a compelling case for Lucee over other platforms. Components of success:
1. Lucee IDE and plugins for text editors
2. Engine re-write targeted at generating optimized Java code for maximum performance
3. A successful web site using Lucee as a showcase
What about a project to generate an optimized Java version of Coldbox or FW/1? That would provide an immediate boost to sites running those frameworks without trying to optimize any and all CFML code. Is that still too big a scope?