Gianugo kicked off good discussion on a mailing list (message reposted to the Feather blog). It gets at an idea that has been floating around for a good while, that Open Source does not equate to Open Development, and while the difference is glaring obvious to folks who have been around open source for a while, it is not so to many others.
Open Development is what people tend to think of with the idealized view of grassroots (I hate that word) Open Source. Diverse people working together on a labor of love, probably with some folks being paid to work on, it others doing it pro bono. Open Development generally strongly encourages outside contribution, and works to reduce barriers to participation.
Closed Development, on the other hand, is where the community around the project discourages outside participation. This could be a corporate strategy ("lite" open source version, "enterprise" commercial version; GPL or Commercial dual licensing; maintaining control of a codebase for a core product offering with a support revenue based business model), a side effect of circumstances (core developers all work together, or hack on the project together in a user group so to participate effectively requires being there).
Most of the high profile open source and free software projects (I use Open Source so that it is inclusive of non-copyleft licenses, but I include copyleft licenses in Open Source), which tend to drive the perceptions of the field. FreeBSD, Apache, GNU/Linux, PostgreSQL, and many others fit this mold to a T. The perception of how these projects operate colors the perception of how all open source projects operate, but it is not a valid comparison in many cases.
The strengths of Open Community development have been highlighted for years in much of the FSF literature, the Cathedral and the Bazaar, and the astounding success of projects such as GNU/Linux and the Apache HTTPD Server. On the other hand, there is an outright explosion of Closed Community Open Source emerging over the last couple years, and the trend is accelerating.
Closed Community projects tend to leave a bad taste in the mouths many of folks who have been involved with Open Community development for a while. Much of this is driven by one class of Closed Community development, explicit attempts at profiteering on the Open Source name. This was all the rage for a while, with everything under the sun being "open sourced" under licenses ranging from hideously broken, to deeply bizarre, eventually mostly settling on GPL(-ish)/Commercial dual licensing in the tradition of Sleepycat.
Mostly, despite the bad taste, this was still a good thing in the short term. It opened up the ability to debug into libraries, make local modifications, and in some cases lead to open community forks which went on to become fabulously successful projects after the parent company tanked. In others, there has been much less success, for a wide range of reasons.
In other cases, companies have made long-terms bets on the viability of closed community, open source development. Generally these are companies with a great deal of open source experience who recruit developers from open community projects. Some fairly high profile "open source companies" fit this bill, including MySQL and JBoss. They are making an interesting play, and I am very curious to see how the model goes in coming years. By keeping development teams tight, and ensuring wider channels of communication for developers, this model can achieve an awful lot very quickly, while still maintaining many of the advantages of open source. It also provides an obvious source of support, which is very important to many users.
There are drawbacks to this model in comparison to Open Community development, however. The viability of the product is tightly tied to the viability of the company. For non-trivial codebases the effort for a newcomer to learn it well enough to contribute meaningfully, without the support of folks who know it already, is extraordinary enough that it rarely happens in favor of a rewrite (see Mozilla, and there folks were involved who knew the codebase intimately). It is, also, much more difficult to leverage the user base to fuel development as the nature of customers (ones who need support) who are most appealing from a business sense (with deep pockets and who really need support as compared to "put out the fire, okay, thanks, bye") don't general become developer/users, or if they do, there is often a "no recruiting" policy which combined with development decisions being made by project managers leads to a few small patches, and no ongoing growth of the developer into the project.
When you come to have a hard, architectural, dependency on a project the differences really starts to stand out. On one hand, with the closed community style lends itself to a natural monopoly on support, which for a popular project is a nice position to be in, and lends stability (or the perception thereof) to the support option. On the other hand, open communities allow you to actually delve into the communty yourself, and build up better support options. Even better, if the primary driver is bought by Oracle the developer base is not at risk, and at worst a few people stop contributing. In the good case the developers stick around anyway, and sometimes spin off their own companies around the product which lost major vendor contributions. The examples go on, and on.
I have a natural affinity for open communities, I think it is a better long term model. It is, however, far from cut and dried. The Really Closed Communities like Splunk (throw it over the wall), and bait and switch shops are pretty bad; but the developing more or less in the open, with a closed ocmmunity, and releasing under a forkable license players... are very interesting. That said, I still like open communities more =)
Sylvain followed with a good discussion. As did Dave, Matthew, and Ugo.