understanding the requirements for open source...

1

Understanding the Requirementsfor Developing and Designing

Open Source SoftwareWalt Scacchi

Institute for Software ResearchUniversity of California, Irvine

Irvine, CA 92697-3425Wscacchi@ics.uci.edu

ISR-NSF Workshop on Continuous Design of Open Source Software8 October 2003

http://www.ics.uci.edu/~wscacchi/Presentations/Workshop2003/OSS-Req-Design-Process

2

Overview

• Research methodology• Open source processes for Requirements• Software development informalisms• Implications• Conclusions

3

Research methodology• Prior empirical (case) studies of Open Source

Software Development (OSSD) Projects– Mockus, Fielding, Herbsleb, 2000, 2002, Apache httpd

server– Reis and Fortes, 2002, Mozilla Web browser– Schach et al., 2002; Holt et al., 2000, Linux Kernel– Koch and Schneider 2001; German 2002, GNOME User

Interface– Jorgensen, 2001, FreeBSD operating system– Garg et al., 2002, OSSD (“progressive open source”)

within HP

4

Research methodology• Individual case studies: significant details,

but limited (and premature) generalization,little/no comparative analysis

• No studies that examine multiple OSSDprojects in multiple domains– Such studies would offer higher degree of

comparative analyses and generalization ofresults

5

6

Research methodology• Comparative case studies

– Multiple open software development projects• Within communities, across multiple communities

• Qualitative (“grounded theory”) techniques• Analyzing and modeling

– development processes– work practices and roles– development artifacts and tools– community structures and process dynamics

7

OSS processes for Requirements• Post-hoc assertion of requirements+design

after implementation• Reading, sense-making, accountability• Continually emerging webs of discourse• Condensing and hardening discourse• Global access to this discourse

8

OSS processes for Requirements/Design

• OSS Requirements/Designs are– not explicit– not based on engineering formalisms– products of socially constructed formalities

• OSS Requirements/Designs are embeddedwithin “informalisms”

• Example OSS informalisms follow

9

10

11

12

13

14

15

Traditional vs. OSS processes forRequirements

• Elicitation• Analysis

• Specification andmodeling

• Validation

• Communicating andmanaging

• Post-hoc assertion• Reading, sense-

making, accountability• Continually emerging

webs of discourse• Condensing and

hardening discourse• Global access to

discourse

16

Software Informalisms

• Community communications– Threaded discussion forums– Email (list servers)– Newsgroups– IRChat/Instant messages– Community digests (“Kernel Cousins”)

17

Software Informalisms• Scenarios of Usage as linked Web pages

18

Software Informalisms

• How-To guides, To-Do lists, FAQs• Traditional software user documentation

– Unix/Linux man pages• External publications

– trade articles– scholarly research papers– books (cf. O’Reilly Books)

19

Software Informalisms

• Open Software Web Sites– Community Web sites– Community Software Web sites– Project Web sites– Source code Webs/Directories

20

21

22

23

Software Informalisms

• Software bug reports– Ad hoc report Web– Bugzilla (database tracking)

• Issue tracking– Issuezilla

24

25

Software Informalisms

• Software extension mechanisms– Inter-application scripting

• Csh, Perl, Python, Tcl, scripting• Pipelines (cf. CXCDS)

– Intra-application scripting (e.g., UnrealScript)– Plug-in architectures

• Apache server architecture

26

Software Informalisms

• Free/OSS licenses and work practices –institutionalize F/OSS culture (values,norms, and beliefs)– GNU Public License (GPL)– and more than 35 others (http://opensource.org)– “Creative Commons” Project at Stanford Law

School developing public license framework

27

28

Implications

• Software informalisms are the media ofsoftware requirements/design processes

• Software informalisms are the subject ofsoftware requirements/design processes

• OSS requirements/design processes areimplied activities or capabilities

• (Re)reading, reviewing, and reinterpretinginformalisms is a prerequisite to writing OSS.

29

Implications• Developing open software requirements and

designs is a community building process– not just a technical development process– OSS peer review creates a community of peers

• OSSD processes often iterate daily versusinfrequent singular (milestone) SLC events– frequent, rapid cycle time (easier to discover and

improve) vs.infrequent, slow cycle time (harderto discover and improve)

30

Implications

• Determining the quality of OSSrequirements/designs:– not targeted to consistency, completeness,

correctness– instead focusing attention to community

building, freedom of expression, ease ofinformalism navigation (traceability), implicitvs. explicit informalism structuring

31

Conclusions

• Developing OSS requirements/design isdifferent than requirements engineering andcurrent software design techniques– not better, not worse, but different and new– more social, more accessible, more convivial

• OSS systems don’t need and probablywon’t benefit from classic softwarerequirements/design engineering.

32

Acknowledgements• Project collaborators:

– Mark Ackerman, UMichigan, Ann Arbor– Margaret Ellliot, Chris Jensen, UCI-ISR– Les Gasser, UIUC– John Noll, Santa Clara University– Julia Watson, The Ohio State University

• Funding support (no endorsement implied):– National Science Foundation, IIS#-0083075, ITR#-

#0205679, ITR#-0205724, and IIS#-0350754.

33

References• M. Elliott and W. Scacchi, Free Software Development: Cooperation and

Conflict in A Virtual Organizational Culture, to appear in S. Koch (ed.),Free/Open Source Software Development, Idea Publishing, 2004.

• C. Jensen and W. Scacchi, Simulating an Automated Approach toDiscovery and Modeling of Open Source Software DevelopmentProcesses, Proc. ProSim'03 Workshop on Software Process Simulationand Modeling, Portland, OR May 2003.

• W. Scacchi, Understanding the Requirements for Developing OpenSource Software, IEE Proceedings--Software, 149(1), 24-39, 2002.

• W. Scacchi, Free/Open Source Software Development Practices in theComputer Game Community, IEEE Software, (to appear, 2004).

• W. Scacchi, Understanding Free/Open Source Software Evolution:Applying, Breaking and Rethinking the Laws of Software Evolution,revised version to appear in N.H. Madhavji, M.M. Lehman, J.F. Ramiland D. Perry (eds.), Software Evolution, John Wiley and Sons Inc, NewYork, 2004.