Open Source Development: About Community and Sponsored Projects

Filed under: Commercial OSS — by Roberto Galoppini at 4:05 pm on Friday, July 4, 2008

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).

Sponsored Developers 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	Solve a problem Create a “free software” alternative to proprietary solution	Achieve greater adoption Get development help on areas that are of ow priority for the firm (e.g. special dialects)
Key Issues	Garnering Resources Building healthy community, attracting talented developers Distributing software Gaining “mindshare” with minimal marketing	Gaining legitimacy Building healthy community, attracting talented contributors Resolving ambiguity about control and ownership
Contributor Motivations	To make software happen To gain fulfillment To build and learn new skills To Solve personal and professional problems	To complete areas that are of high priority for contributors To gain visibility by prospective employers To influence sponsor’s alignment with complementary projects
Control	Democratic, transparent, usually meritocratic Some leadership and stratification	Varies but usually sponsor retains direct or indirect 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.

Technorati Tags: Commercial Open Source, community-driven, collaborative software initiative, open source projects, SAKAI, Dahlander, Magnusson, OMahony, West

6 Comments »

470870

Comment by James Dixon

July 4, 2008 @ 4:52 pm

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

470984

Comment by Roberto Galoppini

July 4, 2008 @ 6:52 pm

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!

486468

Comment by Joel West

July 15, 2008 @ 11:21 pm

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

486495

Comment by Joel West

July 15, 2008 @ 11:31 pm

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

490730

Comment by Roberto Galoppini

July 18, 2008 @ 4:26 pm

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?

510710

Pingback by Open Source Development: About Community and Sponsored Projects | OSS Spyglass

July 30, 2008 @ 1:28 am

[…] Open Source Development: About Community and Sponsored Projects | Commercial Open Source Software […]

RSS feed for comments on this post. TrackBack URI

Roberto Galoppini's
Commercial Open Source Software

Where Free Software meets Business
equally critical of proprietary and open source myths,
advocating software choice beyond
marketing and romanticism