1

Collaboration, Leadership, Control, and Conflict Negotiation in theNetbeans.org Open Source Software Development Community

Chris Jensen and Walt ScacchiInstitute for Software Research

Donald Bren School of Information and Computer SciencesUniversity of California, IrvineIrvine, CA, USA 92697-3425{cjensen, wscacchi}@ics.uci.edu

Abstract

Large open source software developmentcommunities are quickly learning that, to besuccessful, they must integrate efforts not onlyamong the organizations investing developerswithin the community and unaffiliated volunteercontributors, but also negotiate relationships withexternal groups hoping to sway the social andtechnical direction of the community and itsproducts. Leadership and control sharing acrossorganizations and individuals in and betweencommunities are common sources of conflict.Such conflict often leads to breakdowns incollaboration. This paper seeks to explore thenegotiation of these conflicts, collaborativeefforts, and leadership and control structures inthe Netbeans.org community.

Keywords

Collaboration, Conflict Negotiation, Leadership,Process, Open Source Software Development,Netbeans.org

1. Introduction

Is open source software development (OSSD)best characterized as being strictly cooperative, oras cooperative and in conflict at the same time[Easterbrook 1993]? Conflict clearly arises duringsustained software development efforts [e.g.,Sawyer 2001]. But previous studies of conflictassociated with Internet-based communities hasfocused attention to that found in specific OSSDprojects operating as virtual organizations [Elliottand Scacchi 2003], as non-profit foundations[O'Mahony 2004], or in online discussioncommunities [Smith 1999]. None of these studiesspecifically help us understand the kinds ofconflict, cooperation, and collaboration that arisesor is needed to coordinate large-scale OSSDprocesses and effort in large project communities

where corporate sponsorship may be a central facetof OSSD.

NetBeans.org is one of the largest OSSDcommunities around these days [cf. Jensen andScacchi 2003]. Netbeans.org is a Java-focusedOSSD community backed by Sun Microsystemsdevoted to creating both an integrated developmentenvironment (IDE) for developing large Java-basedapplications, as well as a platform for developmentof other software products. Originally started as astudent project in 1996, the Netbeans.org projectwas acquired and subsequently released as an opensource community project by Sun, whoseNetbeans.org team includes many of thecommunity's core developers. While the issuespresented here stem from observations in theNetbeans.org community, they are by no meanslimited to this community, nor have theirchallenges been insurmountable.

Our study focuses on three items. First, weidentify the objects of interaction amongparticipants in the NetBeans.org community thatare media through which collaboration, leadership,control and conflict negotiation are expressed andenacted. Second, we explore relationships arisingin NetBeans.org on an intra-community level.Then, we look at relationships betweencommunities like Netbeans.org and othercommunities and organizations.

2. Objects of Interaction

Much of the development work that occurs in anopen source software project centers around thecreation, update, and other actions (e.g., copy,move, delete) applied to a variety of softwaredevelopment artifacts. These artifacts serve ascoordination mechanisms [Schmidt and Simone1996, Simone and Mark 1999], in that they helpparticipants communicate, document, andotherwise make sense of what the emerging

2

software system is suppose to do, how it shouldbe or was accomplished, who did what, what wentwrong before, how to fix it, and so forth.Furthermore, within a project community theseartifacts help coordinate local, project-specificdevelopment activities, whereas between multipleproject communities, these artifacts emerge asboundary objects [Star 1990] through which inter-community activities and relations are negotiatedand revised. The artifacts may take the form oftext messages posted to a project discussion list,Web pages, source code directories and files, sitemaps, and more, and they are employed as theprimary media through which softwarerequirements and design are expressed. These“software informalisms” [Scacchi 2002] areespecially important as coordination mechanismsin OSSD projects since participants generally arenot co-located, they do not meet face-to-face, andauthority and expertise relationships amongparticipants is up for grabs.

The NetBeans IDE is intended to support thedevelopment of Web-compatible Javaapplications. In the context of the NetBeans.orgproject and its role within a larger Web-compatible information infrastructure, additionalartifacts come into play within and acrossprojects. These include the content transferprotocols like the HyperText Transfer Protocol(http) which are systematically specified inInternet standards like RFC documents, as well asmore narrowly focused communication statecontrollers associated with remote procedure calls(or remote method invocations). They alsoinclude shared data description formats like theHyperText Markup Language (html) and theeXtensible Markup Language (XML), as well asclient-side or server-side data processing scripts(e.g., CGI routines). Such descriptions may befurther interpreted to enable externally developedmodules to serve as application/module plug-ins,which enable secondary or embedded applicationsto be associated with an OSS system. Otherartifacts are brought in from other OSSD projectsto serve as project support tools, such as thoseused to record and store system defect (bug)reports (Issuzilla), email list managers, and evenlarge comprehensive collaborative softwaredevelopment environments and project portals,like SourceCast [Augustin, Bressler, and Smith2002]. Finally, OSSD projects may share bothstatic and operational artifacts in the course ofcollaborating or cooperating through mutuallyintelligible and interoperable developmentprocesses, which might take an explicit form likethe Java Community Process (JCP), or an implicitand embedded form such as that which emerges

from use of project repositories whose contentsare shared and synchronized through tools thatcontrol and track alternative versions (CVS), bugreports, or Web site content updates.

Accordingly, in order to explore where issues ofcollaboration, leadership, control and conflict mayarise within or across related OSSD projects, thenone place to look to see such issues is in howproject participants create, update, exchange,debate, and make sense of the softwareinformalisms that are employed to coordinatetheir development activities. This is the approachtaken here in exploring the issues both within theNetBeans.org project community, as well asacross the (fr)agile ecosystem [Highsmith 2002]of inter-related OSSD projects that situateNetBeans.org within a Web informationinfrastructure.

3. Intra-Community Issues

As noted in the first section, NetBeans.org is alarge and complex OSSD project. To help convey asense of the complexity, semi-structured modelingtechniques such as rich pictures [Monk andHoward 1998] can be used to provide a visualoverview of the context that situates the creationand manipulation of the software informalisms andOSSD processes that can be observed in theNetBeans.org project [Oza, et al, 2002]. Figure 1displays such a rich picture, highlighting the varietyof roles that participants in the NetBeans.orgproject perform, the types of concerns they have ineach role, and the development tasks theyregularly enact, as part of the configuration ofOSSD activities they articulate and coordinatethrough software informalisms [cf . Simone andMark 1999].

We have observed at least three kinds of issuesarise within an OSSD community likeNetBeans.org. These are collaboration, leadershipand control, and conflict.

3.1. Collaboration

According to the Netbeans.org communityWeb site, interested individuals may participate inthe community by joining in discussions onmailing lists, filing bug and enhancement reports,contributing Web content, source code, newsletterarticles, and language translations. These activitiescan be done in isolation, without coordinating withother community members, and then offered up forconsideration and inclusion. As we’ll see, reducingthe need for collaboration is a common practice inthe community that gives rise to positive and

3

negative effects. We discuss collaboration in termsof policies that support process structures thatprevent conflict, looking at task completionguidelines and community architecture.

3.1.1. Policies and Guidelines

The NetBeans.org community has detailedprocedural guidelines1 for most commondevelopment tasks, from submitting bug fixes touser interface design and creating a new release.These guidelines come in two flavors: developmenttask and design style guidelines. In general, thesepolicies are practiced and followed withoutquestion. Ironically, the procedures for policyrevision have not been specified.

Precedent states that revisions are brought upon the community or module discussion mailinglists, where they are debated and either ratified orrejected by consensus. Developers are expected totake notice of the decision and act accordingly,while the requisite guideline documents areupdated to reflect the changes. In addition, as somecommunities resort to “public flogging” for failureto follow stated procedures, requests for revisionare rare and usually well known among concernedparties, so no such flogging is done withinNetbeans.org.

Overall, these policies allow individualdevelopers to work independently within a processstructure that enables collaboration by encouragingor reinforcing developers to work in ways that areexpected by their fellow community members, aswell as congruent with the community process.

3.1.2. Separation of Concerns: an ArchitecturalStrategy for Collaborative Success

Software products are increasingly developinga modular, plug-in application program interface(API) architectural style in order to facilitatedevelopment of add-on components that extendsystem functionality. This strategy has beenessential in an open source arena that carriesfreedom of extensibility as a basic privilege or, insome cases, the right of free speech or freedom ofexpression through contributed source code. Butthis separation of concerns strategy for codemanagement also provides a degree of separationof concerns in developer management, andtherefore, collaboration.

In concept, a module team can take the plug-in

1http://www.netbeans.org.org/community/guidelines/

API specification and develop a modular extensionfor the system using any development process incomplete isolation from the rest of the community.This ability is very attractive to third-partycontributors in the Netbeans.org community whomay be uninterested in becoming involved with thetechnical and socio-political issues of thecommunity, or who are unwilling or unable tocontribute their source code back to thecommunity. Thus, this separation of concerns inthe Netbeans.org design architecture engendersseparation of concerns in the process architecture.Of course, this is limited by the extent that eachmodule in the Netbeans.org community isdependent on other modules.

Last, volunteer community members haveperiodically observed difficulties collaboratingwith volunteer community members. For example,at one point a lack of responsiveness of the(primarily Sun employed) user interface team2,whose influence spans the entire community, couldbe observed. This coordination breakdown led tothe monumental failure of usability efforts for aperiod when usability was arguably the most-citedreason users chose competing tools overNetbeans.org. Thus, a collaboration failure gaverise to product failure. Only by overcomingcollaboration issues was Netbeans.org able todeliver a satisfactory usability experience3.

3.2. Leadership and Control

Ignoring internal Sun (and third party)enterprise structure, there are five observable layersof the Netbeans.org community hierarchy.Members may take on multiple roles some ofwhich span several of these layers. At the bottomlayer are users, followed by source contributors,module-level managers, project level releasemanagers (i.e. IDE or platform), and finally,community level managers (i.e. IDE and platform)at the top-most layer. Interestingly, the“management” positions are simply limited tocoordinating roles; they carry no other technical ormanagerial authority. The release manager, forexample, has no authority to determine what willbe included in and excluded from the release4. Nordoes s/he have the authority to assign people tocomplete the tasks required to release the product.The same is true of module and community

2http://www.netbeans.org.org/servlets/ReadMsg?msgId=531512&listName=nbdiscuss

3http://www.javalobby.org/thread.jspa?forumID=61&threadID=9550#top

4http://www.netbeans.org.org/community/guidelines/process.html

4

managers. Instead, their role is to announce thetasks that need to be done and wait for volunteersto accept responsibility.

Accountability and expectations ofresponsibility are based solely on precedent andvolunteerism rather than explicit assignment,leading to confusion of the role of partiescontributing to development. Leadership is notasserted until a community member champions acause and while volunteerism is expected, thisexpectation is not always obvious. The lack of aclear authority structure is both a cause of freedomand chaos in open source development. Thoughoften seen as one of its strengths in comparison toclosed source efforts, it can lead to process failureif no one steps forward to perform critical activitiesor if misidentified expectations cause dissent.

The difficulties in collaboration acrossorganizations within the community occasionallybrought up in the community mailing lists stemfrom the lack of a shared understanding leadershipin the community. This manifests itself in twoways: a lack of transparency in the decision makingprocess and decision making without communityconsent. While not new phenomenon, they areespecially poignant in a movement whose basictenets include freedom and knowledge sharing.

3.2.1. Transparency in the Decision MakingProcess

In communities with a corporately backed coredevelopment effort, there are often decisions madethat create a community-wide impact that are madecompany meetings. However, these decisions maynot be explicitly communicated to the rest of thecommunity. Likewise private communicationbetween parties that is not made available on thecommunity Web space or to the forwarded to othermembers is also hidden. This lack of transparencyin decision-making process makes it difficult forother community members to understand andcomply with the changes taking place if they arenot questioned or rejected. This effect surfaced inthe Netbeans.org community recently following adiscussion of modifying the release process [cf.Erenkrantz 2003]5.

Given the magnitude of contributions from theprimary benefactor, other developers were unsureof the responsibility and authority Sun assumedwithin the development process. The lack of a

5http://www.netbeans.org/servlets/BrowseList?listName=nbdiscuss&by=thread&from=19116&to=19116&first=1&count=41

clearly stated policy outlining these bounds led to aflurry of excitement when Sun membersannounced major changes to the licensing schemeused by the community without any warning. Ithas also caused occasional collaborationbreakdown throughout the community due toexpectations of who would carry out whichdevelopment tasks. The otherwise implicit natureof Sun's contributions in relation to otherorganizations and individuals has been revealedprimarily through precedent rather than assertion.

3.2.2. Consent in the Decision Making Process

Without an authority structure, all decisions indevelopment are done through consensus, exceptamong those lacking transparency. In the case ofthe licensing scheme change, some developers feltthat Sun was within its rights as the majorcontributor and the most exposed to legal threat 6

while others saw it as an attack on the "democraticprotection mechanisms" of the community thatensure fairness between participating parties7. Alack of consideration and transparency in thedecision making process tend to alienate those whoare not consulted and erode the sense ofcommunity.

3.3. Conflict Resolution

Conflicts in the Netbeans.org community areresolved via community discussion mailing lists.The process usually begins when one memberannounces dissatisfaction with an issue indevelopment. Those who also feel concern withthe particular issue then write responses to thecharges raised. At some point, the conversationdissipates- usually when emotions are set aside andclarifications have been made that provide anunderstanding of the issue at hand. If the problempersists, the community governance board is taskedwith the responsibility of resolving the matter.

The governance board is composed of threeindividuals and has the role of ensuring the fairnessthroughout the community by solving persistentdisputes. Two of the members are elected by thecommunity, and one is appointed by SunMicrosystems. The board is, historically, a largelysuperficial entity whose authority and scope arequestionable and untested. While it has beensuggested that the board intercede on a few rare

6http://www.netbeans.org.org/servlets/ReadMsg?msgId=534707&listName=nbdiscuss

7http://www.netbeans.org.org/servlets/ReadMsg?msgId=534520&listName=nbdiscuss

5

occasions, the disputes have dissolved before theboard has acted. Nevertheless, board elections aredutifully held every six months8.

Board members are typically prominentmembers in the community. Their status carriessomewhat more weight in community policydiscussions, however, even when one member hassuggested a decision, as no three board membershave ever voted in resolution on any issue, andthus, it is unclear what effect would result. Theirrole, then, is more of a mediator: to drivecommunity members to resolve the issue amongstthemselves. To this end, they have been effective.

4. Inter-Community Issues

As noted earlier, the NetBeans.org project is notan isolated OSSD project. Instead, the NetBeansIDE which is the focus of development activities inthe NetBeans.org project community is envisionedto support the interactive development of Web-compatible software applications or services thatcan be accessed, executed, or served through otherOSS systems like the Mozilla Web browser andApache Web server. Thus, it is reasonable toexplore how the NetBeans.org project communityis situated within an ecosystem of inter-relatedOSSD projects that facilitate or constrain theintended usage of the NetBeans IDE. Figure 2provides a rendering of some of the more visibleOSSD projects that surround and embed theNetBeans.org within a Web informationinfrastructure. This rendering also suggests thatissues of like collaboration and conflict can arise atthe boundaries between projects, and thus theseissues constitute relations that can emerge betweenproject communities in OSSD ecosystem.

With such a framing in mind, we haveobserved at least three kinds of issues arise acrossOSSD communities that surround theNetBeans.org community. These arecommunication and collaboration, leadership andcontrol, and conflict resolution.

4.1. Communication and Collaboration

In addition to their IDE, Netbeans.org alsoreleases a general application developmentplatform on which the IDE is based. Otherorganizations, such as BioBeans and RefactorITcommunities build tools on top of or extending theNetBeans platform or IDE. How do these

8http://www.netbeans.org.org/about/os/who-board.html

organizations interact with Netbeans.org, and howdoes Netbeans.org interact with other IDE andplatform producing organizations? For someorganizations, this collaboration may occur interms of bug reports and feature requests submittedto the Netbeans.org issue-tracking repository.Additionally, they may also submit patches orparticipate in discussions on community mailinglist or participate in the Netbeans.org “Move theNeedle” branding initiative. Beyond this,Netbeans.org participates in the Sun sponsoredJava.net meta-community, which hosts hundreds ofJava-based OSSD projects developed by tens ofthousands of individuals and organizations.

A fellow member of the Java.net community,the Java Tools Community, considered by some tobe a working group9 for the Java CommunityProcess, is an attempt to bring tool developerstogether to form standards for tool interoperability.Thus Netbeans.org, through its relationship withSun, is a collaborating community in thedevelopment of, and through compliance with,these standards, and looks to increasingcollaboration with other tool developingorganizations.

4.2. Leadership and Control

OSSD generally embrace the notion of choicebetween software products to build or use. At thesame time, developers in any community seeksuccess for their community, which translates tomarket share.

In some cases, communities developingalternative tools do so in peaceful coexistence,even collaboratively. In other cases, there is agreater sense of competition between rivals.NetBeans and its chief competitor Eclipse (backedlargely by IBM) fall into the latter category.Eclipse has enjoyed some favor from users due toperformance and usability issues of NetBeans, aswell as IBM's significant marketing anddevelopment resource contributions. Yet, theyhave a willingness to consider collaborativeefforts to satisfy demands for a single, unifiedIDE for the Java language that would serve as aplatform for building Java development tools anda formidable competitor to Microsoft's .NET.Ultimately, the union was defeated, largely due totechnical and organizational differences betweenSun and IBM10, including the inability or 9http://www.internetnews.com/dev-news/article.php/329599110http://www.adtmag.com/article.asp?id=8634,and

6

unwillingness to determine how to integrate thearchitectures and code bases for their respectiveuser interface development frameworks (Swingfor NetBeans and SWT for Eclipse).

4.3. Conflict Resolution

Conflicts between collaborating communitiesare resolved in similar fashion to their means ofcommunication- through discussion between Sunand Eclipse representatives, comments on theNetbeans.org mailing lists, or other prominenttechnical forums (e.g. Slashdot and developerblogs). Unfortunately, many of these discussionsoccur after the collaborating developer has movedaway from using Netbeans.org (often, in favor ofEclipse). Nevertheless, the feedback they providegives both parties an opportunity to increaseunderstanding and assists the Netbeans.orgcommunity by guiding their technical direction.

5. Discussion and Conclusion

Generally, volunteer Netbeans.org developersexpect Sun to provide leadership but not control.People outside the community (e.g. users, formerusers, and potential users) often voice theirconcerns in off-community forums (e.g., Slashdot,blogs, etc) rather than NetBeans.org communitymessage boards, due to accountability or visibilitybarriers (creating an account, logging in accounts),small as they may seem to be. In addition, suchmessage forums may not be a part of such anindividual’s daily work habits- they’re more likelyto visit a site like Slashdot.org than theNetbeans.org forum because they are not interestedenough in staying abreast of NetBeansdevelopments or participating in the community.Nonetheless, people working in, or interested injoining or studying OSSD projects, must addresshow best to communicate and collaborate theirdevelopment processes and effort, how to facilitateor ignore project leadership and control, and how towork you way through conflicts that may or maynot be resolvable by community participants.

Overall, we have observed three kinds ofcoordination and collaborating issues arise withinOSSD project communities like NetBeans.org, andthree similar kinds of issues arise across OSSDcommunities that surround NetBeans.org within anecosystem of projects that constitute a Webinformation infrastructure. Previous studies ofconflict in either OSSD projects have examinedeither smaller projects, or in virtual communities http://www.eweek.com/article2/0,1759,1460110,00.asp

that do not per se develop software as their focus.As corporate interest and sponsorship of OSSDstimulates the formation of large projects, or elsethe consolidation of many smaller OSSD projectsinto some sort of for-profit or not-for-profitcorporate enterprise for large-scale OSSD, then wewill need to better understand issues ofcollaboration, conflict, and control in OSSD.

6. Acknowledgments

The research described in this report issupported by grants from the National ScienceFoundation #ITR-0083075 and #ITR-0205679and #ITR-0205724. No endorsement implied.Contributors to work described in this paperinclude Mark Ackerman at the University ofMichigan Ann Arbor; Les Gasser at theUniversity of Illinois, Urbana-Champaign; JohnNoll at Santa Clara University; and MargaretElliott at the UCI Institute for Software Research.

7. References

Augustin, L., Bressler, D., and Smith, G.,Accelerating Software Development throughCollaboration, Proc. 24th Intern. Conf. SoftwareEngineering, Orlando, FL, 559-563, May 2002,

Crowston, K. and Scozzi, B., Open SourceSoftware Projects as Virtual Organizations:Competency Rallying for Software Development,IEE Proceedings—Software, 149(1), 3017, 2002.

Easterbrook, S. (ed.), CSCW: Cooperation orConflict, Springer-Verlag, New York, 1993.

Elliott, M. The Virtual Organizational Culture ofa Free Software Development Community, Proc.3rd Workshop on Open Source SoftwareEngineering, 25th. Intern. Conf. SoftwareEngineering, Portland, OR, May 2003.

Elliott, M. and Scacchi, W., Free SoftwareDevelopers as an Occupational Community:Resolving Conflicts and Fostering Collaboration,Proc. ACM Intern. Conf. Supporting Group Work,21-30, Sanibel Island, FL, November 2003.

Erenkrantz, J., Release Management within OpenSource Projects, Proc. 3rd Workshop on OpenSource Software Engineering, 25th Intern. Conf.Software Engineering, Portland, OR, May 2003.

Highsmith, J., Agile Software DevelopmentEcosystems, Addison-Wesley Pub. Co., 2002.

7

Jensen, C. and Scacchi, W., Automating theDiscovery and Modeling of Open SourceSoftware Processes, Proc. 3rd Workshop on OpenSource Software Engineering, 25th. Intern. Conf.Software Engineering, Portland, OR, May 2003.

Jensen, C. and Scacchi, W., Process Modeling ofthe Web Internet Infrastructure, submitted forpublication, June 2004.

Monk, A. and Howard, S. The Rich Picture: ATool for Reasoning about Work Context,Interactions, 21-30, March-April 1998.

O’Mahony, S., Non-profit Foundations and theirRole in Community-Firm Software Collaboration,to appear in Making Sense of the Bazaar:Perspectives on Open Source and Free Software,J. Feller, B. Fitzgerald, S. Hissam, & K. Lakhani(Eds.), O'Reilly & Associates, Sebastopol, CA,2004.

Sawyer, S., Effects of intra-group conflict onpackaged software development teamperformance, Information Systems J., 11, 155-178, 2001.

Scacchi, W., Understanding the Requirements forDeveloping Open Source Software, IEEProceedings—Software, 149(1), 24-39, 2002.

Scacchi, W., Free/Open Source SoftwareDevelopment Practices in the Computer GameCommunity, IEEE Software, 21(1), 59-67,January/February 2004.

Schmidt, K., and Simone, C., CoordinationMechnanisms: Towards a Conceptual Foundationof CSCW System Design, Computer SupportedCooperative Work, 5(2-3), 155-200, 1996.

Simone, C. and Mark, G., Interoperability as aMeans of Articulation Work, Proc. Intern. JointConf. Work Activities Coordination andCollaboration, San Francisco, CA, 39-48, ACMPress, 1999.

Smith, A.D., Problems of Conflict Management inVirtual Communities. In M.A. Smith and P.Kollock (eds.), Communities in Cyberspace,Routledge, New York, 134-163, 1999.

Star, S. L., The Structure of Ill-StructuredSolutions: Boundary Objects and HeterogeneousDistributed Problem Solving, in DistributedArtificial Intelligence (eds. L. Gasser and M. N.Huhns), Vol. 2, 37-54. Pitman, London, 1990.

8

Figure 1. A rich picture view of the roles (labeled icons), concerns (clouds), and activities(hyperlinked text) found in the intra-community context of NetBeans.org

[cf. Oza, et al, 2002].

9

Figure 2. An overview of the inter-community ecosystem for NetBeans.org