Should you Release Your Framework?

I think there are lots of good reasons to write a framework - the biggest being the learning experience. While it takes a lot of time, if you really want to "get" how a given class of framework (MVC, ORM, DI, etc.) operates and to understand the design decisions required, writing your own framework is the best way to do that. (Of course, there are also a number of questions to ask yourself before writing a framework if you actually plan to use it in production - it's not usually the best way to go).

But then I saw Sean's post and it made me wonder - what are best practices for deciding whether or not to release the framework you wrote (assuming you are open to doing so)?

Of course, if you want to release your framework, you can, but the question is (I think) whether your framework will add anything to the community as it could be argued that each additional framework takes a very small amount away from the community in terms of increasing the number of options and hence the difficulty of selecting a framework. Honestly, I am not sure that I buy this argument as I think most of the time more code samples and approaches are better than less. I tend to think more frameworks beat less and the market will figure it out, but I wouldn't argue against someone if they took that position as I can see how it could be argued that to cover the small mindshare cost of a new framework, it should bring something new to the table.

I think there are three types of new frameworks. Exact copies of a reference implementation, small modifications to existing approaches and different approaches to solving existing problems. For me there is little benefit in releasing exact copies, you should consider contributing to existing frameworks if you want minor modifications or reasonable extensions, and there is real value in releasing new approaches as whether or not they take off they introduce new ideas and approaches to the community.

I think there is the smallest benefit in releasing an exact copy of a reference implementation unless there is a reason that your implementation is substantially superior or a non-technical reason (support, documentation, speed of bug fixes, etc.) that will differentiate your offering. The perfect example, is that I may well choose to write an xUnit implementation in CF as a pure learning exercise just to *really* get this whole unit testing thing (Kent Beck says that one of the things he does is to write an implementation of xUnit in any language he learns as a way to get to know the language, and who am I to argue with him!). However, I personally would not release that as a framework as I like Pauls implementation and feel that the xUnit interface is sufficiently well settled that I wouldn't be bringing anything new to the table. If I did anything cool in the way I implemented it, I'd throw the relevant snippets up on my blog, but I don't see a hole in the xUnit space, so I wouldn't bother to release a competing framework. (I *do* think there is space for alternate approaches to unit testing such as implementing Design by Contract and that we are still lacking a good CF implementation of acceptance test frameworks like fitNesse, but that is a whole other issue.)

In terms of minor modifications, if ColdSpring met my general design goals, but I just wanted a programmatic config file, I would probably have contacted Dave and asked if he would mind if I write such as thing and would have offered to contribute it to the framework if it added any value. Similarly, if you see that Transfer or Reactor, MG, M2, ColdBox or FuseBox *almost* meets your needs, drop a line to the core team asking if they might be open to you adding an extension to the framework. Often the answer will be no if it doesn't fit the vision, but I think it is a good idea to at least ask the question.

As a side note, it would be interesting to hear more about how Model-glue came about and to hear the arguments from the "don't add new frameworks crowds" about whether they feel Joe was right to release MG based on the criteria they use for determining whether a new framework is valid. (In case you haven't guessed, this is because I feel a lot of the "don't release a new framework arguments" are bogus - I like Mach-II but am *very* glad we also have Model Glue and I think Joe has added amazing value to the community with the project). For me Model Glue is actually a pretty good example of why competing similar frameworks are good. It may be a little confusing, but I feel that the CF world would be poorer without Model-Glue, but I guess that is just my opinion! I suppose if you were *really* into the "we have enough frameworks" mindset, you could ask why Mark released Transfer rather than contributing his amazing caching code to help with some of the performance problems Doug was running into with Reactor last year. Again, I'd personally rather see the two projects than the one, but maybe that is just me . . .

However, if you want to do something fundamentally different from an existing framework (a page controller for MVC or a single cfc DI engine that can be easily packaged with small projects and that uses mixins rather than decorators to optimize DI into transients) I think it makes perfect sense to release it as a project.

To take some personal examples, in terms of MVC, I will be posting LightBase because it is (to my mind) a very substantial departure from FB, M2 or MG. To be fair, I didn't call Joe or Matt and Pete up to ask if they'd be open to me rewriting Mach-II or Model-Glue using Iterating Business Objects for input data type validation, object controllers with a "feature" level facade instead of events, to drop implicit invocation, to add explicit support for object based views and view compositions and to move to a page rather than front controller model, but I'm guessing it is safe to say that it might have been perceived as a bit of a change in the positioning of the framework and hence inappropriate :->

Equally with LightWire, I could have asked Dave and Chris if they would be open to me rewriting ColdSpring as a small, single cfc for easy packaging with sample applications, using programmatic rather than XMl configuration, and optimized for programmers who happen to like to make heavy use of DI into transients. However, it seems to me that replacing a framework with completely different code that is neither in the style of or relevant to the programming approaches of the core team isn't contributing to a framework, it is creating a new framework and it honestly didn't cross my mind to ask Dave or Chris if they'd be interested in replacing ColdSpring with a new implementation (and I can't see why they would given how cool, functional and powerful ColdSpring is already). So, I was a little surprised to be called out by Dave as not being a team player for starting a new project instead of contributing to ColdSpring, but I guess it takes all sorts . . .

Of course, if I'd just wanted to add programmatic config, I'd get where Dave was coming from, but I had a design requirement of a single cfc for easy packaging with small sample apps and a framework optimized for DI into transients. We all know ColdSpring is capable of DI into transients, but it is not what it was designed for and I can't think of any way of "contributing" to a project to turn it into a single, small cfc. Contributing is contributing and rewriting is rewriting.

You could ask whether the design decisions I chose are right, but that is not the point. As architects, we make design decisions based on our requirements and while it is perfectly valid and useful to debate such decisions, there is a place in any community for a number of tools solving similar problems in different ways.

So, to summarize, I personally feel that it seldom does much harm to just release your framework, but if there is an existing reference implementation that meets your design goals, consider just using that. If it is close, drop a line to the core team to see if they'd let you commit your mods (and make sure your design criteria are relevant for your project - not just a bogus reason to write a new framework). But if you believe you have valid reason for design criteria that preclude an existing framework (doesn't matter if your design criteria are right or wrong - popular or unpopular - most of the best frameworks seem weird when they are first released) then I hope you will release it as whether it ultimately becomes popular or not, both you and the community will be better off for it.

Thoughts?!