Several weeks ago, I thought I’d try and rally a group of people (to my mind, ‘key’ and ‘active’ sursounders… about 10 of them) to try and put together a specification for integrating Ambisonics into Vorbis.
I had no idea of the difficulty of this task until it was well under way.
The aim was to by-pass the sursound (mail list) style of endless debate and quickly produce a smart, solid, reasonably-future-proof specification that the Vorbis-dev people could implement.
I’ve been trying to put my finger on exactly why this is such a challenge. I have to say I have a re-newed respect for the open-source communities who put together projecs like Linux. How do they make consensual decisions and move forward?
The challenge, I have come to believe, is that
- participants all have different expectations from the exercise (sometimes personal, sometimes strategic), and
- that there must be some kind of ‘responsibility hierarchy’. Decisions have to eventually land at someone’s feet, to be able to move forwards.
Not all decisions can be consensual. The challenge is then to not lose participants along the way.
Aaron Heller suggested that such technology-defining exercises _must_ begin with a clear and concise definition of the expected outcome… thereby aligning the participants expectations. He postulated that there are 2 ways to go about defining a technology, or a format.
- technology-push. For ambisonic file formats, that would translate into: “how does ambisonics want to be represented in a format” and
- application-pull. In our case, that would be “how can we deliver streaming ambisonics over the Internet”
This little effort has clearly been ‘application pull’.
What matters is that someone sitting at home can go to a web page, hit ‘play’ and get an ambisonic file to play over their cuboid speaker array.
Its all about getting ambisonics ‘out there’ and it doesn’t matter what the internals of the format looks like. Pure application-pull.
The best way to get a group of super-smart contributors to move forwards on this, I have realised, is to constantly go back to the stated goal: “The goal is to deliver ambisonics over the internet, how does the suggestion of … affect that goal“.
Its been a huge learning curve for me. We are not there yet, but I think the effort is starting to bear fruit … if we can just continue on the current path for perhaps an other week, I think we will have a convincing and implementable spec.
I should note that an other extremely difficult decision was the decision to limit the membership of the group. This was not done because it was thought that certain sursounders would have bad input … it was done because by limiting the numbers, it would be easier to reach consensus and move forwards. Maybe this has been the wrong decision. Given a more explicitely stated goal, it may have been possible to parse greater numbers of input and still move forwards.