A great debate has arisen about which init system should succeed the venerable System V init system in the popular Debian GNU/Linux distribution. See bug #727708 for details. The two main contenders, Systemd and Upstart, each provide a set of important features while each offering some limitations. Systemd is a Linux-only init system, due to its use of cgroups and other Linux-specific features. It has already been adopted as the default init system in several other popular distros, including Arch, Fedora, and openSuSE (1). By contrast, Upstart will accept patches to work with other kernels, like the kFreeBSD or Hurd kernels that Debian also supports. Upstart is only primarily used on Ubuntu (and its derivatives) and Google's Chrome OS (2). Below I will present some brief arguments for each system (this is not an exhaustive list, there are many more) and then draw my conclusion about which system I believe Debian should choose.
Upstart
Upstart has a small scope for what it tries to do; it is primarily an init system. This makes it easier to transition to, in that it is not deeply integrated with so many parts of the system. Moreover, the Upstart developers have said they will readily accept patches for compatibility with other kernels, which is valuable to Debian since it officially supports kFreeBSD and Hurd.
A disadvantage of Upstart is that Canonical, the company behind Ubuntu, requires that contributors sign a CLA in order to work on Upstart.
Systemd
Systemd started out small, but has grown to be an ambitious set of tools for core Linux services, more akin to a "kitchen sink" project than an isolated service performing a single function. To me this appears to go against the UNIX Philosophy, which advocates the use of smaller, simpler components which each work together. Moreover, one of the new components systemd brings to the table is its journal (called journald), which replaces the traditional syslog service for system logging. The new journald uses a binary log format which does provide many advantages (additional metadata, space savings, more sophisticated log rotation, and protection from intruders altering logs), however I am concerned that this makes the logging system more complex and obscure to use. If you want to read logs off of a hard drive written by journald, you must boot it with a live-cd or other system which also has systemd, rather than just any system with a text editor. I worry that this adds a barrier to being able to retrieve this often vital information from a system.
Conclusion
Although I have worked with Upstart more than systemd, I would advocate in favor of systemd adoption for Debian. I think it is important to look at Arch Linux, and their reason for adopting systemd to help formulate this conclusion. Arch's philosophy, called The Arch Way, defines how the distribution developers make decisions and what core values they include in the distribution. One of the core tenents is simplicity:
Simplicity is absolutely the principal objective behind Arch development. Many GNU/Linux distributions define themselves as "simple." However, simplicity itself has many definitions. Arch Linux defines simplicity as without unnecessary additions, modifications, or complications, and provides a lightweight UNIX-like base structure that allows an individual user to shape the system according to their own needs. In short: an elegant, minimalist approach.
You can read specifically about why Arch adopted systemd in this post. I think the fact that Arch, with values very akin to the UNIX philosophy, decided to adopt systemd should dissuade the concerns I have listed above about complexity. If Arch feels it does not violate the simplicity principle and provides real value, then I don't think these concerns carry weight. Moreover, Lennart Poettering, the original author of systemd, has listed some concerning limitations with how Upstart handles filesystem detection both during boot and after a system is running (hotplug). While I like the modularity and simpler design of Upstart, I do see the value in systemd's apparoach and think that ultimately it has more momentum and will be able to provide tighter integration for the system as a whole.
Regarding Debian's support of kFreeBSD and Hurd, I think it would be better for them to adopt the FreeBSD init system (and Hurd's implementation when ready). Although this means more work for the Debian developers, it will afford tighter integration with each system, which I believe to be very valuable.
In conclusion, it is great to see such a lively debate and more than one good piece of software to implement this important part of the Linux operating system.