What lurks in the dark corners of the Castle
I had a chat with a pal of mine recently, about why he would recommend working with Web Forms over MonoRail.
The short answer was that he didn't want to end up with an ungooglable exception. The reasoning is that there isn't any nook or crany in Web Forms that hasn't been discovered, talked about, solved, and most importantly than all, indexed by Google.
I don't agree with this approach, but I recognize that this is a valid way of operating. The major reason that I don't agree with this is that I have run into issues with ASP.Net that were essentially un-googlable and undebuggable.
Castle currently has four or five major projects ( I was surprised myself, I expected it to be at least a two digit number ).
Learning each of them by itself is not hard, at least not in the "good enough to work with and learn on the job". Getting to a master level isn't any harder than in any other technologies, it just takes time and experiance.
There are certainly quite a few more experts in Web Forms than about MonoRail, but I find that I have to struggle to get what I want a lot less in MonoRail, and I get into far less situations that require the use of an expert. One of the core principals of Castle is that it should be simple. And by simple I don't mean the implementation, but the usage. It takes a minute to explain how SmartDispatcherController works, and any programmer can grasp how it can be used from three sentences. The implementation of the Smart Dispatching is quite complex, but you never need to see it.
One of the main differences between OSS and Commercial software is the amount of time that is invested in the frills. Active Record and NHibernate has a designer, which is nice, but it is not a level 1 priority to any of the people using either Active Record or NHibernate. The reason is that both those frameworks were built knowing that a designer is not something that you should need in order to work with them.
WebForms has a huge task on developing custom controls. Not only must the control play nice in the page life cycle dance, they also need to jump through many many hops in order to work in the designer. MonoRail's ViewComponents, on the other hand, are literally HTML generators, with no extra complexity on top of them. Again, the simple outward interface makes it easy to work with the frameworks.
Some of those things require a fair shift in thinking, but once you get comfortable with MonoRail, there is no steep learning curve until you get to Windsor integration, which simply require that you understand how IoC works. Instead, there is a lot of discovery going on, mostly with helpers, filters, and such.
Now, Castle's is built of many projects that are designed to be used independantly. But, they are also designed to work together. This means that the Whule Is Truly Greatly Than The Sum Of Its Parts. Taking Active Record, MonoRail and Windsor for a spin is a fun ride, but that require that you understand all three, and their interactions. The nice thing about it is that it is not that big of a jump from knowing them to working with them together.
To summarize, a basic working knowledge of Castle is probably something that you would want to have before you would start building applications with it. There are numerous getting started guides out there right now, which can help you grok what you are trying to do. I don't believe that you need an expert on hand to solve problems, looking at the forums or asking in the mailing list will usually get you the answers that you seek. There is also a lot of effort in making the exceptions detailed and self explenatory.
Naturally, I am biased, so I am not sure that my opinion in this matter counts, what do you think?