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!