I tend to spend part of my blogger’s time and effort to spread the word about academic researches and EC-funded projects, often unknown due to poor dissemination. I think it is a great thing that you spend some time blogging about your findings.

I took the chance to report about your newest paper on another post about open source communities, maybe raising other issues about what I call hybrid production model.

Getting back to your comments, I believe that IT vendors are the most important open source actor, but not the only one. Actors like the Collaborative Software Initiative are just trying to industrialize bottom-up processes seen with Apache before, and later with organizations like SAKAI.

I guess that open source ecosystems in the next future will be seeing consumers playing a much important role.

Do you agree?

The paper quoted in this blog posting is the one that Siobhan & I wrote in June 2004 — effectively our first draft.

The paper I was referring to one published in April 2008. The newer paper reflects many months of working out the governance issues that distinguish sponsored from independent projects.

Joel

Given our focus, we may have simplified away James’ case where he needs the technology and therefore does something to make it happen. This is very consistent with the story of Brian Behlendorf and the Apache contributors.

However this is where I’d draw the distinction. Brian was contributing because as an employee of a user company — i.e. a company running a website. The data collection for this study focused on IT vendors, normally companies that want to give away X so they can sell Y. So the motivations here tended to be more strategic: we’ll assign 2.5 bodies to support project X to make sure it is available for us when we need it.

I can certainly see how the line gets blurry for IT vendors: IBM support Apache on principle, but a particular bug needs to be fixed by next week so that WebSphere 12.7 won’t crash. Still, for big companies there’s normally a requirement to get permission to work on OSS projects (at least during work hours) and so the decision to participate in a project would have to be approved as fitting the strategic goals of the company. Presumably a CTO (especially in a non-public company) would have more discretion than a bench-level engineer.

Joel West
San Jose State

I quoted the West and Mahony’s original table fully, and I agree that the Contributor Motivations section is probably not the most interesting (Lakhani and Wolf are my first choice in this respect).

I agree that open source software selection is a very interesting topic. I will cover this issue at some extent talking about how super-communities fit into the open source development picture, and your feedback is welcome!

Based on my own experience I don’t agree with West and Mahony’s items in the Contributor Motivations section. I have contributed to both commercial and organic projects in the past and my motivation is the same regardless of the model: I have a need for the software that the project produces but I am stalled or blocked by a documentation, design, or coding issue. I participate in the project to unblock myself and in the process I contribute my changes to the project.

In terms of how I select the packge in the first place I try several projects and choose the one that has the bet fit for my needs (this includes functionality, architecture, community etc). I don’t care whether it came from JBoss or Apache or Sourceforge.

James Dixon, CTO, Pentaho