Understanding Best Practices

in Free/Open Source
Software Development
Walt Scacchi
Institute for Software Research
School of Information and Computer Science
University of California, Irvine
Irvine, CA 92697-3425
Wscacchi@ics.uci.edu
18 October 2003

1
http://www.ics.uci.edu/~wscacchi/Presentations/COSST/BestPractices.pdf
 What is free/open source software
development?
• Free (as in “freedom”) vs. open source
– Freedom to access, browse/view, study, modify and
redistribute the source code
– Free is always open, but open is not always free
• F/OSSD is not “software engineering”
– Different: F/OSSD can be faster, better, and cheaper
than SE
• F/OSSD involves more software development tools, Web
resources, and personal computing resources

2
 Who is investing in OSSD?
• Large corporations: (IT and Financial)
– IBM-Eclipse, Sun-NetBeans and OpenOffice, HP-
Gelato, Apple-Darwin, Microsoft Research-Rotor,
SAP-DB, etc.
– Barclays Global Investors, DKW
• Mid-size corporations:
– RedHat, Novell
• Small (start-up) companies:
– ActiveState, Collab.Net, Jabber, Ximian, JBoss,
Compiere, etc.
3
 Sample practices for F/OSSD
• Requirements and design
• Configuration management and work
coordination
• Maintenance/Evolution
• Project management/career development
• Software technology transfer and licensing

4
F/OSS Processes for Requirements
or Design
• F/OSS Requirements/Designs
– not explicit
– not formal
• F/OSS Requirements/Designs are embedded
within “informalisms”
– Example OSS informalisms to follow (as
screenshot displays)
• F/OSS Requirements/Design processes are
different from their SE counterparts.
5
 SE vs. F/OSS processes for
Requirements
• Elicitation • Post-hoc assertion
• Analysis • Reading, sense-
making, accountability
• Specification and • Continually emerging
modeling webs of discourse
• Validation • Condensing and
hardening discourse
• Communicating and • Global access to
managing discourse

6
Retrospective
requirements
specification
example

7
 Configuration management and
work coordination
• Use CM to coordinate and control who gets to
update what part of the system
– Many F/OSSD projects use CVS (single centralized
code repository with update locks) and frequent
releases (daily releases on active projects)
– Linux Kernel: BitKeeper (multiple parallel builds and
release repositories)
– Collab.Net and Tigris.org: Subversion (CVS++)
– Apache: Single major release, with frequent “patch”
releases (e.g., “A patchy server”)
8
 Concurrent
version
system (CVS)
for coordinating
source code
updates

9
 Evolutionary redevelopment,
reinvention, and redistribution
• Overall evolutionary dynamic of F/OSSD is
reinvention
– Reinvention enables continuous improvement
• F/OSS evolve through minor mutations
– Expressed, recombined, redistributed via incremental releases
• F/OSS systems co-evolve with their development
community
– Success of one depends on the success of the other
• Closed legacy systems may be revitalized via
opening and redistribution of their source
– When enthusiastic user-developers want their cultural experience
with such systems to be maintained.
10
Revitalizing
legacy
applications
via
open
source
example

11
 Project management and career
development
• F/OSSD projects self-organize as a pyramid
meritocracy via virtual project management
– Meritocracies embrace incremental mutations over
radical innovations
– VPM requires people to act in leadership roles based
on skill, availability, and belief in project community
• F/OSS developers want to have fun, exercise
their technical skill, try out new kinds of systems
to develop, and/or interconnect multiple F/OSSD
projects (freedom of choice and expression).
12
A pyramid meritocracy and role
hierarchy for F/OSSD

(images from A.J. Kim, Community Building on the Web, 2000)

14
 Example
of
F/OSS development
patterns that
encourage having
fun and getting
a new job

15
 Software technology transfer and
licensing
• F/OSS technology transfer from existing
Web sites is a community and team
building process
– Not (yet) an engineering process
– Enables unanticipated applications and uses
– Enables F/OSSD to persist without centrally
planned and managed corporate software
development centers

16
 Example
of F/OSS
technology transfer
that enabled
creation of new
kind of application
(e.g., online virtual
dancing)
17
 Free/OSS licenses
Reiterate and institutionalize F/OSS culture
(values, norms, and beliefs)
– GNU Public License (GPL) for free software
– More than 35 other open source licenses
(http://opensource.org)
– “Creative Commons” Project at Stanford Law
School developing public license framework

18
19
 Implications
• F/OSSD is a community building process
– not just a technical development process
– F/OSS peer review creates a community of peers
• F/OSSD processes often iterate daily versus
infrequent singular (milestone) Software Life
Cycle Engineering events
– F/OSSD: frequent, rapid cycle time (easier to
improve) vs.
– SLC: infrequent, slow cycle time (harder to
improve)
20
 Conclusions
• Developing F/OSS is different than
software engineering
– not better, not worse, but different and new
– more social, more accessible, more convivial
• F/OSS systems don’t need and probably
won’t benefit from classic software
engineering.

21
 Open source
software research
Web site at
UCI

22
 Acknowledgements
• Project collaborators:
– Mark Ackerman, UMichigan, Ann Arbor
– Les Gasser, UIllinois, Urbana-Champaign
– John Noll, Santa Clara University
– Margaret Ellliot, Chris Jensen, UCI-ISR
– Julia Watson, The Ohio State University
• Funding support:
– National Science Foundation, IIS#-0083075, ITR#-
#0205679, ITR#-0205724, and IIS#-#0350754.
– No endorsement implied.
23
 References
see http://www.ics.uci.edu/~wscacchi
• W. Scacchi, Understanding the Requirements for Developing
Open Source Software, IEE Proceedings--Software, 149(1), 24-
39, 2002.

• W. Scacchi, Open EC/B: A Case Study in Electronic Commerce

• W. Scacchi, Free/Open Source Software Development Practices

• W. Scacchi, Understanding Free/Open Source Software

24