It makes perfect sens !

Eventually, yes, although I believe, please correct me if I'm too realistic, a great number of people have come to rely on the old way of doing things, develop things, doing business.

The conclusion I draw is we need some sort of transitionary, translationary document, to nudge the critical mass of participants close enough to the edge/sweet spot, where they themselves takes the leap of faith I can see implied in your post.

Transparency, exactly, spot on !
Only IMHO, we need "glue", in the form of projects, processes, big picture people and
a shared language to get there.

Consequently, I'm not that interested in Tribe *in itself*, but I'm very interested in what can be done together with people I'm meeting through Tribe.

The situation right now, is people trampling all over trying to be the first to code, implement, execute.
This will create a confusing period over the next two years, as the players try to define the playing field, setting defacto standards, or at least get a significant part of the action.
I'd like to see us putting some effort in languaging, implementing, prototyping and executing a shared language, then we could open source this for the benefit of all the coders out there that could run with this to the immense benefit of us all.

Sorry, got a little evangelical there,
but honestly, this can be done,
we have all the necessary ideas, insights, building blocks and patterns from which to build this.

Through putting some months into a shared language effort, we could actually leap-frog
across the otherwise seemingly inevitable two years of code-standards-implementation-usability confusion.

Put my notions into whichever context you'd like,
RDF, XML, OPML, API, FOAF and you'll discover the actual business confusion, driven by the desire for recognition of individual efforts.

So again, to return to your very insightful post,
"enabler" is the exact right concept,
and, we need a framework from where we can execute on our enablements.