One of the standard knocks against systemd is that it keeps growing and expanding, swallowing more and more jobs and so on. I've come around to feeling that this is probably a problem, but not for the reasons you might expect. The short version is that the growing bits are not facing real competition and thus are not being proven and improved by it.

Say what you like about it, but the core design and implementation of systemd went through a relatively ruthlessly Darwinian selection process on the way to its current success. Or to put it more directly, it won a hard-fought fight against both Upstart and the status quo in multiple Linux distributions. This competition undoubtedly improved systemd and probably forced systemd to get a bunch of things right, and it's given us a reasonable assurance that systemd is probably the best choice today among the init systems that were viable options.

(Among other things, note that a number of well regarded Debian developers spent a bunch of time and effort carefully evaluating the various options and systemd came out on top.)

Unfortunately you cannot say the same thing about the components that systemd has added since then, for example the journal. These have simply not had to face real competition and probably never will (unless the uselessd fork catches on); instead they have been able to tacitly ride along with systemd because when you take systemd you more or less have to take the components. Is the systemd journal the best design possible? Is it the option that would win out if there was a free choice? It might be, but we fundamentally don't know. And to the extent that real competition pushes all parties to improve, well, the systemd journal has probably not had this opportunity. Realistically the systemd journal will probably never have any competition, which means that it's enough for it to merely work well enough and be good enough and it probably won't be pushed to be the best.

(Sure, in theory other people are free to write a better replacement for the journal and drop it in. In practice such a replacement project has exactly one real potential user, systemd itself, and the odds are that said user is not going to be particularly interested in replacing their existing solution with your new one, especially if your new one has a significantly different design.)

I would feel happier about systemd's ongoing habit of growing more and more tentacles if those tentacles faced real standalone competition. As it is, people are effectively being asked to take a slowly increasing amount of systemd's functionality on faith that it is good engineering and a good implementation. It may or may not be good engineering (I have no opinion on that), but I can't help but think that real competition would improve it. If nothing else, real competition would settle doubts.

(For instance, I have a reflexive dubiousness about the systemd journal (and I'm not alone in this). If I knew that outside third parties had evaluated it against other options and had determined that it was the best choice (and that the whole idea was worth doing), I would feel better about things.)

By the way, this possibility for separate and genuine competition is one good reason to stick to a system of loosely coupled pieces as much as possible. I say pieces instead of components deliberately, because people are much more likely to mix and match things that are separate projects than they are to replace a component of a project with something else.

(This too is one area where I've become not entirely happy with systemd. With systemd you have components, not pieces, and so in practice most people are going to take everything together. The systemd developers could change this if they wanted to because in large part this is a cultural thing with technical manifestations, such as do you distribute everything in one source tarball and have it all in one VCS repository.)

Sidebar: this doesn't apply to all systemd components

Note that some of what are now systemd components started out life as separate pieces that proved themselves independently and then got moved into systemd (udev is one example); they don't have this problem. Some components are probably either so simple or so easy to ignore that they don't really matter for this. The systemd journal is not an example of either.