I don't think this is the right place for this question, mainly because we don't attract the right crowd, but I'll answer this anyway. This is more of a long comment.
Making a general-purpose file format is quite hard, mainly because a format designer has two considerations:
It should be easy to implement a program that exports data into the format.
This is critical, as having no exporter means no adoption of the format, so the format dies if this criterion is not satisfied.
It should be easy to use the format for both importing and exporting.
Ease of export is governed by:
- how well the features of the format match your start application's features
- how easily the application's features can be converted to generic entities
Ease of import is governed by:
- how few features you need to implement
- how well the generic entities match the source application's requirements
The standard way to ensure both goal 1. and that there is a good match between source app features and file format facilities is to implement many features. This is poison to the importer writers. So, if easy to use means easy to export, then its usually a bad thing for the importer.
The other way to solve this is to deconstruct a higher-level data structure into something generic, but this may reduce the utility of the format for the importer. Some feature of the source application may be lost on the way. For example, you might end up with a triangle mesh instead of NURBS surfaces or baked animation instead of F curves.
Ultimately, import/export questions will only ever get solved when all applications use the same features. Application developers don't actually want that, as it would limit their scope of innovation.
Alembic solves a different problem from COLLADA
COLLADA tries to solve the problem of exporting assets into game developer pipelines. So, COLLADA is used as a sort of serialization routine for OpenGL. As such, the core of COLLADA is not really super useful for a movie data migrator. COLLADA's problem is that it's too much for everyone.
Ideally, you would want to export the scene graph and computation history, but this can only work as long as the inner workings of the 3D apps are harmonized. If you limit yourself to a subset of what your application can do, then its pretty easy to get a clean transfer. The bogeyman lies in the cool and unique features of your application. So, the moment you start doing something truly complicated which pushes the envelope, it becomes a hard task to migrate the data.
Alembic solves the problem of how to export massed volumes of geometry so you don't need the scene graph. This is useful for movies as you get all you need. But, it is of limited use for game programmers.
Neither Alembic nor COLLADA really solve my problem. That is not to say they don't solve any problems. Simply supporting the sheer amount of different possible data is complicated. But, I'd like to sidestep this problem because I don't have the resources to implement it all. On the other hand, I need the unique features of the scene graph.
Alembic has a better approach than COLLADA for its use case, but I don't have enough personal uses under my belt to say anything useful beyond this.
Will they work for you?
Depends. If you need geometry that is simple polygons, a few UV maps, and a few channels of shaders, then both Alembic and COLLADA should work fine, as should FBX, perhaps even OBJ or PLY.
If you need animation, then you would need to decide whether you need the source animation data — F curves, motion capture data, etc. — inside your destination application or if you just need the baked geometry for each frame. If geometry is enough, use Alembic. In movie/art cases, it's more efficient and can handle even complex scene graph changes because it's essentially a geometry cache. Otherwise, you need either COLLADA, FBX, or a custom exporter.
PS: COLLADA is not the first verse of the song. More like the fifth.
