Happy Birthday OpenBD

Depending on how you look at it OpenBD is a year old or just about a year old (So the date is not exact but tonight at cfObjective we have BOFs which is when OpenBD went legit with its open sourceness 1 year ago). It has been a crazy year with adversity and acceptance. I was reading my Steering Committee interview (posted a little over a year ago now) and wanted to comment on a particular question in there:

Looking ahead 12months, what needs to happen before we can claim Open BD a success?

I think there are multiple criterion for success and we'll discover new criteria as we move forward with this project. At this point I see our first major milestone as being a successful point, or version, release that incorporates functionality suggested by the community, voted on by the committee, executed by New Atlanta (or others), and verified/accepted by the community. In order for us to claim success I think we also need to see company adoption of Open BlueDragon, and contributions to the project from the community. Not really even code contributions but help with documentation, tutorials and evangelizing the product. Nothing less than world domination really.

I have to say after rereading my success criteria I was pretty aggressive with what needed to be accomplished. I knew who was involved though and I have to say we have been a success! We have now had 3 successful releases (1 major 2 minor), including an awesome admin console built from the ground up. We have had functionality voted on/brought up by the community (some not from the ColdFusion community either might I add!) and subsequently added to the engine. New Atlanta (while never releasing the admin which I had originally hoped they would) has been active in contributions as has Alan and Andy (not part of New Atlanta). Lastly but certainly not least we have had an amazing community the google groups are active with questions, discussions, help and advice. We have a wiki that the community has helped publish content, and we have had multiple bugs submitted to us.

I think this year we could stand to get better organized, offer a better/clearer road map and communicate what we are thinking about working on next. This is a challenge because we have super intelligent guys working on this project and sometimes when they get an idea BOOM its done before we have time to talk about. Also I think something I didn't say but the intent was there is we should (and do) need to have a big focus on growing the CFML community. We'll probably never (as the small group of folks that we are with just enough scratch to buy some stickers for all 4 of our fans at cfObjective ;) ) grow the community 200k+ in 1 year like Adobe but I'd like to think we can contribute to growth as well. Are some of the folks using OpenBD as an alternative to ColdFusion, yeah sure it is going to happen. What I'd really like to do is for every 1 person we get from inside the community I'd love to add 2 from outside the community. That is a lofty goal, and quite honestly I don't see us fulfilling it. If I set our expectations high maybe we can achieve a more realistic goal: grow the CFML community not just the OpenBD community.


That being said if you are at cfObjective and you have played with OpenBD and/or are using it find me or Matt Woodward and ask us for stickers we got 'em and I know we'd both love to hear success stories, and pains.

CFML landscape

I had been meaning to publish this for a while but I decided to sit on it and wait for some of the dust to settle. I was eager to see exactly how many people would join the new Broadchoice Railo.

Now that Railo has finally opened up I think it is high time we take stock in the CFML landscape. What follows is how I view it with (of course) my personal twist/insight in each engine. I've tried to keep my personal commentary to a minimum, or at least hold it off till the end.

Open BlueDragon is GPLv3. It is the most open system with the most open development, though I think we could improve some. Anything that comes from OpenBD is GPLv3 or compatible. It is extensible but currently does not offer any store or other automated mechanism to add the extensions to the engine (though it is not hard and it is documented). So long as a commercial extension does not try to package and distribute the entire engine there are not problems with commercial extensions. Open BlueDragon is backed by a AW2, not New Atlanta. AW2's business model does not rely (primarily) on the CFML engine, though they do leverage it in some of their work from what I understand. When OpenBD was announced the project tried to gain confidence from the community by include some high profile names in the project steering committee (personal observation: BlueDragon had a bad name due to some old NA bad blood with Adobe and many were skeptical).

Railo is LGPL (sorry I can not remember the version I think 2 but maybe 3). It is mostly open. The core offers compelling compatibility and an astounding set of functionality. It is extensible via an app store type model where modules can be added onto the engine (I have not done enough looking to see if this is still manual or automated through the admin). Railo itself plans to make some functionality for pay. Railo the engine is backed by Railo the company and the business model s structure entirely around the Railo engine (services and product sales). Railo has positioned themselves inside the CF community as a competitor to Adobe by sponsoring CF centric events and hiring prominent figures in the CFML community.

ColdFusion is currently the most closed (in terms of source and openness to talk about what is being worked on). It is commercial and when you pay you get the whole kit and caboodle. ColdFusion can be extended through a couple of different means but not quite as tightly integrated as Railo or OpenBD at this point (the main extension point at the Java level is through CFX tags). ColdFusion is the original engine to use CFML and has gone through 2 acuisitions. It's a steady income for Adobe, they care about the CF community and do their part to keep it alive and happy (it is after all steady income for them).

To Adam Lehman's credit I think the information about CF9 has been much more open than previous releases. Don't take this comment too lightly this is a large shift for a large corporation. This comes from some one involved in many previous releases of ColdFusion and I personally see a huge difference in this release. The last couple of releases of ColdFusion have been driven heavily by the community. This is good but at the same time, the community is not full of big thinkers and typically we ask for functionality we need right now. This has resulted in stagnation of the ColdFusion platform, sure it has kept up but it has not PUSH forward much. Let's face it while Adobe (and Macromedia before them) have done a stellar job developing a great product the whole platform itself has sort of dwindled as they have focused on the language too much (not saying the platform has not grown it has but more evolutionary than revolutionary). The innovation seems to have slipped away and as a direct result we have multiple engines available to us now.

Ok now that I got my little side bar tangent out, which engine is right for you? I'm not going to make that decision for you, what is important (in Open BlueDragon team's eyes) is you have an option. We see that as possibly the most important part of being available, you have options. Each engine has compelling reasons to consider it for use. For me personally, in my development, I like the fact that I have complete control over the source code if I need/want it. I like that and that drives me towards OpenBD. For my company, we like a solid platform backed by a single entity and ColdFusion offers that to us.

Fusebox Update

As of a little before the posting of this blog fuseboxframework.org has moved onto a new set of tools to communicate with the community, trac.fuseboxframework.org will begin redirecting shortly. Firstly, and one I am very excited about, is the move over to our new Confluence wiki. Confluence is a very powerful wiki with an amazingly easy GUI to edit entries. My hope is that this increase in ease of use over trac helps the community provide more documentation, as it seems like this has always been sore spot in Fusebox. I also found there was some pretty good documentation already on the wiki it was just hidden, hopefully the (complete, and auto updating) Tree view on the left will help expose that wonderful documentation that has been hiding. I've still got work to do to improve the wiki but I felt that since all the (known/important) content has been transferred it's time for the new wiki to launch. Feel free to check it out (and bookmark it!):

http://wiki.fuseboxframework.org

Second up, and admittedly not as smooth a transition, is Jira. I've worked with Jira for a long time at my work and I enjoy the product, though I will say I enjoy using it a lot more than setting it up. I think there are areas to improve in getting the Jira site really humming but I do feel like I've made it far enough. Tickets can now be create anonymously, as can comments, I am still working on all the spam filter stuff though. I have made an attempted to transfer all outstanding tickets that may warrant attention over to the new Jira system. Unfortunately there was no good tool to transfer from Trac to Jira so I might be missing content. You can find those tickets in a different project. If you have a ticket you want priority that is in the Old Fusebox Project I strongly suggest recreating it or sending me a note to move it (I'll be more than happy to move it). The new ticketing system can be found here:

http://jira.fuseboxframework.org

SVN browsing is lagging behind but I do plan to stand up fisheye and I will be taking over the SVN repo in a short while. I want to thank Simeon for hosting Fusebox for such a long time, he's dedication to Open Source is really awesome. I felt it was time to take responsibility myself, I hope everyone enjoys the new tools as much as I do. I always interested in feedback, positive or constructive.

MXUnit ExpectedException

I'm glad to see the next minor release of MXUnit :) I'm even happier to see ExpectedException make it into the release. I'd been doing a lot of development in Java and using the latest JUnit and the expected exception annotation was so nice. When I went back to writing test cases for Fusebox I found myself avoiding writing tests that would throw errors (like testing bad paths for Fusebox parsed files). Well long story short I found myself one night debugging something in Fusebox only to find Fusebox should have been throwing an error. Since I never tested for it I never caught that Fusebox was not throwing an error. That motivated me enough to spend the 30 or so minutes it took me to write a couple test cases and add the functionality to MXUnit.

So the old way to test for an error was something like this:

      <cffunction name="ensure_error_on_load_extentions_with_bad_path">
           <cftry>
               <cfset extManager.loadExtensions(getDirectoryFromPath(getCurrentTemplatePath()) & '/notthere') />              
               <cfset Fail("Last line should have thrown an error") />
               <cfcatch type="mxunit.exception.AssertionFailedError">
                   <cfrethrow>
               </cfcatch>
               <cfcatch type="fusebox.BadDirectory" />
               <cfcatch type="any">
                   <cfset debug(cfcatch) />
                   <cfset fail("Bad Error")>
               </cfcatch>
           </cftry>
       </cffunction>

Now all we have to do is this:

       <cffunction name="ensure_error_on_load_extentions_with_bad_path" mxunit:expectedException="fusebox.BadDirectory">
               <cfset extManager.loadExtensions(getDirectoryFromPath(getCurrentTemplatePath()) & '/notthere') />              
       </cffunction>

I love the feature, and I hope others enjoy it too.