It would be really cool to have a "Summer of NHibernate" like webcast series where you start with a new project and build on it using NServiceBus. Start slow and explain the decision process. Have it grow into a full fledged sample project and provide the source code at each step. I believe this would help a lot of beginners and could act as a great source of documentation.

I don't like building new solutions on top of closed-source proprietary implementations and protocols. I noticed that amqp or any of the implementations are not on the todo list when I think it should be at the very top. Pub/Sub messaging is best left up to the broker/infrastructure. It would also nServiceBus a lot of value if it could be run completely on *nix os's.

add this serialization to the bus! ;)

NServiceBus would be even more valuable if it could be used on Windows Mobile devices using Compact Framework as a first-class citizen, allowing mobile devices to publish messages and act as receiving service endpoints. Windows Mobile does support a compact version of MSMQ.

In a similar vein, Silverlight support would be great. The .NET subset in Silverlight and Compact Framework is pretty close.

I read somewhere that Udi does not have the time to write an NServiceBus book but there are many in the community that would love one. My solution is have Udi outline the chapters and assign them to members of the community. All the results could be posted to a central repository for his approval. I realize there is documentation in Wikis and blogs but it is scatter all over the place. For me my main resource for learning is an ereader and having a single document is key.

It would be nice to have a basic Profiler or status monitor. Something like Oren Eini has for his Rhino Service Bus would be nice or perhaps somehow create hooks into the NServiceBus to allow for one to be easily implemented and customized.

If NServiceBus is flexible enough to handle in-process, out-of-process, cross-machine and cross-cloud messaging, then it would be crazy powerful to use the same API for local service event aggregation and UI commanding as you use for communicating across the cloud.

I can imagine scenarios where in-process endpoints as well as remote endpoints could subscribe to some of the same messages.

Make it possible to listen to queue on a remote machine

I suggest to colaborate with appharbor and create a plugin for nsb & msmq

Be able to use Websphere MQ for the queue instead of MSMQ

Allow NServiceBus to use to max limit of the queue instead of limiting it to 4 Megs. On Windows Server 2003 & 2008 you can specify a value based on server resources.

Please update NServiceBus.ObjectBuilder.Unity.dll to support Unity 2.0

WIF and claims integration would be fantastic

It is very promising technology. Looks like it would be easy to implement. And it gives the NServcieBus a lot of improvement in a speed and the pattern variety.

1. Allow configuring nservicebus from app/web.config instead of fluent only (subscription storage).
2. Unify configuration - provide one configuration handler eg. "nservicebus" and allow configuring inside it endpoints, subscriptions, sagas, etc.
3. Use .NET convention and provide configuration with camel- instead of pascal- case.

It would be nice to have an Bridge implementation like you already have for Proxy and Gateway. This would allow for wiring up remote workers that can not use a Proxy or Gateway process at there location.

log4net recently switched to a new snk for signing their official DLL's. Version 1.2.10 used a private snk, while 1.2.11 now uses a different, public snk. We now have to do assembly binding redirection because NServiceBus relies on 1.2.10 while other 3rd party libraries we use rely on 1.2.11.

I found a ruby gem but I can't tell if it is part of the project or if there is any documentation surrounding how to use it.

I would suggest to use mode XmlConvert.ToString for dateTime, decimal, float types. Or at least use CultureInfo.InvariantCulture. Now if reading/writing processes uses different cultures like (en-EN and de-DE) it has problems with decimals. de-DE uses comma as floating point, and en-EN uses comma for thousand separator. This causes such situation: serialized 65,34 in DE culture is deserilized to 6534 in EN culture.