I'm probably the least competent (Perl-wise) of all the people who've already replied, AND I know little of the particular situation under discussion, so take this with a whole box of Morton salt. :) I do, however, have a degree in Sociology and Psych, so I'm going to take a NSH stab at it anyway.

I've seen meltdowns that were public, and meltdowns that were kept private, both in the open source and commercial worlds. Just as the emotions of the participants are their personal business, so are the choices to make it public. Most of the times I, personally, have been involved in a public meltdown, I've sure as hell wished it'd been kept private. At least, after the fact... ;-]

Wanting to learn what happened is only human. However, I'd like to suggest two things. First off, the technical issues on each side have almost certainly already been made public through ML discussions and web pages, et al. Secondly, let me suggest that you'll never really learn how to avoid a meltdown by watching. No matter how much fun watching a football game on TV is, you're going to get painfully flattened if you even think you can walk onto the field during a game.

Meltdowns occur for lots of reasons. Sometimes it's technical, sometimes it's ego. Sometimes it's just a choice being made that doesn't 'sit well' with a team member. Sometimes it's that the people involved really believe their project is an important one and needs to be "done right". Maybe it even really is that important. Certainly that has occasioned more than a few of the "left in a huff's" that I've seen in the FreeBSD Project, and cooler heads have sometimes come back to work. The important thing to realize is that the reasons for any given meltdown are specific to that team and that meltdown. Monday-morning quarterbacking doesn't add a whole lot to the situation, no matter how much fun it may be.

It may seem as though there are more meltdowns in open source projects than in the commercial world, and there probably are, but there's also a bright side. Open Source projects can be picked up by anyone who has the chutzpah to take them on. Very few of the commercial meltdowns I've seen have been recoverable.

As a user of open source, as opposed to a developer, I've come more and more to realize what an exceptional and amazing contribution to humanity that this whole movement is, and how much we rely on each individual developer to keep his/her act together in spite of the pressures. Given the lack of financial compensation that is so prevalent in open source development, these pressures can be monumental. We who are merely users need to do our part to support and encourage those who develop. A few quiet /msg's at the right time -- OFF LIST -- can do an amazing amount to shore up the self-motivation of a talented developer. No matter how much they're doing it for their own reasons, praise helps. Money, too, whether it's a new development server or just a beer. I realized this past tax season that I've contributed more in time and money to open source than I've paid for Microsoft products (though not (yet) for all s/w I've paid for), but, then again, I've made more money as a result of open source. I can't count the value of it, for myself or for the world. It's too high! :D

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.