As noted above, yum is in an extremely active state of development. Volunteers are writing a GUI for yum to make it in some sense auto-documenting and simpler for novices to use. The primary developers periodically ask the yum list for ideas for new features (although since most of those list members are systems administrators using yum to manage entire organizational-scale networks, they have not in the past been shy about requesting new features without prodding and often accompany the requests with patches to facilitate their addition). Bleeding edge participants can access the latest development snapshot of yum, which is updated as often as several times a day. With this sort of energy, it should come as no surprise that yum has an ambitious future.
Things on the yum TO DO list include:
Kickstart (and Red Hat's interactive installation tool) are in many ways lovely tools but they have one major flaw. If they are interrupted at any time after the system configuration has been selected and the package installation process is begun, they have to be rerun from the beginning. Since they can take quite a long time to complete (installing whole gigabytes worth of programs and data over channels that might be as slow as a DSL link supporting tens of kilobytes per second) there is a significant window where the system is vulnerable to interruption. Also, as a pure matter of convenience, one might wish to be able to "use" (or otherwise work on) a system in its basic configuration while its customizing packages are being uploaded and installed, especially if the latter will take hours to complete.
Yum will eventually (soon) permit these two steps to be completely separated. Indeed, this could be done now, but not easily as a ``prepackaged'' process. One will be able to kickstart (or interactively install or an install based on a PXE ramdisk)) a very basic system - one with "no" packages but the basic/default package - and then use yum to "finish" the install to bring it up to a predefined standard. If it is interrupted in the middle, it can just be restarted - yum will not duplicate or waste any of the work it has already accomplished but will just chug along until it is finished. In the meantime, the system can be worked on or with as it will be bootable and usable after the initial very short pre-yum installation process.
Making yum work at the source level is very exciting indeed. If yum were able to retrieve RPMs and their dependencies as source RPMs and automatically begin building and installing binary RPMs starting at the bottom of the dependency trees, it would be possible to do away with binary rpm support to whatever extent one desired. A system install could begin with a basic system plus the associated compiler, and then (with the help of yum) build itself. This would make it more or less impossible to build systems with problems associated with incompatible binaries or libraries, as those problems would be revealed and resolved at the source level and corrected in the primary repositories almost instantly.
This would not, in fact, consume an inordinate fraction of a system's resources to do. The smallest disks currently being sold are order of 40 GB in size, more commonly 80 GB or more. Caching a local copy of source and binary RPMs on a system occupies a modest fraction of that that will only diminish in time, and with yum one would only actually retrieve what one actually wanted to install.
This represents a genuine paradigm shift, and might well completely alter the way Linux and GPL/open source software in general are distributed and supported. A Linux distribution would become little more than a collection of source RPMs, with tools that would convert them into a binary RPM repository for convenience sake in a matter of a few hours. Provided only that metadata descriptions are sufficiently robust to cope with the network of revision dependencies that can exist between source RPMs, in short order the same basic set of source RPMs would represent stable Linux across all distributions.
To conclude, yum has already begun to alter the installation and update paradigm used to scalably maintain RPM-based Linux computers, but it in a sense has only begun to do what it is capable of doing. In the near future, yum and its contributed extensions may well alter Linux itself, and by extension the Internet itself, by providing a simple way of network-distributing arbitrary software in source/package form. Even compact disks are now proving clumsy as ways of moving around the many gigabytes of tools and data associated with a fully functioning Linux system, and at best they represent a base from which to work that necessarily must be kept up to date and patched in any event. The network will of necessity be the mechanism for this process of updating in the future, and yum is the best tool to emerge to date for supporting the entire process.