In software development one is eating his own dog food when he is using its own product (i.e. the software he develops). I'm using Drupal for my personal website, so I'm eating my own dogfood. Drupal.org is using Drupal, so the Drupal community is eating its own dogfood. Many developers in the Drupal community, or the Open Source community in general, eat their own dog food.

There are a number of well-known advantages to eating our own dogfood: it provides evidence that Drupal works and that we are confident using it ourselves. Furthermore, as users of our own software, we help discover bugs and identify shortcomings. When developers are users there is plenty of incentive to fix bugs and the feedback loop doesn't become much shorter than that. For those reasons, eating your own dogfood is a common strategy in software development.

Now, in the May-June edition of IEEE Software (volume 23, issue 3), Warren Harrison provides some good arguments against excessive dogfooding:

In a market-driven industry such as software development, developers must understand not just their product but the products of others. It's the rare company indeed that can't learn something from its competitors. Engineers who use their own company tools exclusively tend to propagate all the bad aspects of their tools because they might not even realize an alternative approach exists. At the same time, they often fail to either understand or appreciate the good points of other companies' tools. I recall a discussion I once had with a well-placed manager at a dogfooding company I'll call "ABC Corporation". He snorted that it had been years since anyone at the company had read anything that wasn't marked "ABC Confidential".

New engineers who come into a dogfooding company with exposure to other toolsets are often forced by peer pressure to conform to the party line that all other tools are inferior and the company's approach is superior. Often, when hiring new engineers, managers consider exposure to other companies' toolsets as negative rather than positive. Some companies that proudly tout their dogfooding simultaneously display a surprising degree of arrogance along with a corresponding degree of cluelessness. It isn't clear, however, if the arrogance begets the dogfooding or the dogfooding begets the arrogance.

Maybe don't use Drupal for your next project and learn from that experience? Either way, make sure to dabble your toes in the waters of other systems once in a while! I, for one, enjoy chatting with Steven Noels from Daisy, I thouroughly enjoyed myself with Joomla, and time-permitting, I hope to dig deeper and to explore other content management systems as well.

Comments

oadaeh (not verified):

That sounds like very good advice and I can see it's merits, but there is another approach to achieving the same goals. I spent quite a bit of time pursuing a CMS system a few years back. Much of the time was spent in learning the system and it's configuration schemes, and then in learning how to get around it's limitations when it didn't allow me to do what I wanted. (Usually, the basic installation was quick and easy.)

When I found and started using Drupal, I pretty much shut the doors on all the others. The primary reason is: lack of time. I don't really have the time to keep up with all that goes on in Drupal, much less installing one of a hundred (or so) other CMS platforms. I do think there is value in knowing what other CMSs do and how they do it, but I also believe I can have that knowledge w/o going through the experience (and sometimes the pain), if I pay attention to what other people report and how they report it and how they get the information they use to report.