I've had good open source experiences and bad ones. My good experiences have been almost solely in releasing Perl modules on CPAN. My best CPAN efforts share a few notable traits - they're simple, they meet a reasonably common need and they do so in a flexible and efficient manner. These modules have been used by numerous people in a variety of situations. Their generous feedback has radically enhanced the utility and functionality of the code. In short, developing for CPAN has been a completely positive experience.
My bad open source experiences have centered around full applications; I've released a few and been involved in the development of others. Now, at the time of their release I've always thought they had the right characteristics to be successful open source projects - they met a common need and they were as flexible and efficient as I could make them. However, the positive responses have generally been minimal or non-existent. Some people did try to use these programs, but their reactions were rarely helpful. I'm not entirely certain why this is. Perhaps it has to do with the target audience; Perl modules are used by the same people that can contribute positively to their development. Or perhaps its just that creating an entire application is an order of magnitude harder than module development.
Creating open source software has costs. There are bottlenecks in open source development that just don't exist in an internal project. Of course, there are also huge benefits to be gained, not the least of which being the prospect of free labor. In my experience a failed open source project results in a large loss in time and energy. The question then is to determine whether a given project has enough of a chance to become a successful open source project to offset the cost.
In the case before me at the moment, I don't believe it does. The application will be a large-scale development to create a critical piece of business architecture. It meets a general need among similar businesses, but there is good evidence that businesses tend to solve this problem in radically different ways. My judgment is that the costs associated with making the system flexible and general enough to be released publicly would be unlikely to be repaid. Certainly some would attempt to make use of the software if we released it but my guess is that we would be unlikely to be successful enough to repay our efforts.
Instead, I favor releasing pieces of the project as modules on CPAN. Every time we recognize a solution to a general problem we should take it as an opportunity to lop off a new module. By focusing our efforts on this goal during the design of the project I hope to devote a significant portion of our development time on open source modules. In the end I believe this will be both more beneficial to the Perl community and more efficient than releasing the entire body of code would have been.