Method diffusion in large open-source projects

Voluntary adoption of development methods in Debian

Research question

What are the factors which lead Debian developers to adopt new methods and more efficient workflows?

Overview

• Debian

• Diffusions
• Research approach
• Contribution

The Debian Project

• Founded 1993
• 1000+/2000+ volunteers, globally-spaced (52 countries)
• Possibly largest FLOSS project
• 100% Free
• Produces Debian GNU/Linux:
  • 22'000+ (binary) packages
  • 11 architectures
  • ~150 derivatives

"one of the largest software systems in the world, probably the largest" [Amor-Iglesias et al., 2005]

The typical Debian developer

These are from experience/discussions/speculation:

• Volunteer
• Hacker [Levy, 1984; Coleman, 2005]
• Professional user of Debian in advanced/complex settings
• Young (~26 years)
• Academic background
• Technophile
• Perfectionist

Decisions often appear unreasonable from a management perspective

Problems with current workflows

• Non-integrated (e.g. rudimentary bug tracking system integration)
• Repetitive
• Error-prone
• Boring
• Bazaar of cathedrals

Developers are doing what the computer could be doing more efficiently

Why we are still doing it the old way

• No incentive to change
• Large choice of incompatible methods
• Great inertia: processes are highly complex and intertwined
• Yak shaving awareness

• There is no authority which can prescribe the One True Approach
• There is no One True Approach, but a healthy competition of approaches
• Nobody knows how to drive diffusions of such approaches

What can be done?

• Identify the factors which lead developers to adopt
• Publish a framework structuring those factors
• Let proponents of the various approaches use these factors prescriptively to engineer their methods for higher chance of adoption
• This preserves competition rather than trying to push One True Approach

Overview

• Debian

• Diffusions
  • Frameworks
  • Rogers' Diffusion of Innovations
  • Problems with existing frameworks
  • A new framework?

• Research approach
• Discussion

What are factors?

• Aspects of a method diffusion
• Help to anchor assessment of a diffusion
• Examples:
  • relative advantage
  • ease of installation (trialability)
  • documentation (accessibility)
  • programming language used (ideological)
  • responsiveness of developers
  • […]

What's (in) a framework?

• Structuring/logical grouping of factors
• Orthogonality
• Well-defined domains of variables
• Facilitates comparisons and assessments

Problems with existing frameworks

I have tried [Rogers, 2003], [Wejnert, 2002], [Frambach and Schillewaert, 2002], [Gallivan, 2001], [Chau & Tam, 1997], [Saga & Zmud, 1994], [Fichman, 1992], [Davis, 1986], [Kwon & Zmud, 1987], [Tornatzky & Klein, 1982], and a few others…

Common issues:

• no prior knowledge of innovation required
• low degree of network externalities
• (lack of) orthogonality
• authoritarian decisions

Need for a new framework

It seems I need a specific framework for diffusion in

• voluntary social systems
• with members making "unreasonable" choices
• taking part in complex processes
• having great network externalities

But:

One does not discard a framework by looking at it, one discards a model when a better one has taken its place [Kuhn, 1970]

Thus, a bottom-up approach.

Overview

• Debian
• Diffusions

• Research approach

• Discussion

Research approach

Two (or three) phases of research:

1. Delphi approach to identify factors
2. Application and verification of the framework
3. (optional) Community survey

Phase 1: Basics of the Delphi approach

The Delphi method: a structured group communication with the aim to reach consensus (or establish the degree of disagreement) [Dalkey et al., 1967].

• Participants (~30) are asked a question (by email).
• Responses are anonymised and merged.
• The result is sent to all participants - who may modify their previous responses. - or who are asked to respond to a new question.
• The process repeats until degree of con/divergence can be determined.

Phase 1: rounds of the Delphi study

1. brainstorming, creation of factors
2. selection of pertinent factors
3. merging of factors
4. development of a terminology of factors

Phase 2: application and verification

• Descriptive use
• Two classes of methods:
  • package build helpers (done)
  • patch management systems/version control systems (ongoing)
• Prescriptive use left for further research

I have collected a large number of other classes I could study.

Phase 3: (optional) community survey

Goals:

• Assess factor relevance
• Probe individual adoption behaviour and perception of diffusions
• Demographics

Survey strategy:

• Console-based, interactive script
• Intuitive use, unrestricted navigation
• Allows for comments to be submitted
• Uses version control to track and integrate responses
• Authenticates responses with a cryptographic signature

Contribution

• A framework to assess diffusions in Debian
  • (no suitable framework seems to exists)
  • maybe suitable to other FLOSS projects; if not, then can be used to compare projects
• Improved workflows in Debian
• A new survey technique suitable for surveying hackers
• Possible new insights into volunteer management

Discussion

What are the factors influencing your adoption / rejection decisions?

Thank you …

Licence

These slides, their design, and the content are © Martin F. Krafft and released under the terms of the CC by-nc-sa 2.5 licence.

reStructuredText sources: slides.rst and ui/base/*.

Slides based on the S5 presentation system.