Notes on Open Source Software Process

Open Source Software (community, software development) "process"

• is continually emerging via:
• reenactment
• reinvention
• (re)negotiation
• gives rise to:
• OSS articulation process (cf. P. Mi and W. Scacchi, Articulation: An Integrated Approach to the Diagnosis, Replanning, and Rescheduling of Software Process Failures, Proc. 8th. Knowledge-Based Software Engineering Conference, Chicago, IL, IEEE Computer Society, 77-85, 1993).  
• reallocation of resources (source code products, artifacts, tools, other I/O resources, new agent roles, etc.) or teamwork effort 
• cf. process breakdown diagnosis (problem space) taxonomy for need to reallocate resources in Articulation.
• cf. reallocation of teamwork effort, S. Bendifallah and W. Scacchi, Work Structures and Shifts: An Empirical Analysis of Software Specification Teamwork, Proc. 11th. Intern. Conf. Software Engineering, IEEE Computer Society Press, Pittsburgh, PA. 260-270, May 1989.
  
• (stream of) continuous improvement (events, enhancements (bug repairs, new functionality, etc.)) in reaction/proaction towards "breakdowns" at hand 
• cf. process repair (solution space) taxonomy in Articulation.
• enactment is: 
• small/fine-grained 
• short duration 
• high frequency 
• creates incremental product/release (e.g., nightly build) 
• suitable candidate for process redesign 
• becomes more like traditional software engineering process: 
• as project size increases 
• from individuals  (persistent identity, loosely-coupled, little/no organization)
• to work groups/project teams (individuals coupled and organized with group identity)
• to enterprises (e.g., foundations, corporations, other businesses -- external enterprises that establish boundaries around and constrain persistent group activities)
• so that enactment becomes 
• larger-grained 
• longer duration 
• lower frequency 
• focused on infrequent (e.g., monthly, quarterly) "full product" release 
• documents have an ambiguous or unclear purpose: 
• age? 
• relevance to current process instances? 
• do developers follow the process described in project-specific process documents?
• stimulates or is modulated by personal/professional incentives/interests 
• (individuals, work groups) freedom to do what you like 
• RMS, Linus Torvalds, (plus thousands of others) -- making and sharing free, open source software as community/common good 
• (individuals, enterprises) make more money 
• Michael Tieman (from Stanford Ph.D. student to Cygnus Corp. founder, to CTO of RedHat via corporate acquisition) 
• Larry Augustin (from Stanford Ph.D. student to founder of VA Linux Corp. and LinuxWorld)
• (enterprises) enable new business model/strategy (e.g., Mozilla @ AOL-TW to become AOL 8.0 browser?)
• requires attention to Release sub-process 
• nomenclature/naming (e.g., SourceForge development status, "stable release", "release candidate")
• Apache httpd 2.0.35 as "official stable release" within 2.0.* version space 
• Mozilla browser 1.0rc1 as "release candidate" 
• following prior release of 0.99, 0.98, 0.97, etc. 
• 1.0rc2 released within one week at 1.0rc1 after major security bugs discovered, reported, and patched
• requires attention to Project Management sub-process 
• traditional (hierarchical, "cathedral-style") software engineering PM 
• more formal (requires explicit documentation of software development artifacts)
• explicit 
• process (e.g., waterfall, incremental release, Spiral) model/framework 
• schedules 
• staffing 
• budgeting (possible use of cost models like COCOMO)
• centralized provision of project resources 
• cf. D. Parnas, A Rational Design Process: How and Why to Fake It, IEEE Trans. Software Engineering, 12(2), 251-257, February 1986.
• virtual (market-like peer-to-peer, "bazaar-style") OSS PM (virtual PM) 
• less/not formal, but tool-based coordination (e.g., CVS, IRC channel assignment and use, Bugzilla/Issuzilla for reporting problems and resolution, nightly builds)
• implicit 
• process (e.g., little (dated, hard to find) or no documents) model
• no schedule
• staffing via community building
• no budget
• decentralized provision of project resources