A system that "eats its own DogFood" by consuming some of its own results (outputs and/or services), possibly in a recursive and/or compositional fashion.

Examples:
* A good framework tends to evolve by actually using its own parts to provide broader and deeper functionality.
* databases that use themselves for storing meta-information (schemas, for example)
* systems that use their own output as input later on
* version control tools that have to version control some of their own information as part of the user services they provide
* bootstrapping systems which compile/process themselves in more primitive forms in order to iteratively produce the more mature form (somewhat like a multi-pass cycle, but it's recursive)
* modeling/semantic languages like UML that uses their own constructs to model the meaning and relationships of those constructs. 

There may be two levels of "dogfooding" going on in such a system: The obvious one is that the developers of the system are actually using it (the developers consume what they produce); The other one is that the system is actually using itself as well (the system consumes what it produces -- similar to the bootstrapping mentioned above). I believe ''system dogfooding'' always implies ''developer dogfooding'', but not vice versa. The above are examples of ''system dogfooding'' (the system consumes itself). Examples of ''developer dogfooding'' might be:
* developers of debuggers using the product to debug itself,
* SCM tool developers using their own tools for version management and change control of the SCM project,
* testing tool developers using their wares to test their wares, and
* CASE tool vendors who use their own tools to model/animate those tools or generate some of the tool's own code.

All these examples require some BootStrap''''''ping to get to that first working version of the product before it can be used on itself, but afterward the product is used for itself (though its not always the same as the product using itself).

When a system eats its own DogFood, it helps show the viability and credibility of the system by showing that it can successfully rely upon the very same outputs/services that are "allegedly" of utility to its intended users.

-- BradAppleton (originally posted to patterns-discussion list in Sept'97)