Talk:Multimedia Container Format
According to the edit log, this article was "based on the project's website." If that means the text was copied — which would explain its tone (first person, Behind the Music feel) — did the project license this text under GFDL? —Fleminra 02:57, 3 March 2006 (UTC)
Why did MCF fail
The failure of MCF is partially due to me being quite inexperienced at the time, working as the project leader, and I want to write my later thoughts about it as a warning for others. While it was quite unanimously accepted by the community that the project should be based on dictatorship (i.e. a project leader rather than votes on each technical issue) and my lead of it was not questioned, I did in many cases end up denying suggestions by community members and outsiders on the basis that the format should be kept minimal and perfected for a "version 1" release. Even though I had the support of the community behind me (with the notable exception of Steve Lhomme himself when he began pushing EBML), the fact that I and Steve were the only active developers at the time led to the known result of the community quickly shifting over when I was absent and Matroska was being developed rapidly.
My later experience, mostly with the Performous project, has shown that instead I should have permitted all those requests as experimental features, developed as separate branches and merged to the main specification once done, if the community agreed on them being useful. This kind of approach keeps the guys with suggestions happy while not disturbing the mainline development. If the feature turns out to be crap (like I most often suspect) or people lose interest on developing it before it gets finished (which I often fear will happen and ruin the entire project), no harm is done as the branch can be abandoned or deleted without affecting the main development. On the other hand, if the feature truly is good, the branch can be merged as a clearly beneficial development. This approach also makes people work harder on finishing and polishing their idea so that it would more likely get merged.
Another very important thing is that one should always release early, release often. For a file format this is somewhat tricky as then people might create files in the development format, making it harder to do any compatibility-breaking changes. MCF had a system to account for this: files of "version 0" should be considered a development version and players were supposed to display a warning dialog whenever such a file was encountered. The mistake of us was not making use of this feature and developing fully working software based on the early specifications. Not only would such software have done forking Matroska much harder (Steve wouldn't have had six months' head start with writing software) but more importantly it would have sped up the development due to less guessing about possible implementation difficulties and such.
In case someone wants to write about this on the article itself, feel free to. I will refrain from commenting there as that could be seen as a conflict of interest issue. Tronic2 (talk) 00:22, 24 September 2010 (UTC)