Process modeling across the web information infrastructure

SOFTWARE PROCESS IMPROVEMENT AND PRACTICESoftw. Process Improve. Pract. 2005; 10: 255–272Published online in Wiley InterScience (www.interscience.wiley.com). DOI: 10.1002/spip.228

Process Modeling Acrossthe Web InformationInfrastructure

Research SectionChris Jensen*,† and Walt ScacchiInstitute for Software Research, University of California-Irvine, Irvine,CA, USA

Web-based open source software development (OSSD) project communities provide interestingand unique opportunities for software process modeling and simulation. While most studiesfocus on analyzing processes in a single organization, we focus on modeling softwaredevelopment processes both within and across three distinct but related OSSD projectcommunities: Mozilla, a Web artifact consumer; the Apache HTTP server that handles thetransactions of Web artifacts to consumers such as the Mozilla browser; and NetBeans, a Java-based integrated development environment (IDE) for creating Web artifacts and applicationsystems. In this article, we look at the process relationships within and between thesecommunities as components of a Web information infrastructure. We employ expressive andcomparative techniques for modeling such processes that facilitate and enhance understandingof the software development techniques utilized by their respective communities and thecollective infrastructure in creating them. Copyright 2005 John Wiley & Sons, Ltd.

KEY WORDS: interorganizational process modeling; process collaboration; process conflict; interorganizational interaction; processintegration; open source software development; Apache; Mozilla; NetBeans

1. INTRODUCTION

Previous studies of interorganizational processesfocus on devising languages to represent work-flows across organizational boundaries (Rasch andHansen 1997, Lenz and Oberweis 2001, Shenand Liu 2001) and verification of workflow nets(van der Aalst 2002b). Little work (van der Aalst2002a) demonstrates real-life interorganizationalprocesses. In contrast, this article contributes aframework for discovering, analyzing, and mod-eling interorganizational software processes within

∗ Correspondence to: Chris Jensen, Institute for Software Rese-arch, University of California-Irvine, Irvine, CA, USA 92697-3425†E-mail: [email protected]/grant sponsor: US National Science Foundation;contract/grant number: 0083075; 0205679; 0205724; 0350754

Copyright 2005 John Wiley & Sons, Ltd.

a multiproject software ecosystem. The ecosystemselected is a network of organizations responsi-ble for core of the Web information infrastructure.Although nonopen source organizations are alsomembers of this ecosystem, our focus is on opensource software development (OSSD) organiza-tions. Large-scale geographically distributed soft-ware development projects, such as OSSD projectcommunities, present challenging process prob-lems. The Apache, Mozilla, and NetBeans1 OSSDcommunities collectively have millions of estimatedusers, and tens of thousands of community par-ticipants contributing in one fashion or another.Such magnitudes would be difficult for most closed

1 The Eclipse project affiliated with IBM is similar in many waysto the NetBeans project, in that both efforts are very large OSSprojects developing Java-based IDEs. But for our study, weselected the NetBeans project.

Research Section C. Jensen and W. Scacchi

source organizations to manage. Yet, these threecommunities have proven extremely successful atit. Further, they have done so in a delicate ecosys-tem that includes evolving Web standards, dataand software repositories, and tools. These serveas a framework for integrating each community’stools together. Therefore, as the components of thisframework coevolve, each community must syn-chronize, (re)integrate, and stabilize its positionwithin the process space.

In this article, we look at processes within andacross three related OSSD project communities (cf.Scacchi 2002). In our efforts to model softwaredevelopment processes on both community andinfrastructure levels, we have used a varietyof techniques. These include detailed narrativemodels of processes, semistructured hyperlinkedmodels, formal computational process models, anda reenactment simulator (Scacchi et al. 2004), all ofwhich serve as input for other process engineeringactivities (Scacchi and Mi 1997, Noll and Scacchi2001). Further, all of our process models arehypermedia artifacts that, when submitted backto the communities, may be consumed by theprocesses they describe.

From here, we will set the stage for our investi-gation with a discussion of each process modeledindependently before examining the infrastructureas a whole in order to examine intercommunityprocess modeling issues and outcomes as we foundthem. Finally, we look at the modeling techniquesthemselves, how they may be used to guide devel-opers, and how they can serve as a basis for processsimulation and other process activities.

2. MODELING PROCESSES WITHIN WEBINFORMATION INFRASTRUCTUREPROJECTS

The Apache Web server, Mozilla Web browser,and NetBeans integrated development environ-ment (IDE) together form a Web information infras-tructure for developing and deploying Web-basedsoftware applications, content, and services (Field-ing et al. 1998, Mockus et al. 2002). However, asthe projects that develop each of these three opensource software systems operate as virtual enter-prises (Noll and Scacchi 1999), we have no basisto assume that their development process activi-ties, roles, or tools are identical or common, nor

how or where they interact. Thus, in order for theseprojects, and other OSSD projects like them, to col-lectively produce and sustain a viable global Webinformation infrastructure, they must be able atsome point to synchronize and stabilize their pro-cesses, their process activities, shared artifacts, andtargeted software releases (cf. Cusumano and Yoffie1999).

Before we can understand software develop-ment processes across each of these three Webinformation infrastructure components, we mustunderstand them individually. As previously intro-duced (Jensen and Scacchi 2003b, Scacchi et al. 2004),we address three process modeling techniques hereas a sampling of those we have applied in our study.These are the rich hypermedia, process flow graphs,and formal modeling. Formal modeling in turn sup-ports tools for simulated reenactment of softwareprocesses, which is used to preview, interactivelywalkthrough, validate (Atkinson and Noll 2003),and support process training on demand (Scacchiand Mi 1997). Additional details on these techniquescan be found elsewhere (Scacchi et al. 2004).

This section seeks to address both of these issues.We start by presenting a brief overview of the qualityassurance (QA) process in the Mozilla Web browserrelease cycle, modeling it as a rich hypermedia,followed by the Apache release process, modeled asa flow graph, and lastly, the NetBeans requirementsand release process, which we model formally andreenact. For brevity, we will skip presenting therich hypermedia, flow graphs, and formal modelsfor each process; however, these models are detailedelsewhere (Ata et al. 2002, Carder et al. 2002, Jensenand Scacchi 2003b, Oza et al. 2002).

2.1. Rich Hypermedia Modeling with the MozillaQuality Assurance Process

Building on and extending the rich picture conceptdescribed by Monk and Howard (1998), we createda rich hypermedia variant as an informal model ofsoftware development processes in each of Mozilla,Apache, and NetBeans projects. These models showthe relationships between tools, agents, their devel-opment concerns (i.e. nonfunctional requirements),and activities that compose the overall process,and its functional requirements. While Monk andHoward propose a flat, static model, our hyper-media is interactive, deep, and navigational (Nolland Scacchi 2001), including process enactment

Copyright 2005 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2005; 10: 255–272

256

Research Section Process Modeling Across the Web

scenarios described and hyperlinked as use cases.Use cases are a known technique compatible withthe Unified Modeling Language (UML) for repre-senting user-system process enactment scenarios(Fowler 2000). The hypermedia artifacts are alsoannotated with detailed descriptions of each tool,agent, and concern. Each of these process objectsis hyperlinked to its description. Descriptions can,in turn, be linked to other data or hypermediaresources. In this way, the modeler can define thescope of the rich hypermedia to include as lit-tle or as much information as the need requires.The rich hypermedia provides a quickly discern-able intuition of the process without the burdenof formalization. A rich hypermedia model for theMozilla quality assurance process is shown as animage map in Figure 1.

The daily Mozilla QA cycle (Carder et al. 2002)begins with the closing of the source tree tosubmissions. After this, the ‘code sheriff’ and system

build engineer create a build of the source code treeusing the Mozilla Tinderbox build tool. If builderrors are present, the sheriff and build engineercontact the ‘on the hook’ developers, reviewers, andsuper reviewers responsible for the build source,then they are called on via e-mail notifications tocorrect the defects. When the defect is corrected orthe problematic source code is removed, the sourceis rebuilt. This process iterates until all build errorsare corrected, and the compiled and built sourceand executable image is ready for the next processstep.

The build results (including the executable soft-ware image) are placed on the community FTPserver and the ‘smoke test’ coordinator issues a callfor developers and volunteer testers via the commu-nity Internet relay chat (IRC) channel to downloadand evaluate the build results (e.g. execute the imageon a test platform). After this, developers partici-pating as QA contacts, QA owners, and volunteer

Figure 1. Mozilla quality assurance process rich hypermedia (cf. Carder et al. 2002)


257


testers will announce what they plan to test, down-load, and install the build and perform a seriesof smoke tests, security-specific (SSL) smoke tests,or less critical ‘general tests’ (periodic regressioncheckups), based on bug reports submitted to thebug repository. Testers note and discuss the resultsover the IRC channel. Critical bugs are identifiedand assigned to the on-the-hook developers to bepatched, whereupon the source is retested. Noncrit-ical bugs are set aside until another tester confirmsthem, uploaded to the Bugzilla defect repository,and further dealt with at a later time. Once all criticaldefects are corrected, the sheriff and build engineerreopen the source tree to further development andsource submission.

When first detected, defects are entered intoBugzilla as unconfirmed, noting their severity,component, and platform where the defect wasobserved. A member of the quality assuranceteam (either a QA contact or owner) must thenresearch the defect and certify it as a new defect ormarking it as a duplicate of another known defect.Patches are then created by developers during thecourse of development or by drivers as the releasedate approaches to ensure the overall quality ofthe product, and the status revised to reflect thechanges.

2.2. Process Flow Graph Modeling with theApache HTTP Server Release Process

The process flow graph illustrates the flow ofresources (development artifacts) through a pathof interaction. The interaction accounts for processagents using tools that manipulate the resourcesthrough performance of tool-based activities. Thissemistructured workflow representation provides apartial ordering of the process fragments and allowsus to tease out dependencies between artifacts andactivities seen in the rich hypermedia. It also offersan idea of which artifacts and activities are mostvital to development, by measuring the fan-in andfan-out of each.

These artifacts are likely to be the cause ofbottlenecks in the development process when theyare found to be inadequate, incomplete, or faultyresults of prior development activities. Borrowingfrom Web modeling terminology, an artifact thatis a hub or nexus for several activities will holdup development until it is completed or foundsatisfactory. Likewise, an artifact that is a product of

several inputs inhibits activities that require it untilit is ready for further processing. Additionally, wecan also detect cycles of development (re)work,such as in the stabilization process and refining thesoftware build release plan.

While these insights can be captured in otherrepresentational forms, this diagram, like the richhypermedia, provides an overall representationof the context for process activities without theweight of the details of more formal models.Process entities shown in the flow graph mayalso be hyperlinked to resources in the communityWeb to provide interactive richness, as well as toenable process inspection activities. Figure 2 showsa process flow graph for the Apache HTTPD Serverproject’s release process, where the boxes denoteprocess activities and ellipses denote the resourcesor artifacts flowing through the process. Further,software developer roles are associated with eachprocess activity.

As shown by this flow graph, in the Apacherelease process (Ata et al. 2002, Erenkrantz 2003),anyone can submit features or bug fixes in the formof patches to the server project. To be included inthe project source repository, a ‘committer’ who haswrite access to the repository must upload the code.These patches are uploaded to the developmentbranch of the repository. It may then be promoted tothe stable release branch by a vote of the committers.While any developer can vote on an item, only thevotes of primary author, committers, and membersof the project management committee are binding(Fielding 1999). To be promoted, there must be atleast three binding positive votes, and no vetoes.Further, for a release, there must be a majorityapproval (that is, at least three binding positivevotes, and more positive than negative votes).Granting a developer committer status requiresa complete consensus of the project managementcommittee.

When a committer decides to create a release,she/he typically sends an announcement to fellowdevelopers outlining the release plan, and statingwho the release manager will be. Acceptance of therelease plan requires a ‘lazy consensus’ approval ofthe committers2. As development moves towardscompletion, the release manager determines whichfeatures are fit for inclusion in the release and

2 http://httpd.apache.org/dev/guidelines.html


258


Figure 2. Apache HTTP server release process flow graph (cf. Ata et al. 2002)

which are not. Those that pass are compiledinto an alpha build, which is made available onthe community Web site and announced on thedeveloper mailing lists. Developers and committersare then called upon to test the build on their ownservers manually or through use of the automatedApache server test suite. Discovered defects aresent to the community development e-mail list (andpotentially submitted to Bugzilla) and patched bydevelopers and subsequently subjected to the patchreview process. In the stable source branch, releasesthat pass the committer vote usually skip the betaand release candidate phase and proceed to generalavailability.

When the release manager is adequately satisfiedwith quality of the source in the developmentbranch, she/he will declare the release suitablefor beta or final release candidacy. When she/heannounces this, the builds are made available onthe main page of the community Web and adoptedby a wider audience, for continued testing and

patching. At some point, the release manager deemsthe source fit for general public use and createsa general availability build release, announcing iton the development, committer, and tester mailinglists. This build is then voted on by the committersand tested on the Apache community Web site. Ifthere is a simple majority of approval and at leastthree positive votes, the release is declared final.The result is announced via the community Weband mailing lists, and then released for distributionvia a system of mirrored Web sites.

2.3. Formal Modeling and ReenactmentSimulation with the NetBeans Requirements andRelease Process

We developed formal models of software processesfollowing our preexisting process meta-model (Miand Scacchi 1996) using Protege-2000 knowledgeediting environment (Georgas 2002, Noy et al. 2001).The resulting models have the form of a semantic


259


web/hypertext (Noll and Scacchi 2001). The workdone here is identifying instances for all theprocess meta-model components: agents, resources,tools, actions, and activity control flows, whichwe represent using the Protege-2000 tool. Once aprocess instance is input, it may be exported to anXML format, a graphical representation using theOntoViz tool, or to our process modeling language,PML (Noll and Scacchi 2001).

Protege-2000’s editing and visualization facili-ties provide for a multitude of alternative viewsand visual rendering of the modeled process com-ponents, as well as their interrelationships anddependencies. As a result, the graphical renderingof a process model or process object-relation classviews can at times be more intuitive than a coded

textual format. Figure 3 shows a graphic represen-tation of an underlying PML model of the NetBeansRequirements and Release process that has beeninterpreted for visual rendering and layout of itsrelational interdependencies. However, the textualPML representation can be used as input to otherprocess engineering tools such as those supportingprocess enactment or process improvement.

The first step in the NetBeans requirements andrelease process (Oza et al. 2002, Jensen and Scac-chi 2003b) is to establish a release manager, a setof development milestones (with estimated com-pletion dates), and a central theme for the release.The theme is selected by the community mem-bers who have taken charge of the release, withthe goal of overcoming serious deficiencies in the

Figure 3. Visual rendering of the NetBeans requirements and release process formal model using Protege-2000


260


product (e.g. quality, performance, and usability),in addition to new features and corrective mainte-nance planned by module teams. Historically, mostreleases have been led by members employed bySun Microsystems, which provides developmentand financial support for the community, thoughvolunteer releases also occur. On the basis of this,and in conjunction with input from the featurerequest reports, lead developers will draft a releaseplan, providing the milestones, target dates, and fea-tures to be implemented in the upcoming release.After review and revision by the community, theplan is accepted and developers are asked to vol-unteer to complete the tasks outlined therein anda volunteer is sought to act as release managerand coordinate efforts of community. Usually, adeveloper will either volunteer or be volunteeredfor the role via the mailing list by and acceptsthe nomination or is accepted through communityconsensus.

All creative development must be completedby the feature freeze milestone date specified inthe release proposal, which signals the end ofthe requirements subprocess and the beginningof the stabilization phase, the release subprocess.At this point, only bug fixes may be submitted tothe source tree. The stabilization phase consistsof a build-test-debug cycle. Nightly builds aregenerated by a series of automated build scriptsand subsequently subjected to a series of automatedtest scripts, the results of which are posted tothe community Web site. Additionally, the qualityassurance team performs a series of automated andmanual testing every few weeks, as part of the Q-Build program with the aim of ensuring that sourcecode submitted regularly meets reasonable qualitystandards. Defects discovered during testing arethen recorded in the IssueZilla issue repository andsubsequently corrected. When the release branch isbelieved to be devoid of critical ‘show-stopping’defects, it is labeled a release candidate. If aweek passes without any further showstoppers, therelease candidate is declared final; else the defectis corrected and another release candidate is putforth. In addition to the formal depiction given inFigure 3, the NetBeans requirements and releaseprocess has also been reenacted. The motivation forthis is as follows.

Process analysis seeks to identify potential pit-falls that can be discovered before or after theirdeployment or adoption in a project. Process model

verifiers check static semantic properties such aswhether a resource required downstream is pro-vided by some upstream process activity (Atkinsonand Noll 2003). Process simulators provide dynamicanalysis capabilities through enactment or reenact-ment of processes, which are especially useful whenvalidating, modifying, or redesigning a process, aswell as for providing on-demand training (Scacchiand Mi 1997, Scacchi 2000, Atkinson and Noll 2003).

Our process enactment simulator (Choi and Scac-chi 2001, Noll and Scacchi 2001) interactively servesa series of Web pages, or links to multiple alternativepages, according to the control flow expressed in thePML model of the process flow graph. This simula-tor allows process performers and other communitymembers to simulate enacting the process througha step-by-step interactive walkthrough. With such areenactment simulator, developers within a projectmay be able to exercise, critique, and identifyimprovement opportunities within processes thatcan be observed at a distance. It also provides thepotential for a more easy transition from the sim-ulator to live process enactment transactions onthe community Web site.3 In doing so, we havebeen able to detect processes whose workflowsmay be ‘hidden’, unseen, or unfamiliar to projectparticipants with little/no involvement with theprocess. Similar analyses can also detect processflow segments that are unduly lengthy or otherwisesuboptimal, which may serve as good candidatesfor process improvement or redesign. It allows forviewing and detection of the effects of duplicatedwork by participants that may be unaware of suchduplication. Figure 4 thus displays a screen shotof one step during the reenactment of the Net-Beans requirements and release process (Jensenand Scacchi 2003b). This display shows the pro-cess decomposition on the left, the enactment step,and corresponding link traversal options next, andthen the enacted step’s invocation on the right.

With the above insight into the developmentprocesses executing within Mozilla, Apache, andNetBeans, we can now explore development pro-cesses between them.

3 For example, the NetBeans.org project posted a link to ourProSim’03 Workshop article (Jensen and Scacchi 2003) wheresome of these ideas were initially proposed and evaluated. Seehttp://www.netbeans.org/community/articles/UCI papers.html.


261


sequence Set Release Date {

...iteration Update IssueZilla { action Report Issues To IssueZilla { requires { Test results } provides { IssueZilla entry } tool { Web browser } agent { users, developers, Sun ONE Studio QA team, Sun ONE Studio developers } script { <a href="http://www.netbeans.org/issues/">Navigate to IssueZilla </a> <a href="http://www.netbeans.org/issues/query.cgi">Query IssueZilla </a> <a href="http://www.netbeans.org/issues/enter_bug.cgi">Enter issue </a> } }

...

The PML fragment (excerpt) that specifies a process step for the action, “Report Issues toIssueZilla”, corresponding to its reenactment below.

Figure 4. A step in the simulated process reenactment of the NetBeans requirements and release process (cf. Noll andScacchi 2001)


262


3. MODELING PROCESSES ACROSS WEBINFORMATION INFRASTRUCTUREPROJECTS

We would like to be able to model interorga-nizational processes using the same techniqueswe use to model intraorganizational processes:top–down modeling followed by bottom–up dis-covery. In intraorganizational process modeling,we often know a priori the types of activities, arti-facts, tools, and roles we are likely to see (Jensenand Scacchi 2003b). Subsequently, we can createa reference model describing how to classify theirinstances (Jensen and Scacchi 2003a). This guidesus in our search for process data within the soft-ware development artifacts available for study. Inmodeling interorganizational processes used acrossprojects in the Web information infrastructure, wehave no such reference model. Instead, we firststep back and examine the types of relationshipsthat exist between organizations. Management andinformation systems research give us tools to char-acterize the types and extent of interorganizationalprocesses. We show how to identify stakehold-ers (boundary agents) and objects of interaction(boundary objects), and their concerns, modelingthem as a rich hypermedia. Next, we examine com-munication processes between organizations, as aremodeled in flow diagrams, as described previously.These can be then modeled formally, and reenacted

via simulation. Finally, we apply this strategy in adetailed example.

3.1. Characterizing Interoperation Among WebInformation Infrastructure Projects

Successful interoperation between components ofa Web information infrastructure depends on therelationships between the organizations of whichit is comprised. Traditional management literature(Bluedorn et al. 1994) identifies six mechanisms ofinterorganizational interoperation or integration,which entail loose or tight coupling. These mech-anisms include joint ventures, network structures,federation, cooperative agreements, trade associa-tions, and interlocking directorates (see Table 1).Though originally devised to describe corporateand government interorganizational relationships,our choice is to apply them to provide an over-all characterization of a software ecosystem for, inthis case, the Web infrastructure. Unsurprisingly,the degree of coupling carries implications for thedegree of process integration between these orga-nizations. Alter (1999) defines degrees of processintegration (ranging from loose to tight coupling)to include sharing a common culture, utilizingcommon standards, information sharing, coordi-nation, and finally collaboration, as described inTable 2. Together, these give us a basic frame-work for examining the types of processes we can

Table 1. Interorganizational synchronization and stabilization mechanisms (after Bluedorn et al. 1994)

Interorganizationalform

Example Tightness of coupling

Joint venture Apache, GNU foundation members Tightly coupled. Two or more firms form a separate entity fora variety of strategic purposes (e.g. market power, efficiency,transfer of learning).

Network structure System plug-in developers Tightly coupled. A hub and wheel configuration with a focalfirm at the hub organizing interdependencies of a complexarray of firms.

Federation Mozilla ‘on-the-hook’ developers Tightly coupled. Established to manage and coordinate theactivities of affiliated members (common in hospitals). Thefederation controls all or part of the management activities ofthe members.

Cooperative agreements Meta-communities (e.g. JTC) Loosely coupled. Arrangements between two or more firmsthat have strategic purposes, but do not have sharedownership.

Trade associations Tool integration Loosely coupled. Distribute trade statistics, analyze industrytrends, offer legal and technical advice, and provide aplatform for collective lobbying.

Interlocking directorates NetBeans governance/communitymanagement

Loosely coupled. Information sharing, expertise and enhancedorganizational reputation.


263


Table 2. Levels of business process integration (cf. Alter 1999)

Level Example Description

Common culture OSSD motivations, developmentmethods

Shared understandings and beliefs

Common standards Data formats, communicationprotocols

Using consistent terminology and procedures to makebusiness processes easier to maintain and interface

Information sharing OSSD Web repositories Access to each other’s data by business processes thatoperate independently

Coordination Meta-communities, tool integration,plug-in development

Negotiation and exchange of messages permittingseparate, but interdependent, processes to respond toeach other’s needs and limitations

Collaboration NetBeans, Mozilla spell-checkingmodule development

Such strong interdependence that the unique identity ofseparate processes begins to disappear

expect to find in the Web infrastructure. Further,they provide the constructs of the rich hyperme-dia: interacting members of the Web infrastructure(stakeholders), their relationships, and the motiva-tions of these relationships (concerns). Identificationof these stakeholders, relationships, and concernsrequires analysis of the interprocess communica-tion among infrastructure projects. We address thisnext.

3.2. Interprocess Communication Among WebInformation Infrastructure Projects

Communication between project communities pro-vides opportunities both for integration and sourcesof conflict between them (Elliott and Scacchi 2003,Jensen and Scacchi 2004). We will say communi-cation is integrative if it identifies compatibilitiesor potential compatibilities between developmentprojects. From a process perspective, integrativecommunication enables external stakeholders tocontinue following their internal process as normal,perhaps with a small degree of accommodation.They also reinforce infrastructural processes sincethey do not require changes in the interoperationsbetween communities. If the degree of accom-modation or adaptation becomes too great, thiscan precipitate conflictive communication betweenproject communities. Conflict may occur due tochanges in tools or technologies shared betweenthem, or in contentious views/beliefs for how bestto structure or implement new functionality or datarepresentations across projects. These conflicts mayrequire extensive process articulation to adapt (cf.Scacchi and Mi 1997). Sections 4.2.1 and 4.2.2 take acloser look at process integration and conflict, fol-lowed by a discussion of how these processes arediscovered and modeled.

3.2.1. Process IntegrationProcess integration can be direct and explicit, as inthe case where NetBeans and Mozilla communitymembers collaborated on a spell-checking module.But, it can also be indirect and implicit. For Mozilla’sbrowser to correctly present Web artifacts, it mustimplement both protocols for processing Web trans-actions to the Apache server, and also standards fordisplaying content of the document or object typesgenerated by NetBeans IDE. Similarly, the NetBeansIDE must produce artifacts and applications formsthat artifact consumers, including Mozilla’s browserand Apache’s server, expect. The Apache server, forits part, must comply with the standard transac-tion protocol the Mozilla browser anticipates (e.g.HTTP/1.1) and provide Web application modulesupport required by applications produced by theNetBeans IDE. Although these communities maynot have explicitly negotiated and agreed on com-mon data standards to be used between them, theyhave individually implemented standards providedand maintained by outside parties – particularly,the W3C, the World Wide Web Consortium.

These standards can be viewed as objects of inter-action or boundary objects4 (Star 1989, Pawlowskiet al. 2000). Following Alter’s (1999) classification,shared standards connote a low degree of processinteraction between organizations in the Web infras-tructure. However, other boundary objects exist, asshown in Table 3. Within OSSD project commu-nities of the Web infrastructure, boundary objectsinclude (a) shared beliefs and culture (Elliott andScacchi 2003), (b) community infrastructure tools,

4 Boundary objects are those that inhabit and span severalcommunities of practice, as well as satisfy the informationalrequirements of each community (Star 1989).


264


Table 3. Boundary objects of the Web information infrastructure

Object type Example

Community infrastructures

Community culture/bylaws Source licenses, governance style, community organizational compositionCommunity infrastructure tools Defect repositories (e.g. Bugzilla, IssueZilla), collaborative development tools

(e.g. WIKI, CVS, mail list managers)Development processes Defect discovery/submission procedures, source check-in procedures

Product infrastructureProduct infrastructure tools Plug-ins, modules, librariesDevelopment artifacts/software informalisms Software documentation, how-to guides, design styles (e.g. P2P, client-server)Protocols HTTP, RPCsShared data formats HTML, CGI, XML

such as defect repositories produced by other affil-iated organizations (Halloran and Scherlis 2002),and (c) development processes. Additional bound-ary objects are found in the product infrastructure(e.g. applications program interfaces and remoteprocedure calls that enable data sharing and remoteinvocation of software modules across systems).These may take the form of software applicationplug-ins or modules. The Java-based Tomcat WebServer, created by the Apache community andintegrated into the NetBeans IDE, is one exam-ple. They may share or coordinate developmentartifacts. And, as discussed, they may implementor utilize common data communication protocolsand data representation formats that enable reliablecommunication between their tools. Although nostructure is implied by the modeling paradigm, ourrich hypermedia has traditionally featured devel-opment tools at the center of intraorganizationalprocess models. In modeling the Web informa-tion infrastructure, we have expanded our view toinclude other types of boundary objects, as shownin Figure 5a.

While certain boundary objects indicate a degreeof interaction between processes in the Web infras-tructure, it is yet unclear how this interaction playsout. As long as each member of the infrastructureadheres to these standards, they may choose to oper-ate independently, following their individual pro-cesses as usual. However, the Web infrastructure isnot a static network of interacting objects or a singlecoherent virtual enterprise. Commonly held stan-dards change to meet evolving needs. Relationshipsbetween interacting software system developed byotherwise independent OSSD projects help adaptto infrastructure changes. Such relationships mayrequire tighter coupling at the level of integration

or explicit collaboration between organizationalprocesses. By synchronizing their communicationprotocols and common data representations withone another through the process integration mecha-nisms of their choice, they stabilize the network.When an individual community varies from astandard or implements an update/revision to anexisting standard, the other communities act to sup-port it or choose to reject it. Likewise, defects in datarepresentations or operations of one Web infras-tructure software system can cause breakdowns ornecessitate workarounds by the others. We look atthe causes and negotiations of these conflicts next.

3.2.2. Process ConflictProcess conflict can precipitate or follow from pro-cess breakdown, disarticulation, or disintegration.Conflictive activities often arise from organiza-tions competing for market share and control ofthe technical direction of infrastructure and sharedtechnologies. It also arises from common and lessbelligerent activities, such as introducing a new ver-sion of a tool or database that other organizationsdepend on, requiring massive effort to incorporate.In these cases, the organization placed into conflictmay simply choose to reject adopting the new toolor technology alterations, possibly selecting a suit-able replacement tool/technology if the current oneis no longer viable. This path was chosen by theshareware/open source image editing communityinfrastructure due to patent conflicts with the GIFimage format in the 1990s, leading to the creation ofthe portable network graphics (PNG) image formatstandard5.

5 http://cloanto.com/users/mcb/19950127giflzw.html


265


(a)

(b)

Figure 5. (a) Rich hypermedia modeling of processes spanning web information infrastructure projects.(b) Intercommunity interprocesses communication flow spanning Web information infrastructure projects. (c) FormalPML, (d) and reenactment models of processes spanning Web information infrastructure projects


266


Process Web Information Infrastructure Evolution (excerpt)

... Sequence Mozilla Processes{ Action Release Bugzilla Defect Repository{ ...} ... } Sequence Tigris.org Processes{ Sequence Create IssueZilla{

Action Download Bugzilla Sources{ ... } Iteration Modify Bugzilla/IssueZilla Sources{ ... }Action Release IssueZilla Issue Repository{...}

}... }... Sequence NetBeans Processes{ ...

Sequence Deploy IssueZilla issue repository{ ... } ... Sequence NetBeans Development Process{

Action Submit Issues to IssueZilla{ ... } Action Detect Inefficiency/Problems with IssueZilla{

Requires { Issue reports } Provides { Problem description } Agents { NetBeans developers } Tools { HTTP Web browser implementation, IssueZilla deployment }

Script { <a href=http://qa.netbeans.org/processes/bug-handling-guidelines.html>Developers notice that IssueZilla cannot track bugs across versions</a> <a href=http://www.netbeans.org/servlets/ReadMsg?listName=nbdiscuss&msgId=333146>Developers bring up the matter on community mailing lists/message forum</a> }

}Action Determine Possible Workarounds/Solutions{

Requires { Problem description } Provides { List of workarounds/solutions } Agents { NetBeans developers } Tools { HTTP Web browser implementation, IssueZilla deployment, developer, community discussion

message forums } Script { <a href=http://www.netbeans.org/servlets/ReadMsg?listName=nbdiscuss&msgId=389086>Discuss

workaround viability</a> <a href=http://www.netbeans.org/servlets/ReadMsg?listName=nbdiscuss&msgId=331896>Discuss workaround viability</a> } }

(d)

(c)

Figure 5. (Continued)


267


Conflicts across OSSD projects that get resolvedare done so through collaborative means. Mosttypically, this occurs through the exchange ofmessages between participants (message threads)communicated on project discussion forums orother computer-mediated communication systems(e-mail, chat, instant messaging, etc.). Alternatively,an organization causing or resisting a tool or tech-nology may succumb to pressure exerted by supportfrom the rest of the infrastructure. Irreconcilable dif-ferences, if they persist and are strongly supported,can lead to unresolved conflicts (e.g. softwareupdates that do not get implemented), incompat-ibilities in the interoperating software systems, orpossibly to divisions in the infrastructure.

3.2.3. Discovering Interprocess Communication AcrossWeb Information Infrastructure ProjectsThough instances of direct communication betweenorganizations within the infrastructure are visible(e.g. NetBeans and Mozilla developers collaboratingon spell-checking module), indirect communicationappears the more prevalent method. We see itin the form of version changelogs announcingsupport (and changes in support) for tools andtechnologies integrated into development. It mayalso appear in defect/feature request repositories, e-mail discourse, and community newsletters withinthe respective community Web sites, in additionto external news sources (e.g. slashdot.org andfreshmeat.org). Communities must monitor theseinformation sources to assess their degree of impactand whether the impact is directly or indirectlyintegrative or conflictive. NetBeans, for example,uses the IssueZilla bug/feature request repositorydeveloped by the Tigris community, which is, inturn, an extension of Mozilla’s Bugzilla tool (seeFigure 5b). Detecting indirect communications andtheir relationships to development process activitiescan be as simple as entering community specificterms, such as ‘Mozilla’, in the Search functioninput field on the NetBeans main Web page.6

This action will search the NetBeans communityWeb site for instances of artifacts (e.g. projectWeb pages or forum postings) that contain theterm Mozilla. The returned search results providelinks to development artifacts or boundary objectsassociated with different development releases,

6 http://www.netbeans.org/

bug reports, software module (in)compatibilities,or external (user) functionality assessments. Inother cases, process communication can be nearlyimpossible to detect if no evidence is publiclyavailable or is too circumstantial to validate.

3.2.4. Modeling Interprocess Communication AcrossWeb Information Infrastructure ProjectsSynchronization and stabilization of shared arti-facts, data representations, and operations or trans-actions on them are required for a common informa-tion infrastructure to be sustained. This process isnot ‘owned’ (Larsen and Klischewski 2004), locatedwithin, or managed by a single organization orvirtual enterprise. Instead, it represents a collec-tively shared set of activities, artifacts, and patternsof communication that are enacted across the par-ticipating communities. Thus, it might better becharacterized as an ill-defined, ad hoc, or one-offboundary-spanning process that differs in formwith each enactment. Consequently, the form ofthese processes is dynamic and emergent, ratherthan static and recurring. Modeling such one-offprocesses thus must be justified, since they occurinfrequently and do not reoccur. As such, ourapproach to modeling trades off representationaldetail of individual process forms, and insteaduses a more abstract, low-fidelity representation(Atkinson et al. 2004). This is done so as to onlymodel (or suggest) an abstract set of relationshipsof interaction, whose individual elements would becomposed anew for each enactment.

Community communication channels (i.e. recur-ring patterns of communication of shared arti-facts, data representations, or protocols) can beused to connect the interprocess resources flowsbetween interoperating communities within theWeb infrastructure. Each channel between com-munities connotes ad hoc processes that articulatethe interoperability or interdependence of tools andtechnologies between them, as well as the boundaryobjects shared between them. The Web informa-tion infrastructure development process can there-fore be characterized by the communication flowthat enables integration or conflict process activ-ities between constituent projects. Figure 5b illus-trates some of the interorganizational relationshipswe have uncovered across the NetBeans, Mozilla,and Apache organizations, spanning many of themechanisms of interorganizational interoperationdescribed by Bluedorn and associates (1994), as


268


well as the degrees of process integration outlinedby Alter (1999) as a low-fidelity resource flow graph.Subsequently, these communication channels thatenable interoperation and interdependence can berepresented as a rich hypermedia, a low-fidelityresource flow graph, or as a low-fidelity formal pro-cess model, as shown in the examples of Figure 5. Anarrative of the NetBeans IssueZilla issue trackingtool integration process depicted is these modelsfollows.

3.3. Example: NetBeans IssueZilla Integration

The NetBeans community Web site is hosted bySun Microsystems utilizing the commercially avail-able collaborative development environment andWeb portal software from Collab.net. Collab.netin turn utilizes the IssueZilla open source issuetracking system (sometimes also called ‘issuetrack’).Thus, the NetBeans project community has a recip-rocal trading relationship (see Table 1) – in thiscase a producer–consumer relationship – with theTigris.org community. Tigris.org has a similar rela-tionship with Mozilla. As such, any changes made,defects discovered, and documentation providedby Tigris.org and Mozilla may provide occasionfor integration and conflict processes between Net-Beans and the Tigris.org and Mozilla communities.One such occasion occurred in April of 2001. Net-Beans developers noticed an inability to track issuesacross multiple versions and branches of the sourcetree7. This caused interorganizational coordinationproblems as they needed to know what techni-cal problems existed in the previous version. Inresponse to this and other less serious imperfec-tions of Bug/IssueZilla system, NetBeans devel-opers were forced to come up with workaroundsuntil a new issue tracking system could be adopted.These workarounds involved storing the versioninginformation in heretofore-unused meta-data fieldsin each bug report, and implementing a transitionplan for this new bug submission process. Unlikeintegration and conflict situations that arise fromchanges to the organizational network, the circum-stances that created the need for a workaroundled to a process adaptation within NetBeans thatarose from an inability for existing network state toinnately handle the changing needs of the NetBeans

7 See: http://qa.netbeans.org/processes/bug-handling-guide-lines.html

community. The adaptation process proceeded asfollows.

Upon realizing the inadequacy of the issuerepository, and following discussion thereof on themailing lists8, core developers posted an updateto the bug-handling guidelines community Webpage, announcing the nature of the problem andpossible solutions. This was followed by discussionon the mailing lists of the desirability of thesolutions presented9. Being an open source toolitself, some developers considered trying to modifythe IssueZilla tool; however, development on it hadceased10, the source from Bugzilla had long beenforked11, and the only available source versionswere very complex12. In the end, the decisionwas made to alter the issue submission policy touse a previously unused field in the issue reportto store the version-specific data as a stopgapsolution, until a new defect repository was adopted.Though the inadequacy of the issue repository wasreported in April 2001, the community still awaitsthe deployment of a new issue repository. Figure 5provides rich hypermedia, process flow graph, andformal PML, and reenactment representations ofthis process.

4. DISCUSSION

The Apache, Mozilla, and NetBeans project com-munities are three prominent members of a largerorganizational ecosystem that constitutes the Webinfrastructure. In the space of software develop-ment, this ecosystem forms a development domain:the Web information infrastructure. Other promi-nent members of this ecosystem include OpenOf-fice.org, Tigris.org, Microsoft, IBM, the JCT, theW3C, and the Java Community Process (JCP). Thethree communities are the focus of our process mod-eling effort because they are developing large-scalesoftware systems and related products through

8 http://www.netbeans.org/servlets/ReadMsg?listName=nbdiscuss&msgId=3331469 http://www.netbeans.org/servlets/ReadMsg?listName=nbdev&msgId=7921510 http://www.netbeans.org/servlets/ReadMsg?listName=nbdiscuss&msgId=38885411 http://www.netbeans.org/servlets/ReadMsg?listName=nbdiscuss&msgId=38908612 http://www.netbeans.org/servlets/ReadMsg?listName=nbdiscuss&msgId=331896


269


complex processes that integrate efforts of tens ofthousands of developers with millions of users. Atthe same time, the ecosystem is not static. The com-munities, and different OSSD projects within them,rise and fade from prominence. As they increasein mass (membership) and interconnectivity, theycreate a sense of both gravity and inertia aroundthem, and other organizations may seek integra-tive relationships. While closed source projects tendto enjoy tightly coupled integration with relativelyfew counterparts, OSSD communities tend towardsloosely coupled interoperability with many coun-terparts. The effect of this is that there are likelymany more organizations impinging on the ecosys-tem with more complex, but weaker, bindings thanthose of proprietary system relationship networks,which may well be sparser and rely on more stableties enforce through contractual arrangements orpartnerships.

5. CONCLUSION

In this article, we described techniques and issuesin modeling software processes used within threelarge and interdependent open source softwaredevelopment communities. The software devel-oped in these communities form an informationinfrastructure for creating, serving, and consumingWeb artifacts. We described an approach to mod-eling software development processes within andacross these communities, as well as issues andtrade-offs that arise along the way. Our approachdraws attention to the need to model such pro-cesses using informal, semistructured, and formalprocess modeling techniques and representations,as well as to reenact them using a process simula-tor. We demonstrated how development processeswithin these communities interact in terms of adhoc or fragmentary processes across communitiesthrough the direct or indirect flow of developmentartifacts found on each community’s Web sites.This helps show the potential for the use of Web-based artifacts like rich hypermedia, resource flowgraphs, and semantic web/hypertext models to cap-ture and specify the processes of OSSD projectsin the Web information infrastructure. We believethis promotes a more comprehensive, multimodelunderstanding of the processes rendered, as well asoffering insights for the application of additionalprocess improvement tools and techniques. The

results presented here suggest a need for additionalwork in discovering, modeling, simulating, andanalyzing interorganizational software processes.Our classification framework is rooted in a moretraditional, closed source software developmentparadigm. But, are interorganizational relationshipsand their associated processes changing with theinvolvement of nontraditional software develop-ment organizations? Do these factors differ acrosssoftware ecosystems? Finally, how can these lessonsbe applied to devising and improving interorgani-zational processes? Questions such as these denoteissues to be addressed in follow-on studies that seekto model software processes that span independentprojects in different organizations. After processes?

ACKNOWLEDGEMENTS

The research described in this report is sup-ported by grants #0083075, #0205679, #0205724, and#0350754 from the US National Science Foundation.No endorsement implied. Contributors to workdescribed in this article include Mark Ackerman atthe University of Michigan Ann Arbor; Les Gasserat the University of Illinois, Urbana-Champaign;John Noll at Santa Clara University; John Geor-gas, Maulik Oza, Eugen Nistor, Susan Hu, BryceCarder, Baolinh Le, Zhaoqi Chen, Veronica Gasca,Chad Ata, Michele Rousseau, and Margaret Elliottat the UCI Institute for Software Research.

REFERENCES

Alter S. 1999. Information Systems, A ManagementPerspective, 3rd edn. Addison-Wesley: Reading, MA.

Ata C, Gasca V, Georgas J, Lam K, Rousseau M. 2002. TheRelease Process of the Apache Software Foundation,http://www.ics.uci.edu/∼michele/SP/index.html [10January 2005]

Atkinson D, Noll J. 2003. Automated validation andverification of process models. Proceedings of the 7thInternational IASTED Conference on Software Engineeringand Applications, Marina del Ray, CA.

Atkinson DC, Weeks DC, Noll J. 2004. The design ofevolutionary process modeling languages. Proc. 11thAsia-Pacific Software Engineering Conference, Busan, Korea,587–592.

Bluedorn A, Johnson R, Cartwright D, Barringer B. 1994.The interface and convergence of the strategic


270


management and organizational environment domains.Journal of Management 20(2): 201–262.

Carder B, Le B, Chen Z. 2002. Mozilla SQA and ReleaseProcess, http://www.ics.uci.edu/∼acarder/225/ [10January 2005]

Choi JS, Scacchi W. 2001. Modeling and simulatingsoftware acquisition process architectures. Journal ofSystems and Software 59(3): 343–354.

Cusumano M, Yoffie D. 1999. Software development oninternet time. Computer 32(10): 60–69.

Elliott M, Scacchi W. 2003. Free software developersas an occupational community: resolving conflicts andfostering collaboration. Proceedings of ACM InternationalConference on Supporting Group Work, Sanibel Island, FL,21–30.

Erenkrantz J. 2003. Release management within opensource projects. Proceedings of the 3rd Workshop on OpenSource Software Engineering, Portland, Oregon, 51–55.

Fielding RT. 1999. Shared leadership in the Apacheproject. Communications of the ACM 42(4): 44–45.

Fielding RT, Whitehead EJ, Anderson KM, Bolcher GF,Oriezy P, Taylor RN. 1998. Web based development ofcomplex information products. Communications of theACM 41(8): 84–92.

Fowler M, Scott K. 2000. UML Distilled: A Brief Guide tothe Standard Object Modeling Language, 2nd edn. AddisonWesley: Reading, MA.

Georgas J. 2002. Software Process Modeling with Protege.University of California: Irvine, CA. 9 June, 2002.http://www.ics.uci.edu/∼jgeorgas/ics225/index.htm[10 January 2005]

Halloran T, Scherlis W. 2002. High quality and opensource software practices. Proceedings of the 2nd Workshopon Open Source Software Engineering, Orlando, FL.

Jensen C, Scacchi W. 2003a. Applying a referenceframework to open source software process discovery.Proceedings of the First Workshop on Open Source in anIndustrial Context, Anaheim, CA, 39–42.

Jensen C, Scacchi W. 2003b. Simulating an automatedapproach to discovery and modeling of open sourcesoftware development processes. Proceedings of ProSim’03Workshop on Software Process Simulation and Modeling,Portland, OR.

Jensen C, Scacchi W. 2004. Collaboration, leadership,control, and conflict negotiation in the NetBeans.orgcommunity. Proceedings of the Fourth Workshop on OpenSource Software Engineering ICSE04-OSSE04, Edinburgh,Scotland, 48–52.

Larsen MH, Klischewski R. 2004. Process ownership chal-lenges in IT-enabled transformation of interorganiza-tional business processes. Proceedings of the 37th AnnualHawaii International Conference on System Sciences, BigIsland, Hawaii.

Lenz K, Oberweis A. 2001. Modeling interorganizationalworkflows with XML nets. Proceedings of the 34th AnnualHawaii International Conference on System Sciences, Maui,Hawaii, on CD.

Mi P, Scacchi W. 1996. A meta-model for formulatingknowledge-based models of software development.Decision Support Systems 17(4): 313–330.

Mockus A, Fielding R, Herbsleb J. 2002. Two case studiesof open source software development: Apache andMozilla, ACM Transactions on Software Engineering andMethodology 11(3): 1–38.

Monk A, Howard S. 1998. The rich picture: a tool forreasoning about work context. Interactions 5(2): 21–30.

Noll J, Scacchi W. 1999. Supporting software develop-ment in virtual enterprises. Journal of Digital Informa-tion 1(4): http://jodi.ecs.soton.ac.uk/Articles/v01/i04/Noll/[10 January 2005].

Noll J, Scacchi W. 2001. Specifying process-orientedhypertext for organizational computing. Journal ofNetwork and Computer Applications 24(1): 39–61.

Noy NF, Sintek M, Decker S, Crubezy M, Fergerson RW,Musen MA. 2001. Creating semantic web contents withprotege-2000. IEEE Intelligent Systems 16(2): 60–71.

Oza M, Nistor E, Hu S, Jensen C, Scacchi W. 2002. A FirstLook at the NetBeans Requirements and Release Process,http://www.ics.uci.edu/cjensen/papers/FirstLook-NetBeans/ [10 January 2005]

Pawlowski S, Robey D, Raven A. 2000. Supporting sharedinformation systems: boundary objects, communities, andbrokering. Proceedings of the Twenty First InternationalConference on Information Systems, Brisbane, Queensland,Australia.

Rasch RH, Hansen JV. 1997. A design approachfor analyzing interorganizational information systems.Annals of Operations Research 71(1): 95–113.

Scacchi W. 2000. Understanding software processredesign using modeling, analysis and simulation.Software Process–Improvement and Practice 5(2/3): 183–195.

Scacchi W. 2002. Understanding the requirementsfor developing open source software systems. IEEProceedings – Software 149(1): 24–39.

Scacchi W, Jensen C, Noll J, Elliott M. 2005. Multi-ModalModeling of Open Source Software Requirements Processes,


271


Proceedings of the 1st International Conference on Open SourceSystems, Genova, Italy.

Scacchi W, Mi P. 1997. Process life cycle engineering:a knowledge-based approach and environment.International Journal of Intelligent Systems in Accounting,Finance, and Management 6(1): 83–107.

Shen M, Liu D. 2001. Coordinating interorganizationalworkflows based on process-views. Lecture Notes inComputer Science 2113: 274–283.

Star SL. 1989. The structure of Ill-structured solutions:boundary objects and heterogeneous distributed problem

solving. In Distributed Artificial Intelligence, Vol. 2.,Gasser L, Huhns MN (eds.). Pitman: London, 37–54.

van der Aalst WMP. 2002a. Inheritance of interorga-nizational workflows to enable business-to-business E-commerce. Electronic Commerce Research 2(3): 195–231.

van der Aalst WMP. 2002b. Inheritance of interorgani-zational workflows: how to agree to disagree withoutloosing control? Information Technology and ManagementJournal 2(3): 195–231.


272

Documents

Process modeling across the web information infrastructure