There has been quite a bit of rambling in the Blender community on the drop of external QuickTime support in Windows builds of Blender 2.58. Nathan Letwory, one of the release managers for the Windows platforms, explains the reasons behind the decision.
Hello Nathan! Maybe first tell us a little about yourself and your duties and responsibilities as a release manager for Blender.
Hi Gottfried. I've been a Blender developer since 2003, having started with bringing back the Game Engine on the Windows platform (those project files back in those days were a mess). Since then I've worked on many different areas of Blender, last tasks having been contracting for Blender Foundation (bug fixing, bug fixing and bug fixing), working on COLLADA support and recently setting up Studio Lumikuu - a studio around Blender.
I'm currently one of the Windows platform maintainers, and I create the official Blender binaries for the Windows platform. I generally keep an eye out on the development, ensuring everything keeps compiling and working on Windows as much as possible, shaking every now and then my virtual fist at GCC users. Much of Windows support translates into fiddling with our low-level library GHOST (events and application windows), working with file and path code (file manager, although Andrea W is the owner of that module) and wondering what to do with our installer (I think people should just get the .zip, extract it anywhere they have access to and run Blender from there - it's as easy as that, and no headaches with installers).
Who else was involved into the decision to drop QT support on Windows and how did the decision process take place?
The Windows platform maintainers discussed this and because of the reasons mentioned in the answer for the next question it was decided to drop. See http://wiki.blender.org/index.php/Template:ModulesOwners for the maintainer list (a great list, too, if you want to know who to contact for a specific subsystem in Blender).
Can you summarize the reasons for the drop?
For me the main reason was simply the incompatibility of the license of the SDK. It doesn't fit with GPL. And before anyone asks: no, I don't consider Quicktime to be a system library.
Next to that, it was available only in 32bit versions of Blender. With increasing adoption of Windows 64 it is not a very feasible path to continue with. To top it off, a user needed to have Quicktime installed to have it all actually work.
For a developer getting the SDK jumping through several hoops isn't fun either.
But the first reason simply outweighs any of the others. Perhaps sad, but that is how it is.
Is there a discussion about cross-platform alternatives to the features provided by QuickTime?
Not that I am aware of. I guess one could look at integrating a lib that handles GIF or PSD. For movie containers and formats there should be enough to choose from to satisfy most of the needs.
What do you think is the best way to solve compatibility issues with proprietary software?
I understand that ease of use is paramount to a great workflow, but it should be done in the framework of what we can and cannot do. The best way to solve such issues would obviously be to have proprietary software use the open formats, but that's probably more of a daydream right now.
I think writing up scripts to use external tools to do conversion and other data manipulation is currently the best thing to look at. With the recent addition of pre/post Render event callbacks it should be possible to automate already many things with that - convert, transcode, encode, auto-upload.
Thanks, Nathan, for this inverview!