From Zikula Core 1.4 we have started using Composer and I've been asked to explain the reasoning behind this. Composer is a PHP dependency manager that has taken the PHP community by storm. It is vastly superior to PEAR for a number of reasons I will cover in this post.
Until recently, we've always stored vendor libraries directly in the core repository and it's always been a maintenance chore to update vendor libraries. Using Composer, one can just specify the libraries one depends on and it will not only go and download them for you, but it'll update the packages when there are upstream changes (all controllable). What this means for developers is you must manually run the composer command after cloning a repository and when the composer.json manifest is updated.
But that's not all, because there's also packagist.org which tracks all packages available in Composer (although Composer is not coupled to Packagist). This is great news for library authors because there is immediate exposure to the PHP community. All a library author needs to do is define a composer.json manifest in their Github repository (or any VCS repository for that matter) and then tell Packagist about it. From there on, others can specify your library with just a single line in your project's composer.json manifest.
Where the real magic happens however is they way in which Composer is able to solve dependencies. You might rely on just one vendor library, say "doctrine/doctrine-orm version 2.3.0" - with just that one require, composer will download and manage all the other requirements, like Doctrine Common, Doctrine DBAL, Symfony2 Yaml and Console.
Composer's last piece of magic is it's ability to autoload PSR-0 compliant library, and in fact, most non-compliant libraries also as it generates an autoloader specific to your requirements. Clever stuff!
Next time you get the source version of Zikula Core 1.4, please checkout the README.md for instructions on how to run Composer