Open Source Development: About Community and Sponsored Projects
Classifying Open Source production models is not an academic curiosity, as result from recent conversations on how the development model affects at large the software life-cycle and, more important, the business strategy.
Theodore Ts’o opened a conversation about organic vs non organic open source development, following a Mozilla’s organic definition. Matthew Aslett later reopened the discussion further exploring the bee keeper analogy, getting some reactions from Stormy Peters and James Dixon (original author of the Bee Keeper model).
Are all your developers corporate-sponsored? by camera_rwanda
Beyond definitions, the way open source firms cope with their communities, and how their business is affected by the relationship, worth some attention. The relationships between firms and communities in open source software has been analyzed by very few academic papers so far. Dahlander and Magnusson in their paper “Relationships between open source software companies and communities: Observations from Nordic firms” distinguished three different approaches to handle the firm–community relationship: symbiotic, commensalistic, and parasitic. Managerial issues vary depending on the chosen approach. The symbiotic approach seem to be the most promising in terms of the possibility to influence the community, but firms adopting it are also confronted with challenging managerial issues related to decision rights and control.
West and O’Mahony in “contrasting community building in sponsored and community founded open source projects” investigated how changes in building and attracting an “external” when open source firms spin out internally developed code. The following table from the paper reports key issues for community-led and sponsored open source projects.
|
Community initiated |
Sponsored |
|
|
Reasons for Initiation |
|
|
|
Key Issues |
|
|
|
Contributor Motivations |
|
|
|
Control |
|
|
The paper suggests that ongoing relationships between the sponsor and the community face a trade-off between appropriating returns from the commons versus providing incentives for external participants to join the community. As a matter of fact unilateral decisions and legal obligations make difficult recruiting contributors. On the contrary governance mechanisms enabling the sponsor to determine project’s evolution through pluralistic support are definitely of help in this respect.
Apache, the Collaborative Software Initiative, Eclipse, OpenOffice.org or SAKAI seem to follow very different approaches to community building, technology transfer and fostering open source ecosystems. That is for another post, maybe more than one: I will make some interview before reaching any conclusion, in if any.
Roberto Galoppini, 
James Dixon 4:52 pm on July 4, 2008 Permalink
These are great points Roberto.
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
Roberto Galoppini 6:52 pm on July 4, 2008 Permalink
Hi James, it is great to hear back from you!
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!
Joel West 11:21 pm on July 15, 2008 Permalink
I would tend to agree that the motivations section was not the strongest part: it was less our own work and thus heavily derived from the prior research of others (including Lakhani and Wolf). The main focus we had — what we thought the contribution was — was on governance of sponsored projects and how that differs from independent ones. This is consistent with Siobhan’s work on community governance and my own interest in openness as a source of competitive advantage.
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
Joel West 11:31 pm on July 15, 2008 Permalink
Oops, now I can see the source of the confusion.
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
Roberto Galoppini 4:26 pm on July 18, 2008 Permalink
Hi Joel, I am really glad you joined the conversation.
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?
Open Source Development: About Community and Sponsored Projects | OSS Spyglass 1:28 am on July 30, 2008 Permalink
[…] Open Source Development: About Community and Sponsored Projects | Commercial Open Source Software […]
IT Management Tutorials - ITManagementNews.com 9:50 pm on March 27, 2009 Permalink
[…] Community-led open source projects are transparent and accessible, but letting sponsors enter the game directly requires to pay attention to make efficient and effective open source collaboration markets. […]