Skip to content

On the intrinsic and extrinsic motivation of free/libre/open source (FLOSS) developers

paper
Based on existing literature Krishnamurthy argues in favor of an integrative theory on open source motivation rather then the either-or of intrinsic versus extrinsic motivation found in other literature. He identifies 4 factors: financial incentives, nature of the task, group size and group structure. Financial incentives can be classified by 4 variables:

  • Distribution pattern
  • Type of provider
  • Contingent or fixed
  • Conditionality

He is also concerned on the effects of financial incentives on the larger ecosystem

“While acknowledging the work of previous authors, it is my argument that
in order to gain a fuller understanding of developer motivation what is needed
is a more direct investigation of the impact of financial incentives on the FLOSS
ecosystem. Following previous work on FLOSS as a virtual organization
(Marcus, Manville and Agres 2000, Ljungberg 2000), the ecosystem is defined
as a loose collection of individuals and firms working on various projects
that lead to the public release of software and source code. The ecosystem is,
thus, at a higher level of abstraction in comparison to a community since (a) it
includes individuals and firms and (b) it is not specific to one project.”

Intrinsic motivation in open source software Development

paper
Open source is considered a public good, which is produced for free by skilled, highly educated programmers. This paper examines open source in the context of private provision of public goods. This model is augmented with the concept of the OSS programmer as a ‘homo ludens’ and gift-giving. Programming OSS is considered to have a utility benefit (gift-giving) and a play benefit (homo ludens). This model is then compared to preexisting literature on the topic and shown to be additional evidence for the intrinsic motivation of OSS programmers as well as an alternative to the theory that programming OSS has a signaling, indicating quality of the programmer to outsiders, role.

The Material and Social Dynamics of Motivation: Contributions to Open Source Language Technology Development

paper

This paper argues that prior research on the motivations of open source developers has focused too much on intrinsic versus extrinsic and the hacker ethic-for profit juxtaposition frameworks. As a result not all motives have received fair attention. A case study is done on the OpenOffice.Org project, a hybrid firm-commnity project exploring other motivational attributes. Rather then fixed motivations the case study proposes that motivation is a complex and changing pattern tied to personal histories and changing objectives. Types of contribution are used to understand how an individual is connected to the project.

Contrasting Community Building in Sponsored and Community Founded Open Source Projects

paper

A case study of a project, VistA, the primary healthcare information system for the US Department of Veterans affairs, which has been moved from it’s corporate (closed source) context into a public open-source project. Two different models of open source communities are proposed: sponsored and community founded open source projects.
Community founded projects are usually structured to prevent a takeover by an organization. Community founded project in their purest form build both the technical and organizational infrastructure of a project from the ground up with volunteers. As they mature they create a series of major releases, have clear membership criteria, adopt governance mechanisms and have an ecology of organizations that support their work.
Sponsored projects originate when an internally developed product gets released to the public under an open source software license and an external community is created. Sponsors invest in the organizational and technical foundations of the project and fulfill an ongoing role in providing direction. Sponsored projects can run into problems when the corporate sponsor fails to relinquish control. Contributors to sponsored projects may be concerned with their legal rights to the code they have helped develop.

Key issues for creating sponsored projects:

  • building a collaboration infrastructure
  • designing governance mechanisms
  • making key decisions about licensing and relationships to external commercial efforts

The mechanisms and success of using open source as a technology transfer mechanism varies based on:

  • on-going technology needs: e.g. in an exit strategy control will be less likely but so will organizational support.
  • Applicability of technology to external needs
  • Financial goals and constraints

Understanding the nature of participation & coordination in open and gated source software development communities

paper

This paper explores the motivations for participating in two open source communities, both the communities originated from the same corporate sponsor. The study is based on interviews and mailing list data, conference observation and on-line project documentation. The two projects represent two different kind of communities: ‘gated source’ communities and ‘open source’ communities. The difference between these two communities lies in following:

  • the open source community allows everybody to download, use , modify and distribute the code
  • the gated source community specifies the terms of the license and how decisions will be made in the community. Only those who agree to the license of the corporate sponsor can download, use and modify the code. Gated communities can involve the payment of royalties to the corporate sponsor and redistribution of the code is usually restricted.

The initial reason to get involved was a need to use the software for work purposes. In the long run the gated source community’s participants continued with their need to use the software whereas the open source community’s participant also found other reasons, especially it being a challenge and fun.

Interviews

As @Brionv already dented I’m currently at Wikimania doing interviews for my masters thesis on open source communities. If you consider yourself a Mediawiki developer or that you might become one I’d love to talk to you. feel free to ping me at hennar – at – gmail dot com or find me at Wikimania (Reddish hair, ussually put up, green glasses and I carry a jeans shoulderbag).

Analysing mediawiki commits

CVSAnaly2 is currently processing mediawiki commits based on the git mirror of the main subversion repository :D .

pip install "https://github.com/SoftwareIntrospectionLab/cvsanaly/tarball/master#egg=master"

git clone git://github.com/mediawiki/mediawiki-svn.git mediawiki
cd mediawiki
cvsanaly2

Traceback (most recent call last):
File "/usr/local/bin/cvsanaly2", line 33, in
import pycvsanaly2.main
File "/usr/local/lib/python2.6/dist-packages/pycvsanaly2/main.py", line 34, in
from repositoryhandler.backends import create_repository, create_repository_from_path, RepositoryUnknownError
ImportError: No module named backends

git clone https://github.com/SoftwareIntrospectionLab/repositoryhandler.git
cd repositoryhandler
python setup.py install

git clone git://github.com/mediawiki/mediawiki-svn.git mediawiki
cd mediawiki
cvsanaly2

Analysing code repositories

I want to compare activity of non-paid developers in a project before and after the introduction of financial rewards. For this I’ll look at commits as a measure of how active people are.

Commits are a useful measurement here as it shows real activity, other activity happens as well (mailing lists, IRC), but code written is commonly looked at as shorthand for how active somebody is. Commits show real activity rather then self-reported activity, there’s less (social) lying.  They can be analyzed statistically. Most importantly for me, as these projects are currently paying developers, the data exists going back years to a time before payment.

The data can be gamed, after all humans will perform to the standard used to measure them. However, this data has been created already and gaming previously created data is harder (probably too hard for most people to care).

Methods of repository analysis:

  • http://www.ohloh.net: a social network for open source developers. They analyze a lot of OSS projects down to the individual contributor level (even across projects) in several kinds of repositories but data is only available for the last 300 days (due to performance issues)
  • http://www.statsvn.org/: analyzes svn repositories and generates nice images out of it. Creates a nice graph, but haven’t found the data itself yet, of #commits per developer over time going back as far as available in the local svn repository. Requires access to the repository and only does subversion.
  • http://tortoisesvn.net: has some screens to see statistical graphs, same issues as Statsvn above but compounded by it not being a statistical tool, so even less likely to have the data lying around easily.
  • http://www.panbi.org/: works on subversion repositories (and other non-versioning system things) but seems to only be in very early stage development.
  • http://cvsanaly.tigris.org/: Looks similar to statsvn but for cvs
  • htp://svncrawler.sourceforge.net: Another subversion analysis program, not the most intuitive charts, but information dense. Most output is ascii based

Sponsored Open Source Projects

“Sponsored projects,” in academic research, are projects initiated by an organization, commonly a commercial firm but sometimes a government agency.

Most research on open source focuses on community-found projects,  examples include Apache or the Linux kernel.  Less studied are the sponsored open source projects, such as OpenOffice.Org or MySQL. A potential third category are the projects who started out sponsored but are now in control of the community, for instance Mozilla’s Firefox.

Contrasting Community Building in Sponsored and Community Founded Open Source Projects finds the major challenges for sponsored projects  concern:

  • lack of modularity, a modular software design encourages participation as it is easier to find a spot to participate in
  • spinout of code that is perceived to be for maintenance reasons as opposed to a partnership
  • pre-emptive governance design may lead to questionibng of motives of the sponsoring organisation
  • unclear boundary between commercial and community control

The same paper finds four roles for sponsors:

  • provide code
  • provide resources
  • transfer of knowledge, information about the code and it’s background
  • community leadership:  managing leadership is the key obstacle in the creation of these communities

 

 

 

 

Context

Open source development has long been thought of as a hobby. Research as early as 2001 however has shown that not all open source is done on a volunteer basis. Organizations are involved in the open source community in different ways: developing open source software, sponsoring open source projects with grants our bounties. The effects of this financial sponsorship of a project is not always bliss, as can be seen  for instance on this  thread on the wikitech-l mailing list from September 2010.