Fusebox at the crossroads (again)
August 7, 2009 · 10 Comments
Fusebox is the oldest application framework for CFML and it's gone through a number of dramatic changes over the years. Initially it was more of a methodology than a framework and it was really only with Fusebox 3 that it solidified into a full set of core files and what we traditionally think of as a "framework" these days. Fusebox 4 was a complete rewrite and not backward compatible. Fusebox 4.1 added some interesting new features and then Fusebox 4.2 (previewed in 2005) never appeared. It was a bit of a dark period for Fusebox with no progress being made and some awkward politics behind the scenes. In 2006, I was asked to take over the project and I insisted that backward compatibility be maintained, despite another full rewrite. The result was Fusebox 5, but not without yet more political drama, mostly behind the scenes. In order to move forward, Fusebox shifted out of the control of The Fusebox Corporation and under TeraTech's benevolent guidance. I almost had to fork the project to make that happen. Initially, TeraTech were very proactive and they organized a large survey of developers to find out what they wanted from the framework as well as supervising a complete overhaul of the website. The result of the survey was Fusebox 5.5 - and the no-XML option. The website was a huge improvement but support dwindled before the documentation could be fully overhauled. I made a minor point release and began planning Fusebox 5.6. I wasn't using Fusebox in any of my projects, however, which made it difficult to push ahead solo, without input and guidance from the project owner, TeraTech. The community were happy with the framework and only a few enhancement requests were coming in. Adam Haskell expressed interest in becoming more involved so I handed over the role of lead developer to him and he settled in, making small enhancements and starting to plan for the future. Like me, he found little input or guidance from TeraTech and, because of their disinterest, also found it hard to get traction on any real change. Well, just as I almost forked Fusebox three years ago to get Fusebox 5 released and the framework moving forward, Adam is now on the brink of forking Fusebox to get things moving forward again. When this issue cropped up in 2006, lots of discussions led to the previous project owners agreeing to hand off the project to a new team. Adam has made the same request of TeraTech. I hope they take the same path and allow the framework to move on. Otherwise, what we know as Fusebox today will remain stagnant and the code will resurface under a new name and development will continue anyway, leaving TeraTech with an outdated legacy. That's one of the great things about open source: you can never close it down and you can never lock people into a single vendor. If you have any opinions on the future of Fusebox, feel free to comment here or on Adam's blog post - and feel free to talk to either of us at CFUnited next week.