Very worth reading, and I would like to add some comments from the organization/enterprise point of view.
I agree that most enterprise based projects stop in Open (available)
model, and some of them even fail on that (old link but current, IMHO). Because of this, they never get full advantage of a open source development model. I call this we release code because it’s cool (I know it’s reducing too much, but open source nowadays it’s not only a development model but a marketing strategy).
This kind of openness is very often confused with the Open (for participation)
, and obviously it doesn’t work as expected (oh!).
I mean, just because it’s available it’s not enough to make people participate, because releasing the source code it’s only the first step to make a community grow. It can grow without help, but you won’t get all you could from it. Sometimes you’ll get free support, sometimes you’ll get bug reporting, and it’s nice when it works.
I’m not a community manager or something like that, but I don’t understand when a company wants to open a project just because the open source flag it’s cool, and after that they don’t care enough to build a community around this release.
Zimmerman explains a third model that, in my opinion, it’s the most difficult to achieve in the enterprise based project: Open (transparent)
. That model may lead to a a community driven project, and it’s the ultimate kung-fu of public collaboration, but it doesn’t fit very well in a enterprise driven project. In fact, some big projects have suffered this.
My two cents.
