Two interesting posts on the subject of vendor and community open source development have been published today by Stephen O’Grady and Matt Asay. First Stephen called for the rhetoric to be toned down and for participants in the ongoing debate to avoid claiming that one governance model is “better” than the other.

“Organic projects might generate more contributions which in turn might allow them to evolve faster which in turn might allow them to compete more effectively. And so on. Which is ultimately why I’m comfortable with inorganic projects and contributions: I (generally) trust the market,” he writes, adding:

“With but a few exceptions, I’m a believer in allowing the market to make its own decisions on which software development and governance models they choose to support. I’m not naive; I understand that commercial deployment is hardly a strict meritocracy, and that influence - financial and otherwise - is rampant.”

Stephen is right that the claims that an inorganic approach is somehow “not open source” do no one any favours and distract attention from the real issue, which - to my mind - should be identifying the comparative benefits to ensure that the next generation of vendors learn from the experience of current vendors to choose the right approach to fulfill their specific goals.

The second post, from Matt, links to an interview with OpenOffice.org contributor and Novell desktop architect Michael Meeks in derStandard in which he discusses Sun’s apparently diminishing involvement in the project.

Leaving aside this claim for a moment, which I am sure Sun would dispute, what Michael’s comments highlight is that what matters is not so much whether a project is organic or inorganic per se but how it is managed.

“This isn’t just a Sun problem,” states Matt. “Michael’s comment speaks to a much broader problem as more and more open source goes corporate: How do you encourage development as a corporation?”

Pentaho’s CTO James Dixon has described the vendor-based approach using The Beekeeper model, while in June I examined how that model could also be applied to community-based projects.

In The Beekeeper James does a great job of listing some of the tasks involved in managing a community, while in my post I touched briefly on some of the relative strengths and weaknesses:

“While the honey collector does not have responsibility to look after the bees that a bee keeper has he will have to take care not to disrupt the nest and may well choose to make an effort to nurture the nest and encourage honey production. Of course, as these are wild bees there is also always a risk that the bees will leave the nest or production will dry up. The collector is also aware that any improvements resulting from his efforts are available to everyone and rivals can easily set up alternative honey collection businesses.”

There is much more to it than that of course, and it is important to study and understand the differences rather than simply dismiss one model or the other out of hand. Stephen is right, toning down the rhetoric is an essential part of the process.