Opensourcing: Outsourcing to a Global Unknown Workforce

Professor Brian FitzgeraldLero – the Irish Software Engineering Research Centre

University of Limerick IRELAND

Brunel University5 Sep 2011

Overview

Background The Opensourcing concept Using Psychological Contract Theory (PCT) to

study Opensourcing Research Approach – Mixed Method Findings

Qualitative case studies Quantitative survey

Conclusions

Background Early OSS implementations in back-office

‘invisible’ infrastructure Deployed by ‘tech savvy’ under the radar

Now ubiquitous Visible front-office applications To military and beyond!

(mil-oss.org to crowd-sourcing)

Opensourcing Companies wish to leverage perceived advantages of OSS

Reduced costs Reduced cycle-time Access to larger talent-pool Innovation & shared best practice Closer proximity to customer

Opensourcing – providing an OSS version of hitherto proprietary software

Akin to offshore outsourcing Outsourcing to a global unknown workforce

Offshoring v. Outsourcing

In-house Outsourced

On

shor

e

In-house (traditional model)

Subcontractor in the same locale

Off

shor

e

Foreign branch of the same company

Subcontractor in a foreign locale

1

Offshoring v. Outsourcing

In-house Outsourced

On

shor

e

In-house (traditional model)

Subcontractor in the same locale

Off

shor

e

Foreign branch of the same company

Subcontractor in a foreign locale

1

Openso

urcin

g

Psychological Contract Theory (PCT) and OSS

PCT (Argyris, 1960, Levinson et al, 1962, Rousseau, 1989)

“the contractual parties’ mental beliefs and expectations about their mutual obligations in a contractual relationship, based on perceived promises of a reciprocal exchange”

Also prominent in OSS Mutuality and reciprocity – copyleft, free-riding Psychological contracts – 60% volunteers,

unwritten rules of engagement

Research Question

What are the critical company and community obligations in a successful opensourcing relationship?

Research Approach

Analytical Memos

Transcripts

Initial set of obligations derived from literature Šseed categories

1. InterviewsIntermediate

set of obligations

2. Coding

Rationale

Structure Theoretical grounding

Finalized set of

obligations

3. Survey

4. Analysis

Data

+

Initial Company* Obligations Based on Outsourcing (Koh et al 2004)

Company Obligations

Relevance to OSS

Clear specifications More likely in OSS 2.0 – new vertical domains telecomms, automotive

Prompt payment ~40% OSSers paid Bounty programs

Close project monitoring Never a bazaar Project planning & conferences

Project ownership > importance as OSS more visible

* Company = Customer in Koh et al

Initial Community* Obligations Based on Outsourcing (Koh et al 2004)

Community Obligations

Relevance to OSS

Clear authority structure Benevolent dictator Core & peripheral developers

Taking charge Benevolent dictator

Effective human capital management

Itch worth scratching Self-selection

Effective knowledge transfer

Remarkably successful exemplar of global software development

Effective inter-org teams Open Source Service Networks (OSSNs)

* Community = Supplier in Koh et al

Research Phases

Qualitative Phase I In-depth qualitative ‘revelatory’ case studies

IONA Technologies – Celtix product Philips Medical (DVTk) Telefonica (Morfeo)

Refine obligations in context – intermediate set of company/community obligations

Quantitative Phase 2 Large-scale survey (n=207)

Factor analysis, analysis of variance, and regression analysis Validate/refine results from qualitative phase

Data Sources: Qualitative Phase I

Workshops Interviews Supplementary Sources

Sep 2005: Presentation and discussion of Celtix business model and strategy.

Apr 2006: Workshop presentation on opensourcing strategy and discussion of DVTk and Morfeo projects.

July 2006: Debriefing presentation of findings.

July 05 – June 2006: Interviews witho Chief Scientist, IONA o Chairman, ObjectWebo Admin, IONAo Open Source Program

Director, IONAo Two Project Managers, IONAo Two Developers, ObjectWebo Two Managers, Philips

Medical Systemso Developer, DVTko Manager, Telefonicao Developer, Morfeo

IONA and ObjectWeb maintain detailed and comprehensive web portals for the Celtix project. We also had access to mailing lists and project development wiki pages.

Also, detailed web portals and mailing lists for DVTk and Morfeo projects were available.

Company Obligations (Phase I)

Achieving consensus on development roadmap Not too forceful and dominant in pushing own

agenda Accept a general roadmap (vision) of future

functionality rather than seeking a precise requirements specification

Company Obligations (Phase I)

Project ownership Provide senior management commitment to

the project - may be perceived as contrary to traditional proprietary business model

Open Source Program Director appointed in IONA

Provide R&D resources to further develop the project

Company Obligations (Phase I)

Marketing project to increase visibility Provide professional expertise in relation to

marketing and productizing the software Help improve the reputation of the community of

contributors Provide a business opportunity for the community to

use the product

Company Obligations (Phase I)

Transparency and close project monitoring Transparent in plans for the future of the project Open to outside contributions Use an appropriate license to safeguard community

contributions

Company Obligations (Phase I)

Creating a sustainable ecosystem Seek to create trust in the relationship with the

community Preserve continuity by keeping developers on projects

for a longer period than the norm in proprietary development

Community Obligations (Phase I)

Clear authority structure and transparent process Transparent authority structure to allow customer see

the community decision-making process Behave as a professional team

Community Obligations (Phase I)

Responsible and innovative attitude Take responsibility and deliver on commitments Be creative and innovative in suggesting new

functionality and directions for the project

Community Obligations (Phase I)

Creating a sustainable ecosystem Offer high quality people who understand the project

domain very well without requiring additional training Exhibit loyalty and continued involvement in the

project

Phase 2 Survey

Questionnaire constructed on basis of qualitative phase 1 analysis

Pre-tested with four practitioners (2 company, 2 community)

207 usable responses Non-response bias

Late respondents as surrogates for non-respondents

No statistically significant differences

Phase 2 Demographics

Respondents from 37 countries Affiliation: company (56%) v. community (44%)

>5 years OSS experience (53%) < 1 years OSS experience (10%) Gender (previous studies indicate that

98/99% of OSS developers are male) 4% of the respondents female in this study

3% of community respondents 5% of company respondents

Principal Component Analysis

Three high-level company factors emerged Creating open company-community ecosystem Providing professional business expertise Not seeking to dominate and control process

Mean, SD, Scale Reliabilities and Intercorrelation

Variablea Mean SD 1 2 3 4 5

1Create open company-community ecosystem

3.67 0.76 (.79)

2Provide professional business expertise

3.61 0.61 .42** (.63)

3Did not seek to dominate and control process

3.37 0.80 .33** .12 __

4Community professional obligations

3.74 0.61 .42** .27** .28** (.79)

5Opensourcing success

3.95 0.81 .54** .37** .28** .57** (.84)

Company v. Community Differences

Analysis of importance of fulfilment of each other’s obligations

Community respondents less positive than company regarding Was open to outside contributions

Company respondents less positive than community regarding Provided a transparent authority structure Helped improve public perception of the project

Obligation Fulfilment v. Opensourcing Sucess

Dependent Variable

Independent Variables Model

Opensourcing success

Company ObligationsCreate open company-community ecosystemProvide professional business expertiseDid not seek to dominate and control processCommunity professional obligations

.35***

.21***.12*

.38***

FR2

38.56***.47

Final Set of ObligationsCompany Obligations Community Obligations

Do not seek to dominate and control process Not too forceful and dominant in pushing own agenda Accept a general roadmap (vision) of future functionality

rather than seeking a precise requirements specification

Clear and democratic authority structure and process transparency Provide a transparent authority structure to allow customer see the

decision making process within the community Behave as a professional team

Provide professional management and business expertise Preserve continuity by keeping developers on projects for a

longer period than the norm in proprietary software development

Provide a business opportunity for the community to use the product

Provide professional expertise in relation to marketing and productizing the software

Provide R&D resources to further develop the project Provide senior management commitment to the project

Responsible and innovative attitude Take responsibility and deliver on what is committed to Be creative and innovative in suggesting new functionality and

directions for the project Help achieve a positive impact among customers

Help establish an open and trusted ecosystem Behave as a responsible member of the opensourcing

ecosystem Open to outside contributions Transparent in plans for the future of the project Seek to create trust in the relationship with the community Engage in community-sustaining activities

Help establish a professional and sustainable ecosystem Offer high quality people who understand the project domain very well

without requiring additional training Exhibit loyalty and continued involvement in the project

Conclusions

Symmetric and complementary obligations Create an ecosystem Symbiosis: augment what other provides – professional

marketing and global reach/legitimacy

Tension as each party needs to accommodate change - balance must be achieved

Coopetition – community collaborates and competes with company

Source of innovation

This work was supported, in part, by Science Foundation Ireland grant 03/CE2/I303_1 to Lero–the Irish Software Engineering Research Centre (www.lero.ie)

Thank you

ShamelessPlug Time!