That was exactly my reasoning.  If we use `__init__`, subclasses need to be *very* careful to use `super` to upcall, and even then there are still subtlties.  Also, this method has a return value.

I suppose I could implement `ShellMixin` as a subclass of `BuildStep`, but I have a visceral dislike of how that worked out with `LoggingBuildStep`.  I think that the mixin model is a bit easier to reason about: users are writing a build step (so subclass that), and need some shell-related behaviors (so mix that in).  I think the big win is that it avoids ambiguity about any methods that `BuildStep` recommends overriding in subclasses, but which `LoggingBuildStep` then overrides and discourages *its* subclasses from overriding.

It also gets away from the idea of the parent class implementing `start` or `run` and calling hook methods for the subclasses -- that got a bit out of hand with `createSummary` and `evaluateCommand` and `commandComplete` and lions and tigers and bears.  With the mixin model, the user is responsible for writing `run`, and can do just about anything there, with the most common behaviors supported by easy-to-use mixin methods.