I reply as a middleware and tool developer, not as blender developer. This may not be the place, but I believe my concerns also cover what Blender is doing. My problem with OpenCollada:

1) It's way too big, and most apps don't need to either import or export most of the format. Take a look at my Python exporter, which does most of the job and it takes much fewer lines than even an interface with OpenCollada. It's a lot of code to add to a project/repo and enlarges the binary unnecesarily. 2) A strong point for using a library such as OpenCollada is proper validation of the incoming DAE files. However, in the real world, it's easy to find sightly broken files that you would rather import anyway than being format nazi and refuse the import. Being honest, not even OpenCollada plugins for MAX and Maya open their own DAEs most of the time. 3) It's been a lot of years and I still can't understand why there is such a good support for MAX and Maya, and zero Blender support. Aren't Khronos and ithe companies it represents supposed to fund and/or encourage adoption of their format, yet the most open of the 3D modellers does not support the most open 3D format? 4) Collada is an open format, but most apps that support it export their data in different but valid ways. An example of this is the export of skeletons, the usage of the inverse bind transform, how named/vs unnamed bones are used, etc. Most apps that wish to import Collada don't work internally like Collada and already have to do an important effort to guess what the DAE layout looks like. OpenCollada is just too "general purpose" and does not help this situation. Back then, other implementations such as FCollada provided several tools that aided in the guesswork or provided data the way it was meant to, so at least you could save writing some code or doing some guessing. 5) I don't think blender should have "yet another DAE importer/exporter", but something custom tailored to it's needs. I already wrote several Collada importers for middleware or propertary game engines and can attest that most of the work is not really importing Collada itself (what OpenCollada does), but guessing how the Collada file is laid out and how to translate that to the way Blender works. Using a large library such as OC only adds an unnecesary layer of complexity at the simpler part of a problem. 6) Collada is a very outdated format at this point. There is no support for constraints, material support is still really poor (still no official support for normal mapping or displacement mapping, let alone any sort of node-based materials), multiple texcoord support is broken because each app exports it any way it wants, and many other issues. This could be solved simply by going the FBX way and exporting blender-only extensions (besides the standard stuff) in a DAE, describing the full blender material or something, so importers can do the best at guessing, and save artist time from having to reimplement materials all over again when importing. I'm not sure how well can OC do this. Exporting custom properties is also really useful.

Cheers