AMQP is real interesting. I like to think of it as "email for applications". It lets programs send "email" to each other.<p>You could do this using regular email, but regular email is hard to wire up to programs and isn't very flexible (eg. it's relatively hard to set up new email accounts).<p>With these messaging protocols, programs can just create channels for themselves and set up all sorts of interesting communications protocols -- eg. point to point, publish and subscribe, one to many etc. And it's (relatively) reliable so you know the message is going to get delivered.
I am a member of the AMQP Working Group and the OASIS AMQP Member Section. Last month we released the AMQP 1.0 protocol. This is something that we are really passionate about.<p>The one thing that has really held back the broad adoption of AMQP is the delay behind the release of the 1.0 version of the protocol. Now that we have this under our belt we need implementers such as RabbitMQ, StormMQ, Microsoft, INETCO etc to add support for AMQP 1.0. Finally, we need native AMQP clients installed by default and widely supported by OS and hardware developers, put simply, we need the full participation of the main operating system stack suppliers such as Microsoft and Redhat.<p>Luckily enough, both RedHat and Microsoft are members of the AMQP Working Group. I assume that they will release native clients and thus pave the way for broad adoption. It is the growth of pervasive AMQP clients and a strong and healthy developer community that will drive adoption and general acceptance of AMQP.
FWIW, AMQP is the preferred protocol of Celery, the python distributed task library; which we've been using it heavily for the past year at Crocodoc. I have nothing but praise for AMQP and RabbitMQ in particular in terms of performance or reliability.
Though nothing new, I see what they are trying to do: to bring enterprise messaging down to the masses.<p>Next year HN projects: Nxxxx.js, MxxxxxDB and RabbitMQ.