Fork me on GitHub


Fusebox 5.6

FuseBox 5.6 - Project Plan

Vision for Fusebox

Fusebox is a free, easy to use framework for web development that organizes your code for fewer development bugs and faster maintenance. It has a low runtime overhead. It is mainly targeted to ColdFusion but also has versions for PHP and ASP.

Fusebox 5.6 is backwards compatible with versions 5.x and 4.x

Initial Goals
  1. Documentation of the Internals of the Framework
  2. We want for the community to be able to pick up an issue and do the work themselves. From there they could provide us with a patch that would contain the fix. In order for us to expect developers to do this. We need to provide some documentation on how the framework works on the inside.
  3. Provide Examples on how to fork and patch
  4. Create documentation on how to fork and submit a patch back to the main project.
  5. Write Selenium Tests and Applications to test against
  6. Write a couple of different small Fusebox applications that can be used to test the framework. After those are finished create some Selenium tests to test the applications given different versions of Fusebox. The overall goal here is to create a simple way to do backwards compatibility testing in combination with continuous integration. Also get some complete applications from the community to test Fusebox changes on.
  7. Document small initial performance improvements
  8. Go through the code and create tickets for small performance improvements that we can see.
  9. Improved error reporting
  10. Give better error reports when there is a mistake in one of the fusebox or circuit XML files that will help a user (especially a new user) see where the mistake is in their code.
  11. Continuous Integration
  12. Either a Jenkins or Bamboo server will be made public containing the results of the CI for the framework. All commiters will be on the notification list of failed or successful builds.
  13. Move project to github
  14. We will move the project to github to allow for easier forking and code management.
  1. Simplify
  2. Archive what is there
  3. Recognize the community patchers that have helped the most
  4. Figure out a way to connect with the community while keeping things civil
  5. The biggest parts of the site are
    1. how to get involved
    2. how to use the framework
    3. documentation wiki


The goal of the roles is to keep the organizational structure flat. While thousands of people patch to the linux project. There are very few that can commit to the core kernel. Seeing that Fusebox is the most prevalent framework still I don’t think we need an Evangelist or anything like that. Let the framework stand and grow on its own.


We will keep the commiters to a minimum. A goal would be to have at least 3 people who could commit but no more than 6. A commiter’s role would be to ensure code quality and that the changes being commited are in the best interest of the overall project. Major architecture decisions will be made by the commiters only after asking input from the community. Setup a voting process where the community could vote on major decisions before a major change is made.

A commiter codes for the best of the framework (not from ego), is responsive to community feedback, and has good attention to detail to ensure bug free releases.

Community Patchers

The community can contribute back to the project by creating patches and fixing issues

Community Documenters

These help improve the user documentation on the wiki. They are good at explaining concepts in simple terms and making items consistent.
Ideas for new development

  1. A way to configure the request to either pull a model file or hit a service layer
  2. tag libs for UI controls
  3. lots of examples for real world development
  4. Security
  5. SAML
  6. OAuth

Project Ownership and Copyright

The project will remain in the Apache License. The copyright will be removed as most modern project no longer need or have a copyright. The domain ownership will be transferred initially to John Blayter. The domain ownership shall only be owned by a commiter of at least 3 months. The rights of the domain ownership must be given up if 50% or more of the commiters vote to have it moved to another commiter.

Communication plan

who is saying what, where and when about the transfer? eg news on site announcing change. Post to mailing list(s). It will help you if (most) fuseboxers are behind the change. They will want to know how it will affect them and what will improve. A change FAQ would be helpful here. And I also suggest inviting people to help out as patchers or documenters. Explaining how they can join in. Don't want yet another repeat of the us vs them / insiders battles which we have had in the past.

Change FAQ

Q: Will Fusebox still be free?
A: Yes. Still under Apache open soruce Liciense

Q: Who will control Fusebox?
A: Anyone in the Fusebox community can make changes which will be committed to the code base by experienced Fusebox users (Committers)

Q: Who are the current committers
A: Please see the current contributors

Q: How can I become a committer
A: Yes you can become a committer but why don’t you start as a community patcher.