As with so much of the landscape of service-oriented architecture, large vendors with extensive marketing departments have tried to prescribe how their software should be used to solve specific problems instead of investing in the bigger SOA picture.
Software is the enabler for the broader SOA project, but you need to have a baseline understanding in place before software becomes practical. At a minimum you need to know the problem you are solving before you choose software packages.
Dave Linthicum blogged about this subject this morning:
The fact of the matter is that SOA governance, and governance in general, is really a people and process thing, with technology only coming into play to automate the processes and support the people. If you don't establish that, you're going to fail at SOA governance and thus fail at SOA, no matter how much technology you invest in.
I would push a bit further (without blatantly shilling) that SOA governance makes a lot of sense to be open source. Instead of forcing users into a technology, open-source tools allow them to manipulate the software to their business. And with frictionless distribution (meaning you can get the software without having to pay license fees first), there is an obvious appeal to enterprise users.
Contrary to what many people think, there are a great many SOA success stories starting to pop up (more on that later--I am doing a Webinar this week). We're now starting to get to the meat of solving enterprise problems rather than forcing models, stacks, and "an SOA" on users.
Disclosure: my company sells an open-source SOA governance product.