[Paul Dickin]"4.1.1 actually, which came Dec 2003 after a NAB announcement/demo and summer delivery of 4.0.0, which was broken out of the starting gate. I think there were two or three further unstable iterations, before 4.1.1 which worked. As FCP v4 was the first native OS X version it sort of paralleled FCP X's 64-bit/AVF first-versionness. And actually in your golden-glow hindsightedness you are really referring to v4.5, which took over 15 months to arrive after the v4 announcement."

Sorry, Paul, I was very unclear when I called FCP "mature." I didn't mean bug-free, or even feature-complete.

I won't argue your points on bug releases, but I will argue the arrival of major features. OS X support came in FCP3 [link]; while FCP4-7 may have been compiled for OS X only, they were still written against the Carbon API, which Apple introduced for OS 8 and extended through OS 9 and OS X. FCP Classic was never ported to Cocoa (OS X's native API). XML was introduced in FCP v4, as I stated.

Rather, I was trying to say that the internal architecture itself was pretty mature and stable by v4, in the sense that it was apparently seeing more maintenance than redesign. Even by FCP7, you could still crash with a KGCore error, even though the product hadn't been Key Grip since 1998.

This was a plus for third-parties, who had a stable platform to develop around, and a minus for Apple, who ultimately found it so limiting that they had to scrap it entirely and start from scratch with FCPX.

Architecture is important, and difficult. It needs to be stable (in the sense of unchanging) enough that others can develop for it, but flexible enough that it doesn't bind your hands as you try to add features to meet unforeseen needs. You need to balance forward potential against backwards compatibility.

Look at Apple and Microsoft to see two different (but both valid) philosophies on this. Microsoft has historically prioritized backwards compatibility, lowering re-development requirements on developers, but also slowing innovation. Apple's innovation comes at the cost of requiring frequent re-development, and Apple is very willing to pass that cost on to their third party developers.

Back to FCPX. It's changed enough under the hood since its release seven months ago to spawn two releases of XML and break Automatic Duck. FCPX 10.0.3 definitely represents progress over 10.0.0, and with much progress still to be made, I'm not suggesting that Apple should slow down. I'm just saying that the product and possibly its architecture is in a period of very rapid flux right now and represents a moving target for developers.

This in turn passes risk on to users for critical and basic workflow features like interchange. That's what I'd like to see a hybrid approach; let Apple take responsibility for the basic, industry-standard interchange fundamentals like EDL and OMF/AFF, but let third-party developers handle other workflow tools as Jeremy has outlined.