First I'd like to say that I'm stoked about the work the Prism team has been doing. I have to admit that when they started out in January to deliver a set of guidance for building composite WPF applications, I was skeptical. But they have come a great distance and I am truly proud to have been able to contribute to the effort as part of the advisory board. I think their work is a huge success for Microsoft and more importantly to the .Net community at large. I believe this had a great deal to do with their interaction with the community, their transparency, use of Agile methodologies and tons of unit testing to boot. I hope this becomes a trend for Microsoft.
With the first release of Prism right around the corner, I've been thinking more about what direction I'd like to go with Caliburn from here on out. Before I get into that, let me back up and talk a little about how Caliburn came to be...
Several years ago I started playing with WPF, building various little applications, experimenting and generally being impressed with the framework and having a good time as well. In 2006, the Microsoft Codemaster Challenge came along and CB and I decided to see how far we could take WPF by building an online multiplayer game. It turned out pretty well (enough to land us in the top 20 out of over 4,400 applicants world-wide) and we learned a lot about WPF in the process. Unfortunately we were unable to pursue are game development dreams at that time, and were forced into building "real world" applications. At that time (early 2007) I had begun experimenting more with UI architectures in WPF, originally inspired by Crevier and Gossman's blogs. There were certain command-related patterns that happened repeatedly when trying to build an MVP style design. These patterns often resulted in tedious boiler-plate code. To eliminate this tedium, I created the ancient ancestor of Caliburn's ActionMessage. I worked on this for a bit, improving it for my own use and eventually wrote this article, describing an early, crude version of the framework. I worked on this version a bit more and we eventually used it on a real project of ours, a smart client for a large state organization. Over the coarse of this project I realized a number of shortcomings, improvements and features I wanted to work on. In late 2007 I began officially working on what is now Caliburn by starting from scratch and building a framework based on a bit more real-work experience. In the early part of this year, I continued to add features and eventually officially published the framework.
A lot has happened since that time. Mainly, I've built more WPF applications, been involved with Prism and added tons of features and improvements to Caliburn. I've found advising Microsoft on Prism and working on Caliburn simultaneously to be a constant struggle. Some days I hated Microsoft for trying to build what I had already built, other days I was strangely relieved by the thought. I've found that running my small open-source project is quite challenging (props to the big boys who do it well) and have recently felt the stress mount.
Things changed for me the other day. I was looking through some of the Prism code in preparation for our regular meeting. I hadn't looked at it in a while due to the fact that I had to miss several meetings for scheduling conflicts. I came to their EventAggregator implementation and thought to myself "Dang, that's a really nice implementation." I looked at it a bit more and realized, "Hey, I like that better than my implementation!" Well, actually Caliburn has two different implementations that are completely different solutions to the same problem, but I like the Prism solution better than both of mine! I began to think about refactoring my solution, but then I though "Why couldn't I just use the Prism aggregator in my applications?"
This brings me to Caliburn's future. Lately I've been feeling that Caliburn has grown rather large and difficult to learn (something I criticized both CAB and Acropolis for). I haven't had time to fix bugs, document, test, provide an RI, etc. - and I feel like the project has gone out of focus. Also, when I look at Prism, I see a large overlap in features with Caliburn:
- EventAggregator - I actually like the Prism implementation better than mine.
- RegionManager - This is virtually identical to Caliburn's CompositionMangaer. No really, they are practically the same implementation. (I guess they took some of my advice.)
- Module Loading - This is also very similar to Caliburn.
As I have struggled with managing an open source project and wrestled with how to divide my time between features, bugs, etc. I've wondered "Wouldn't everything be easier if I just let Prism do what it does best and Caliburn do what it is good at?" If Caliburn supports a unique set of features, apart from Prism, and could be used as a logical extension to Prism, then I could focus on a smaller set of features, make sure they work well and are consistent, provide ample documentation and samples and actually get some decent test coverage. (Not to mention reclaim my home life...)
So, I'd like to get some feedback from you. I have no idea how many of you are using Caliburn our how you would feel about this change in direction. Please leave me a comment because I don't want to make a decision that is going to seriously cripple anyone. There are several paths I could take Caliburn and I'd love to hear what you would favor:
- Continue development as is.
- Shamelessly steel the Prism EventAggregator and replace both my implementations with theirs.
- Remove features duplicated in Prism from Caliburn - event aggregation, ui composition and module loading. Users who want these features can use Prism in combination with Caliburn.
- Take a hard dependency on the Prism framework and build on top of it. This would further reduce duplication and enable the two frameworks to work seamlessly as one.
- Scrap Caliburn, but take the unique features (like ActionMessage) and implement them as part of PrismContrib to better flow into the existing community surrounding Prism.
Honestly, I'm leaning towards 3, 4, or 5. I could easily move through these as a progression, one at the time. However, I want to be clear that I don't want to cause undue pain for those who are using Caliburn at present, so please leave a comment. If everyone screams "NO!" then we stick with option 1. But, the truth is, I really have no idea whether Caliburn has 2 or 200 people who are using it seriously and would love to find out anyway. Would a future with complimentary features between Caliburn and Prism be meaningful for you?
06-06-2008 9:24 AM