xml version 1.0 encoding UTF-8 standalone no
record xmlns http:www.loc.govMARC21slim xmlns:xsi http:www.w3.org2001XMLSchema-instance xsi:schemaLocation http:www.loc.govstandardsmarcxmlschemaMARC21slim.xsd
leader nam 22 Ka 4500
controlfield tag 007 cr-bnu---uuuuu
008 s2010 flu s 000 0 eng d
datafield ind1 8 ind2 024
subfield code a E14-SFE0003504
Understanding organizational adoption theories through the adoption of a disruptive innovation :
b five cases of open source software
h [electronic resource] /
by Delmer Nagy.
[Tampa, Fla] :
University of South Florida,
Title from PDF of title page.
Document formatted into pages; contains X pages.
Dissertation (Ph.D.)--University of South Florida, 2010.
Includes bibliographical references.
Text (Electronic dissertation) in PDF format.
Mode of access: World Wide Web.
System requirements: World Wide Web browser and PDF reader.
ABSTRACT: This dissertation seeks to understand how organizations adopt a disruptive technology, open source software. Five cross-sectional case studies at municipal governments were performed using a theoretical model based off of eight organizational adoption theories. Results of the case studies highlight how each construct from each theory was present at the organizations. However each construct was of variable influence based upon organizational characteristics and the time or stage of adoption.
Advisor: Rosann Collins, Ph.D.
x Information Sys and Decision Sci
t USF Electronic Theses and Dissertations.
Understanding Organizational Adoption Theori es through the Adopti on of a Disruptive Innovation: Five Cases of Open Source Software by Delmer Nagy A dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy Department of Information Sy stems and Decision Sciences College of Business University of South Florida Major Professor: Rosann Webb Collins, Ph.D. Walter Nord, Ph.D. Manish Agrawal, Ph.D. Richard Will, Ph.D. Donald Hardaway, Ph.D. Date of Approval : March 18, 2010 Keywords : Disruptive Technologies, Case Study Copyright 2010, Delmer A. Nagy
Dedication To my wife, Adrian, whose patience and support knows no bounds. To my parents, who listened and spoke at the right time. To Helen, unconditional love changes people. To Blanche, knowing that courage is in my blood. To John Chan, showing me how it should be done. To Ali, 21 miles. To Saturday night dinner s, sanity is undervalued. To Evan Duggan, Shane Sharpe and David Ha le, for inspiration to influence others. To myself, I thought I could.
Acknowledgement First and foremost I would like to acknowledge an outstanding committee. Heading this committee was Rosann Collins, thank you. Without your help this project would not have happened. Your wisdom and guidance managed to separate wheat from chaff and integrate awkward figures. Walter Nord, thank you. Talking over burgers and fries was a nice change of pace. Don Hardaway, thank you. Your insight in to open source software is exemplary. So is your patience with my understanding and perc eption of the subject. I feel as though my understanding grew and has more room to grow. Manish Agrawal, thank you. Your attention to detail has helped me understand where this work fits into a larger picture. Richard Will, thank you. Your support and assistance meant much to me. Charles Kroncke, reassurance comes from unexpected places. Thank you for your help. To Cathy Slagle, one day each summer is not enough tim e to spend with you. You are an expert who can navigation the intricacies of the ad ministration. Your kindne ss and help will not be forgotten. To Judy and Nadia. Thank you for your help and your company.
i Table of Contents Chapter 1 Introduction....1 Research Questions .3 Dissertation Format ....3 Chapter 2....5 Literature Review and Research Model Development..5 Organizational Adoption Theories..5 Organizational Adoption and Diffusion.... 6 Traditional Adoption Stages.6 OSS Adoption Levels.9 Organizational Adoption and Diffusion Theories.11 Environmental Constructs..12 Organizational Constructs..15 Innovation Constructs.17 A Combined Model of OSS Adoption Open Source Software Adoption Chapter 3..26 Research Design...26 Research Questions ...26 Appropriateness of Case Study when lacking theoretical guidance ...27 Research Methods Case Study ...28 Criticism of Case Studies Research Lens Organizational Adoption Model. ..30 Study Participants .32 Data Collection ..34 Data Analysis and Interpretation .36 Research methodology: Summary 39 Chapter 4..40 Results...40 Roswell Network Integration .40 Overview of Roswells Case Study.40 Description of Roswell Description of Roswells IT Department...43 Roswell Participants
ii Overview of Open Source Adoption by Roswell...45 Security. .46 Server. 47 Networking 47 End User Applications.. 48 Database 48 Roswells Open Source Adoption Themes.48 Roswells Model Factors.49 Environmental Factors .49 Organizational Factors .57 Innovation Factors 65 OSS Disruption within Roswells IT Department Interpretation of Roswells Model Factors Environmental Factors .74 Organizational Factors .76 Innovation Factors 79 Interpretation of Roswells OSS Adoption Interpretation of OSS Disruption wi thin Roswells IT Department...83 Summary of the Roswell Case Columbus The Need to Succeed .86 Overview of Columbuss Case Study.86 Description of Columbus.87 Description of Columbuss IT Department...88 Columbus Participants Open Source Adoption at Columbus.91 Security. .92 Server. 93 Networking 93 End User Support.. 94 Open Source Adoption Themes at Columbus...94 Columbuss Model Factors.97 Environmental Factors. 99 Organizational Factors... 103 Innovation Factors.. 109 OSS Disruption within Columbuss IT Department..111 Interpretation of Columbuss Model Factors..111 Environmental Factors... 111 Organizational Factors... 114 Innovation Factors.. 116 Interpretation of Columbuss OSS Adoption..117 Interpretation of OSS Disruption wi thin Columbuss IT Department
iii Summary of the Columbus Case..118 Decatur Cultural Divide Overview of Decaturs Case Study...120 Description of Decatur...122 Description of Decaturs IT department..122 Decaturs Participants...123 Open Source Adoption at Decatur...124 Networking.. 125 Database.. 126 Server... 127 End User Applications 128 Security 129 Open Source Software Adoption Themes at Decatur.129 Decaturs Model Factors...132 Environmental Factors... 132 Organizational Factors... 134 Innovation Factors.. 137 OSS Disruption within Decaturs IT Department..138 Interpretation of Decaturs Model Factors.140 Environmental Factors ...141 Organizational Factors... 143 Innovation Factors.. 148 Interpretation of Decaturs OSS Adoption..150 Interpretation of OSS Disruption wi thin Decaturs IT Department Summary of the Decatur Case..151 Jackson Hero Driven Adoption 152 Overview of Jacksons Case Study...152 Description of Jackson...153 Description of Jacksons IT department..154 Jacksons Participants...155 Open Source Adoption at Jackson...156 Networking.. 157 Security 158 Open Source Software Adoption Themes at Jackson.159 Jacksons Model Factors...165 Environmental Factors... 165 Organizational Factors... 169 Innovation Factors.. 174 OSS Disruption within Jacksons IT Department..176 Interpretation of Jacksons Model Factors.176 Environmental Factors... 177 Organizational Factors... 179 Innovation Factors.. 182 Interpretation of Jacksons OSS Adoption.184
iv Interpretation of OSS Disruption wi thin Jacksons IT Department Summary of the Jackson Case..185 Bowling Green Best of Breed 187 Overview of Bowling Greens Case Study...187 Description of Bowling Green...188 Description of Bowling Greens IT department..189 Bowling Green Participants..189 Open Source Adoption at Bowling Green...190 Security.... 191 Server... 191 Open Source Adoption Th emes at Bowling Green.192 Bowling Greens Model Factors...192 Environmental Factors... 193 Organizational Factors... 194 Innovation Factors.. 199 OSS Disruption within Bowling Greens IT Department..200 Interpretation of Bowling Greens Model Factors.201 Environmental Factors... 201 Organizational Factors... 203 Innovation Factors.. 206 Interpretation of Bowling Greens OSS Adoption..207 Interpretation of OSS Disruption in Bowling Greens IT Department Summary of the Bowling Green Case..208 Chapter 5 Discussion...210 Discussion of Guiding Questions... 210 Theoretical Operation of Environmental Factors..213 Adoption Stages Influenced by Environmental Factors External Communication... 216 Peer Adoption.. 219 Vendor Relations. 220 Technical Communities.. 223 Theoretical Operation of Organizational Factors..226 Adoption Stages Influenced by Organizational Factors Internal Communication 227 Environmental Scanning 230 Administrative Intensity.. 233 Technical Knowledge.. 236 Wealth .. 239 Slack Resources... 240 Theoretical Operation of Innovation Factors..241 Adoption Stages Influenced by Innovation Factors Relative Advantage. 243 Compatibility... 245
v Complexity... 247 Theoretical Operation of Adoption Perspective.249 Theoretical Operation of Adoption Stage on Innovation Disruption...251 Theoretical Operation of Adoption Level on Innovation Disruption...253 Discussion of Adoption Theories 255 Innovation diffusion theory...256 Technical knowledge and know-how...257 Organizational Resources.258 Managerial fashion Network externalities.260 Critical mass...260 IT Context...261 Routine versus Radical..261 Discussion of Research Questions. 262 Chapter 6 Findings and Contributions..267 Limitations... 272 Future Research.. 274
vi List of Tables Table 1. Technology Adoption Stages..7 Table 2. Organizational Adoption Theories..12 Table 3. Environmental Constructs...13 Table 4. Organizational Constructs...16 Table 5. Innovation Diffusion Innovation Characteristics....7 Table 6. Innovation Constructs..20 Table 7. Prior research into open source adoption..22 Table 8. Roswell IT department Mem ber Role and Responsibilities..45 Table 9. Roswells Adoption of OSS...46 Table 10. Roswells Environmental Factors..75 Table 11. Roswells Organizational Model Factors..79 Table 12. Roswells Innovation Factors.81 Table 13. Columbus IT Department Member Role and Responsibilities...91 Table 14. Columbuss Adoption of OSS Table 15. Columbuss Environmental Factors Table 16. Columbus Organizational Model Factors...116 Table 17. Columbuss Innovation Factors...117 Table 18. Decatur IT Department Mem ber Role and Responsibilities.124 Table 19. OSS Adopted at Decatur..125 Table 20. Decatur Environmental Factors..143 Table 21. Decatur Organizational Adoption Factors.147 Table 22. Decatur Innovation Characteristics Table 23. Jackson IT Department Mem ber Role and Responsibilities.156 Table 24. OSS Adopted at Jackson..157 Table 25. Jackson Environmental Factors..179 Table 26. Jackson Organization al Adoption Factors.182 Table 27. Jackson Innovation Characteristics Table 28. Bowling Green IT Department Member Role and Responsibilities.189 Table 29. Bowling Greens adoption of OSS by area.189 Table 30. Bowling Green Environmental Factors..203 Table 31. Bowling Greens Organizational Model Factors Table 32. Bowling Green Innovation Factors.207 Table 33. Study Guiding Questions..211 Table 34. External Communication.218 Table 35. Peer Adoption Table 36. Vendor Relations...223
vii Table 37. Technical Communities Table 38. Internal Communication..230 Table 39. Environmental Scanning..233 Table 40. Administrative Intensity...236 Table 41. Technical Knowledge Table 42. Wealth Table 43. Slack Resources.241 Table 44. Relative Advantage...245 Table 45. Compatibility.246 Table 46. Complexity.249 Table 47. Factor Effects on Adoption Stage Table 48. Theoretical Fit of Adoption Theories..269
viii List of Figures Figure 1. Study Model Overview Figure 2. Study Model Constructs Identified.21 Figure 3. Study Model Restated..30 Figure 4. Roswells OSS Adoption.42 Figure 5. Roswell Interview Codes.73 Figure 6. Columbuss OSS Adoption.87 Figure 7. Columbus Codes..98 Figure 8. More Columbus Codes Figure 9. Decaturs OSS Adoption...121 Figure 10. Decaturs Codes...141 Figure 11. Jacksons OSS Adoption.153 Figure 12. Jacksons Codes...177 Figure 13. More Jackson Codes Figure 14. Bowling Greens OSS Adoption.188
ix The Adoption of Disruptive Technologies: The Case of Open Source Software Delmer A. Nagy ABSTRACT This dissertation seeks to understand how organizations adopt a disruptive technology, open source software. Five cross-sectional case studies at municipal governments were performed using a theoretical model based o ff of eight organizational adoption theories. Results of the case studies highlight how each construct from each theory was present at the organizations. However each construc t was of variable influence based upon organizational characteristics and the time or stage of adoption.
1 Chapter 1. Introduction Organizational adoption decisions c oncerning disruptive technologies are complicated as disruptive technologies are no t easily identified ahead of time (Daneels 2004). A seemingly incremental change to an innovation in one domain can be applied to a new context with disruptive results (C hristenson 2000, Christensen and Raynor 2003). This has led researchers who investigate disruptive technologies to believe that an innovations impact on an adopting organization can be disruptive in some settings and absorbed as routine in others (Christe nson 2000, Christensen and Raynor 2003). Because of the challenge of identifying a di sruptive technology many technology adoption theories have overlooked the nature, increm ental or disruptive, of an innovation when examining the organizational adoption of new innovations (Lyytinen and Rose 2003). The few studies that examined the a doption of disruptive innovations have focused on organizational factors, like techni cal knowledge, administ rative intensity and internal communication, and how they infl uence the adoption of these innovations (Bucher, Birkenmeier, Brodbeck, and Escher 2003, Srinivasan, L ilien and Rangaswamy 2002, and Dewar and Dutton 1986). This focus on organizational factors stems from a rejection of technological dete rminism; that the technology itself does not influence an organizations adoption of the innovation.
2 However focus on organizational character istics discounts other organizational adoption research and theories that propose th at environmental factors, such as vendors and technical communities, as well as innovati on characteristics, such as relative advantage and compatibility, influence th e adoption of new technologies (Rogers 1995, Zhu, Kraemer, Gurbaxani, and Xu 2006). This lack of research examining how disruptive innovations are adopted by organizations appears to reveal two gaps in technology adoption research. The first gap centers on the nature of di sruptive innovations. When an innovation is considered disruptive does its adoption create a disrupt ion in the adopting or ganization? Second, what characteristics, organi zational, environmental, or innovation related drive the adoption of new disr uptive technologies? The purpose of this study was to help close these two gaps in existing organizational adoption resear ch. The study first sought to understand if and how the adoption of a disruptive innovation caused disr uptions in adopting organizations. Second the study examined the three different technol ogy adoption perspectives, environmental, organizational and innovation, to better unde rstand how constructs from these three different areas influence the organizati onal adoption of a disruptive technology. The disruptive technology examined by this study is open source software (OSS). This type of software is widely acknowl edged as a disruptive innovation and provides a context for this study. For a detailed discussi on of what this study considers OSS, and how OSS is disruptive, pleas e see appendix item B.
3 Research Questions The driving questions of this study seek to understand how the adoption of a disruptive innovation causes disruptions in adopting organizations and how environmental, organizational and innovation factors interact during the organizational adoption of a disruptive innovation. To answer these questions the adoption of OSS, a well established disruptive innovation, was used as a disruptive innovation to answer these questions. Consequently the research questions were revised to account for open source software, changing the first research question to: 1. How does the adoption of open source softwa re result in disruptions to adopting organizations? With the addition of OSS the second research question was altered to: 2. How do environmental factors, organi zational characteristics and innovation characteristics interact during the organi zational adoption of ope n source software? Dissertation Format The remainder of this dissertation is or ganized as follows: Chapter two reviews prior organizational adoption lit erature. It is di vided into two sec tions which cover organizational adoption theories and prio r research examining the organizational adoption of a disruptive innova tion, open source software. Chapter three covers the methods used by this study. The chap ter is broken down into sections describing the research appr oach, data collection, a nd data analysis. The next chapter, chapter four, describes the findings of this study. This is followed by
4 chapter five which discusses the findings, wh ile chapter six highlights the contributions and limitations of this research and provide s future direction for subsequent studies.
5 Chapter 2. Literature Review and Research Model Development The literature review for this study covers two areas of prior research. First, the research model for this study is proposed by reviewing ex isting organizational adoption theories. Second, literature investigating open source software adoption is reviewed to understand how these studies f it into this studys research model. Further literature examining the nature of OSS and disruptive technologies can be found in appendix item B which discusses disruptive tec hnologies and OSS in detail. Organizational Adoption Theories Prior research into the organizational adoption of innovations has resulted in several theories that model organizational adoption of t echnologies. Most of these theories draw from innovation diffusion lite rature as opposed to studies examining the individual adoption of i nnovations. Individual techno logy adoption research has traditionally focused on the individual whil e diffusion research has centered upon groups of people. Because organizations are groups of people, diffusion theories appear to align better with the organizational co ntext (Rogers 1995, Fichman 2000). This section begins by reviewing the di fferences between adoption and diffusion research, then provides an overview of eight organizational adoption theories. This is followed by an examination of how external entities affect organizational adoption. The
6 next section identifies organi zational characteristics and is followed by an examination of how innovation characteristic s influence organizational adoption. Finally, a model combining these three factors is then described. Organizational Adoption and Diffusion There are differences between techno logy adoption and technology diffusion. The first part of this section id entifies what adoption is and how it differs from diffusion. The second part of this sectio n contextualizes adoption to the open source phenomenon. Traditional Adoption Stages Adoption in an organizational context ha s traditionally referred to a level of awareness and commitment by an individual organization towards a specific technology or idea (Rogers 1995). Meanwhile diffusion is the stage in which the technology has spread through a population of, or group of entities, be they people, groups or organizations (Rogers 1995). The terms are not independent as diffusion of a technology relies upon individuals, groups and organi zations within a popul ation to adopt the innovation. Prior studies have f ound that adoption may occur at different stages (Rogers 1995, Zahara and George 2002, Cooper and Zumd 1990, Meyer and Goes 1988, and Fichman and Kemerer 1997). If this body of research is combined, five different adoption stages can be identified. Tabl e 1 highlights these stages.
7 Table 1. Technology Adoption Stages Adoption Stage Reference Knowledge/Awareness Meyer and Goes (1988), Coope r and Zmud (1990), Rogers (1995), Fichman and Kemerer (1997), Zahra and George (2005) Evaluation/ Choice/Interest Meyer and Goes (1988), Rogers (1995), Fichman and Kemerer (1997) Adoption Meyer and Goes (1988), Cooper and Zmud (1990), Rogers (1995), Fichman and Kemerer (1997), Zahra and George (2005) Assimilation/ Routinization Cooper and Zmud (1990), Fichman and Kemerer (1997), Zahra and George (2005) Infusion Cooper and Zmud (1990) Zahra and George (2005) The first stage of adoption that research ers have found is that of knowledge or awareness. At this stage an organization or individual becomes attune d to the existence of the innovation. This does not mean that the po tential adopter is in terested or curious about the innovation; they simply know that the technology exists. Curiosity of how the innovation could integrate into an organization is the second stage of adoption. Organizations and individuals enter this stage of adoption when they begin to gather information about how an i nnovation might affect existing processes or operations. This stage is characterized by an evaluation of some kind as potential adopters attempt to determine if the technology would be a good fit for their context. The results of the organizational evaluation determine if the party advances to the third stage, that of actual adoption. Many researchers cons ider organizations to be adopters once they have purchased or implemented the new technology. However this definition of adoption allows for a broad scope of organizational adoption as organizations can adopt in many different seve ral forms: from pilot programs and standalone implementations to organization-wide deployment. These different types of
8 adoption are far from equal, and can easil y be confused with evaluation as pilot programs. The fourth stage of organi zational adoption, or assimila tion and routinization, is much clearer. Not only is an innovation or technology adopted, but it has been widely integrated into work processes. This indica tes that the innovation has become a reliable tool for the adopter to accomp lish specific tasks. Therefore the major differences between this stage, routinization, a nd the third stage, adoption, are the scope of adoption and the time that an innovation has been adopted. No t only is wide-spread adoption needed to reach this stage, but time and some fam iliarity and comfort with the innovation is necessary. Following assimilation and routinization is the stage of infusion. At this stage of adoption researchers advocat e that the innovation has gone beyond being used as an individual technology. Not only has it become an integral part of a business processes; the adopter has learned how to apply the technology to othe r uses. This focuses on going beyond the intention or scope of the original implementation to meet other duties that the organization performs. The five stages of organizational a doption are closely re lated to another technology adoption phenomenon, technology diffu sion. While related to organizational adoption, technology diffusion differs as it is a phenomenon that examines the stage of adoption of a technology by a specific popul ation. This causes the two phenomenons, organizational adoption and technology diffusio n, to differ on the unit of analysis. For a technology diffusion study, multiple units of a population need to be examined to
9 determine the adoption stage, or the tec hnology diffusion, of an innovation as their aggregated adoption stage will determine ho w the innovation has diffused. Meanwhile an organizational adoption study would focus on individual organizations. Based on these definitions, this study is an organizational adoption study as it exam ined five different organizations, too small a sample size to id entify any diffusion tren ds of a population, but large enough to draw conclusions about individual organizations. OSS Adoption Levels Traditionally adoption literature has referred to the different stages of adoption as stages or levels interchangeably. This study separates the terms b ecause OSS appears to be an unusual innovation in th at there are different levels of adoption. Grand, von Krogh, Leonard and Swap have proposed that OSS can be adopted at four different levels of adoption (2004). Therefore this study will di fferentiate adoption stages from OSS adoption levels to better understand how this innovation is being adopted and used by organizations. Grand et al proposed that OSS has multip le adoption levels after examining a series of business case studies. They concl uded that organizations can use open source software as an end product (i.e ., as a software package), as a complementary asset (i.e., as a component of a larger product), as a design choice (i.e., as a softwa re design), or as a business model. These adoption levels are di fferent from the traditional technology adoption levels of awareness, interest adoption, routinizat ion and infusion. Grand, von Krogh, Leonard and Swap propose that the first level of adoption, using OSS as an end product, involves little organizational commitment to OSS beyond
10 implementation and support. This includes de ploying the applicati on, training end users and maintaining the program over time. Organizations can perform these duties internally, or where available, can outsource these tasks to other firms. The second level of adoption, that of usi ng open source as a complementary asset, focuses on integrating OSS with proprietary so ftware or hardware to create a hybrid product. This level of commitment is thought to increase organizational commitment to include open source development as organizations at this level need to integrate OSS with proprietary products. Th e need to integrate the two technologies implies that organizations need to be proficient enough with open source development to integrate OSS with proprietary technologies. Commitment to OSS is taken a step furt her with the decision to utilize an open source design. This third level of adoption proposes that or ganizations fully abandon the proprietary paradigm and rely extensivel y on open source communities to supplement development and innovation. It is not quite clear if th ere are situations where organizations can adopt an open source de sign and not adopt an open source business model, the fourth level of adoption. Open source business models constitute the last level of adoption. This includes selling implementation, support, training, customization, and proprietary add-ons. However if the sale of propr ietary add-ons is an open source business model, then perhaps the identification of the complementar y asset level is not a stand alone level of adoption. Regardless, Grand et. all identify unique characteristics of OSS adoption and highlight how this technology differs from traditional software.
11 Because organizations appear to have di fferent adoption stages and OSS adoption levels these variables are used to refine this studys model. OSS adoption levels are thought to moderate the disr uptive effect of OSS adopti on based upon the level of OSS adoption. These ideas are incorporated into the model and are high lighted in Figure 1. Figure 1. Study Model Overview Organizational Adoption and Diffusion Theories Nearly all adoption and diffusion theories can trace their origin to elements of Everett Rogers (1995) landmark work, The Diffusion of Innovations. This groundbreaking research compiled hundreds of case studies on innovation adoption and resulted in Rogers Innovation Diffusion Theory. Ho wever, as important as the Innovation Diffusion Theory is, researchers have yet to create an overarching theory explaining technology diffusion (Fichman 1992 ). Theoretical work in this area generally focuses on a specific construct identified in Rogers Th eory, i.e. the innovation, the adopter, or the environment surrounding the innovation (Fichman 2000).
12 This study examining the adoption of OS S uses eight organizational adoption theories to develop a preliminary model to examine the adoption of OSS. Table 2 highlights these theories, describing their constructs and how they relate to the preliminary model. Table 2. Organizational Adoption Theories Theory Reference Main Assertions Factor Described Innovation Diffusion Theory Everett and Rogers (1995) The characteristics of the innovation, how innovative the adopter and the co mmunication channels influence adoption Innovation, Organizational Characteristics and Environment Technical Knowledge and Know-How Attewell (1992) Organizational know ledge and know-how determines the adoption of an innovation Organizational Characteristics, Environment Organizational Resources Damanpour (1991) Organizational resources and characteristics determine the adoption of an innovation Organizational Characteristics Managerial Fashion Abrahamson (1991) Organizational adoption is influenced by peer adoption Environment Network Externalities Katz and Shapiro (1986) Technical network externalities and third party sponsorship determine the adoption of an innovation Environment Innovation Critical Mass Markus (1987) Information technologies need to have a critical mass of adopters before they achieve widespread adoption Environment IT Context Swanson (1994) Innovations are adopted based upon a contextual purpose Innovation Routine vs. Radical Nord and Tucker (1987) Innovations are adopted based upon how similar or different they are relative to other organizational technologies Innovation Environmental Constructs Of the eight theories identified in Table 5, five identify constructs relate to external parties that influe nce the adoption of innovations These constructs focus on communication channels, peer adoption an d third party sponsorship. Table 3, Environmental Constructs, summarizes these ex ternal organizational variables thought to influence the adoption of OSS.
13 Table 3. Environmental Constructs Construct Theory Reference Description External Communication Innovation Diffusion Theory Rogers (1995) The different methods of communicating with external organizations Peer Adoption Critical Mass, Managerial Fad and Fashion Markus(1987), Abrahamson (1991) Innovation utility becomes increasingly effective based on peer adoption Peer adoption influences organizational adoption Vendor Relations Network Externalities, Technical Knowledge Katz and Shapiro(1986), Attewell (1992) Vendors supply services and technology standards to organizations Technical Community Technical Knowledge Attewell(1992) Communities surrounding technologies supply technical knowledge External communication, or how adopter s communicate the benefits of an innovation between one another, are identified by Innovati on Diffusion Theory (Rogers 1995). They are important because they infl uence how adopters become aware of the benefits of new innovations, in fluencing the first two levels of adoption, awareness and curiosity. Rogers found that communication channels can be formal, or based on relationships that are clearly de fined, or informal, those rela tionships that are not clearly defined (Rogers 1995). Subsequent research in to the adoption of innovations has verified the importance of these channels in gene rating awareness about innovations (Ball, Dambolena and Hennessey 1986, Nilakanta an d Scamell 1990). Because communication channels appear to be critical in building the awareness and curiosity of the first two stages of adoption they will be included in th e model at the external organizational level. Communication channels are closely linked to another construct: peer adoption. Peer adoption appears to be important for tw o main reasons. First, some innovations, like the telephone and email are considered critical mass innovations; they become increasingly effective as mo re parties adopt the innovation (Markus 1987). This implies
14 that organizations are more likely to adopt an innovation with critical mass characteristics if their peers also adopt the innovation. Ther efore this study will examine if organizations believe that OSS adoption becomes more ef fective if their peers also adopt the innovation. Secondly peer adoption may influence orga nizational adoption of innovations as a technology can become fashionable to a dopt (Abrahamson 1991). Abrahamson stated that fashion may influence adoption in tw o ways. First organizations may adopt an innovation to imitate another organization or fo r original reasons. Secondly the origin of the adoption may come from within the organi zation or from outside of the organization. This implies consultants or other external or ganizations can influence the adoption of an innovation by sponsoring the innovation, which is the third construct identified by examining theories focusing on external organizations. In addition to Abrahamsons, two other theories indicate that third parties influence the adoption of innova tions. Katz and Shapiros Ne twork Externalities theory proposes that technology vendors are one su ch organization (1986). They influence the adoption of an innovation in two ways. First vendors sponsor a technical standard. This determines how innovations integrate and ultimately which innovations can work together (Katz and Shapiro 1986). Secondl y vendors provide services for their innovation. They create suppo rt structures for their in novations that increase the awareness of, and facilitate the use of, th eir innovations (Katz and Shapiro 1986). This is closely related to Attewells theory of tec hnical knowledge and know-how (1992). Attewell claims that innovations are not only adopted because of the awareness of
15 their benefits, but also because of organi zational knowledge and know-how relating to the application and use of that innovation. Innovation knowledge is thought to go through a cycle in which technical knowledge about a specific innovation is known by a select few innovators who created the invention. Thes e individuals are thought to then form an organization through which they can then sell their exper tise on the innova tion to other organizations. These adopting organizations are then thought to inte rnalize the technical knowledge and know-how of the innovation, crea ting an organizational learning cycle. Because three theories, Abrahamsons Fad and Fashion, Katz and Shapiros Network Externalities, and Attewells Know ledge and Know-how, focus on the roles of external organizations this st udy will also examine their influence in the adoption of OSS. How these organizations help set managerial trends, set technical st andards, and supply technical knowledge will be examined. Th e constructs identified by reviewing organizational adoption theories conceptu ally develop variab les identified by the organizational level definition of disruptive technologies. Organizational Constructs Like studies examining the organizational adoption of disruptive innovations, organizational a doption research has often focused on organizational characteristics. These studies have highlig hted many factors outside of environmental scanning and capability building as affecti ng the organizational adoption of innovations. When looked at in aggregate, three groups of organizational charac teristics appear to influence the adoption of innovations: struct ure, knowledge, and size. Table 4 highlights the organizational constructs id entified in this section that will be examined by this study.
16 These factors are categorized into three groups, structure, knowledge and size, to theoretically deve lop this studys adoption model. Table 4. Organizational Constructs Construct Theory Reference Description Structure Internal Communication Administrative Intensity Innovation Diffusion Theory, Organizational Resources Rogers(1995), Damanpour (1991) How organizations are organized to accomplish their tasks determines adoption Knowledge Environmental Sensing Technical Knowledge Organizational Resources, technical knowledge Damanpour (1991), Attewell( 1992) Pre-existing organizational knowledge and how organizations sense and absorb new information determines adoption Size Wealth Slack resources Organizational Resources Damanpour (1991) The amount of organizational resources are thought to determine adoption In his meta-analysis of organizationa l adoption factors Damanpour examined many of these factors from all three groups, structure, knowledge and size (1991). With regards to organizational structure Damanpour highlighted that prior studies examining organizational adoption had identified the foll owing structural fact ors: communication, centralized/decentralized decision making, form alities, and administrative intensity to determine how organizational structure aff ects the adoption of innovations (Damanpour 1991). When he tested his meta-analysis, Damanpour found that of these factors only communication and administrativ e intensity were statistical ly significant structural factors that explained organizational i nnovation adoption when the radicalness of innovations was taken into account as a mode rating factor (1991). Therefore this research will examine these two structural factors when investig ating the adoption of OSS by organizations. Organizational knowledge has also been tested and accepted as a factor
17 determining the adoption of innovations (F ichman and Kemerer 1997). This factor appears to have three components which include the ability to sense new information in the environment, the ability to apply and internalize this information and existing technical knowledge (Cohen and Le vinthal 1990, Damanpour 1991, Attewell 1992, Fichman and Kemerer 1997, Zahara and George 2002). Prior research into the adoption of disruptive innovations has highlighted the importance of environmental sensing and the ability to internalize this information (S rinivasan et. al 2002, and Bucher et. al 2003). These aspects, environmental scanning and technical knowledge will also be examined to better understand how these constructs eff ect the adoption of OSS by organizations. Finally the third organizational characteri stic that studies have examined is organizational size. Size is t hought to be a proxy for variab les such as scale, wealth, specialization and slack res ources, factors found to have a positive impact on organizational adoption of innovations (Tornatzky and Fleischer 1990, Damanpour 1991). In keeping with these prior studies, this research will also examine organizational size. Innovation Constructs Fundamentally organizations adopt an innovation to get some kind of intended benefit. These benefits are not always strai ghtforward, as there are several characteristics that have been found to influence an innova tions overall utility. Four theories of organizational adoption focus on innovation ch aracteristics. Innovation Diffusion Theory provides the foundation for the other three theories by identifying five classic
18 characteristics: relative advantage, co mpatibility, complexity, trialability and observability (Rogers 1995). These charac teristics are highlighted in Table 5. Table 5. Innovation Diffusion Innovation Characteristics Characteristic Descrip tion Effect on Adoption Relative Advantage The degree to which it is perceived to be better than what it supersedes Positive Compatibility consistency with existing values Positive Complexity difficulty of understanding and use Negative Trialability The degree to which it can be experimented with on a limited basis Positive Observability The visibility of its results Positive However the importance of all five characte ristics has been called into question as trialability and obser vability were not found to be si gnificant by a meta-analysis of innovation characteristics, but were found to be important in a subsequent study (Tornatzky and Klein 1982, Moore and Benbasat 1991). To simplify this study only the relative a dvantage, compatibility and complexity of OSS will be examined. This is done as the goal of this research does not center on clarifying the importance of trialability and observability but rather how these different groups of theories, environmental, organizati onal and innovation interact. To this end this study will focus on characteristics that have been consistently proven important with organizational adoption, relative advantag e, compatibility and complexity. These characteristics are present in three other th eories, Network Externality Theory, Routine vs. Radicalness Theory, and IT Context Theory. Network Externalities Theory, as propos ed by Katz and Shapiro, stresses the importance of technical standa rds and innovation integration. This is very similar to
19 Innovation Diffusion Theories compatibility co nstruct which has traditionally focused on consistency with existing organizational values. Nord and Tucker also extended the compatibility construct with their theory of Routine vs. Radicalness. Their extension focuses on prior activities taken by the organization. How similar an innovations char acteristics and purpose are relative to what an organization has already perf ormed is thought to constitu te a degree of radicalness which is thought to influence the adoption of an innovation. Finally Swansons theory of techni cal context proposes that innovation characteristics can have diffe rential effects depending on th e use of the innovation. This appears to be similar to Rogers relative advantage construct which has traditionally meant the degree to which an innovation is perc eived to be better than what it supersedes (Rogers 1995). Swanson extends this characteri stic to include the context in which an innovation is used as opposed to a pre-de termined relative advantage of a given innovation. This study will examine modified versions of Rogers innova tion characteristics of relative advantage, compatibility and complexity to examine the organizational adoption of OSS. Table 6 reviews the innovati on level constructs th at this study will investigate.
20 Table 6. Innovation Constructs Construct Theory Reference Description Relative Advantage Innovation Diffusion Theory, IT Context Rogers (1995), Swanson (1994) The degree to which an innovation is perceived to be better than what it supersedes within a task context Compatibility Innovation Diffusion Theory, Network Externalities Theory, Routine vs. Radical Rogers (1995), Katz and Shapiro (1986), Nord and Tucker(1987) The degree to which an innovation is perceived to be compatible with existing organizational values, activities and technologies Complexity Innovation Diffusion Theory Rogers(1995) The degree to which an innovation is difficult to understand A Combined Model of OSS Adoption This chapter has reviewed adoption litera ture to identify speci fic constructs and variables that will be examined by this study to understand both th e adoption of OSS and its effect on the IT function of organizations A combined model identifying all of the factors this study will examine is shown in Figure 2.
21 Figure 2. Study Model Constructs Identified The model highlights the relationships of the constructs examined by this literature review. But more importantly th e model provides a theoretical foundation to investigate the research questi ons. Relationships G1a, G1b, and G1c allow for testing of the second research question investigating th e adoption perspective. Meanwhile G2a and G2b address the disruptive nature of the adoption of OSS. Open Source Software Adoption The final section of this literature review examines existing research investigating OSS adoption and how this research fits into the adoption model. To date there have been four studies examining OSS adoption. They ar e summarized in Table 7, Prior Research G1a G1c G2 G1b Environmental Factors External Communication + Peer Adoption + Vendor Relations + Technical community + Innovation Characteristics Relative Advantage + Compatibility + Complexity Organizational Characteristics Structure o Internal Communication + o Administrative Intensity Knowledge o Environmental Sensing + o Technical Knowledge + Size o Wealth + o Slack Resources + Organizational Adoption Stage Awareness Interest Adoption Routinization Infusion Disruptive Impact on IT Function Disrupts Routine G2a Open Source Adoption Level As is Hybrid Design Business Model
22 into Open Source Adoption. Three of the four studies focus on the adoption of Linux, an open source operating systems, rather than O SS adoption in general. The fourth study, while examining multiple open source applicat ions focused on adoption barriers rather than the adoption of OSS. Table 7. Prior research into open source adoption Reference Theory Findings Constructs Tested Chau and Tams (1997) Innovation diffusion theory Perceived barriers, internal technical standards, compatibility and satisfaction with existing systems were found to be statistically significant factors for open systems adoption. Technical Knowledge +, Technical Standards + Goodes (2004) Exploratory research Perceived lack of relevanc e, lack of support, lack of resources, commitment to Microsoft and a perception that open source software was not commercial were the driving factors of firms to reject open source software. Technical Knowledge +, Vendor Services +, Technical Standards + Peng (2005) Innovation diffusion theory Linux adoption by software service providers followed a bell-shaped curve as predicted by innovation diffusion theory. Peer Adoption + West and Dedrick (2006) Inductive theory Internal technical standards and organizational uses that lim ited the scope of the OSS were found to be significant factors in determining adoption. Vendor Standards +, Technical Standards +, Administrative Intensity Chronologically, the first study, Chau and Ta ms, examined factors affecting the adoption of open systems (1997). The phenome non that they investigated would be officially named open source a year later in 1998. Because of this Chau and Tam spent a portion of their research in identifying wh at open systems were and they accurately described an open source ope rating system like Linux. They based their adoption model for organizational off of elements of Innovation Diffusion Theory (Rogers 1995). To test their model they conducted eightynine interviews of both technical and non-technical managers. They found that the perceived barriers to adoption, internal technical standards, compatibility and sa tisfaction with existing systems were all
23 statistically important factors determining th e adoption of open systems. These factors are captured in this studys model and s hould be validated by this research. In 2004 Sigi Goodes examined why organi zations reject OSS. By surveying 500 of Australias top public companies, Goode found that there were seven main reasons why organizations did not use open source so ftware. These reasons include a lack of relevance, a lack of technical support, mini mal or no business requirements, insufficient resources, a commitment to Microsoft, a belief that open sour ce software was not commercial and no time. Goodes findings a ppear to highlight technical knowledge, technical standards and vendor support, or th e availability of technical knowledge and services from vendors. This study captures th ese factors in the res earch model and should validate them. The first study to specif ically examine Linux adopti on was conducted by Zheshi Peng (2005). Peng used Innovation Diffusion Theory to investigate how adoption stage, the number of suppliers and supplier partne rships impacted the adoption of Linux and Linux product offerings at an industry leve l. Peng created a research model that integrated Rogers Innovation Diffusion Theo ry with Moores Technology Adoption Life Cycle and the Density-Dependence Model. He then tested this model by performing a secondary data analysis of over 3,300 business articles starting from 1993 and ending in 2003. His had three main findings, those concerning new suppliers, new product offerings and new Linux partnerships. Peng found that while new suppliers followed a bell-shaped pattern proposed by Innovation Di ffusion Theory, new product offerings and
24 new Linux partnerships did not. Instead new product offerings experienced a slow steady increase that had, at the time of the study, yet to plateau or slope downward. New Linux partnerships followed a similar trend, slowly increasing over time. These findings are incorporated into this studys model in the vendor relati ons construct. The final adoption study examin ed in this literature revi ew also investigates Linux adoption. Conducted by West and Dedrick (2006 ), this research focused on OSS adoption in the context of being a technical standar d. Linux was proposed as a new standard, i.e. open source as opposed to proprietary, and they sought to understand how it might be adopted in the presence of both network effect s and switching costs that favor incumbent technologies. Taking an interpretive approach, West and Dedrick interviewed twenty-one MIS managers or executives at fourteen different MIS departments. They then refined aspects of inductive theory and constructs from Netw ork Externality Theory (Katz and Shapiro 1986) and Chau and Tams (1997) work in open standards adoption to arrive at three main conclusions. Their first conclusion was that standards adoption was influenced by vendor support of for a standa rd. Organizations appear to rely upon vendors standards to facilitate the integration of different systems. This was followed by evidence that the t echnical standards of innovations were also important for Linux adoption. West and De drick found that system s that had reduced scope and hardware requirements incr eased the likelihood of Linux adoption. Finally the authors found that administrative intensity of an organization in setting standards and practices also effected the adoption of Linux. Organizations that focused
25 on a single standard, either through employ ee certifications or legal commitments, appeared to focus on those st andards. This decreased th e likelihood of Linux adoption unless Linux was the organizational standa rd that organizations adhered to. These three factors, vendor standards, technical standards and administrative intensity are accounted for in the research m odel. Additionally West and Dedricks study gives credibility for adoption studies to ex amine all three factors, environmental, organizational and innovation, when determini ng the adoption of OSS. Existing literature examining the adoption of OSS provides confir ms how a number of factors from this studys research model have already been examined in the cont ext of open source software adoption. Collectively these studies serve to valida te the research model, as these studies highlight environmental, orga nizational and innovation specific factors as influencing adoption. However none of thes e prior works highlight any disruptive consequences, if any, of adopting OSS, nor do they identify a specific theory or group of theories as being influential in understanding the adoption of OSS.
26 Chapter 3. Research Design This chapter describes the methods and philosophical perspective used for this study. First the research questi ons and theoretical model guiding the study are reiterated. Next an appropriate research method, case studie s, is identified to an swer these questions. After this a section highlights how the data were collected, analyzed, and interpreted. Finally the chapter is summarized, high lighting the methods used by the study. Research Questions The research questions asked in this study seek to close two gaps in organizational adoption literature. First, does the adoption of a disruptive technology, like OSS, cause disruptions in adopting organiza tions. This gap in organizational adoption research drives the first research question: 1. Does and if so how does the adoption of open source software result in disruptions to adop ting organizations? The second gap in organizational adoption li terature concerns factors impacting the organizational adoption of innovations. Technol ogy adoption researchers have identified environmental constructs, like vendors and th ird parties, organiza tional constructs, like administrative intensity and technical knowledge, and innovati on constructs, like relative advantage and compatibility, that influence the adoption of new innovations. How these
27 constructs interact during orga nizational adoption is unclear. This creates a theoretical gap that the second research question seeks to answer. 2. Do, and if so how do environmental fact ors, organizational characteristics and innovation characteristics a ffect the organizational adoption of open source software? The literature review conducted in ch apter 2 identified eight different organizational adoption theories. These theories were combined with research about OSS adoption to create a theoretical model for this study. However, because existing literature does not provide direction or evidence of how these factors interact or when these factors influence organizational adopti on, there is a great deal of uncertainty as to how these factors affect the adoption of innovations like OSS. Because different organizational theori es propose constructs that influence organizational adoption, but do not integrate these different constructs, no single theory or group of theories is available to guide this study. Instead there is an abundance of competing organizational adoption theories that do not account for one another. This lack of organization between organizational adop tion constructs leaves a gap in theory. Because of this gap in understanding how these constructs interact, a case study methodology was selected. Appropriateness of Case Study wh en lacking theoretical guidance According to Yin (2002) a case study is useful for inquiring about a contemporary phenomenon within its real-life context a nd is especially suite d when the boundaries between the phenomenon and context are not clear (Yin 2002). Benbasat et al. (1987, p.
28 370) agree with Yin in his assessment of the appropriateness of case studies. They claim that they are appropriate when The bounda ries of the phenomenon are not clearly evident at the outset of the research and no e xperimental control or manipulation is used (Benbasat et. al 1987). Furthermore Benbasat et. al promote case studies for IS research at an organizational level. They claim that the object of management information systems (MIS) as a discipline focuses on understanding information systems within organizations. Therefore the case study is of special im portance because interest has shifted to organizational rather than technical issues (Benbasat et al. 1987). These researchers advocate th e use of case studies in th e absence of theory. This study will use case studies not because of an ab sence of theory, but because of a lack of theory linking together the cons tructs of extant theories th at affect the same phenomenon, organizational adoption of OSS. Research Methods Case Study According to Orlikowski and Baroudi ( 1991) the case study is the most common qualitative method used in IS research. The case study has multiple definitions as it can be used as either a unit of analysis, as in an individual case, or as a research method, through a case study (Stone 1978, Benbasat 1984, Yin 1984, Bonoma 1985 and Kaplan 1985). This research uses case studies in both wa ys; by using semi-structured interviews with individuals who work in IT departme nts, the case study methodology is employed. By analyzing five different case sites the st udy also uses cases as a unit of analysis.
29 Criticism of Case Studies Critics of case studies often point out that case study resear chers have problems making controlled observations and deductio ns. Their proximity to the phenomenon, when combined with potential biases and prej udices often leads to conclusions that are difficult for others to replicate. Because of difficulty in replicating studies, it is also difficult to generalize findings to larger popul ations (Lee 1989). This research examined a series related organizations, which, accord ing to Lee this should reduce these shortcomings, allowing for a better descrip tion of the phenomenon (Lee 1989). Research Lens Organizational Adoption Model Because the literature review conducted in Chapter 2 resulted in a research model that provides a starting point for this study. Rather than start with a blank sheet, constructs from established theories serve as a guide for this study. This model grounds this research by providing points of inqui ry based upon existi ng constructs. The constructs from the eight theories were used to create a list of interview questions that were asked in semi-structured interviews. These questions can be found in Appendix D, Interview Questions, while the research model, Figure 3 is shown below.
30 Figure 3. Study Model Restated The study uses a model to provide a framework through which the case studies can be conducted. This allows for a starting po int, as prior research has already identified the constructs. However, because prior re search does not identify the relationships between constructs, the relationships between th e different groups of constructs, seen in the model as relationships G1 (a-d) and G2 (a-b) became the focus for the semi-structured interviews conducted during th is study. Model relationships, G1 (a-d) and G2 (a-b), created guiding research ques tions that supplemented the studys research questions, leading to the examination of rela tionships between model factors. G1a G1c G2 G1b, G1d Environmental Factors External Communication + Peer Adoption + Vendor Relations + Technical community + Innovation Characteristics Relative Advantage + Compatibility + Complexity Organizational Characteristics Structure o Internal Communication + o Administrative Intensity Knowledge o Environmental Sensing + o Technical Knowledge + Size o Wealth + o Slack Resources + Organizational Adoption Stage Awareness Interest Adoption Routinization Infusion Disruptive Impact on IT Function Disrupts Routine G2a Open Source Adoption Level As is Hybrid Design Business Model
31 For example, in response to the second research question, How do environmental factors, organizational charac teristics and innovation characte ristics interact during the organizational adoption of open source software ? four guiding questions G1a, G1b, G1c and G1d are asked. G1a How do environmental adoption cons tructs operate during OSS adoption by organizations? Or more specifically, G1a How do external communication, vendor relations, peer adoption and technical communities affect OSS adoption by organizations? G1b How do organizational constructs opera te during OSS adoption by organizations? Or more specifically, G1b How does internal communication, envi ronmental sensing, technical knowledge, wealth, slack resources, and administrat ive intensity affe ct OSS adoption by organizations? G1c How do innovation constructs opera te during OSS adoption by organizations? Or more specifically, G1c How do the relative advantage, compatib ility, and complexity of OSS affect OSS adoption by organizations? And finally guiding question G1d follows exis ting literature by pl acing an emphasis on the different groups of different organizat ional factors driving adoption by asking: G1d Is the adoption of open source software is better explained by organizational characteristics as opposed to environmenta l factors or innovation characteristics? The model also addresses the first resear ch question, How does the adoption of a disruptive innovation result in di sruptions to the adopting or ganization? For OSS to be disruptive to organizations, it must first be adopted by an organization. Once adopted,
32 organizational adoption stage of OSS is then anticipated to affect the organizational IT function. Prior research proposes that adopt ion stages of adoption, routinization and infusion are thought to disrupt the IT functi on while adoption stages of awareness and interest are not. This provides a foundati on for G2a, the second guiding question: G2a Do OSS Adoption stages of adoption, routinization and infusion disrupt an organizations IT function in terms of implementation, operation, and support? As the model highlights, disruptions cau sed by the adoption of OSS are thought to be moderated by the level of OSS adoption. Orga nizations that adopt OS S at all levels are thought to be disrupted, but the disruptions are proposed to be larger at hi gher levels of OSS adoption. This relationship provides an other guiding question for this study, formally ask in G2b: G2b Does open source adoption level modera te the disruptive impact of OSS on the organizational IT function, with lower levels of adoption hav ing less disruptive effects? These guiding questions created a list of questions that were applied in semistructured interviews to st udy participants. Study particip ants, both the case sites and individuals interviewed, and que stions asked during the semi -structured interviews are more fully covered in the ne xt section, Data Collection. Study Participants To increase the likelihood that this study s results would be generalizable to similar organizations a comparative case study method was selected. This involved recruiting five differe nt municipal IT departments whic h makes the research method and the unit of analysis a case study method.
33 The five that participated were out of a group of eleven that were contacted. This group was formed as these eleven municipal governments were of similar size, serving over 75,000 citizens. Municipal IT departments were invited by contacting the head of the municipal IT department by telephone. During the telephone c onversation an invitatio n to participate in this study was offered. As pa rt of the conditions site anonymity was assured. Additionally participants were given access to studys resu lts and a review of other IT department practices including training, knowledge manageme nt and cost cutting measures. Five of the eleven municipal IT departme nts agreed to participate. Municipal IT departments of cities having more than 75,000 residents were selected for a variety of reasons. First, the governments of cities this size mirror medium to large size organizations in terms of budget and personnel. As table 1 in appendix item E shows, the smallest of the participat ing municipalities had a city budget over 125 million dollars while the largest municipali ties had city budgets over 725 million dollars. Second, because municipal governments are in the same industry; that of local government, use of multiple local government cases appears to increase the likelihood of study results being applie d within the industry. Third, municipal IT departments were se lected because the researcher had no prior connection to the municipal IT cont ext. This was done to limit biases or preconceived notions about the context, espe cially when interpreting the interviews. Finally municipal IT departments, like most organizations, are not in the IT industry. Although these departments focus on information technology, they, like most
34 businesses, do not create, manufacture or sell technology to customers. This makes municipal IT departments less likely to be cutting edge innovators or early adopters of new, disruptive information technologies like OSS, and follow technology adoption patterns more common to other business industries. Participation by the municipal IT depa rtment members was not random. Study participants were chosen by the municipal IT department. Additionally the municipal IT department scheduled the interviews, determ ining the ordering of when the interviews were conducted. Data Collection In this study two main methods were us ed to collect data, face to face semistructured interviews and site documents. Face to face interviews followed a semistructured approach because the interviews la sted between thirty minutes and an hour. In this brief time the researcher sought to understand the different factors surrounding OSS adoption, the disruptions the technology possibl y created and the rela tionship between the constructs. The interview script, Appendix It em C, provided a basis for the questions asked study participants, but, it should be noted that not every question was asked of every participant as the time allotted for the interviews was limited. Rather, as the semistructured format allows, the researcher focused on understanding the relationships between the study constructs and the driver s of OSS adoption. This is a well accepted form of data collection as premier journals in several fields have published work based upon semi-structured interviews (Repenning and Sterman 2002, Brusoni, Prencipe and Pavitt, 2001, Levina and Ross 2003, Pinsonneault and Rivard 1998).
35 Questions were asked of participants from the interview script which was based upon the study model. Follow up questions were then asked to understand the relationships between study constructs and effects caused by the adoption of OSS. These questions varied by participant. Some interviews followed the script; other interviews resulted in unusual responses that led to un ique follow up questions that were not asked of other individuals. Interviews were conducted by the primary research er at the participating municipal IT departments be tween October of 2007 and Apr il of 2008. The interviews were digitally recorded and then transcribed for analysis which will be discussed in the data analysis section. Rather than interviewing individuals of similar organizational role, it should be noted that study participants were of varyi ng organizational role and level within their municipal IT department. Participants incl uded executives, such as Chief Information Officers or Directors of Info rmation Technology, as well as area managers, such as Managers of the Database Area or Manage rs of the Networking Area, as well as operations personnel within these different areas, such as Database Analysts or Programmer Analysts. The variation in partic ipation at each site allowed for a spectrum of evidence to be collected from the study participants. The second method of data collection wa s an examination of site documents. These documents included city websites, budg ets, organizational st ructure, reports and other documentation. These documents supplemen ted the interviews and helped flesh out an understanding of the five participati ng IT departments. Documents included
36 organization charts, organization mission statements, statements of individual responsibilities, job de scriptions, lists of e quipment and other detail s of the participating departments. Data Analysis and Interpretation Data collected from this study were anal yzed at two levels. The first level of analysis was the individual ca se study. At this level of an alysis individual interviews were examined by coding the interview transcripts according to the interview script. Questions asked study participants can be f ound in Appendix item C. The coding schema used to code the interviews is al so in the appendix, Appendix item A. Because coding was done in alignment w ith the study model, selective coding was used. Selective coding was done by two c oders who were trained by the researcher. The coders had an initial coding accuracy of 92%, or 92% of their codes matched both the other coder and the studys coding schema. The coders were later able to agree on 98% of the total codes when they reconciled the research codes with the primary researcher of the study. Coding was done according to strips or se gments of interviews that mentioned study constructs. Because strips or segments could mention several topics, the same strip or segment could be coded for multiple constructs as the dialogue could contain more than one meaning. For example: We started transitioning into Linux bec ause when it came out and it just kind of like caught on. There was so much more software available on it. It wasnt like SCO was expensive and SCO was really stable, but I mean things like when
37 Mozilla would come out, you would get li ke all the new ones on Linux right way, and there would be like one version that came out on SCO youd have to wait a year and a half to get the one that came out and handled whatever you wanted to do. Roswell Systems Administrator A This strip was given multiple codes as it identifies several cons tructs in the study model. As the interviewer states, the depart ment transitioned to Linux, an OSS. Because the technology was routinely us ed at the time of the study, it received an adoption stage code of routinization. This also included the adoption stages of awareness, interest, and adoption as the organization needed to pr ogress through these levels to achieve a routinization adoption stage. Additionally the strip highlight s an innovation construct, relative advantage as the partic ipant identified more frequent updates as being superior or more desirable than less fr equent updates. Therefore th e strip was also coded for identifying a relative advantage of OSS. Because the interview script contained questions focusing on the different constructs used in the study model, coding of the interviews confirme d that the constructs existed at the site. Coding transcripts according to the model constructs also facilitated a general understanding of how the constructs affected OS S adoption stages, adoption levels and disruptive effects. However coding the interviews to th e study model did not clarify the relationships between the constructs, the relative e ffects of the constructs, or what drove the constructs within the organization. Rather, this understanding, how constructs were related to one another and what drove the constructs in the organization, was interpreted by the researcher. Understanding
38 how the constructs were related to one another was done by interpreting both model constructs and contextual themes at the participating site. To do this, the researcher asked further questions of himself, such as: What drives OSS adoption here? How is the organization adopting OSS? Why is the organization adopting OSS? By asking these secondary questions case themes, or contextual drivers associated with an IT departments adoption of OSS, were able to be identified. These themes appeared to provide an explanation of what drove the f actors at each site. Additionally, like other case studies, more than just facts related to the model constructs were discovered. Rich data about the context and how the model constructs interacted revealed how model constructs interact ed with one another and how the context of the municipal IT department affected the constructs themselves. Analysis was also conducted across the cases. By examining the different site themes and contrasting them with organiza tional factors, a deeper understanding of the OSS adoption patterns of lo cal government was interpreted by the researcher. This interpretation was based upon re-occurring tre nds and themes as characterized by the adoption of OSS by study participants. The product of this interpreta tion was insight into the nature of the municipal IT department understanding of how organizational adoption theories interacted with one another, and the identification of two additional constructs that appear to integrate or facilitate existing organizational adoption constructs.
39 After the cases were analyzed, the construc ts were assigned an impact value, high, medium or low. This value was based upo n the researchers interpretation of the construct during OSS adoption. Furthermore cons tructs were interpreted as having an overall impact value on OSS adoption as well as having impact values during different adoption stages. This allowed for a relative comparison of the importance of different constructs during the process of OSS adoption. Research methodology: Summary This chapter has outlined the methodology employed to gather and analyze the data for this research. A case study method us ing semi-structured interviews which based questions on a theoretical model was used to gather data. Five municipal government IT departments provided a setting for the study. Their participati on set the contex t outside of the IT industry in organizations si milar to medium sized businesses. The theoretically generated model was used as a basis for the semi-structured interviews which allowed for a deeper understa nding of constructs and the forces driving the model constructs. Data were analyzed as individual cases and acr oss cases. Analysis of individual cases centered on fi rst coding strips from the transcripts. These coded totals were then interpreted, along with contextual information from the interviews, by the researcher to interpret driving themes for OSS adoption at each case site. The five case sites were then interpreted by the researcher, allowing for the identification of overarching trends between the cases.
40 Chapter 4. Results The five case studies are divided into ten sections. The first section provides an overview of the case study. This is followed by a brief description of the municipality in which the participating IT department is loca ted. The third section is a brief description of the participating IT depa rtment, while the fourth sect ion describes the individuals interviewed. Meanwhile the fifth section pr ovides an overview of open source adoption by the organization. The sixth s ection begins to delve deeper into the case by examining the organizational open source adoption themes This is followed by the seventh section which provides observations of model factors, while the eighth section interprets how model factors were influenced by the site. The ninth section pr ovides an interpretation of OSS adoption at the site, and the tenth and final section is a summary of the case. Synthesis of the cases, or observations and tr ends from the five cases, are discussed in Chapter 5, Discussion. Roswell Network Integration Overview of Roswells Case Study Roswells adoption of OSS was heavily in fluenced by the citys network. Because the city had implemented thin client/thick se rver technologies in th e 1980s, transition to OSS technologies was incremental as these tech nologies used similar technical standards.
41 This allowed Roswell to pursue vendors that offered OSS products, further facilitating adoption. However the factor that stood out concerning Roswells OSS adoption was the municipalitys commitment to th e existing municipal network. This meant that the city sought to im plement IT in a manner that balanced function with the cost of integrating the t echnology into the exis ting municipal network. For example the CIO said that department heads regularly requested popular technologies, like BlackBerries to which he would respond, what do you need it for? If the need was instant communi cation, the IT department w ould search for technologies that integrated with the existing network that provided similar functi onality. This affected how Roswell adopted OSS and other technologie s as the IT department would search for IT that not only met end user needs but also integrated with the existing infrastructure of the city. Because OSS was an incremental adva nce in thin client architectures, a large portion of the citys network ran on OSS technol ogies. This alter how the IT department adopted technologies as the department sought to integrate new t echnologies with the existing network which was comprised of many OSS innovations. This altered the organizational perspective of how OS S fit into the citys technology. The network integration approach with in the IT department affected the administrative intensity, or how technologies we re searched for, within the department. Because the network was heavily implem ented through OSS technologies, the IT department routinely decentraliz ed search activities to search for alternative technologies. This approach, network integration, influen ced model factors of technical communities, vendors, technical knowledge and environmen tal scanning. Where OSS aligned with the
42 network and end user requirements, Roswe lls IT department implemented OSS over proprietary software. However, where O SS alternatives lacked functionality, the department did not hesitate to implement proprietary technologi es. Figure 4 highlights how the OSS integration of the department affected Roswells model factors. The remainder of the case more fully expands on how the environmental, organizational and innovation factors operated w ithin the IT department. Figure 4. Roswells OSS Adoption Description of Roswell With a population slightly more than 75,000 citizens, Roswell is the smallest of the participating cities in this study. It is often desc ribed as a bedroom community, as most of the residents work in nearby areas. Those residents who do work within Roswell are often employed in the retail and service sectors, as thes e are the largest sectors of Roswells local economy. While Roswell is pr imarily residential, its notable local Vendor Relations Technical Communities Environmental Scanning Technical Knowledge OSS Adoption Stage/Level Administrative Intensity OSS Integration Approach + + + + + + + + +
43 industries include electronics and light manufacturing. Sin ce Roswell is part of, and geographically-contiguous with a larger me tropolitan area of well over one million, its feel is more urban than rural. As an organization, the city has more th an fifteen departments that employ more than 900 people. These departments are funde d by a city budget that was in 2007, over 125 million dollars. The majority of this reve nue, more than 69%, was collected from property taxes. See appendix D for a co mparison of the size of the different municipalities. The mission of the municipal government is to provide superior services that enhance the quality of life and community pride. The citys vision is to be recognized as a vibrant, distinctive community with a dynamic, diverse, innovative, and highperformance workforce that provides superior services through responsible stewardship. This focus on quality goals and an unde rstanding of the need for dynamism and innovation to provide services guide the muni cipal government and these efforts have not gone unnoticed. Leading Roswell is a professional city manager. This full-time employee of the city reports to an elected commission of citiz ens. These citizens who comprise the elected commission set goals for the city manager a nd indirectly guide municipal activities. Description of Roswells IT Department With just over a two million dollar bu dget and slightly more than twenty employees, Roswells IT department is the sm allest in this study. See appendix item E, table 2, for a comparison of participant sizes. Although it is smaller than the other
44 participating departments, Roswells IT de partment had areas th at corresponded to the other participating IT departments. Thes e areas included administration, operations, development and end user support. Roswells IT department has been the onl y IT resource the city has known. As the only IT resource within the c ity, the IT department has ha d a major influence on the IT adopted by the city. By influe ncing which technologies are c hosen by the city, Roswells IT department has been able to showcase its ability to help save the city money, for example, the departments use of open source software is heralded on the citys website for saving taxpayer money. This has increased the importance of the department, giving the department autonomy and eliminating bur eaucratic levels of government between the city manager and the IT department. This is significant because this IT department has a direct link to city leadership to support or hinder projects that do not align with their goals. Roswell Participants Data for this study were gathered by conducti ng nine interviews, nearly half of the IT department, during the fall of 2007. Table 8 highlights the role a nd responsibilities of the individuals intervie wed. What was remarkable about th e personnel at Roswell is that there had been almost no turnover in empl oyees during the last fifteen years. The administrator of the IT department said th at only two people had left the department during his time in the department. Both in dividuals more than doubled their government salaries, and even with this extra money, one of the individuals had asked to come back to the IT department.
45 Table 8. Role and Responsibilities of Ro swell IT department members interviewed Interviewee Responsibilities Administrator of the IT department Responsible for overseeing all technolog y purchases, the operation of the IT department, strategic planning, proj ect management, and departmental budgeting. Participates in depa rtmental hiring process. Administrator of Operations and Support Responsible for managing operations a nd support personnel. Assists municipal employees with day to day ope rations of IT. Participates in departmental hiring process. Administrator of Operations Servers A Responsible for the citys networks, serv ers and applications on the servers. Perform research and development. Partic ipates in daily administration of city networks. Participates in project pl anning. Manages network personnel. Focuses on Linux servers and applications. Administrator of Operations Servers B Responsible for the citys networks, serv ers and applications on the servers. Perform research and development. Partic ipates in daily administration of city networks. Participates in project pl anning. Manages network personnel. Focuses on Windows servers and applications. End User Support Specialist Responsible for supporti ng end-user computing and infrastructure within the city. Focus on security and security applications. Development Programmer Responsible for supporting source code, business processes and database management for select city applications. Operations Specialist A Responsible for supporting e nd-user computing and infrastructure within the city. Focus on Windows servers and systems. Operations Specialist B Responsible for supporting e nd-user computing and infrastructure within the city. Focus on networking. Development Systems Analyst Responsib le for translating business requireme nts into software requirements. Expected to positively contribut e to end user relationships. Overview of Open Source Adoption by Roswell According to members of the IT departme nt, 40%-60% of all software used by the city is open source. OSS used by Roswell is both purchased from vendors and freely downloaded from OSS projects. Software s ourcing, purchased OSS, downloaded OSS or proprietary software, while influenced by the citys architecture also appears to depend on meeting contextual end user needs. For example the department had recently implemented a proprietary poli ce department software soluti on when it was aware of two open source alternatives. Th e proprietary system was chosen because it provided functionality that neither of the open source solutions coul d deliver. Therefore software sourcing appears to be complex at Roswe ll as the department takes both end user requirements and existing technical infrastr ucture into account when making technology
46 adoption decisions. Table 9 highlights the many areas and appli cations adopted by Roswell IT department. Table 9. Roswells Adoption of OSS Departmental Area Applications Adopted Influential Model Factors Adoption Stage Adoption Level Impact on IT Function Security Linux Variants, Nessus*, NMap, John the Ripper, Backtrack Internal communication, administrative Intensity, technical knowledge, environmental scanning, compatibility, relative advantage, Routinization Business Model** Routine Server Linux Variants Internal communication, administrative Intensity, technical knowledge, environmental scanning, compatibility, relative advantage, Routinization Business Model** Routine Network GroupWise, Evolution, Beagle, Linux Variants Internal communication, administrative Intensity, technical knowledge, environmental scanning, compatibility, relative advantage, Routinization Business Model** Routine End User Applications Open Office, PREPS, GIMP Internal communication, administrative Intensity, technical knowledge, environmental scanning, compatibility, relative advantage, Routinization Business Model** Routine Database PostgreSQL Internal communication, administrative Intensity, technical knowledge, environmental scanning, compatibility, relative advantage, Routinization As-is Routine *Open Source modules ** These areas either placed bounties on spec ific functionality or coded it themselves Security The security area of Roswell had adopted a wide variety of OSS. Many of these applications come in distributi ons of other open source appli cations like server software or operating systems. Because members of the security area have issued bounties to get functionality the department desires into base packages, the adoption level is classified as at a business model. The security areas adoption of OSS appe ars to be heavily influenced by the thin-client, thick-server architecture. Security personnel in Roswell
47 spent time in either the network or server area before moving into the security area, increasing their exposure to OSS te chnologies used in these areas. Server Central to Roswells IT infrastructure is the departments server area. This group implemented the technologies that ran most of the citys software, as the thin-client, thick-server technology focuse d on terminals linked to serv ers. Persons in the server group routinely used OSS and participated in the development of OSS applications, either by placing bounties on functionality de sired by the department, or by creating appropriate code and offering it to the OSS project. Because of its involvement with OSS development, the server group can be descri bed as having a routin ization adoption stage and a business model adoption level of OSS. Networking Like the server area in Roswells IT department, the networking area was heavily involved with OSS adoption. This group impl emented the technologies that linked the citys servers together. Persons in the server group routinely used OSS, participating in the development of select OSS applications. Th is participation came in one of two forms, either by placing bounties on functionality desired by the department, or coding the desired functionality into the program and shari ng it with the OSS proj ect. Like the server group the networking group can be described as having a routinizati on adoption stage and a business model a doption level of OSS.
48 End User Applications End user applications at Roswell are mo stly OSS. These applications were found and installed specifically to integrate with th e thin-client, thick-server environment that Roswell employs. Like the security, serv er and networking areas, the end user applications area has placed bounties on O SS functionality. However unlike many of these areas the end user applications area does not participate in the development of software. Because of the routine use of OSS, and because the end user applications area indirectly modifies the deve lopment of the software, cla ssifying it as a business model adoption level. Database The final area in Roswells IT department to have adopted OSS applications is the database area. This area purchased a distribut ion of an open source database to routinely store municipal information, giving this ar ea a routinization adoption stage. Because members working in the database area did not contribute to the OSS, either by coding functionality or by placing bounties on software features, the adoption level of this area is considered as-is. Roswells Open Source Adoption Themes Two main themes appear to have influe nced model adoption f actors at Roswell. First the city has a history of using a tec hnology associated with OSS; thin-client UNIX based information technology architectures. In the early 1990s the city chose a thin client infrastructure rather than personal computers for city computing. When the organizations providing the operating systems for the thin-client environment had
49 difficulties, the city began searching for alternative operating systems. As the city was accustomed to a UNIX based environment, this evolved into Linux, an OSS closely related to UNIX. The second major theme at Roswell that appears to drive OSS adoption is a commitment to employee training and developm ent. As per the Administrator of the IT department, Ive cut capital programs before I cut training. Administrator of the IT department Roswells IT department support of employ ee training is eviden t in a $1,000 training budget for every department member, which they are allowed to spen d as they see fit. This allows for Roswell IT personnel to gr ow their skill sets a ccording to how they believe they can best serve the municipality. Roswells Model Factors Environmental Factors Both the commitment to thin-client technologies and employee development appear to influence the environmental factors at Roswell. The commitment to thin client technologies started in the ear ly 1990s. According to System s Administrator A, who has been with the city for more than twenty five years: (If we had adopted Personal Computers as opposed to thin client servers) We would have ended up replacing disk dr ives and video cards and power supplies all day. And thats all you would ever do, run around and fix peoples PCs (Personal Computers). So we started looki ng at different things and we settled on
50 X-terminalsSo everybody wanted the X-terminals and we basically got all the stuff out probably within tw o or three years and we kind of avoided the whole PC thing in that way. Systems Administrator A Systems Administrator B, who has a similar te nure to Systems Administrator A, verified this commitment to thin-client technologies. Its (Roswells IT framework) always been server-centric type of computing rather than locally. Systems Administrator B Much of the IT departments external communication centers on sources that help provide thin c lient technologies. However exte rnal communication, primarily looking at new technologies, is promoted within Roswells IT department. In the CIOs words (Looking at new technology benefits us ) because I guarantee that in 6 months theres going to be a vendor sitting in my office trying to sell it to me! I can then say Well what about this, how does it addr ess this, it doesnt handle this So I can have these intital frank conversations with these sales people and I know when theyre bullshitting and when they re ally know what th eyre talking about. So that benefits the city immediately. CIO External communication with vendors is routine as vendors help provide services, such as training, technology implem entation and external validation for the city. Several members of the department commented on the use of vendors in these functions: We hired a consultant for two days. He gave me like a crash course on MAC OSX and how to manage the server and what not and then from there I just kind
51 of pretty much taught myself. Got so me books, did some reading and you know, just took off with it. IT Support Specialist II A Ive got consultants working with me on the creation of it (strategic plan), okay? Only because I dont have the time nor th e resources on staff to do a strategic plan. CIO Four different consultants over about a year and a half. All four of them said Leave them alone. How theyre doing what theyre doing on the budget that they have, leave them alone. So finally th e city said Okay you guys know what your doing. But every three or four years it comes back up and we have to start defending why were doing open source. Programmer/Analyst/DBA A Because the city has a history of using th in client technologies the city mainly worked with UNIX providers. But during the late 1990s, when Linux became an alternative to UNIX technologies, the city migrated to Linux. We used to use STL UNIX which was kind of like a Linux, but it was prior back when computers were really ahead of th eir time. Systems Administrator A Its a financial system that was orig inally purchased running on UNIX using a proprietary database and programming language. (The vendor) is currently migrating that over to Linux and they have a web browser interface on an open source databasepeople love it. CIO
52 We started transitioning into Linux bec ause when it came out and it just kind of like caught on. There was so much more software available on it. It wasnt like SCO was expensive and SCO was really stable, but I mean things like when Mozilla would come out, you would get li ke all the new ones on Linux right way, and there would be like one version that came out on SCO youd have to wait a year and a half to get the one that came out and handled whatever you wanted to do. Systems Administrator A Because they have a history of worki ng with OSS, Roswells IT department utilizes their external communi cation with its vendors to get customizations put into base OSS packages. We actually work with our vendors to cu stomize code. Like for instance one of the applications that we have Evolution or OpenOffice for instance, we work very closely with the vendo rs and they help us customize code and what not and if we need to you know have problems upgrading it or moving it over to another machine or what not, theyre always able to help us. IT Support Specialist II A We try to stay away from (on-site) cust omizations. Because any time you have to run a patch or do anything you run into problems. Systems Administrator B Open source you can buy the product and you can customize it based on your needs, so you can generic, you know like say operating system. You can get like
53 Redhat or something like that and then you can add packages or add features as you see fit based on your current need within your organization. Which you know its fantastic, I mean its infinitely cust omizable for your situation. Because everybodys setup is a little bit different. Their networks are different; you know their needs are different. IT Support Specialist II A Interacting with open source vendors appears to alter Roswells IT departments expectations when dealing with vendors. Th ey appear to expect their vendors to be responsive and move quickly. We get patches on some things (OSS) like the same day, n ext day. Systems Administrator A We had an (Vendor X) server here we want ed to upgrade the disk drives in it. That took like six months. Six to nine months to basically make a purchase and have the guy come out here, image the syst em, put drives in and image it back. Systems Administrator A If you get in with some of the people, and you know you do testing for them and they know you run it and th ey take some pride in it. I mean if you find something bad in there I mean theyll basically drop what theyre doing and go fix it. Which is you know if you ever try to get a patch out of Microsoft or one of the commercial vendors it might be two years before the version comes out. Systems Administrator A
54 Use of OSS vendors does not mean that the city has abandoned proprietary applications; rather they look to meet e nd user functionality within their existing architecture as opposed to fo cusing on a vendor name or pr oduct. For example the city recently implemented a proprietary police sy stem. After evaluating several software packages, some of which were open source co mpatible, the city decided to purchase and implement a proprietary police information system. There are two open source police systems out there. And when I say open source, theyre proprietary packages written in an open source language using open source databases which runs on an open source platform. But the software is proprietary, which is fine. I dont have an issue, but theyre very selective. They either do just CAD or just records manage ment, or one or the other. And both of those are just not mature enough with the features that we were looking for...theyre both years away from being any where near as mature as the package that weve purchased. It is a matter of meeting a certain service level. CIO Because Roswell focuses on thin client technologies their reliance upon their peer relations appear to be almost non-existent. Most municipalities in the state rely on personal computers rather than thin client technologies. This difference appears to encourage Roswell to largely ignore their peers when searching for new technologies. I couldnt tell you anybody else who is doing what were doing here. IT Support Specialist II B Perhaps this focus on thin client technology has encouraged Roswells IT department personnel to shift from their peers to technical communities Because
55 employees are encouraged to examine, or play with, new tec hnologies, Roswell IT department members seem to look for technica l communities that help provide them with this information. I really encourage my staff to enhance their skills constantly through either seminars, lectures, online training. Just spending time at their desk. Something they want to go learn about? Take it apart, wo rk with it, just go play with it, you know? CIO But theyll (IT department members) go out and play with stuff and that carries over to their private life a lot too. Because what theyll do is theyll go play with it at home. And then they play with it here and yo u know if it costs a few bucks to go buy something that they need, Ill fund it for them. Because more than likely, the city is going to get a benefit out of it. CIO Roswells interaction with technical communities also appears to be affected by the IT departments focus on thin-client t echnologies and employee training. Two of the three Systems Administrators at the city ar e active members of open source communities. (Systems Administrator C) will find all th ese toys and all these great little things and hell bring them in. Normally (Syste ms Administrator A) is the one that installs and tunes them. Programmer/Analyst/DBA A (Systems Administrator C) is our open source interface. He talks with the open source world all the time. Hes done quite a bit, hes well respected because he
56 knows when Roswell gets something that we ve asked for, that we will literally go test it and give them feedba ck. And thats part of partic ipating in the open source community. CIO This involvement with open source communities appears to focus around getting customizations or requests put into base OSS packag es. Although the citys IT department members rarely develop software for these communities they commonly pay technical communities to develop their customi zations for open source projects through a practice called bounties. We dont do that much customization unique to our state, or Roswell. What we do is we get in enough on the ground floor in the developmen t of it (an open source application) and make suggestions as to what the software should do. So we usually get all the features and func tions that we want right into the base software thats supported by th e open source community. CIO Well have software, theyll be package s that might be more mature where we havent been on the ground floor and we se e something. Well actually put a bounty out, and what that is, is your asking for a software change. You put a bounty out, you say Here, were willing to pay this much money for it. And somebody out in the open source world will pick it up, write it, and deliver it for you. You dont pay them until it is right. So we do that periodically, so hell (Individual X) put the bounties out and we ll get the changes to the software that we need and we pay them through Paypal. CIO
57 Now when I say a bounty, were ta lking about anywhere from $200-$500. I mean were not talking a lot of money here. You know I mean, you know if you probably break down the hours that they have to work, theyll probably be charging you $10 an hour. CIO This alters how Roswell interacts with its technical communities In addition to using these communities as an online resource to solve day-to-day problems, Roswell leverages technical communities to help develop software to meet current and future city needs. For example Roswells IT department had worked with the developers of a scheduling system to get their customizations implemented into the standard package of the software, ensuring that they would not need customizations or special support for their specified functionality. Organizational Factors Within Roswell the focus on a thin-client architecture and employee development not only affected environmental factors, but also affects orga nizational model factors. For example Roswells commitment to employee development seems to facilitate high technical knowledge, environmental scanning and internal communication as employees are encouraged to learn new thin gs and share this information with one another. The knowledge that we learn, we share it amongst everybody in IT. You talk to my staff, we share everything between us. We dont have anybody that hordes information. CIO
58 It is inconceivable to me that somebody would work in an IT department and not want to share their knowledge with a fellow employee. But I guess people are trying to protect their jobs so theyll be like Oh, well Ill keep this to myself and Ill know how to do it and nobody else will so they wont get rid of me! IT Support Specialist II A We dont have like Well youre a develope r, you can never do this network management or youre a support person you can never do network management. And sometimes if somebody comes in and has the skill for stuff they will informally become your network person. Systems Administrator A I know it sounds crazy but everybody has ideas and everybody puts their two cents in and everybody you know cont ributes. IT Support Specialist II B Perhaps this attitude of knowledge sharing stems from a desire to be prepared for employee turnover or to allow for departmental redundancy. (The CIO) would like everybody to do everybody elses job. Manager for Operations and SupportIt took me twelve years to learn this and you can take twelve years, so Im no t going to tell you what I learne d in twelve years. It doesnt exist here. So in other word s you feel collective. Every one shares what they know. So youre as smart as everybody else in that sense. Manager for Operations and Support
59 You gotta wear many hats. IT Support Specialist II A Everyone here wears a lot of hats. E verybody here does a lot of different things. IT Support Specialist II B I work with everybody. Everybody works with everybody. Programmer/Analyst/DBA A Or perhaps this attitude towards knowledge sharing stems from a desire to, as the CIO said, stay ahead. I allow time to do that (environmental sc anning) as part of my program here. I call it R&D, research and development, b ecause thats how we kind of stay ahead of what I feel is, we stay ahead of people because my staff is out there looking for things to go play with, a nd I allow them time. CIO Regardless of the motivation for allowi ng for knowledge acquisition, the employees appear to genuinely enjoy the department. This has resulted in very little turnover within the department, increasing the average tenure of the department members. I like the challenge. It is always something different, theres always something new going on, and theyre (the IT depar tment) very much about training and upgrading your skills and they give us a training budget every year so we can continually you know learn. IT Support Specialist II A We think of her as th e new person, shes probably been here ten years. Systems Administrator A
60 The department furthers this commitment to technical knowledge, environmental scanning and internal communication by encouraging employee training and internal discussions. Each empl oyee has their own training budget, which at the time of this study was $1,000. Additionally the employees themselves decide how to use their training dollars. Ive cut capital pr ograms before I cut training. CIO They (IT department) need to keep thei r skills up. They need to understand that we want to invest in them. Normally what happens is, thats what people look for, because its a turnover issue. First thing that normally happens is that organizations cut out the tr aining. Then what happens ? Everybody gets upset. People start leaving, you know because th ey want to go learn. They want to see other things. So I dont cut that (training). CIO We have a budget for every person in IT for trainingIt changes based upon what projects theyre working on. Manager for Operations and Support As departmental members are allowed to develop and specialize in different IT areas, the city has rewarded these memb ers by promoting them. For example a new network administrator and s ecurity lead have come fr om the IT support area. Right now we have just moved him (newer hire) in less than two years he just is now the network administrator for the city of Roswell! He started out in the entry level position. M anager for Operations and Support
61 I didnt have a lot of experience but I really ran with it and have been very happy and now theyre moving me up. Theyve moved me up twice in less than three years. IT Support Specialist II A I dont just do security right now, despite all I do I still do pretty much everything I used to do. IT Support Specialist II B Internal recognition of achievements a ppears to encourage IT department members to refine or extend projects th at they have previously accomplished. They just figured out somethingso t hat our broadcast guy who runs our TV station when hes home, after something gets hosed up with the TV. He doesnt have to come down here at three in the morning to broadcast from the straights up now. They got him so that he can remotely access everything from home through a little notebook. And they even simplified, they already accomplished that about a year ago with him. But they just found a new open source, some kind of a VPN open sourced software thats goi ng to even make, instead of using the three IPs to get all this d one we can save two IPs and its going to be more robust. Its got better compression, theyve figured it out! He wasnt complaining that he needs something, they just said You know we can do this better for you! Manager for Operations and Support
62 They (my staff) always look to see how things are working, not broke, now of course we have things that break and we have to fix it. But they try to find out better and more efficient ways to get th ings done. Manager for Operations and Support (In response to You had solved the probl em, why did you take a solution a step further) Because it was to do it better. You know the initial setup was just to get him access and we revisited it because we kn ew we could do it in a better way. IT Support Specialist II A Because the IT department has a history of collaboration to, not only complete projects and solutions, but to also extend th em, the administration appears to trust the department. This trust appears to result in a lower overall administrative intensity The CIO said: I built a trust level with people peopl e like dealing with me and I still have all of my staff here that were here when I started, and I mean their longevity here, that core of people is over 20 years on a verageI let my staff do their job. I dont micromanage them, I dont tell them they need to go and do this. They need to go out and do their job. CIO However this does not mean that the ad ministrative intensity of the technology adoption process has been removed. Rather it ha s shifted to select parts of the technology adoption process, the begi nning, or requirements anal ysis, and the ending, the implementation.
63 When we look at a new application we actually go in and do a full analysis of the department or division that the software is going in for. We do a needs analysis, we interview everybody in the de partment. We put together a document, or and I say we it is a joint venture be tween the department and IT. If it is large enough well get an outside consultant to come in and validate the needs analysis. Theyll do spot checks through it to make sure everything looks like it is in order.CIO What weve done is were looking, were trying it (new innovations) and the way we work it is before I usually let it out to other people in the city I do my review of it. And my deal with them is Im going to play devils advocat e bad user. Youre the techy guy, so Im going to try every thing in my power to break it (new innovations) do anything wrong with it, and wh en it passes all of that, then Ill let it go out to the field, because I dont want the typical user here in the city to be exposed to that type of unnece ssary training or problems. CIO This appears to alter the administra tive processes around OSS technologies. You know it doesnt change your policy just because it says open source. It doesnt mean the rules dont apply anymore, as a matter of fact the rules are even tighter, if you want to know the truth. But its the same process, you know for selection. CIO
64 I mean theres lots of open source so ftware out there, most of it I probably wouldnt even put in here. Either it doesn t fit well, doesnt work well, its not intuitive; it would cause more trouble t han it would be worth type things. We looked at a lot of things, or the licensing is not right on it. So I looked at a lot of different things when we l ooked at software. And actua lly its the same things I look at when I buy proprietary software You know just b ecause it says open source, you dont go and forget all the th ings you normally look at you know? When you look at open source you gotta do the same thing! CIO One organizational construct that ap pears to drive OSS adoption is the wealth construct. However unlike existing theory Roswells wealth construct works opposite to theory, a lack of wealth appears to motivat e adoption. Rather than increased levels of wealth spurring adoption, decreased levels of wealth appear to be encouraging the adoption of OSS. Because the IT department ha s been able to demonstrate cost savings to the city management the IT department pe rsonnel believe that they have good relations with the executives of the city. Weve had good support from the city manage ment. Systems Administrator A I mean we usually get whatever we b ecause we have a record of not wasting money. If we want something we usually get the money for it. Systems Administrator A
65 Were always aware that Ro swell isnt one of the rich est cities in the world and we try to keep that in mind when we do our work. IT Support Specialist II C Were trying to save them (the taxpaye rs) money. I mean thats part of our goal, but we want to get the right product. It s going to cost money, I dont care how much it costs, I want the right product We yea, we have a budget, but our budget is always generous when it comes to ge tting the right product. We dont skimp on quality. We want the best, most stable, highest quality product to get the job done. In other words thats going to demand le ss of our interaction. That means its going to cost 20% more we budget for that 20% because it will actually save us people and time. Here we dont suffe r from tunnel vision. Manager for Operations and Support From a management point of view I mean weve saved the city you know I think millions of dollars. Systems Administrator A The construct of slack resources was the only organizational c onstruct that appeared to be absent. No employee reported having slack hours. However the department did have a test system that allowed them to test new technologies before implementing them into the citys architecture. Innovation Factors Roswells commitment to thin client arch itecture also appears to affect how the city perceives innovation relate d model factors. The intervie ws highlighted several areas
66 where the thin-client OSS arch itecture appears to influence the departments perceived relative advantage, compatibility and complexity of OSS. Roswells perception of OSS relative advantage seems to be present in the IT areas of security, licensing, maintenance, extension and resource consumption. Roswell department members believed that information system security was enhanced due to the thin-client OSS network. According to Roswell personnel: All those viruses that have come out, theyre all on Windows executable basically. And so we run email and we run our storage on Linux so we run, I mean so basically the people that and we run browing on Linux so basically when someone gets, downloads something, gets it in email, it has now way to execute because its a Windows executable. Systems Administrator A Weve never had a virus tear through our ma il server and take us down for six days or something like some other cities have. So weve saved a lot of employee hours. Systems Administrator A You cant launch an .exe on a Linux machin e so I feel like we are a lot more secure in that aspect as we ll. IT Support Specialist II B The thin client architecture also increases physical security of the citys computer network. There are a select few CD drives and other external hardware interfaces in the thin-client architecture. This encourages Ro swell personnel to use email and electronic means to communicate and relay work. This electronic paper trail can be used to
67 quarantine the citys network if an attack does occur, again providing a perceived relative advantage to the city. We dont have CD drives, the floppy drives at the desk. I mean we tell people to work electronically so if they need to send something to somebody they do it by email, they dont walk around with floppies and bring in stuff from home and install their own programs. So from an IT point of view its a really manageable environment. Its really stable and cost ef fective. But we do fight with people. Systems Administrator A Licensing appears to be a nother area where OSS has a relative advantage over proprietary equivalents. Not only do the license s themselves cost less, but the man-hours needed to track and keep the licenses current appear to be greater for proprietary technologies. This seems to decrease the at tention that Roswell personnel pay to a nontechnical, non-functioning attr ibute of the technology, incr easing the relative advantage of OSS to the city. Ive had to keep track of some of the Microsoft licensing in the past back when we used to use some Office around the c ity and were talking just a couple of hundred licenses and it just seemed like a huge chore just to keep track of that end of it, let alone you know, if youre talk ing all these other app lications yo u have to keep track of. IT Support Specialist II B Running on Linux, you dont have to worry about licensing considerations, all we do is license the product, and thats an ideal scenario for a city. CIO
68 A third area of perceived relative advantage appears to be the maintenance of OSS in Roswells thin-client architecture. Pe rsonnel are convinced that OSS has superior performance to proprietary equivalents, needing less attention. Like the relative advantage of licenses, this perceived performance seems to decrease employee time spent on maintenance activities. Its nice having the server run for w eeks and weeks and weeks without having to reboot it or touch it or do anythi ng with it. IT Support Specialist II A if you go up to our help desk, the phone s arent ringing and its not very busy or anything and when people call its usually I forgot my passw ord. Or Can I get access to this other application? Its not like This is broken and you know that kind of thing. Systems Administrator A Other than the Microsoft st uff, I mean thats theyre always doing stuff to keep that going. But on our si de, our databases never go down. Linux never shuts down. I mean so were never caught in the day to day. We have time to do R&D and the things that we need to do, we re not having to focus on Oh my god, whatever Programmer/Analyst/DBA A Finally, according to Roswell IT depart ment members, the thin-client OSS architecture uses far less resources than proprietary PC technologies. The thin-client environment appears to need fewer servers and less processing power than proprietary PC based technologies.
69 server runs the entire thing (ERP system) for the city. Unlike the police system that we bought requires 11 servers. Its Micr osoft based, that in of itself is not necessarily the whole reason, but it just being Microsoft the vendor does not like to put more than one application on a server. So having multiple applications on a server they feel causes degradation and potentially have conflicts. You know were going Well, youre saying exactly w hat I say, which is the reason why we like Linux! and they cant understand why people want to do it on Linux, theyd rather do it on Microsoft and make every body buy more servers. Which means you need to buy more Microsoft license s, which means you need to buy more Microsoft operating systems, which means you need to buy more Microsoft this and that and everything else. CIO We got enough Microsoft in here for about 15% of the users and we doubled our staff. Programmer/Analyst/DBA A Roswells thin-client architecture also impacts the networks compatibility Because the city uses both OSS and proprieta ry technologies the city has two separate technical standards. While pr oprietary and OSS technologies can interface through proper mediums, such as the Internet or program emulators, proprietar y and OSS technologies do not have the same commands or actions ne eded to perform day-to-day tasks. This appears to decrease the compatibility of OSS technologies with the processes Roswell personnel are accustomed to.
70 Every so often well get so mebody that came in here and you know theyre just determined that they want to have y ou know Excel or something and we go through battles with them and we actually have meetings and theyll saywell say Give us the thing that you cant do in OpenOffice that you could do in Excel. And theyll start talking and talking and basically it comes down to like Well its two clicks in Excel and three clicks in OpenOffice. And were like Okay, but were not going to change our architecture because you have to say insert row from an extra click. Y ou know? Systems Administrator A They call it third world softwar e. IT Support Specialist II A They (other departments) hate us! They hate and they blame us for them not being able to do things the way they ve always done them. Systems Administrator B However within the IT department, the co mmands and technical skills associated with OSS or proprietary, ap pear to be compatible with one another. Systems Administrator A remarked the following: Were using Linux, different flavors of it, and it really doesnt matter what flavor you use once you get used to one you c an pretty much work with another. Systems Administrator A However within the broader contextual areas of security, licensing, maintenance and resource consumption both proprietary and OSS technologies appear to have the
71 same meta-processes. At a high level they s eem to be highly compatible as both standards need to address similar areas. Really operating systems are operating a syst em. It doesnt matt er what it lies on, its how does the applicati on work. Thats all it is. A lot of peopl e just dont want to take the time to learn the differences. IT Support Specialist II C Finally the complexity of Roswells thin-client OSS architecture appears to influence how the IT department pers onnel learn how to us e the technology. Ill tell you open source was new to me so it was a learning curve for me. I went out and I spent a lot of time studyi ng it and understanding w hat it was. I felt comfortable with it a fter about 1 year. CIO Client technology was radical. You know, not to have a PC on everybodys workstation, run everything through the servers. Manager for Operations and Support I admit we have one of the most sophi sticated warehouse environments in the whole country. Manager for Operations and Support Coming into a Linux environment was a bit of a culture sho ck at first. IT Support Specialist II A
72 OSS Disruption within Roswells IT Department Roswells IT department did not ap pear to be disrupted by OSS. OSS technologies were routinely adopted by each of the IT department areas. Additionally departmental processes of support, implement ation, and training appeared to align with OSS technologies as OSS technical communities and vendors were fit where appropriate. For example, according to the Director of the IT Department, every week the city had classes on common open source applications, like Open Office, that city staff could take to learn the technology. Additionally many members of the department referred to using online communities through bountie s to have OSS communities perform maintenance and extension ac tivities associated with technologies used by the department. Finally the System Administ rators interviewed were accustomed to providing feedback on programs to OSS commun ities in exchange for new features or designs, integrating them into OSS practices. Interpretation of Roswells Model Factors Coding the interviews resulted in the identification of 522 instances of model constructs. These codes related to twenty one of the twenty two codes in the study model. Coding can be seen in Figure 3, Roswell Interview Codes, which shows the model constructs, such as adoption level and adop tion stage, and the role of the individual within the IT department who identified the construct. The only construct that was not readily identified was the disruptive constr uct relating to OSS. However some codes, associated with knowledge or complexity, appe ared to be related to disruptive as they
73 implied a change in skills or routines for other members of the city government. For example: They (other departments) hate us! They hate and they blame us for them not being able to do things the way they ve always done them. Systems Administrator B They call it third world softwar e. IT Support Specialist II A Thin Client technology, it was radi cal. You know not to have a PC on everybodys workstation. Run everything through the serversIt was just so cutting edgeI studied trends a year in advance.Administrator of Operations and Support These quotes indicate that, while OSS was not disruptive to the IT department, as it was routinely used by every IT area, it was perceived as disruptive to members of other municipal departments. Figure 5. Roswell Interview Codes
74 As covered in the methodology section, c oding of the constructs verified the constructs but did not provide insight as to how the constructs were related. Rather, because the interviews were conducted within the municipal context, city themes were interpreted from the interviews that were used to understand the c onstructs within the context of the city. Environmental Factors Roswells environmental factors appeared to influence all of the studys stages of OSS adoption. External communication vendor relations and technical communities appeared to influence OSS adoption throughout the innovations adoption process as they were used to facilitate awareness and inte rest in the technolog ies. By communicating with vendors and technical communities that used thin client networks, Roswell IT department members appeared to be well vers ed in thin client technologies and their capabilities. External communication with ve ndors and technical co mmunities appeared to increase the awareness of both propr ietary and open source technologies. These factors, external communication vendor relations and technical communities also appeared important during adopti on and later stages as Roswell used vendors and technical communities as third parties for training, support, and other services. This appears to integrate vendors and technical communitie s into Roswells IT department processes, increasi ng the importance of these fact ors during the latter stages of adoption. The only environmental factor at Roswell th at did not appear to play a significant role in technology adoption was peer adoption This factor did not seem to be relevant
75 because of Roswells uses of thin client technologies. Other municipal IT departments, as observed by this study, do not have extensive use of thin client servers. Rather Roswells peers appear to adopt personal computers (PCs), a different type of computing architecture. This architectural difference a ppears to affect the software adopted by the institutions for specific organizational func tions, and, because Roswells IT department members do not believe that they common infr astructures, they do not access their peers for information. Table X highlights how Rosw ells Environmental Factors appeared to influence OSS adoption, the relative strength of the factor, and which adoption stages appeared the factor seemed to influence. Table 10. Roswells Environmental Factors Factor Theorized Effect on OSS Adoption Finding Influence on OSS Adoption Adoption Stages Influenced External Communication Facilitate adoption by creating awareness and interest in OSS Facilitated the adoption of both OSS and proprietary applications as departmental members were aware of multiple versions of contextually applied soft ware. Influenced later stages by connecting de partmental members to OSS communities for activities such as development or support. High Awareness, Interest, Adoption, Routinization and Infusion Peer Adoption Facilitate adoption by creating awareness and interest in OSS Roswell was largely unaware of other government adoption of OSS. However Roswell was aware of other organizations within industry who adopted OSS. Low Awareness Vendor Relations Hinder adoption through switching costs and other mechanisms Roswells vendors were influential in technology adoption so much as their product met organizational needs. One of those needs was integration with the thin-client architecture which appeared to decrease switching costs. Additionally Roswell seemed to work with OSS vendors to get functionality implemented into the base offerings of their software. Moderate Awareness, Interest, Adoption, and Routinization Technical Community Facilitate adoption by creating awareness and interest in OSS Facilitated adoption as technical communities not only increased awareness and interest of OSS, but also participated in software development High Awareness, Interest, Adoption, Routinization and Infusion
76 Organizational Factors Like Roswells environmental factors, Ro swells organizational factors appeared to be present during the entire adoption process. Internal communication and technical knowledge appeared to affect every stage in the adoption process. Perhaps these factors, along with environmental scanning and the environmental factors of external communication vendor relations and technical communities influenced every stage in the adoption process because of the orga nizational culture of the IT department. Because Roswells CIO encouraged his pe rsonnel to learn about new technologies and share this information with other departmental members, Roswells culture appeared to focus on acquiring new knowledge and disseminating it throughout the IT department. Consequently the culture appeared to influe nce how these model factors were used during the adoption process. Roswells organizational culture also appeared to affect administrative intensity The CIO appeared to have a great deal of trust in his depart ment and only bounded IT department personnel during technology sear ches by placing use requirements when he played devils advocate of a bad user. By ta king up this role to test technologies that were selected by IT department member s the CIO allowed IT personnel to choose technologies that they thought would best fit into Roswell s architecture. Without objective evaluations and testi ng it is difficult to determine if the technologies chosen by IT department personnel were optimal fits in to the network. But what this study does show is that this fr eedom during the technology selection process was not only appreciated by Ro swell personnel, but also considered f un. At the time of
77 the study, turnover in the department was almost non-exis tent as two members had left during the last ten years. Therefore limiti ng the administrative intensity of technology selection to the adoption process appeared to reinforce the departments use of internal and external communication as well as e nvironmental scanning, technical knowledge and use of vendors and technical communities. The only model factor that was observed to operate contrary to theory was wealth Instead of excess wealth facilitating the a doption of a new technology it appeared that a dearth of wealth facilitated the adoptio n of OSS. This is in keeping with theory about disruptive innovations, as there are both new market and low end disruptive innovations. As OSS can be id entified as a low end disr uptive innovati on, or an innovation that enters a market by providing lo w cost services, cost savings or cost pressures, i.e. low levels of wea lth, appear to motivate its adoption. This appears to be in keeping with one of Roswells organizational goals, that of reducing the cost of government. The city even touts its use of OSS to save taxpayer dollars, highlighting the ali gnment between the adoption of OSS and the organizational goal of reducing cost. While wealth was the only model factor to operate outside of technology adoption theory, slack resources was the only model factor that was not observed. Although the IT department did have a test system in place, extra computers and software that mimicked Roswells live system, personnel did not report slack time to search for new technologies. Rather th ese activities appeared to be incl uded in their weekly schedule and not considered slack time.
78 One possible explanation for the lack of sl ack time is that IT department members did not want to appear to have slack time to the researchers. This perception, that of IT department members having slack time, could negatively affect IT department members either through reprimands by their organi zational leaders or by the assignment of additional duties. However, the activities pe rformed by the IT depa rtment do not appear to back this perspective as the IT departme nt appeared to try and continually improve their operations. Table 11 high lights how Roswells Organizat ional factors influenced OSS adoption and adoption stages.
79 Table 11. Roswells Organizational Model Factors Factor Theorized Effect on OSS Adoption Finding Influence on OSS Adoption Adoption Stages Influenced Internal Communication Facilitate adoption by building consensus around potential new technologies Roswell had high levels of internal communication that appeared to build consensus around new technologies. As a senior programmer said High (Adoption) Awareness, Interest, Adoption, Routinization and Infusion Environmental Scanning Facilitate adoption as scanning should increase awareness of OSS Roswell had high levels of environmental scanning. These activities appeared to be part of routine work processes as opposed to slack activities. In the words of the CIO: High (Adoption) Awareness, Interest, and Adoption Administrative Intensity Hinder adoption as decision making is consolidated into a few individuals Administrative intensity appeared to fluctuate based upon the stage in the adoption process. There were high levels of administrative intensity at the requirements gathering and testing phases, but low levels of administrative intensity in idea generation and physical design. Moderate (Adoption) Adoption Technical Knowledge Facilitate adoption as increased knowledge is associated with flexibility and greater capabilities Roswells adoption of OSS appeared to rely heavily on technical knowledge. Their understanding of open source communities, open source standards and open source software seemed to form the basis of their open source adoption. High (Adoption) Awareness, Interest, Adoption, Routinization and Infusion Wealth Facilitates adoption Facilitated adoption as the department sought out technologies that reduced costs associated with IT. High (Adoption) Awareness, Interest, Adoption, and Routinization Slack Resources Facilitate adoption as employees can search for and experiment with new technologies Roswell seemed to have low levels of slack resources. This did not appear to affect search and testing activities as they appeared to be part of routine work activities. Low (Adoption) Awareness Innovation Factors Innovation factors appeared to be extr emely important in determining the adoption of OSS by Roswell. Thes e factors appeared to be e ssential in the determination
80 of Roswells awareness and interest of an OSS. Relative advantage or the degree to which OSS was perceived to have contextual superiority to an equivalent technology, appeared to be limited to three areas: s ecurity, licensing and maintenance which ultimately appeared to affect Roswells IT costs. Compatibility appeared to be more important, as the thin-client architecture, or the technical standard that Roswell chose to implement, appeared to drive many technology adoption decisions, whether or not a technology could be implemented into this architecture, whether the technology was proprietary or open source, appeared to be a key driver for its adoption. In addition to technical compatibility it a ppeared that the compatibility of OSS to align with what Roswell city users expected to use IT impacted the latter stages of adoption around the city, the routinization an d infusion stages. As IT personnel said, Roswells use of OSS appeared to have earne d the disdain of Roswell city employees as other department employees referred to the softwa re as third world or they tried to get proprietary equivalent applications, such as Microsoft Excel, installed. However, the adoption by the municipality as a whole was outside of this studys scope, but would be an avenue of future research. Complexity also appeared to influence Roswells IT departments adoption of OSS. However rather than hi nder the adoption of OSS by the IT department, high levels of complexity appeared to facilitate th e adoption of OSS as the CIO filtered out technologies deemed to complex or difficu lt to use by Roswells average user. This
81 provided Roswells IT department with ge neral guidelines for what OSS could be adopted by the municipality. Within the IT department complexity appeared to be mitigated by high levels of technical knowledge. No IT department ar ea claimed that OSS technologies were too complex or radical, and as summed up by IT Support Specialist II C, Really operating systems are operating a syst em. It doesnt matt er what it lies on, its how does the applicati on work. Thats all it is. A lot of peopl e just dont want to take the time to learn the differences. Indicating that Roswells IT personnel have learned the differences and reduced the complexity associated with OSS technology. Table 12. Roswells Innovation Factors Factor Effect on OSS Adoption Finding Influence on OSS Adoption Adoption Stages Influenced Relative Advantage Facilitate adoption through superior performance Perceived relative advantages in security, licensing, maintenance, and resource consumption facilitated adoption. High Awareness, Interest, Adoption, Routinization and Infusion Compatibility Facilitate adoption by working with other technologies Integration with othe r OSS applications facilitated adoption. High level activities were similar with propr ietary equivalents, but actual commands and execution were substantially different. High Awareness, Interest, and Adoption Complexity Hinder adoption by erecting barriers to adoption Complexity appeared to facilitate adoption as it created a knowledge barrier or filter surrounding what technologies they would implement. Moderate Interest, Adoption, Routinization and Infusion Interpretation of Roswells OSS Adoption OSS adoption by Roswells IT department appears to be a conscious, strategic decision taken by the leadership of the departme nt. It appears to have been done to align the IT department with the city mission, that of provide(ing) supe rior services that
82 enhance the quality of life and community pr ide. By utilizing OSS Roswell appears to reduce IT costs associated with standardiz ed IT department functions. This does not mean that Roswell adopts OSS technologies at every opportunity ; rather it seems that the IT department weighs application functiona lity with associated costs to determine technology sourcing. The selecti on of a proprietary police ap plication, which necessitated the adoption of other propriet ary technologies, illustrates how Roswells IT department searches for optimal functionality in the programs that they choose. Roswells IT department appears to subs titute OSS applications for proprietary ones when the functionality of the OSS applications is comparable or better to the functionality of proprietary programs. As stated earlier in the case, 40%-60% of the citys software has transitioned to OSS applications. This helps to reduce IT costs, not only through the licensing of the technology, but also through the maintenance and operation of the technologies. The OSS technologies sele cted integrate into th e thin-client, thick server architecture used by th e city, allowing the city to avoid using personal computers (PCs), enabling the use of dummy terminals. Dummy terminals cost significantly less than their PC counterparts. Therefore Roswe lls use of OSS does not appear to be linked solely to the benefits of OSS applications th emselves, but also to the thin-client, thickserver architecture which app ears to compound the cost reduc tion of OSS by allowing for changes in hardware.
83 Interpretation of OSS Disruption wi thin Roswells IT Department Roswells integration of OSS into depa rtmental processes did not appear to disrupt the IT department. This integrat ion seems to center around the thin client architecture and technical know ledge of the department. Roswells thin client architecture appears to allow the IT department to align their external forces, such as tec hnical communities and vendors, with internal drivers, such as goals of cost reduction and levels of functionality, by limiting technology switching costs. Because the thin client technology allows the IT department to incorporate both an OSS framework and proprietary technologies, I.E. the proprietary police department system running side-by-side open source applic ations, the department does not appear to be committed to specific technology standards. This allows the department to find best fit technologies that allows IT department personnel to pursue multiple goals, such as ideal functionality and cost reduction, at the same time. The department appears able to do this because of the superior techni cal knowledge of the IT department. This superior technical knowledge seems to flow through the organization, from the top to the bottom, as the Director of the IT department would rather cancel physical projects than cut training. At the bottom of the organization IT department personnel appear to take genuine in terest in the functionality of their technologies, making proactive modifications, even when they are no t called for. This attitude of improving the IT function through the best fit technology appears to encourage the adoption of new innovations which seems to create a virt uous cycle that makes adopting the next technology easier.
84 Disruptions caused by OSS appear to be focused around individuals who are new to the environment, who are accustomed to a single technical standard, or who do not have the associated technical knowledge or who are not accustomed to switching and learning new standards. These disruptions appe ar to last between six and twelve months, as individuals familiarize themselves with the technology. Summary of the Roswell Case Roswells adoption of OSS appears to be influenced by many model factors, especially environmental and organizational factors associated with searching for and learning about new technologies However the model factors appeared to be heavily influenced by city themes of thin-client architecture and employee development. Roswells commitment to these two factors appears to be driven by two further factors: a pair of visionaries in the IT de partment and an employed city manager rather than an elected mayor. Roswells IT visiona ries, Systems Administrator A and Systems Administrator B have been w ith the city for over twenty years. Apparent ly these two individuals played a major ro le in adopting the citys thin client architecture that eventually migrated to open source technol ogies. According to other members of the department: I think a lot of that you know probably has to do with (Systems Administrator A) and (Systems Administrator B). I would gi ve them credit for how our network is set up. IT Support Specialist II B
85 Its like they (Systems Administrator A and Systems Administrator B) think for themselves and try to think rationally about the whole situation. They try to think about the future and they you know try to be objective...they dont take any salesmans complete story...Theyre re al gurus. IT Support Specialist II B I will say that I was not the instigator of that, it was actually being looked at and they had some open source stuff in pl ace when I started here. CIO Additionally the city has a city mana ger, an employee who implements the elected representatives initia tives. Although the city mana ger position has turned over several times in the last twenty years, ea ch manager has valued the cost efficient operation of IT through the use of the thin -client architecture. Their support for IT operations has resisted several initiatives to migrate from the thin client architecture to personal computer technologies. These factors seem to be at the root of Roswells OSS adoption and appear to leave a footprint in model factors associated with searching for and acquiring new technical knowledge. But without strong orga nizational factors, internal communication, environmental sensing and technical knowledge it is doubtful that the city would have implemented so much of their techno logy through open source applications.
86 Columbus The Need to Succeed Overview of Columbuss Case Study Columbuss adoption of OSS was greatly a ffected by the departments need for IT project success. Because the de partment was trying to consolidate IT resources within the city it was trying to maximize political goodwill through IT project successes. Consequently it was paramount for the IT depa rtment to appear successful in new IT projects. This influenced IT department ar eas and operations, incl uding their adoption of OSS. Administrative intensity, or the consolidation of decisi on making, was correlated to the success rates of the various IT department areas. Those areas with successful track records were given more freedom to search for and implement new technologies so long as these technologies furthered the success of the department. This was especially apparent with OSS adoption as these technol ogies were often implemented to optimize proprietary technologies. The need for IT department success enc ouraged the department to utilize vendors who could increase the likelihood of IT success. This approach to IT operations increased the use of vendors for primary IT department functions, increasing the likelihood that the department would adopt proprietary technol ogies. However successful IT department areas were free to search for and implemen t technologies so long as these technologies furthered IT area success. In these areas, OSS was adopted that optimized existing proprietary technologies. Figure 6 highlights the relationships between model factors and the need for IT department success in Columbus. The remainder of the case highlights
87 how the need to succeed influenced e nvironmental, organizational and innovation factors leading to OSS a doption within Columbus. Figure 6. Columbuss OSS Adoption Description of Columbus With a population just under 250,000 citizens, Columbus is the second largest municipality to participate in this study. It is often described as built out community; the city itself has spread out and developed all of the area between other municipalities, leaving no more room to grow. The citizens of Columbus work in a variety of industries including tourism, financia l services, manufacturing, medi cal technology, information technology and marine sciences. As an organization, the city has more th an thirty municipal departments that employ more than 3,000 people. These depart ments are funded by a city budget that was in 2007, over 550 million dollars. In 2007 the ma jority of this revenue, 43%, was Vendor Relations Environmental Scanning Technical Knowledge OSS Adoption Stage/Level Administrative Intensity IT Success Philosophy + / + / + / + / + / + / + / + /
88 collected from ad-valorem taxes. See appendi x item E for a comparison of the size of the different municipalities. The mission of the municipal government is to provide efficient and effective public services that protect and enhance sustainability of our environment and the quality of life within Columbus. Following this guideline, Columbus has received numerous awards for sustainability a nd green initiatives. Nationa l awards and recognition have also been earned by public safety and u tility departments for improved operations. An elected mayor leads Columbus. The cu rrent mayor, who is serving his second and final term, has been nationally recognized as an outstanding leader. The mayor acts as CEO, Chief Executive Officer, for the municipality. Assisting the mayor in governance activities is an elec ted city council. These citizen s who comprise the elected commission set goals for the city manager a nd indirectly guide municipal activities. Description of Columbuss IT Department Columbuss IT department is well esta blished within the city, having been a formal city department for over ten years. De spite this tenure, the IT department is not the only IT resource in the city; at least tw o other municipal departments have their own IT areas. These IT areas work with the centr al IT department to implement, support and maintain the information technologies used by the city. Perhaps the city has not consolidated all IT resources into a single IT department because of city politics: the central IT department is two bureaucratic laye rs away from the elected officials of the city, one level further than the other departments with IT areas. However it does appear
89 that the city is consolidating IT resour ces and will eventually have a single IT department. Despite two other municipal IT resources, Columbuss IT department has a budget over ten million dollars and more than sixty employees. The size of the budget and number of personnel ranks Columbuss IT de partment as the fourth largest or second smallest municipal IT department to particip ate in this study. See appendix item E for a description of all pa rticipating municipal IT departments. The main duties of the central IT depart ment at Columbus focus on integrating and supporting a wide variety of information technologies that the city uses. These technologies include geographic information sy stems (GIS), enterpri se resource planning (ERP) systems, legacy applications and othe r information technologies used by the city. With the implementation of the ERP system a cross-functional IT the role of the IT department appears to be changing. As the ERP system crosses multiple city departments the IT department has been given ownership of this application. Consequently the IT department has been making more decisions regarding the ERP including work-flow, business process rede sign and technology adoption. To date these decisions have been made with input from ot her municipal departments, as the city has ERP analysts that work as boundary spanners to ensure that both departments are working together. But the increased responsibi lities of coordinating city IT appears to also increase the influence of the IT department itself.
90 Columbus Participants The main source of data for this study was gathered th rough seventeen interviews of IT department members. These members came from each area in the IT department, and from varying organizational levels, bot h administrative and operations. Personnel within the city had varying tenures with th e city, with most area administrators having more than ten years of city experience. M eanwhile operations employees greatly varied in their experience, from new hires to twenty year veterans. Interv iews were conducted during the fall of 2007. Department member roles and duties are generalized to those used by this study as ma ny of their job titles appeared to be unique to the city. Table 13 highlights the role and responsibilitie s of the individuals interviewed.
91 Table 13. Columbus IT Department Mem ber Role and Responsibilities Interviewee Responsibilities Administrator of Network Operations Responsible for the citys network, pers onal computers running on the network and the enterprise applications running on the PCs. Administrator of Telecommunications Responsible for the citys telecommuni cations network, personnel and all telephone equipment (hardwired and cellular) used by the city. Development, Programmer A Responsib le for maintaining payroll appli cations and computer processes. Additionally responsible for all progra mmers involved with the citys ERP. Development, Programmer B Responsib le for mid-range servers and the applications that run on these servers. Development, Programmer C Responsib le for maintaining contextual specific applications and the individuals who use, and main tain these applications. Administrator of Development Programmers (ERP) Responsible for the citys enterprise resource planning system. Manages developers and analysts who implement and maintain the system. Operations, Security Responsible for implementi ng security on the citys network and servers. Administrator of IT for External Department Ultimately responsible for managing over twenty employees who maintain and implement the applications used by the Police Department in the city of Columbus. Administrator of GIS Development Responsible for managing GIS employees as well as providing GIS services to other customer departments. Administrator of Communication Operations Responsible for the radio and televisi on technology used by the city. Developer, Systems Analyst A Responsible for ensuri ng that business needs of the Human Resources (HR) department are being impl emented in information technologies, primarily the citys ERP, used by the HR department. Administrator of Application Operations Responsible for computer applications, excluding the ERP and desktop applications, run by the city. Developer, Systems Analyst B Responsible for ensuring that business needs of the accounting department are being implemented in inform ation technologies, primarily the citys ERP, used by the accounting department. Administrator of Server Operations Ultimately responsible for the server and database functions of the city. Manages city employ ees who maintain and implem ent server and database technologies for the city of Columbus Operations, Network Responsible for maintain ing and monitoring the citys networks Administrator of Security Operations Responsible for city information techno logy security, including establishing security policies, implementing physica l security and monitoring network activity Operations, Server UNIX Administrator Open Source Adoption at Columbus Four areas within Columbuss IT depa rtment have adopted OSS applications. Because these applications were commonly used to accomplish work tasks the adoption of OSS can be characterized as being at the routinization stage. Additionally departmental members did not participat e in the development of these OSS, characterizing the adoption level as as-is. Finally the OSS di d not appear to create any disruptions within the IT department as im plementation, maintenance and work processes
92 were not altered by the technology. Because the technology did not appear to disrupt department factors the adoption of OSS by Colu mbus IT department can be classified as routine, not disruptive. Table 14 summarizes the departmental area s adopting OSS. The remainder of this section discusses ea ch areas adoption in greater detail. Table 14. Columbuss Adoption of OSS Departmental Area Applications Adopted Influential Model Factors Adoption Stage Adoption Level Impact on IT Function Security Linux, Apache, Netsys, Snort, PERL, MySQL Administrative Intensity, technical knowledge, environmental scanning, compatibility, relative advantage Routinization As-is Routine Server Bash, Nagios, PERL Technical knowledge, relative advantage, compatibility Routinization As-is Routine Network Bash, C-FTP, Nagios Administrative Intensity, technical knowledge, environmental scanning, compatibility, relative advantage Routinization As-is Routine End User Applications Open Office, Firefox Peer adoption, relative advantage, compatibility Routinization As-is Routine* *Parallel to proprietary applications Security Columbuss IT Security area has adopted OSS for many of the areas functions. Not only does the area use OSS for contextual applications, i.e. security activities like port scanning or threat assessment, it also uses OSS to store and organize area applications and data. Members of the secur ity area routinely used these technologies, but did not participate in their de velopment, classifying the adop tion as as-is. Additionally the implementation of these technologies did not cause disruptions to security activities, classifying the adoption as routine. Finally these OSS technologies were limited in scope, as only the security personnel needed to interact with the OSS adopted.
93 Server The server area in Columbus adopted O SS utilities to help monitor and optimize servers. Server personnel appear to have adopted these OSS utilities to supplement vendor technologies. Like the s ecurity area in Columbuss IT department, the adopting members of the server area did not participate in the development of these utility programs. Consequently the adopt ion stage is routine while th e adoption level is as-is. Additionally because the adoption of these ap plications did not cause disruptions to server area activities the adoption itself can be consid ered routine. Finally the OSS adopted by server personnel was only used by members of the area. This appeared to limit the scope of OSS to within the server area. Networking Similar to the server area in Columbuss IT department, the networking area has routinely adopted many OSS utilities to m onitor and optimize the citys network. Because the networking area did not participat e in the development or testing of these technologies the adoption stage is consider ed routine while the adoption level is considered as-is. Additionally the use of OSS applications did not appear to alter departmental processes or tec hnologies as the OSS adopted were specifically designed to work with the vendor standards that Colum buss networking area used. Consequently the OSS did not appear to disrupt area operations Finally the OSS tec hnologies used by the networking area were limited to networking pe rsonnel, reducing the number of Columbus employees who used the technology and decr easing the scope, or impact of the OSS applications.
94 End User Support The fourth area adopting O SS within Columbuss IT department is the end user support area. Two open source applications have been deployed alongside existing proprietary equivalents, Open Office and FireFox. This adoption of OSS is different from the other areas as these OSS applications ar e widely deployed throughout the city. But these OSS applications were deployed parallel to proprietary software that performed similar functions. However, because these ap plications were routinely used by some members of the city while ignored by others it is difficult to specifically classify these technologies as either being routinely used or not used at all. Additionally classifying the disruptive effects of these applications is al so difficult because of end user use. Do the end users use these technol ogies or do they ignore them in favor of a pplications that they are more accustomed to? Clearly the adoption le vel, as-is, is much easier to identify than the adoption stage as the end user area did not participate in the development of these technologies. However for the purposes of this study the adoption stage will be classified as adoption, as it is unclear if a majority of Columbus employees used the applications. Additionally because the OSS did not cause any disruptions to work processes or IT support, the classification of the adoption can be rout ine, not disruptive. Open Source Adoption Themes at Columbus Columbuss adoption of OSS appears to be affected by one major departmental theme, the need for IT department success. IT success, or the successful implementation and maintenance of new and existing IT wi thout disruption of work processes or departmental knowledge, appears to be critical because Columbuss IT department is not
95 the only IT resource in the city. At least two other municipal departments had their own IT areas. IT department success was stressed by all area managers because it is critical to further consolidate IT res ources within the city. The IT department, as well as other IT ar eas within Columbus, recognizes that IT consolidation into one department will eventually happen. The administrator of an external IT department succinctly capt ured this sentiment when he said: You know we probably really need to begin, we probably ar e going to have to take a look at that holistica lly (city IT) and say Ok, how many people do we really have doing that type of work in this organizatio n? You know if we all of a sudden have to begin to constrict finan cially, you know can we really begin to reduce some of those positions and let central IT provide desktop su pport? Administrator of IT for External Department IT department consolidation has been pursu ed in two different ways. First, in the past the IT department took over struggling IT projects or other IT areas within the municipality. For example the Administrator of Application Operations, who has been with the city for more than twenty years, indi cated that in the past the IT department did not hesitate to takeover struggling IT areas even if it or resulted in ill will among the departments. We had a hostile takeover, we took GIS and moved down here and they (the other department) werent happyThey (other municipal departments) call us the evil empire. Because for a long time it was whatever we say, thats the way its going to be. But its not like that anymor e. You know we have to work with the
96 departments and say What would you like? Administrator of Application Operations This strategy of hostile takeovers or absorbing failing areas into the central IT department does not seem to have consolidated all IT resources within the city. Rather larger departments appear to have resources or skilled personnel that ensure successful operation of IT within these areas. Consequently the IT department seems to have changed their approach to consolidation. The second strategy towards consolidating IT resources focuses on providing IT services as opposed to taking over projects. This was reflected in the current attitudes of several area leaders: I look at my team as a service. Administrator of Development Programmers (ERP) (The CIO) is very aware that (the IT department) doesnt want to be viewed as pushing on the user (The CIO) is very pe ople aware and politically in the city its hard for us as an IT department bec ause we are the support, then to tell everybody what they are going to do is badWe want to be invisible, but at the same time help everybody achieve their job and do it as efficiently as possible. Administrator of Network Operations My philosophy always has been: my cu stomers are the other departments and users within the city. So my approach has always been that I want to keep my
97 users happy, and if I keep my users happy then my boss is happy. Development, Programmer C This change in tactics to consolidate municipal IT resources appears to have altered the IT departments priorities. Rather than focusing on efficient or effective technical aspects of IT proj ects, the IT department now seems more concerned about meeting end user needs and not interferi ng with existing business processes. Meeting external department needs has re sulted in changes to the central IT department policies when making technology adoption decisions. Ot her departments are more involved in technology a doption decisions, often sugg esting the use of specific vendor technologies. This theme, IT success, appears to affect OSS adoption and the model factors. It appears to result in higher leve ls of administrative intensit y, which appears to be a proxy or a substitute for organizational power or c ontrol. The next secti on describes how this theme of IT success influences each of the model factors. Columbuss Model Factors Columbuss model factors appear to be heavily influenced by the departments need for IT project success, or successfu lly completing IT proj ects without causing changes to existing processes or organizational skills. The interviews reveal that all three groups of model factors, environmental, or ganizational and innovation were present at Columbus and influenced the adoption of OSS. Coding of the interviews identified 812 instances of model factors. The codes can be seen in Figure 7 and Figure 8. Of these identified factors more than half, 422, were
98 related to internal communication and administ rative intensity. These instances were not all positive, as there appeared to be se veral communication barriers and administrative processes that impacted IT operations. Howe ver the sheer number of identified codes within these areas highlights how IT depart ment members focused on the success of IT projects. Additionally every other construc t was identified in coding the interviews, however, as the figures show, not every participant identified every construct. Figure 7. Columbus Codes
99 Figure 8. More Columbus Codes The following sections expand each model factor and discuss how Columbus IT departments philosophy, that of successfully supporting the citys business departments, influences the construct. Environmental Factors Because Columbuss IT department is focused on successfully implementing IT projects, the department trie s to repeat what was successf ul in the past, implementing vendor technologies. The administrator of anothe r municipalitys IT department appeared to capture this sentiment when he said: One of our key issues there is that we are not going to modify software, we are going to modify business processes. And so most of the project teamwork isnt involved with rewriting software or re doing code, it is with changing peoples minds about how they go about doing their job and saying Ok, you know instead of you wanting me to change the softwa re, Im not going to do that. Were going
100 to change the way we do business.. Administrator of IT for External Department. Consequently Columbuss IT department has a history of successfully implemented vendor technologies into their work processes. For example a large ERP (Enterprise Resource Planning) implementation was successfully completed in just over a year. Now many municipal departments rely on this software to accomplish their functions. The administrator of application operations described th e relationship between the IT department and their vendors, saying: We work with corporate America; I deal with all of my companies. I have, I communicate with the CIOs of all of themThis is years of building relationships, going through some heartach e, talking to them (vendors) getting mad with them (vendors)Weve done that (w orked with our vendors) a lot, but it has built respect with them (our vendo rs) and we have relationships with them that a lot of their cust omers dont have. Admini strator of Application Operations However this attitude of working with vendors as partners was not consistent among the IT areas. For example the Administra tor of Network Operations did not have such close relationships with Columbuss networking vendors. Right now were in tight with (Vendor X). Weve bought lots of software from them. We probably buy a lot of software b ecause its convenient and the contracts are in placeWe dont hesitate to sa y Hey vendor, lets set something up and
101 look at your product. Before we even think about buying it. Administrator of Network Operations Other members of the department indi cated that the re liance upon vendor technologies created switching costs, preven ting the city from moving away from their vendors. We cannot get rid of (Vendor X) because (Vendor X) is synchronized with their time clocks in the police de partment and all the other de partments where in they have time clocks. And the (Vendor Y) tim e function doesnt work with the time clocks so we have to have (Vendor X), and (Vendor X) doesnt interface with the (Vendor Y) products and soit is a complicated thing. Development Programmer A Well there would be a lot of switching costs involved for us. That way youre changing what youre currently doing, youve got to look at the switching cost. For us to go to (open source applicat ion A) would be a huge switching cost. Number one we own all these (Vendor X) li censes, all of our st aff are trained to support (Vendor Y) environments. So they ve have to be completely retrained. The cost would be huge. Lead Security Officer Reliance upon vendors and thei r technologies appeared to focus environmental factors, such as external communication and technical communities, on existing vendors and their technologies.
102 I wouldnt say that Ive gone to the blogs or whatever. I spend a lot of time on (Vendor Xs) site. Development Programmer B Keeping up with (Vendor X) is 50% of our work, and keeping up with the user is the other 50%. Apply all the patches, test all the patches, things like that. Development Programmer A (Vendor X) is the only technology t hat I use. Development Programmer A By focusing external communication and technical communities on vendor technologies, Columbus IT department personne l appeared to be bi ased towards vendor technologies. Many IT department members view ed alternative appli cations, like OSS, as buggy. For example the Administrator of GIS development said the following: We dont want to implement something thats going to be buggy or troublesome to get support on, you know open-source is a little dangerous in that way. You have to depend on a user community to help you and sometimes they dont respond so you know versus purchased support that you can get with the purchased version of their software. Administrator of GIS Development However this bias seemed to be linked to specific IT areas. For example the networking area, seemed much more open to alternative technologies like OSS. If we can find an open source that is as/or as close to the effectiveness then yea, we are definitely open to that I mean I have to say fr om my own experience Ive
103 found it (OSS) pretty good. You know you call up and you get some help, and you can fudge through it and get through it. Administrator of Network Operations Unlike vendor relations and technical communities, which focused on vendors, peer adoption was an environmental factor that ha d identified alternative technologies for the department to adopt. Because Colu mbus was aware of the success of another municipalitys adoption and subsequent cost reduction, they implemented OSS applications with the idea of trying to emulate these savings. However Columbus implemented these OSS, Open Office and Fi refox, parallel to existing proprietary technologies. It appears that the city will ev entually switch over exclusively to Open Office in the future and is using the parallel deployment to build user familiarity with the technology. Organizational Factors Organizational factors were also focused on IT project success. Administrative intensity was especially important because it heavily influenced organizational processes. Area leaders were qui ck to state that their opinions or recommendations, while considered by the department CIO, were s econdary to the CIOs. This reflected how administrative intensity affected the decision making processes within the IT department. For example: I can make recommendations, but the depar tment administrator makes all of the decisions. Administrator of Communication Operations
104 (Our) CIO understands technology. Now he may not be an engineer, but he knows enough of ithe understands the busin ess process as we llits easy to push new initiatives or initiatives that can bring value to the city. If we convince him it has value, that means maybe reduce cost, or an equal cost that gets better performance on something, then thats a big hurdle for usHe scrutinizes everything, like Why this? This? This? We ha ve to justify and part of my job is to explain the technology on why I want, desire or need that. Administrator of Network Operations Administrative intensity also appeared to impact work processes within the IT department. However not all IT department ar eas had the same levels of administrative intensity. Because the IT department pursued IT project success over other departmental goals, administrative intensity appeared to be moderated by IT area project success rates. IT department areas with a history of IT project success had lower levels of administrative intensity than IT areas that were less proven. This seems to account for the varying levels of admini strative intensity throug hout the IT department. For example the networking and security areas appeared to display lower overall levels of administrative intens ity than the other IT areas as the security and networking areas had a history of successfully implemen ting new projects. For example the network area had completed an overhaul of the city s networking equipment, replacing 100% of the networking equipment, without causi ng a minute of the networks downtime. As administrative intensity varied within the department, areas with high levels of administrative intensity focused on their work tasks. This had the effect of reducing
105 environmental scanning as high levels of administrative intensity compartmentalized IT department areas, to increase IT department su ccess rates. But this concentration on work tasks created stress between areas in the IT department affecting internal communication This impact on internal communicati on was reflected in the interviews: Theres also little kingdoms within th e IT department. Okay and sometimes people, because they are in a specific m odality such as networking or such as (Vendor X) or Email systems, they don t want to have anything to do with the other parts...they want to focus on what they do and not really willing to learn things around themselves. Systems Programmer I In some instances IT area compartmenta lization has resulted in conflicts between IT department areas as many area technologi es overlap common software and hardware. These conflicts appeared to be especia lly prominent between areas of varying administrative intensity. For example the security officer, an area with low levels of administrative intensity, has had problems with areas with high levels of administrative intensity modifying software firewa lls without her consent or knowledge. Oh my god! In the server area there is such a cowboy culture. We used to have a software firewall. Now we have a hardware firewall. Thats my change control. Lead Security Officer Additionally the database administrators, DB As, and enterprise resource planning, ERP, developers, two areas within the department w ith high levels of administrative intensity, seemed to have miscommunicati ons and differing priorities.
106 I think sometimes the DBAs dont underst and the prioritization when there is a production issue. Its something we really need to be dealing with because of not talking to the user group. They dont understand how high level a problem it may have become. Developer, Systems Analyst B Low IT project success rates and high leve ls of administrative intensity reinforced IT area compartmentalization as members focused on their own function. This was especially apparent in IT department areas that used multiple standards. I will say that theres a culture differ ence between the (Vendor X) side of the house and the (Vendor Y) side of the house I have so little to do with the (Vendor X) side of the house its pathe tic. Development Programmer C Compartmentalization and the ability to focus on specific tasks allow some personnel to largely ignore other IT areas within the department. I can only really speak of the GIS work I do. Administrator of GIS Development However areas with high IT project succe ss rates and low administrative intensity appeared to interact with one another regul arly. For example the networking and security areas, areas of high IT projec t success and low administrative intensity, routinely talked with one another, discussing technology options. We do our research and find out whats the best solu tion and things like that. Then we all group up and try brainstormi ng. We work really well together. Security Operator
107 If a problem comes in we toss it out onto the table and we look at whose skills will best fit it and we generally have somebody who can take it on. Development Programmer C Meanwhile other departmental areas, like the ERP (Enterprise Resource Planning) area and the server area, areas with lo wer success rates and higher levels of administrative intensity, had lower levels of communication that appeared to extend into area rivalries. I think sometimes the DBAs dont understand the prioritization when there is a production issue. Its something we really need to be dealing with because of not talking to the user group. They dont understand how high level a problem it may have become. Developer, Systems Analyst B Weve tried to set up some formal times for our teams to spend time together, to learn with each other. Our teams are wo rking really well together now but there was a time when that wasnt true. Ther e was a lot of They dont know what theyre doing Going back and forth. So we thought Ok, you know what, lets have them sit down so they can see how d ifferent their jobs are and kind of gain respect for each others responsibilities. So we did that, but I also try to encourage my team to go out in the business department and learn about what businesses our customers are conducting. Administrator of Server Operations
108 Oh theyve tried things such as they wanted some cross training done between the business analysts and our DBAs, and they wanted these individuals to sit with us for eight hours a day and learn what we do. That ticked most of us off. Development Programmer B Another factor that appeared to be a ffected by administrative intensity was technical knowledge as the hiring process of the IT department sought out extremely skilled individuals. This appeared to be done to increase the likelihood of IT department success. For example, the latest hire in the server area had outstanding credentials, including multiple degrees from an Ivey Lea gue University, and experience with a large fortune 500 organization. Accord ing to the server area administrator the department waited more than six months to fill this position and passed over several qualified applicants. Meanwhile slack resources a construct long associated with technology searching, did not appear to be present. Rather the high leve ls of administrative intensity focused personnel on their immediate work tasks as opposed to looking for new technologies. Additionally slack resources were in short supply as the department was short three members, as three positions we re unfilled, and these responsibilities were doled out among the remaining IT members in addition to their regular duties. Finally Columbuss wealth or the departments budget was being reduced, as all areas were asked to look for areas to trim their budgets. Within this cost cutting environment the department sought out alternat ive technologies that could reduce costs, like OSS, not increase them. Perhaps the lowe r-end, disruptive nature of OSS appeals to
109 organizations with lower wealth that cannot purchase or maintain proprietary applications. Innovation Factors IT personnel appeared to be interest ed in OSS because of a perceived relative advantage the cost of OSS, and how OSS applica tions fit with existing technologies, or the compatibility of the innovation. Personnel were also aware of the complexity of OSS, as this was a major point of rejecting OSS. Columbuss IT department personnel consistently perceived OSS to have one common relative advantage its cost. Because OSS was per ceived to reduce costs it was considered an option only when effectiveness, or IT project success, would not suffer. If we can find an open source that is as/or as close to the effectiveness then yea, we are definitely open to that. Ad ministrator of Network Operations While several individuals in the department were comfortable learning new technologies or using OSS, many personnel perceived OSS to be incompatible with existing technologies or very complex I have people who have experience with other operating systems and my team is very open to learning new things. They would do anything for a new toy. Administrator of Server Operations It would be radical to shift over to (O pen Source Application X). That migration would, just, there would be so much compl exity in a migration like that. It would be a huge undertaking. It would be so mething that we could not accomplish
110 without downtime which means we could not do without our customers noticing something happening and just the amount of planning. Administrator of Server Operations A lot of the things that are open-s ource or that are free, you know its complicated to set up a learning curve t hats really big. Learning how to use it and if theres an issue I mean whos going to support that? Security Operator IT department members thought that OSS versions of existing proprietary technology would be perceived as extremely complex by non-IT department members. Take Microsoft Office. Just moving away fr om that in itself would be a big deal for all the users (outside the IT departm ent) because now they have to relearn where everything is, how to highlight this. I know like in Excel cut and paste is different, things like that. Little things here and there theyll have to relearn and the tendency for someone to, you know if you already have so mething that you know why relearn something? Security Operator A good example is Microsoft Office. Just moving away from that in itself would be a big deal for all the users because now they have to relearn where everything is, how to highlight this. I know like in E xcel cut and paste is different, things like that. Little things here and there theyll have to rele arn and the tendency for someone to, you know if you already ha ve something that you know why relearn something?...I personally run Linux at hom e and have Open Office. Its just not
111 like I said the users here, at least with the city of St. Pete, its like we always want the users, to get them what they want. Dont force them to change or anything like that. Even though the cost benefit is huge. Its like pushing our own agenda. Security Operator OSS Disruption within Columbuss IT Department OSS adoption by Decaturs IT departme nt did not disrupt IT department operations. It did not change processes or core IT skill s beyond the learning of new syntax, as the adoption was limited to select projects and contextual applications. While OSS adopted in this manner reduced the sc ope of OSS within th e organization, the adoption by project teams for their IT projects allowed the technologies to reduce IT costs without sacrificing func tionality or changing organi zational processes throughout the department. Interpretation of Columbuss Model Factors Model factors concerning OSS adoption were heavily influenced by the ongoing theme of IT project success at Columbus. IT project success appeared to be the highest priority so that the IT department could build credibility within th e city to consolidate municipal IT resources within the city. C onsequently, IT project success appeared to influence all the factors in the study model. Administrative intensit y appeared to proxy for IT project success as it appeared to moderate other model factors. Environmental Factors Columbuss environmental factors appeared to play a large ro le in both adoption and rejection of OSS in Colu mbus. These factors seemed to be influenced by the IT
112 departments administrative intensity as departmental member activities and organization was highly regulated. This limited how environmental factors were utilized, primarily to increase IT project success. For example, due to departmental suc cess with implementing vendor solutions, external communication vendor relations and technical communities appeared to focus on vendor technologies. This appear ed to create network effects surrounding existing IT vendors that served to hinder OSS adoption. By hindering the adoption of new technologies, external communication, ve ndor relations and technical communities appear to go against commonly accepted theory. In terms of the model, the network effects caused by focus on vendor technologi es had the outcome of decreasing the awareness and interest in OSS. Of these three environmental factors that seemed to hinder OSS adoption, t echnical communities also appeared to facilitate OS S adoption. Individual departmental members who had low levels of administra tive intensity, appeared to use technical communities to adopt OSS. These individuals appeared more likely to search for alternative technologies, and th eir searches led them to technical communities that facilitated the adoption of OSS. Technical communities not on ly appeared to increase IT department member awareness, and interest in OSS, but also f acilitated adoption and routinization as the communities supplied knowledge and support for the continued use of OSS. Peer adoption was the only environmental factor at Columbus that consistently facilitated OSS adoption. This factor was instrumental in the adoption and deployment of
113 two OSS, Open Office and FireFox. Although th ese actions were done in parallel to existing proprietary technologi es, which appears to redu ce the adoption level from routinization to adoption, departmental memb ers appeared certain th at eventually these applications would replace thei r proprietary equivalents. Most likely this would occur to highlight the cost savings of these technologi es, perhaps once the different IT resources within the city were conso lidated. Regardless of motiva tion, peer adoption seemed to affect the awareness, interest and adopti on stages at Columbus. Table 15 highlights Columbuss Environmental Factors. Table 15. Columbuss Environmental Factors Factor Theorized Effect on OSS Adoption Finding Influence on OSS Adoption Adoption Stages Influenced External Communication Facilitate adoption by creating awareness and interest in OSS External communication focused on vendors. This appeared to create network effects or switching costs that hindered the awareness of OSS within the department. High (Rejection) Awareness & Interest Peer Adoption Facilitate adoption by creating awareness and interest in OSS Peer adoption facilitate d adoption by creating an awareness and interest in achieving similar benefits as recognized by Columbus peers. Moderate (Adoption) Awareness, Interest, and Adoption Vendor Relations Hinder adoption through switching costs and other mechanisms Vendor Relations hindered adoption of OSS by creating network effects that tied organizational work process to vendor technologies. This created switching costs to pursue OSS technologies. High (Rejection) Awareness & Interest Technical Community Facilitate adoption by creating awareness and interest in OSS Hindered OSS adoption when technical communities were linked to vendor sites. Facilitated OSS adoption when individual technical knowledge, or environmental scanning were high or when administrative intensity was low. Moderate (Adoption and Rejection) Awareness, Interest, Adoption, & Routinization
114 Organizational Factors Columbuss administrative intensity appeared to have a great deal of influence over OSS adoption within the IT department as it appeared to serve as a proxy for IT department authority or control. This focu sed the department on IT success, dictating organizational structure and area activities. This resulted in administrative intensity directly moderating how organizational constructs of internal communication environmental scanning slack resources, and technical knowledge influenced OSS adoption. IT department areas with successful trac k records, or areas with lower overall administrative intensity, appeared to have increased the internal communication and environmental scanning Increased internal communication and environmental scanning appeared to facilitate OSS a doption as IT department areas were able to search for new technologies, like OSS, and become aware of, interested in and apply OSS within their departmental areas. Unsuccessful track records, or IT areas that had higher levels of administrative intensity, resulted in IT departmental areas with lower levels of internal communication and environmental scanning. This resulted from these IT areas having their duties specifically outlined. Operations personnel we re expected to focus on completing their work tasks while administrators of these areas were expected to manage the IT function. Lowered internal communication and environmental scanning decreased awareness and interest in OSS as departmental members focused on existing technologies and associated work tasks.
115 Additionally administrative intensity of all levels appeared to eliminate slack resources within the IT department. This appears to be supported as the IT department had three positions that were unfilled. Perhaps these duties were unfilled due to the stringent skill and knowledge re quirements that the IT department exacted from new members. But more likely slack resources we re eliminated as a part of overall budget reductions within the city. High levels of technical knowledge appeared to facilitate OSS adoption. For example the highly skilled server operator who was recently hired routinely used OSS applications to optimize proprietary software. I use a lot of the open source tools bec ause there was very little monitoring of the (Vendor X) structure here. It seems like th e admins they had before were either not as much experienced or they just neglected to do certain things that I would consider basic. Systems Programmer I It appears that higher levels of technical knowledge were positively correlated to higher levels of environmental scanning as personnel with hi gh technical knowledge seemed to scan the environment to be aware of technical trends and available functionality. Meanwhile the wealth construct appeared to play a role in facilitating the adoption of OSS. Because Columbuss IT department was experiencing budget reductions, it appeared that opportunities to reduce costs, such as substituting OSS applications for proprietary ones, were gaining momentum with in the department. Perhaps this explains the parallel deploymen t of Open Office beside Microsoft Office. Wealth and the other organiza tional factors are more fully described in Table 16 below.
116 Table 16. Columbus Organizational Model Factors Factor Theorized Effect on OSS Adoption Finding Influence on OSS Adoption Adoption Stages Influenced Internal Communication Facilitate adoption by building consensus around potential new technologies Columbuss internal communication appeared to facilitate O SS adoption within IT areas as they could build consensus and agreement about the value of the technology. Moderate (Adoption) Awareness, Interest, and Adoption Environmental Scanning Facilitate adoption as scanning should increase awareness of OSS Environmental scanning ap peared to facilitate OSS adoption as individual department members could identify OSS that could optimize other technologies. Moderate (Adoption) Awareness, Interest, and Adoption Administrative Intensity Hinder adoption as decision making is consolidated into a few individuals Adoption where administrative intensity was low, IT areas were likely to identify and adopt OSS. Rejection where administrative intensity was high, IT areas focused on work tasks, reducing the likelihood of the area adopting OSS. High (Adoption and Rejection) Awareness, Interest, Adoption and Routinization Technical Knowledge Facilitate adoption as increased knowledge is associated with flexibility and greater capabilities Appeared to be linked with environmental scanning. Higher leve ls of technical knowledge also allowed individuals to identify how OSS could be used within their areas. Moderate (Adoption) Awareness, Interest, Adoption, and Routinization Wealth Facilitates adoption An absence of wealth appeared to facilitate OSS adoption as the organization looked to reduce costs. Moderate (Adoption) Awareness, Interest, Adoption, and Routinization Slack Resources Facilitate adoption as employees can search for and experiment with new technologies Columbuss high levels of administrative intensity appeared to reduce slack resources and technology search activities. Low (Adoption) Awareness Innovation Factors Columbuss IT department areas appeared to adopt OSS applications primarily because of the compatibility of the innovation. Compatibil ity appeared to be more important than the relative advantage of the software as most OSS applications appeared to optimize proprietary technol ogies rather than provide un ique functionality. Even when
117 a substitute was adopted, like Open Offi ce, it was adopted parallel to vendor technologies. By focusing on highly compatible OSS the complexity of OSS appeared to be reduced. Not only were Columbus employees gi ven proprietary alternatives to OSS, but where OSS was solely adopted, it was limited to areas within the IT department. This seemed to further reduce the overall comple xity of OSS as only individuals with technical skills that could use OSS were exposed to the technology. Consequently, while the relative advantage of OSS was important cost savings or op timization functionality appeared to play a major role in OSS adoption, compatibility appeared to be the innovation factor that aligned with the department theme of IT project success. Table 17 highlights Columbuss Innovation factors. Table 17. Columbuss Innovation Factors Factor Effect on OSS Adoption Finding Influence on OSS Adoption Adoption Stages Influenced Relative Advantage Facilitate adoption through superior performance Cost appeared to be the main perceived relative advantage OSS had over proprietary technologies. Moderate (Adoption) Awareness, Interest, Adoption, Routinization and Infusion Compatibility Facilitate adoption by working with other technologies Compatibility with existing technologies and skills seemed to drive OSS adoption more than the relative advantage of the software. High (Adoption) Awareness, Interest, and Adoption Complexity Hinder adoption by erecting barriers to adoption Complexity appeared to limit the scope of adoption to the IT department or to OSS deployments alongside proprietary equivalents. Moderate (Rejection) Interest, Adoption, Routinization and Infusion Interpretation of Columbuss OSS Adoption OSS adoption at Columbus appeared to align with the IT project success at Columbus. In most instances this appeared to be the result of good fortune or serendipity
118 as the IT department focused on proprietary ve ndor technologies to increase IT project success. This drive for IT project success app eared to reflect through the IT departments administrative intensity. Within this setting OSS adoption seemed to be limited to applications that did not adve rsely affect IT area success, meaning that they enhanced proprietary technologies, were limited in sc ope (i.e. primary users were contextual experts within the IT depart ment) or were deployed alongs ide proprietary equivalent technologies. Interpretation of OSS Disruption wi thin Columbuss IT Department OSS did not appear to cause disruptions within Columbuss IT department. Rather the IT departments theme of IT project su ccess appeared to ensure that, where adopted, OSS applications caused as li ttle change in work proce sses or knowledge as possible. This appears to be supported as the primar y OSS applications adopted were contextual programs limited to highly knowledgeable IT areas. In the instances of OSS adoption outside of specific IT areas, OSS was deployed alongside traditional proprietary technologies. Summary of Columbus Case Columbuss adoption of OSS appeared to be driven by the goals of the IT department to consolidate IT resources with in the city. Consequently the departmental theme of increasing IT project success seemed to drive the administrative intensity at the site, which in turn moderated model factor s. Vendor technologies appeared to be preferred to OSS applications to increase the like lihood of IT project success. However, even within a highly regulated environmen t like this OSS was adopted. Contextual
119 applications that complemented proprietary technologies were adopted by multiple IT areas, sometimes as conscious decisions by the IT areas and at other times as individual initiatives. Regardless of how it is adopte d, it appears that OSS adoption will likely increase at Columbus if it can be shown to increase IT departmental goals, that of successfully implementing IT projects.
120 Decatur Cultural Divide Overview of Decaturs Case Study Decaturs adoption of OSS was greatly influenced by a cultural divide resulting from a new organizational structure that origin ated in the department because of reduced resources. Rather than follow a traditional IT department structure which focused on the functional areas of the IT department, Decatur s IT department had both the traditional functional areas and a projects division. Th e projects division was responsible for analyzing, designing, and implementing new in formation systems (IS) within the city while the functional departments were responsible for maintaining the municipalities existing systems. The new organizational structure resulted from the departments budget. Because the IT department had had the same budget fo r the last two years, but had increased responsibilities over this time period, the department essentia lly experienced a net cut in funding. Consequently the department changed structure to allow for the implementation of new IS that could help reduce costs like OSS. However because the IT department is heavily unionized, new activiti es and technologies can be difficult to implement when union rules are invoked. To work around uni on rules the department formed a new projects division that focuse d on using new technologies. Once new IS were implemented in the projects area, these projects were transitioned to the traditional functional areas to support. Th is affected the adoption of OSS as the projects division actively used these technologies in many new IS projects. Consequently model factors were mixed in their facilitation or hindrance of OSS. If
121 examined through the traditional IT departme nt functions, the f actors of technical knowledge, environmental scanning and vendor re lations acted to hinder OSS adoption as they were linked to existing proprietary ve ndor technologies; however if viewed through the projects division, these same factors acted to promote OSS adoption. Figure 9 highlights the model factor relationships at Decatur. The remainder of the case delves deeper into how environmental, organizationa l and innovation factors were influenced by cultural divide at Decatur. Figure 9. Decaturs OSS Adoption + / + / + / + / + / + / Structure Vendors Environmental Scanning Technical Knowledge OSS Adoption Stage/Level Administrative Intensity Divided Culture Lack of Resources + / + / + / + / + / + / + / + / -
122 Description of Decatur Providing services to the more than 150,000 residents in Decatur is a city government with more than twenty five municipal departments and three thousand employees. These departments and civil servan ts are led by a weak mayor, or a mayor without veto power, and a city commission of seven individuals. This leadership structure provides direction for a profession al city manager who is responsible for managing the city government. Economically Decatur is diverse as it ha s ties to agriculture, manufacturing and information technology industries. This ec onomic diversity has grown the community over the last decade, and without large nei ghboring communities, the city government of Decatur is considering mergi ng with the county to form a single municipal government for the areas residents. Description of Decaturs IT department The Information Technology (IT) Departme nt at Decatur, which has more than sixty personnel, is responsible for supporting most of the citys information technology. However there are multiple IT providers within the municipality. Larger municipal departments have their own departmental IT sta ff. Perhaps this structure is in place as the current central IT department is located thr ee bureaucratic layers away from the elected officials of the city. A lack of organizational power may also be a contributing factor as to why Decaturs IT department was th e only participating IT depart ment in this study not to have an increasing budget. Over the three year period that included the year this research
123 was conducted, the IT department had the same budget. Meanwhile the responsibilities of the department appeared to grow ever y year, resulting in a net budget cut. The increase of responsibilities coupled wi th a static budget resulted in the IT department altering its structure. Unlike othe r municipal IT departme nts, Decatur had two distinct divisions within the IT department: project teams and traditional IT areas. These two groups performed different tasks as pr oject teams implemented new IT projects, often working with other departments within the city. Meanwhile the traditional IT areas supported traditional IT functions. For exam ple the database ar ea was concerned only with support and operation of databases wh ile project teams were more involved in taking user requirements, identifying t echnology needs and implementing technology solutions. Decaturs Participants Twelve IT department members were inte rviewed for this stu dy during the spring of 2008. Table 18 highlights the ro le and responsibilities of th e IT personnel interviewed.
124 Table 18. Decatur IT Department Mem ber Role and Responsibilities Interviewee Responsibilities Administrator of IT Department Responsible for the operation of the IT department. Participates in project planning, project management, and departmental budgeting. Administrator of Hardware Operations Responsible for the operation of the city s hardware. This includes the citys networks, servers, and personal computer s. Participates in project planning, project management and departmental budgeting. Manages personnel associated with infrastructure. Administrator of Software Operations Responsible for the citys applications This includes enterprise as well as personal applications. Partic ipates in projec t planning, project management and departmental budgeting. Manages pers onnel associated with applications. Operations Manager B Responsible for planning and managing projects associated with the citys geographic information systems. Add itionally responsible for managing the geographic information systems used by the citys management and administrative departments. Operations Manager C Responsible for planning and ma naging projects associated with the citys utility departments. Additionally supported and managed severa l applications used by the citys utility departments. Operations Manager A Responsible for planning an d managing projects associ ated with information systems used by the citys management and administrative departments. Operations Technical Support Specialist Responsible for supporting the ema il systems used by the city. Administrator of Network Operations Responsible for the security and ope rations of the citys networks. Development Systems Analyst Respons ible for integrating business requi rements with existing information systems. Operational Database Specialist Responsible for da ily administration of se lect city databases. Applications Systems Administrator Responsible for the support of end user applications throughout the city. Database Administrator Responsible for the operati ons, maintenance, and impl ementation of Decaturs databases. Open Source Adoption at Decatur Five areas within Decaturs IT departme nt had adopted OSS at the time of the study. Table 19 highlights Decaturs IT departments OSS adoption. Most OSS was adopted by project teams rather than IT areas. However, once the project teams had implemented a new IT, the responsibility of supporting or maintaining the IT was given to the traditional IT areas.
125 Table 19. OSS Adopted at Decatur Departmental Area Applications Adopted Influential Model Factors Adoption Stage Adoption Level Impact on IT Function Networking Cold-Fusion*, Smith Projects Wealth, environmental scanning, techni cal knowledge, technical communities, internal communication, relative advantage, compatibility Routinization As-is, Hybrid Routine Database MySQL Wealth, environmental scanning, techni cal knowledge, technical communities, internal communication, relative advantage Routinization As-is Routine Server Linux variants, Apache Wealth, environmental scanning, techni cal knowledge, technical communities, internal communication, relative advantage Routinization As-is Routine End User Applications Open Office Wealth, environmental scanning, relative advantage Routinization As-is Routine Security N Map Wealth, Relative Advantage, technical knowledge, environmental scanning Routinization As-is Routine *While Cold-Fusion itself is a propriet ary application it has several open source packages/extensions which were used Networking The networking areas adoption of OSS wa s heavily influenced by the wealth of Decatur. we have been using a lot of open s ource in doing some of our application development because budgets are tight these days and theres really hardly any funding to do the things that wed like to do. Operations Manager A Two open source applications, Cold Fusion and Smith Projec ts, appear to help the area do the things that theyd like to do. While Cold-Fusion itself is a proprietary application, the department used several ope n source packages or extensions for ColdFusion. These open source packages appear to have been adopted by an Operations Manager A and her team who report to th e Administrator of Network Operations.
126 Because these open source packages integrated into a proprietary framework, ColdFusion, this adoption was classified as having a hybrid adoption level and at the routinization stage. This project team also uses Smith Projec ts, an open source application released under the GPL. Although released under the GPL, Smith Projects was specifically developed for the Cold-Fusion engine. This in creased the compatibility of Smith Projects with existing technologies and appears to be a moderating factor in its adoption. Because the IT department did not participate in th e development of the OSS and used existing releases of the technology, adopt ion can be classified at th e as-is level and at the routinization stage. Database Like the networking area, the database ar eas adoption of OSS has been largely due to new Operations Managers, a project team leader. Two of the three Operations Managers, A & B, had implemented MySQL data bases as the data store for small scale projects that they were in charge of. Thes e Operations Managers used OSS databases to reduce costs associated with proprietary da tabase technologies used by the city. This is in contrast to the technologies that the database area was accustomed to using, two proprietary databases. However the database area was aware of open source databases, as the Operational Database Specialist identified several of them, I have (considered OSS databases), MySQ L, PostgreSQL, EnterpriseDB which is a commercial version of PostgreSQL that has a wrapper that essentially imitates Oracle. Operational Database Specialist
127 The adoption of OSS by the project team s as opposed to the database area highlighted cultural differences within the IT department. The IT areas appeared to reject OSS adoption even when they knew about it while the IT project teams readily adopted this technology. Server While the majority of Decaturs servers ran on proprietary app lications, a growing number of the municipalitys servers utilized OSS as several variations of Linux and Apache Tomcat were used. Oh yes, we use Linux, RedHat, Suse, you know people have played with Ubuntu. Administrator of Hardware Operations Well the servers in our area are Linux based, basically its on a light Linux. Operations Technical Support Specialist I have other servers that are running some of my security stuff, and theyre more appliances than servers, but I have one server and its run Linux, even though a licensed copy. Administrator of Network Operations There are a few Tomcat servers ar ound. Development Systems Analyst These OSS were either purchased from a distributor like RedHat or SUSE, or freely downloaded. Software sourcing de pended upon the context in which the applications were applied. Server personnel reported that servers were classified as supporting either high risk or low risk operations, base d upon this classification OSS
128 sourcing changed. For high risk applicatio ns, where the department used OSS, it purchased supported versions of the software. Applications deemed low risk that used OSS were sourced by downloading the OSS. These differences appeared as personnel discussed the different versions of Linux that the IT department utilized. For example the Administrator of Network Operations purch ased a supported version of Linux when the OSS was critical for supporting several servers at the same time. RedHat Enterprise Server 3. Because its running on a Blade, so better safe than sorry. Administrator of Network Operations End User Applications Use of open source end user applications was very limited at Decatur. Apparently public schools in Decatur had adopted Open Office as an office suite as opposed to purchasing proprietary equiva lents to reduce costs. Weve used for community services the open source Office type package for the schools. Administrator of Hardware Operations However the use of Open Office appears to be limited to these schools and, at the time of the study, did not extend to other municipal departments. Reasons for this adoption were unclear as the IT department was not the primary IT support for these schools. Rather the schools had their own IT support within the educ ation administration. But the Administrator of Hardware Operatio ns was aware of this adoption as he was responsible for hardware inte roperability throu ghout the city, and th is included the IT used by education.
129 Security Like the other municipalities Decatur used several OSS in their security area. An open source application, N Map, pr ovided an array of security tools that the city used to identify and address security risks. N Map was used because the network administrator responsible for security identified it as havi ng superior performance and cost to many of its peer applications. because the guys that are maintaining it (N Map) and keeping it up take pride in the product. And theyre not selling it, they want people to use it, they want to be known as one of the best scanners or one of the best inte rrogators or whatever they call it. And thats why the products are usually bett er. Also we dont have the budget to buy a lot of stuff, so you look for tools t hat are free, and do what you need. And theres a few weve bought a couple real cheap software packages to do a couple of things but for the most part we use free I use free tools. Different groups use different things, so you have to ask them. Network Administrator Open Source Software Adoption Themes at Decatur Decaturs adoption of open source software (OSS) appears to be affected by two main themes, the departmental budget and a ch anging culture. The more important of the two themes was the departments budget as it seemed to drive the cultural change. The departmental budget not only affected the de partments wealth construct, but also appeared to influence other model factors as the department looked to cut costs. Model factors like environmental scanning, techni cal communities and vendor relations took on a new focus, from IT functionality to IT costs. For example:
130 I said I could take a freeware software and do the same thing that youre doing, that youre spending $5 0,000 a month, why would I do it any other way. Operations Manager B The second theme at Decatur, the depart mental culture, appeared to not only influence OSS adoption, but also seemed to in fluence departmental structure. Apparently there are two cultures within th e IT department, new hires and experienced IT members. Now dont get me wrong, our city gover nment is a great place to work, and heres what happens. You have a lot of peopl e that come into the city that are gung-ho, ready to hit the ground running, and then they get sucked into what I call the government mentality, where O kay, dont worry about it. Get it done when you get it done! and then they get su cked into that, ten years down the road, 15 years down the road, 20 years down the road, okay, their looking at Hey, I need 10 more years to retire. And theyre really not trying to do anything else, they just fix the day to day things and dont th ink outside the box, theyre not trying to do anything d ifferent. Operations Manager C New hires appeared to have business experience and approached IT tasks in a fundamentally different way than establishe d IT personnel. Employees with significant IT department experience, or more than eight years, appeared to be members of established IT areas and just fixes the day to day things. These employees preferred to follow the traditional role of municipal IT departments and integrate existing technologies to concentrate on task s assigned by the administration.
131 The traditional IT department employees were also accustomed to following IT guidelines set by the municipa l administration. These guidelines encouraged the IT department to implement and support vendor technologies and not to code or develop software. You cant use the word developer or programmer around here. Were integrators and were implemente rs. Operations Manager A We go in the mentality here in our IT shop is that we dont do any development. Okay, which Ive tried to get my manageme nt to say thats not true. We do development, so now I say we are going to enhance the system. Same word! But its easier to accept that wo rd. Operations Manager B Meanwhile newer employees appeared eager to reduce city costs, even if this meant coding or refining techno logies. This was a di fferent perspective and facilitated the adoption of OSS by newer employees. Not only did the cultural divide affect O SS adoption, but it also affected the IT departments structure. Decatur recently re -organized the IT department structure, shifting the planning and management of new pr ojects from traditional IT areas to project teams. Apparently this was done to enable new gung-ho employees to think outside of the box. Meanwhile the traditional IT areas were staffed by employees who had more experience within the city. In the traditional IT areas pe rsonnel became responsible for the supporting existing projects, allowing them to just fix the day to day things.
132 This structure also influenced OSS adop tion as project teams actively interacted with one another. They shared experience s, both good and bad, and one such experience was OSS adoption. Apparently one good implementation of an OSS had a high probability of leading to the adoption of the same OSS technology by another project group. Decaturs Model Factors Environmental Factors Decaturs culture influenced environmenta l factors. On one side tenured city employees appeared to believe that the depart ment should strive to meet the traditional role of an IT department, by providing techni cal support to the other departments of the city. In this capacity, Decaturs IT departme nts traditional IT area employees leveraged their vendor relations to integrate vendor technologies as opposed to developing applications or coding software. Perhaps city leadership encouraged this mentality that the department should focus on integrating vendor technologies, becau se of past IT project success rates. Apparently Decaturs IT pr oject success rate may not have met organizational expectations. The Development Systems Analyst, a newer employee, said The impression that I get is historically our IT department in the central section, hasnt always done the greatest of jobs in meeting the needs of the business units out in the field Consequently Decaturs veteran IT pers onnel have moved away from software development or coding activities and instead focus on maintenance and support. Instead
133 IT areas rely on vendors to provide both packaged technologies and occasional IT services for the city. Every area head declar ed that their area was a specific vendor shop. For example Operations Manager B said The city made a decision to be a (Vendor X) shop, and we hired and trained up some very skilled individuals. This reliance upon vendor technologies focused established IT personnel on vendor offerings. This affected model factors like external communication and technical communities as these factors focused on ve ndors and their support sites. We have a list of vendors that we can contact Administrator of Hardware Operations They (Company X) provide me a warm body from 8 to 5 every day that works in my room, works on my SAN (Storage Area Network), makes sure my servers are updated Administrator of IT Department We use (vendor site X), which is part of the support that we pay for every year. Operations Manager C Meanwhile newer employees on IT project teams appeared to have a different culture that affected their environmental fact ors. Rather than focusing on the traditional role of IT departments, support for other m unicipal departments, they sought to apply technologies for best fit solutions in the de partment. This focused on reducing costs and lead to several projects adopting OSS. Newer IT personnel on project team members
134 seemed to have wider external communication no loyalty to established vendors and a diverse set of technical communities that they used. They love that (searching for technology options), again Im talking you know this is the new kids on the block if you will (the project team). They (the project team) want to get in and get things done, and I dont want them to get stagnated where they get in that city mentality where theyre just Oh well, this is my job, in fact its all Im doing. And I dont teach them that, and I dont want them to be taught that way. So I try to keep them c hallenged and think outside of the box and think about how they can change things and make our government a better government, because in reality theres a lo t of things we could be doing, city wide that were not doing. Operations Manager C Organizational Factors Organizational factors were also affected by the organizational culture in Decaturs IT department. But the cultural change was driven by the wealth of the department. The Administrator of the IT Depa rtment appeared to follow the experienced employees philosophy and IT department approach when: The business the functional units are really running the business and IT is supporting that with infras tructure. Administrator of IT Department This philosophy appeared to stress how th e department was not supposed to code or develop software, a theme repeated by every experienced employee. However the Administrator of the IT Department implied that this approach to IT work resulted in a culture of mediocrity.
135 Lifetime city employees dont seem to have a sense of urgency. Administrator of IT Department Apparently enough IT department members lacked substantial urgency as the IT department had an eighteen month backlog on projects. Now I happen to think that an 18 month backlog isnt bad at all. Administrator of Software Operations Consequently the Director of the IT depa rtment was quick to point out that his newer hires all had short tenures within th e city. Most new hires had corporate IT experience which altered their world view. Most new hires were put onto project teams that focused on Decaturs IT projects. I think it helps if theyve (our staff) had private sector experience because they understand what we called earlier the sens e of urgency. Ad ministrator of IT Department Operations Managers A, B and C, the Ad ministrator of Software Operations, and the Development Systems Analyst all had corp orate experience and were all hired within the last five years. These individuals confir med that there was a cu ltural divide between older city employees and newer hires and that this divide impacted technical knowledge internal communication and environmental scanning When youre working inside of a governm ent industry you see just whats inside those four walls. You dont see whats on the outside. Operations Technical Support Specialist
136 I dont know, most of the staff are fair ly compartmentalized in what they do. They have one specific job role, one speci fic taskBefore I arrived I guess my predecessor was not as comfortable with doing a lot of the system updates and stuff themselves so they used to bring the vendor on-site and then he would literally, the vendor, would patch the servers, upgrade the software, go around every client PC and change out scanners and stuff like that. But (employee X) and I have taken over that responsibility and we do probably 90-95% of the maintenance and upgrades ourselves, which definitely allows us to save some budget dollars. Development Systems Analyst This is yours, thats mine. We have a lo t of that even internally. (Department A) doesnt want to share with (Department B) well thats yours, thats mine. The two shouldnt cross., now we for ce that from an IT level. Administrator of Software Operations Statements like these indicate that many lifetime city employees, while ready and willing to perform work tasks, were not willin g to look outside their four walls or try something new that changed or altered existing work proce ss. Differences in attitude among IT department employees, the long term employees and the recent hires, appeared to have distinct effects on organizational fact ors that resulted in differing effects on OSS adoption and adoption stage. For example tenur ed employees appeared to have reduced environmental scanning technical knowledge and internal communication while newer employees seem to have higher levels of these characteristics.
137 But differing levels of these organizationa l factors did not appear to be the only differences between the new hi res and lifelong city employ ees. New hires appeared to have a fundamentally different philosophy about what the IT department should do. They seemed to believe that the IT department pe rforms software devel opment activities when they integrate and customize vendor software and should not ignore these activities where feasible as it could reduce departme nt costs and reliance on IT vendors. Vendors are very important to our arena. Personally I think we use vendors too much for some of the things . Operations Manager A Any time we have any new development, if you will, (the city) has it contracted out with a third party vendor. And I dont agr ee with it, I think we could do that. Because we understand all the city business rules, we have the relationships with the customers, because all were doing is bringing a vendor in, having them number one to do a fi t gap session, sit with us. Which means theyre going to sit with us for a week or two, depending on the project, theyre going to spend $3050,000 right there. And we will be the one s who end up doing the enhancements to these new apps. Operations Manager B When I first came here it seemed that we hired consultants to do everything. Now what we do is we buy a lot of stuff o ff of the shelf. If you find something that does 80% of what you need you buy it and you make the other 20. Operations Manager C
138 My folks pretty much do all the back end programming of the applications. Operations Manager A One factor that was consistent betwee n both the newer and older employees at Decatur was slack resources. Both groups indi cated that they did not have slack time. Like other IT departments in this study, th ere were several positions in Decaturs IT department that were unfilled. The responsibil ities of these vacant positions were divided among the remaining IT department members, adding to their tasks and decreasing the amount of slack time individuals reported. Innovation Factors Decaturs adoption of OSS was cl early influenced by one innovation characteristic: the cost of OSS. they (OSS) may not be better than some of the stuff you can buy, but if you have to make a choice by going with the $15,000 be st or the free second best in the industry, Ill take the free second best. Administrator of Network Operations Cost was clearly a fundamental motivato r for OSS adoption, but it was not the only relative advantage perceived by IT personnel. Because OSS can be freely loaded, OSS seemed to circumnavigate purchasing bureaucracies and allow project teams more freedom to source technologies. Decatur, like the other city governments, has many purchasing reviews and processes in place to en sure that taxpayer monies are not wasted. These additional steps in the purchasing proces s create layers of bureaucracy that slow
139 down the pace of work within the IT depa rtment. Consequently, when Decatur IT department members download an OSS for fr ee, they bypass these organizational steps. (On using an OSS) That was a big change for the city because it felt like you had your own and have control over everyt hing we do. Operations Manager B The open source stuff helps us get around the purchasing bureaucracy. As long as we dont degrade our network wer e pretty much open. Operations Manager C Where adopted, Decaturs OSS adoption was compatible with existing hardware and software. Nobody has had a problem. Not in the Li nux OS but on the open source and Office platform type systems. They really dont know the difference and it doesnt cost anything per se. Admini strator of Hardware Operations Finally departmental members did not pe rceive OSS to be more technically complex than proprietary applications. They seemed to think that to implement OSS they would simply need to learn another standard or language. There is some reticence (towards OSS). Has been for a number of years, seems to be of using open source solutions. And my staff, having just geared up to be experts in (technology X) as well as (technology Y), hesitate to learn another system. The skill sets are much the sa me, its primarily syntax, but when the rubber hits the road, you need to be able to get the exact syntax to recover from a disaster situation. Administ rator of Software Operations.
140 (On adopting OSS) Its like getting out of a comfortable chairHere people like the comfortableness of Office under Micr osoft. Administrator of Hardware Operations While the technical complexity of OSS appeared to be minimal, the complexity surrounding organizational support of OSS was more confusing. Several IT area personnel expressed concerns about organizational support for the software and the Administer of Software Operations summed up thes e sentiments by saying: The problem is that it changes so quick and so fast that it is al most impossible to look at it on a long term basis. You look at it and its great today, but where is it going to be in a year? Administrator of Software Operations OSS Disruption within Decaturs IT Department Columbuss IT department was not di srupted by OSS adoption. Adoption did not change processes or skills as the adoption had limited scope, being contextual applications within specific IT department areas or being deployed alongside proprietary applications. While these adoption patterns reduced the scope of OSS, the adoption patterns also allowed the technologies to further IT project su ccess without changing organizational processes or needed skills. Interpretation of Decaturs Model Factors Coding of the interviews with Decaturs IT department identified 371 instances of model constructs. The only constructs not identified were the de sign adoption, infusion level of OSS adoption and peer adoption of OSS. The absence of these constructs is
141 consistent with Decaturs OSS adoption of as-is technology and the external communication activities of the IT depart ment. Figure 10 highl ights the coding of Decaturs interviews. Figure 10. Decaturs Codes Environmental Factors While Decaturs environmental factors app eared to play an essential role in generating awareness and intere st in OSS, the organizationa l culture of Decaturs IT department seemed to drive the environmenta l factors. Again culture was divided based upon tenure within the muni cipal government and prior business experience. Most veteran members of the IT departme nt, or individuals who had more than eight years of municipal government experien ce and little prior business experience, were in established IT areas, and focused on thei r immediate IT related tasks. These IT department members followed municipal guidelin es towards IT as th ey did not code or write new software. Rather thes e individuals re lied heavily on vendor technologies, as most IT areas declared themselves a vendor shop of one kind or another. Consequently veteran IT department members focused their external communication and use of
142 technical communities surrounded these vendor technolog ies. This had the effect of lowering the awareness and interest in O SS because proprietary technologies were preferred by the municipal guidelines. A dditionally established business policies and existing skills encouraged the use of these innovations. Alternatively newer hires within the IT department, or individuals who had fewer than eight years of experience within the IT department and some IT experience in other industries, appeared to focus on meeting departmental needs as opposed to municipal guidelines. These newer hires had l ittle or no loyalty to established vendors and actively sought out alternative technologi es like OSS to meet depart mental goals of reducing costs. This increased the awaren ess and interest in OSS through external communication and technical communities related to OSS. Technical communities also appeared to influence later stages of adoption as Decaturs IT department members relied on these communities for support and insight into OSS. The affect that Decaturs organizational culture had on the e nvironmental factors are summarized in Table 20: Decatur Enviro nmental Factors. The table highlights how several factors both f acilitated and hindered the adoption of OSS.
143 Table 20. Decatur Environmental Factors Factor Theorized Effect on OSS Adoption Finding Influence on OSS Adoption Adoption Stages Influenced External Communication Facilitate adoption by creating awareness and interest in OSS Adoption: Newer hires appeared to focus on finding technologies that would fit within the existing architecture regardless of their sourcing. This increased sources, serving to facilitate OSS adoption by creating awareness and interest in the technology. Rejection : Older employees appeared to focus on integrating vendor standards. This limited their external communication to vendor related sites and sources. Moderate (Rejection and adoption) Awareness, Interest, and Adoption Peer Adoption Facilitate adoption by creating awareness and interest in OSS Neither IT areas nor IT project teams were aware of other municipalities use of OSS. Low (Adoption) Awareness, Interest, and Adoption Vendor Relations Hinder adoption through switching costs and other mechanisms IT area use of vendor te chnologies appeared to focus those areas on vendor offerings. This seems to have limited many OSS implementations to new projects or technologies like Smith Projects that seamlessly integrated with existing vendor standards. High (Rejection) Awareness and Interest Technical Community Facilitate adoption by creating awareness and interest in OSS Adoption: Like external communication, newer hires appeared to focus on technical communities that would accomplish a task or provide a service, regardless of its fundamental source. This had the effect of increasing OSS adoption by facilitating awareness and interest in the technology. Rejection : Older employees appeared to focus on vendor communities to solve established work routines. This served to limit their external communication to vendor related sites. Moderate (Rejection and Adoption) Awareness, Interest, Adoption and Routinization Organizational Factors Decaturs organizational factors seemed critical for OSS adoption as they influenced the awareness, interest, adoption a nd routinization stages of adoption. Like the environmental factors, organizational fact ors also appeared to be driven by the organizational culture of the department and varied between IT department veterans and new hires.
144 Because IT department veterans follow ed municipal guidelines and focused on integrating established vendor technologies rather than code or create software, their organizational factors were heavily influenced by their vendors. Perhaps this reflects a high level of administrative intensity towards established IT ar eas. It is quite probable that established IT areas, such as the networ king or database areas were held to rigid standards to minimize downtime or other unf oreseen errors. This would allow the IT department to provide consistent support fo r IT applications used by other municipal departments. However this had a side effect, limiting internal communication environmental scanning and technical knowledge to established vendor products. This reduced the awareness and interest in O SS among veteran IT department members as they focused on vendor offerings. Internal communication appeared reduced as IT department areas had little to interact about as each area used their own technologies to accomplish their work tasks. Meanwhile newer IT department member s, who were primarily on IT project teams, appeared to focus on departmental pr iorities, primarily reducing IT costs, as opposed to municipal IT guide lines, of integrating vendor technologies. This allowed project teams comprised of mostly new hires to pursue technologies like OSS that reduced IT costs. Perhaps this reflected lower levels of administrative intensity as project teams were encouraged to think outsi de the box as they worked on new projects. This differed from the established IT areas that supported existing projects rather than implementing new projects.
145 Or maybe newer hires more readily adopt ed OSS as they had higher levels of internal communication environmental scanning or technical knowledge Project teams regularly met to discuss their tasks a nd gather insight and information from one another. Communication among project te am leaders was much more frequent; sometimes project leaders would meet multiple times a day, reflecting higher levels of internal communication Environmental scanning was also encouraged. Project team members were encouraged to find technologies that coul d reduce costs. Apparently guidelines for reducing costs were an 80/20 rule. As long as an application performed 80% of the requirements it would be adopted. Finally technical knowledge among newer hires seemed to be of higher levels. Perhaps not the execution of individual technologies but th e scope or breadth of new higher knowledge appeared to be much highe r than veteran IT de partment members. Maybe this is a result of thei r IT experience outside of the municipal government context. Several new members in the IT department rema rked that the change of pace or the rate of change within the munici pal government was much slow er than what they were accustomed to in other industries. These newe r hires indicated that they were accustomed to frequently learning new technologies, which appeared to increase their comfort level in searching for, and using ne w technologies like OSS. Two organizational factors that were c onstant, regardless of employee tenure or organizational culture, were wealth and slack resources Because Decaturs budget was held constant for the last two years while re sponsibilities increased, the department had a
146 low wealth construct, or reduced resources. This was reflected in the hiring and staffing of the department, as there was an 18 month backlog on IT projects. To compensate for this backlog on IT projects, slack resources were reduced. Employees did not have free time to search for new technologies. Rather technology searches were formal activities that were part of IT projects. Slack res ources and other organizat ional adoption factors are summarized in Table 21.
147 Table 21. Decatur Organizational Adoption Factors Factor Theorized Effect on OSS Adoption Finding Influence on OSS Adoption Adoption Stages Influenced Internal Communication Facilitate adoption by building consensus around potential new technologies Adoption: New hires that formed project teams had moderately high levels of communication within their teams. This served to build consensus around OSS technologies, facilitating OSS adoption. Rejection: Traditional IT areas with more established personnel seem ed to have internal communication that focused on work tasks, reinforcing existing technology standards, hindering OSS adoption. Moderate (Adoption and rejection) Awareness, Interest, Adoption and Routinization Environmental Scanning Facilitate adoption as scanning should increase awareness of OSS Project teams had modera tely high levels of environmental scanning as they looked for lower cost alternatives to city technologies. This appeared to increase awareness of OSS within these teams, increasing the likelihood of adoption. Meanwhile IT areas seemed to have limited environmental scanning as they focused on work tasks. Moderate (Adoption) Awareness, Interest, Adoption Administrative Intensity Hinder adoption as decision making is consolidated into a few individuals Adoption: Project teams appeared to have lower levels of administrative intensity as they discussed and experimented with a wide variety of technologies. This appeared to increase adoption. Rejection: Established IT areas appeared to have set IT standards to reinforce task completion. This seemed to hinder OSS adoption as these IT areas focused on existing standards and technologies. Moderate (Adoption and Rejection) Awareness, Interest, Adoption and Routinization Technical Knowledge Facilitate adoption as increased knowledge is associated with understanding how to use and apply OSS Adoption: Project teams displayed a wide breadth of technical knowledge that appeared to facilitate the adoption of OSS. Rejection: IT areas appeared to focus on technical knowledge concerning vendor technologies and work routines within these technologies. This appeared to reinforce vendor standards, hindering the adoption of OSS. High (Adoption) Moderate (Rejection) Awareness, Interest, Adoption and Routinization Wealth Positively facilitates adoption as organizations having higher levels of wealth are thought to have more resources to implement new technologies Decaturs wealth appeared instrumental in the adoption of OSS as the department looked for options to reduce costs. Although the departments budget was held constant for two years the department was asked to take on more IT projects, essentially resulting in a net budget cut. In most instances where OSS was adopted it was selected to reduce IT costs. High (Adoption) Awareness, Interest, Adoption and Routinization Slack Resources Facilitates adoption as employees can search for new technologies Slack resources had little impact on technology adoption as most employees reported no slack time. Rather environmental scanning appeared to be a part of new IT projects. Neutral Not Applicable
148 Innovation Factors The characteristics of OSS were the pr imary drivers for OSS adoption. However adoption appeared more likely where OSS ch aracteristics aligned with departmental values and cultural attitudes than the merits of the technology itsel f. Consequently the cultural divide between the IT departments appeared to influence how OSS innovation characteristics were perceive d by the two different groups. New hires were quick to identify three relative advantages of OSS. First the technology was cheaper, or cost less. Second the ab ility to simply dow nload several OSS applications allowed IT department member s to circumvent orga nizational purchasing procedures. Finally several IT department members, primarily i nvolved with networking and IT security, identified O SS applications as being cut ting edge, or industry leading applications. These characteristics were appare nt to newer hires as they sought to meet departmental goals of reducing costs and ha d much more active environmental scanning and communication than veteran IT departme nt members. Regardless of motivation, the relative advantage of OSS applications drove the adop tion of the technology at Decatur. IT compatibility appeared to be much more impor tant to veteran IT department members than to IT project teams. Because veteran IT department members sought to adhere to municipal IT standa rds of integrating established technologies, if an OSS did not readily integrate with a proprietary appli cation, or if an OSS application caused undue learning, or the need to learn a new procedure for an existing task, th en the likelihood of rejection appeared to be almost certain.
149 Meanwhile IT project teams did not appear to allow compatibility to drive their adoption of technologies. Rather they sought to meet the departmental goals and would work around most inconveniences, learning or technology integra tion, caused by the technology. Finally the perceived complexity of OSS seemed to vary between the two groups. Veteran IT employees, charged with s upporting existing projects, perceived the organizational support of the technology as being complex. Key to this perception was the belief that these technologies did not have established vendors; rather a common belief was that all OSS was created a nd supported by volunteers or hobbyists. Meanwhile newer IT department members were more aware of which OSS applications had vendors and which technol ogies were supported by volunteer groups. Perhaps this difference in perception can be traced back to the communication and environmental scanning habits of the two gr oups, as newer IT department hires more actively sought out new techno logies. Regardless of the pe rception of complexity, Table 22, Decatur Innovation Characteristi cs, summarizes the effect that complexity and other innovation characteristics had on Decaturs adoption of OSS.
150 Table 22. Decatur Innovation Characteristics Factor Effect on OSS Adoption Finding Influence on OSS Adoption Adoption Stages Influenced Relative Advantage Facilitate adoption through superior performance Decatur personnel highlighted the reduced cost of the innovation. However another relative advantage, the ability to circumvent tech nology purchasing procedures and high quality were mentioned by several members. High (Adoption) Awareness, Interest, Adoption and Routinization Compatibility Facilitate adoption by working with other technologies OSS adopted at Decatur seamlessly integrated with other technologies, no modifications or cu stomizations were needed for the software. Moderate (Adoption) Awareness, Interest, and Adoption Complexity Hinder adoption by erecting barriers to adoption Rejection: IT areas considered OSS applications as bei ng complex, changing work processes and activities, hindering OSS adoption. IT pr oject teams did not considered OSS to be complex as their perceptions of what IT department members varied from their IT area peers. Moderate (Rejection) Awareness, and Interest Interpretation of Decaturs OSS Adoption Decaturs adoption of OSS appeared to be driven by a cultural shift that may be the result of decreased departmental budgets It was apparent th at IT department employees fit into a spectrum, from veteran em ployees to newer hires and were placed in either traditional IT areas or in project te ams. The IT project teams were comprised of newer hires who sought to implement new IT projects. These teams seemed to prioritize departmental goals over muni cipal IT guidelines, allowing th em to consider technologies that veteran IT departmental members, w ho focused on integrating vendor technologies, were either unaware of or had no desire to use. Interpretation of OSS Disruption wi thin Decaturs IT Department OSS did not cause disruptions within Decaturs IT department. Rather OSS, where adopted, caused little change in work processes or knowledge. Where OSS did
151 cause changes the IT project teams readily s ought to master the technology and integrate them into existing business pr ocesses. Perhaps this highlig hts the temporal nature of disruptions caused by di sruptive innovations. Summary of the Decatur Case The culture of the IT department appear ed very influential to OSS adoption. Newer IT employees had corporate experience and were put onto IT project teams. These IT department members appeared to be willing to adopt OSS for segments of their IT infrastructure in their projects. Meanwhile more experienced employees were assigned to IT areas for IT support. These IT departme nt members focused on specific groups of technologies, such as databases or servers. Their adoption of OSS appeared to focus on the IT departments drive to reduce IT costs. This split in IT department culture combined with resource shortfalls to influence many model factors including vendor rela tions, technical communities, internal communication, environmental scanning, and tec hnical knowledge which appeared to be instrumental for Decaturs OSS adoption. Slack resources were almost non-existent as IT personnel scrambled to address an 18 month backlog in IT projects. Decaturs long term use of OSS seems to be uncertain. IT project teams are implementing select OSS applicat ions to reduce costs within the department. However, as they move on to other projects it seems unlikel y that the existing IT areas will be eager to support these applications. As project teams comp lete more projects it will be interesting to see how the department balances suppor t needs with the need to implement new functionality.
152 Jackson Hero Driven Adoption Overview of Jacksons Case Study Jacksons adoption of OSS was greatly aff ected by individual actions, or as one IT area manager said, area he roes. Because the IT depart ment had had four different leaders in the last five year s, the IT department lacked a vision or goal to guide the department. Consequently external department s had a large voice in IT operations as they often decided the technologies that they would use; many times these technologies did not align with existing infrastructure, incr easing costs and creati ng technical problems within the city. Without departmental leadership to pr ovide guidance for the department, most department members strictly adhered to uni onized duties and rules. This allowed IT department members to insulate themselves from drastic change s sought by external departments. However, performing tasks that were outside of job descriptions, such as scanning for new technologies, were rare among IT departme nt members. Consequently OSS that was adopted by the IT department was adopted by heroes, or individuals who took initiative to change IT operations within th eir areas. Not only di d these individuals have greater technical knowledge and more e nvironmental scanning than their peers, they were also in administrative or managerial positions. This gave the heroes some authority over their operations, allowing them to na vigate union rules. Fi gure 11 highlights how Jacksons lack of leadership influenced mode l factors. The remainder of the case delves deeper into the environmental, organi zational and innovation factors at Jackson.
153 Figure 11. Jacksons OSS Adoption Description of Jackson The city of Jackson is a large m unicipality, having over 250,000 citizens. Providing services to these citizens are more than 4,000 m unicipal employees who are employed by over twenty municipal department s. Leading the city is an elected city council of seven members which is headed by an elected mayor. The mayor is considered a strong mayor as the mayor can veto city counc il initiatives. + / + / Environmental Scanning Technical Knowledge OSS Adoption Stage/Level Administrative Intensity External Departments
154 Economically Jackson is diverse; it has st rong ties to service, retail, finance, insurance, and real estate industries. Grounding these industr ies in Jackson are several Fortune 1000 corporate headquarters. Description of Jacksons IT department Jacksons central IT department is large, having more than 80 members. However it is not the only IT resource in the city. Other municipal de partments have their own IT resources, and if these indivi duals were included the number of IT personnel in the city would nearly double. Administrator of Infrastructure The city is not truly IT centralized. The city has little groups of people that arent IT people but th ey are departmental liaisonsif we counted them all up we wouldnt have the (80+) members of our department, but Id bet you wed have more than 130 personnelthere are positives and negatives in that these people dont re port to the central IT department. There are many possible reasons as to w hy Jacksons IT resources are not more consolidated; the IT department is located th ree organizational layers away from elected city management, there has been high turnover in IT department leadership, the city is divided into operational silos that do not communicate well w ith one another, and/or the city has displayed a short term perspective to IT operations. Administrator of Infrastructure I thin k our biggest weakness is that our central point of IT authority is nowhere near the citys central point of authority.
155 Administrator of Business Applicati ons The department has been through about five to seven years of some pretty bad turnover at leadershipand when they failed they bolted. The department is still dealing with this. Administrator of Data Operations Theyre all over the place. Parking department is their own fiefdom. Poli ce department is definitely their own fiefdom. Fire department s their own fiefdom. Network Administrator I guess there s been a very open philosophy around the city for several years as far as, you know Buy whatever you need, install it, and well figure it all out later. So now all that stuff has really snowballed and were starting to get a lot of systems that ar e old. You know, the vendor doesnt exist anymore, the employee that knows how to fi x it is goneso that is a lot of the stuff I deal with on a daily basis. Complicating matters the city of Jack son, including the IT department, was undergoing budget cuts at the time of th e study. Although the IT budget was 13 million dollars, it was being cut during the time of th e study. This has resulted in reduced staffing and compounded the use of aging equipment as resources are not available to replace old infrastructure. See Appendix Item E for a desc ription of Jacksons employees and budget. Jacksons Participants Sixteen IT department members were inte rviewed for this study during the fall of 2007. Table 23 highlights the role and responsibilities of the IT personnel interviewed.
156 Table 23. Jackson IT Department Mem ber Role and Responsibilities Interviewee Responsibilities Administrator of Telecommunicati on Operations Responsible for planning municipal telecommunications needs, and the implementation and support of m unicipal telecommunications. Operations Lead D Responsible for a team in charge of infrastructure and soft ware associated with several business applications. Operations Lead C Leader of a team responsible for supporting end user computing and examining how end user technologies fit into the work practices of municipal employees. Network Administrator Responsible for the operations of select subsystems of the citys network. Administrator of End User Applications Responsible for the support and maintenance of municipal end user applications. Administrator of Infrastructure Responsible for all th e information technology hardware used by the city. Coordinates with other area administ rators to plan for city needs. Network Operations Personnel Responsible for the operations of the citys servers. Administrator of Data Operations Responsible for all data communications with in the city of Jackson. This includes the selection, implementa tion, maintenance and trai ning of Jackson personnel involved in the operations of data communications within the city. Administrator of Business Applications Responsible for the selec tion of, implementation, ma intenance and training of Jackson personnel on the business applications used by the city. Operations Lead A Responsible for gathering re quirements for an integrated ERP (Enterprise Resource Planning) syst em for city use. Operations Lead B Responsible for the require ments gathering and implementation of an ERP (Enterprise Resource Planning) human resources module. Security Operations Personnel Res ponsible for user administration on city servers and cross-functional applications Development Programmer Responsible for maintaining and developing cust om computer applications used by the city. Database Development Administrator Responsible for day to day operations and development of select municipal databases. Administrator of Web and GIS Development Responsible for the operation and de velopment of Jacksons web site. Additionally responsible for the opera tion and development of the citys geographic information systems (GIS). Administrator of Security Operations Responsible for the security of the citys electronic information. Participates in project planning. Mana ges security personnel Open Source Adoption at Jackson Two areas within Jacksons IT departme nt had adopted OSS at the time of the study. Both of these areas appear to have management heroes who had adopted these technologies. These area leaders seemed to have little interac tion with one another. While they had both adopted the Linux operating system they had adopted different versions of the program as well as other contextual a pplications. Table 24 highlights Jacksons IT departments OSS adoption.
157 Table 24. OSS Adopted at Jackson Departmental Area Applications Adopted Influential Model Factors Adoption Stage Adoption Level Impact on IT Function Networking Ethereal, Suse Linux Relative advantage, compatibility, environmental sensing, technical knowledge Routinization As-is Routine Security Redhat Linux, NMap, Airsnort Relative advantage, compatibility, environmental sensing, technical knowledge Routinization As-is Routine Networking At the time of the study, Jackson s networking area had adopted two OSS programs. These applications were adopted because they were compatible with the eclectic components comprising Jacksons ne twork. The networking area was responsible for integrating many different technologies, some outdated and othe rs current, and the area manager sought out applications that coul d bridge the different technical standards. As per the Network Operations Personnel, Network Operations Personnel Everything, right now, is kind of just in silos. Our servers, well, theyre really not tied together. Weve made that recommendation and theyve gone out and bought some products, but theyre not implemented as of yet, thats what were doing. Ethereal, an open source multi-platform networking analysis tool, was adopted because it provides functionali ty that allows users to ea sily troubleshoot networks comprised of different technologies. This relative advantage appears to have been identified by the Network Administrator who needed an application that would allow the networking area to shoehorn together netw orking equipment that operated on different standards.
158 Network Administrator Im up at ni ght, cruising the blogs and message boards for new ways to shoestring everything together. The other OSS adopted by the networki ng area, a Linux variant, SUSE, was purchased from a vendor. This vendor supplied the various departments with networking software and hardware, and SUSE Linux was a natural extension of these offerings. This Linux variant was compatible with the other offerings of the vendors and appeared to have a lower total cost of ownership than other offerings. Because OSS applications used by the networking area did not change business processes or the skills need ed to perform work, the adop tion of these technologies is routine. Meanwhile the technol ogies themselves were used as-is on a regular basis, characterizing the adoption as routinization. Security Jacksons security area had adopted three OSS applications, Redhats Linux, NMap and Airsnort. The initiative to adopt th ese applications appears to have been led by the administrator of security operations as he believed these applications were leading technologies. Administrator of Security Operations Open source tools, like NMap, are critical for security. I mean, theyre developed by open source communities before going commercial. I guess if I want ed to pay for something thats behind the curve I could, but I prefer getting my tools at the source, so to speak. However these tools were not used by ever yone in the security area. When asked about OSS the security operations personnel in terviewed responded that they were not
159 aware of any open source software used by the area. Evidently the security area in Jacksons IT department compartmentalized tasks as the administrator of security operations routinely used OSS tools to s can Jacksons network for vulnerabilities, allowing his personnel to perform othe r tasks like user administration. Because the administrator of security ope rations did not develop the OSS that the area used, the adoption level for the area can be classified as as-is. Meanwhile the adoption stage can be considered as routin ization as these tec hnologies were commonly used to perform area tasks. Additionally the technologies seamlessly integrated with the other applications used by th e area, having a routine imp act on the areas function. Open Source Software Adoption Themes at Jackson The major theme behind Jacksons adoption of open source software was the fragmentation of IT resources within the municipality. Because Jacksons central IT department was located several la yers below city leadership, it appeared that other, more prominent city departments had more organiza tional power within the city. This allowed these departments to choose their own tec hnologies, staff their own IT personnel and override or undercut the central IT departments decisions. Apparently city reve nues played a major role in establishing organizational power at Jackson, as municipal departments were di vided into enterprise and general fund departments. This influenced organizati onal power at Jackson as enterprise departments, such as Public Safety and Water Management, held sway over general fund departments, like the central IT department.
160 Administrator of End User Applications Yea, there is a big disparity between the departments here. Some are general fund departments, maybe doing code enforcement, and they dont have a lot of money. Then you have other departments that are revenue generati ng like parking and tra ffic monitoring. The disparity is pretty evide nt with the equipment. Operations Lead A I mean we have en terprise departments like water and sewers basically make their ow n money so to speak. And they have to spend their own money. The IT department is a general fund depa rtment, and as such, budgets rarely meet fundamental needs, let alone allow for major overhauls of IT infrastructure. Administrator of Infrastructure M anagement will come back to me and say Okay, youve asked for $500,000 worth of equipment, but we have $250,000 worth of money that you and three other supervisors can share. So we get together in a room and negotiate with each other. Network Administrator I think if we had more freedom to implement the service in the way that we thought made the most sense to make, you know most cost effective sense, the city (network) would look a lot different. The lack of funding or orga nizational power affects th e central IT department. Because the IT department is beholden to ent erprise departments, they need to be very careful about how they operate. This has resulted in clearly defined roles and
161 responsibilities for IT department personnel. For example, new innovation adoption was almost entirely directed by IT area manage rs as their operations personnel focused on performing area tasks. Administrator of End User Applications Most new ideas and things come from my superior and the managers, and how they want to see things. Operations Lead D I dont do it (look at new technologies) much now, my supervisors and managers do it more than I do now. I just do the work now. Consequently area managers who thought that new technolog ies could improve operations were the individuals within th e department who looked for new innovations like OSS. But of the IT departments six area managers, only two actively sought out new technologies. The Administrator of Business Applications summed up the search for new innovation within the department as: Administrator of Business Applications Our innovation is unfortunately hero drivenThe culture is status quo. So its up to an individual to drive a train for new innovations like an ERP or changing our methodologies. And OSS technologies were no exception. Consequently, the two area managers who had searched for OSS were the onl y individuals to have adopted OSS technologies. Jacksons IT departments new leader wa s focused on consolidating IT resources within the city.
162 Network Operations Personnel Our new director, what hes trying to do is bring them (outside IT personnel) under our umbrella, and maybe even bring them into the department. Database Development Administrator O ur IT department head is trying to reign in the other departments. Hes trying to bring all these IT people from the departmentsso they will actually be wo rking for IT which will be helpful because I tend to believe that theyre sti ll going to be in the departments where the departments need them. But because they will actually work for IT, things will have at least standards and policies and procedures and things. Which they dont have right now. Operations Lead A One of the areas that our department head is looking at is a consolidation of technology people into the central IT department. Operations Lead B This (department cons olidation) isnt rocket science, its just a matter of sitting down and docum enting everything that there is and defining the needs and say Okay, heres the options. Okay Mr. city councilman, you make the call. Perhaps the consolidation of IT resources within the city would allow for more IT planning, as this was a major theme within the department. Apparently decentralization of IT resources and turnover in leadership has left area managers putting out fires,
163 responding to immediate problems that interr upt daily operations as opposed to planning courses of actions. Many indivi duals interviewed thought that a five or ten year plan could greatly reduce the number of different IT standards used by the department and consolidate IT work processes. Network Administrator I would say on a daily basis the thing that makes my job difficult is theres no such thing as long term planning beyond four years for obvious reasons. We get changes in administrations. If we wanted to do something massive like move the city from (Vendor X) to (Vendor Y) I mean, thats not even a four year project. So you show some body the price tag for that, even though the total cost of ownership is lower over 8-12 yearsnobody wants to have to be the administration that paid for that. Administrator of Infrastructure I th ink if we had a true 10-year plan that I wouldnt have (vendor X) type-1 cabling w ith token ring on it. Its not in the interest of the city for the dollars yes it costs money to replace it. But I have an engineer that has never worked with token ring before in his life, the technology is outdated. Administrator of Web and GIS Development We have some databases that are 20 years old and still chugging along. To flush those databases now is problematic without having an over-archi ng enterprise architecture. When we
164 have that architecture in place well be able to be more responsive to that particular exemplar of the diff erent rates of development. However, the consolidation of IT resources is no simple task. Apparently the different municipal departments were very conscious about organi zational power and the ability to decide for themselves the technolog ies they would use. Consequently the city had a departmental IT adoption focus rather than a municipal IT adoption focus, which led to the adoption of co nflicting technologies. Administrator of Data Operations I ts hard to make al l these independents work together. Because we werent involved in the selection at all, and part of the reasons is because we take so long to do it, considering all the options, so we end up trying to shoehorn things into the ne twork because the m oneys already been spent. In summary, Jacksons IT department was very similar to other IT departments that participated in this study. The department divi ded responsibilities among their personnel, had a clearly define d hierarchical structure, a nd had well defined personnel roles. However this division of task roles limited environmental sensing to management; operations personnel were encouraged to focus on their work tasks. This appeared to facilitate hero driven a doption of new technologies or ideas within the central IT department.
165 Jacksons Model Factors Environmental Factors Because Jacksons IT department limited s earch activities for new technologies to IT department area management, area manage ment sought out sources to help them reduce their scanning activities Consequently existing IT vendors were very important for IT department operations. Extensive use of vendors created network effects, which interacted with other environmental factor s, such as peer adoption and technical communities, to reinforce the importance of vendor technologies. For example vendors influenced the technical communities used by Jackson IT employees. Database Development Administrator I go online a lot and use a lot of the (vendor X) groups. There did not appear to be any departmental processe s that limited which vendors Jackson interacted with. Because technology adoption was fragmented within the city, Jackson used almost every municipal vendor. Administrator of Business Applications We use almost every municipal vendor, we have an eclectic group of applications You can label them all legacy if you want. Some of them are pretty good. Some ar e pretty moderate. But we have what we have. Were finishing up our inven tory and theres we ll over 100 core applications that dont ta lk to each other. This reliance upon vendors created a st andards fragmentation as vendor technologies often didnt talk to each other. This added to the work load of the IT department and often dictated IT department actions. For example vendor influence was
166 particularly strong in the telecom as work pr ocesses, technical skills and equipment were heavily influenced, if not di ctated, by Jacksons vendor. Administrator of End User Applications Our telecom rides the vendor. So we always have to manage our process when they change how they do business. We have to adjust on our end. Takes a little bit of my time. In addition to supplying technologies, vendor s were also used to complete work tasks. Some vendors had become extensions of the IT department as they had gained expertise in select operations, resulting in these IT vendors be ing critical to several IT work processes. Network Administrator Well the contra ctor I regularly use, hes intimately familiar with the Police Department and supports a lot of their more legacyd systems. Operations Lead A We have over s even different standards running our operationsWe use quite a bit of contract labor. Mainly because to acquire and keep the skill set needed is really expensive. Environmental factors were also influen ced by the fragmentation of Jacksons IT resources as other municipal departments, es pecially enterprise departments with IT staff, chose their own technologies, ofte n to the detriment of the municipal IT infrastructure. For example Operations L ead B statement about the Human Resource Departments influence in technology adoptio n decisions appears to supersede the IT departments wishes.
167 Operations Lead B Thats because m anagement here doesnt want it (Vendor X implementation). But the (HR department ) carries more weight than the people youve talked to and have already endo rsed it and then recommended it to the governance committee. I was there in the meeting and they voted, one person against and the other twelve for. IT department personnel did not have objections with outside municipal departments choosing technologies that the central IT departme nt would need to integrate with other applica tions and support. Administrator of telecommunications ope rations Because right now they never had telecom up till a couple years ago. A year, two years ago at best. Never, theyve outsourced everything. Thats why all of the departments were doing their own thing. Operations Analyst Wed like people to use (Software X) but its not they can use any tool, as long as it works for their project. Were ok with that. IT department managers often limited themselves to looki ng at proprietary technologies that were used by other municipalities. External communication that was not with IT vendors focused on peer institut ions. When talking with peer institution, peer adoption of vendor technologies was of great in terest to Jacksons IT department. Personnel from multiple IT areas have gone to other municipal governments to observe and evaluate proprietary t echnologies before making innova tion adoption decisions.
168 Administrator of End User Applicat ions Weve kind of gone down to (municipality X), met those folk s, see how they do business. Administrator of Infrastr ucture (City X) has some very good programs in place. Excellent, weve seen a few of them and we know their director. Network Operations Personnel We talk to other people, we go to trade shows like the storage networking world they had over in (City X)Once in a while I talk to (County X) and I just met with (C ounty Y) yesterday on a project. Kind of a joint project we have together. Operations Lead B I know what (city X) did, I know what their requirements were and I know what many other public sector organi zations have had. Its not any different. Network Administrator I looked around nearby municipalities and then countiesso I was able to glean a lot of knowledge from them. Operations Lead D If we are looking at the possibility of pi cking like a package or something like that, that other governments might be using; we go to the other government and we take a look at what theyve got and how th ey use it. We do that, in fact some of the pr ojects that Ive been on over the years Ive actually
169 made trips to California and New Jersey and different places looking for the package that we were considering buy ing and seeing because we didnt want something that you know they come in and give you a demo and thats what it is. I mean you dont ever accept that. Organizational Factors Jacksons theme of IT fragmentation im pacts the organizational factors of the city. Administrative intensity is particularly affected as the IT department has little authority or power within the city. For example, the central IT department does not have the authority to consistently dictate sta ndards to other municipal departments. Operations Analyst Wed like people (other departments) to use (Software X) but its not they can use any tool, as l ong as it works for their project. Were ok with that. Even when standards are successfully pa ssed, municipal depart ments resist their adoption. Database Development Administrator Whe n I was at the water department, the water department is an enterprise department. Meaning they make their own money, and if we wanted something we got it. I mean we didnt check with IT. It IT said No, you cant have it. We had it anyway, I know. When I was there (at the water department), thats when Win 3.1 first came out. And this department did not bless that. They did not want to use that. We had this old menu called Marks Menu and it was horrible. I mean it wa s just awful. So what we all did on our PCs, we had somebody there who was like a hacker. And he put 3.1 on
170 everybodys PCs and then we all had a hotkey and if anybody from IT came in you hit the hotkey, the Marks Menu came up. Thats what we and I know in my heart that they are still out there doing t hat kind of thing. Because I mean we still have people out there that are working on Office 97, you know and thats just ludicrous. But unfortunately because we (the IT department) dont have a whole lot of people and we dont have the manpower to change it. Active resistance of IT standards seems to stem from the history of departmental independence within Jackson. Administrator of telecommuni cations operations I think its (the relationships between the city departments) got a long ways to go. I thin k that it (the city) was so siloed in the past and it was so decentr alized that trying to get their arms back around it and not having the other departmen ts have their own ability to do what they want is a major change. The independence municipal departments ha ve had in the past also influence the internal communication of the city. Network Administrator I mean weve had a lot of interaction with departments that have typically be en silod completely from a technological point of view. Theyve just been allowed to do their own things. Their computers are completely off the network, you know basically we buy them a new com puter and slide the pizza under the door. Lack of inter-departmenta l communication within J ackson appears to be a contributing cause to incompa tible technology standards.
171 Operations Lead C Simple case, not too long ago, this one department bought a new printer. And all they wanted to do was print mainframe reports. Well they bought a low end printer that did not accept PCL language. Thats the only thing the mainframe sends out. So it would not work for the one purpose they wanted it to, you know? Low levels of internal communication and administrative intensity also affect Jacksons IT operations. For example city operations appeared to have an excessive number of databases. Operations Lead B Here we have over 23,000 (vendor x) databases scattered around the cityThats stil l about 15, 16, 17,000 too many. Our departments just cant grasp the concept. Weve got disp arate islands of information strewn throughout the city. Different departments are free to create and implement new databases as they see fit. Data are put into silos and kept from others even when multiple departments use the same information. Not only does this create independent islands of data, but it also questions which departments data is correct. The internal communication problems between municipa l departments appear to carry over to the IT department areas. While the IT areas within the central IT department cooperate with one another, it seems that they do not coordi nate their area activities or technologies. Development Programmer We have so many standards because, well, the teams are somewhat independent.
172 Development Programmer Initially I was pretty much on my own. This is a fairly immature shop. We really dont have strict version control. Operations Lead A We have very soli d cooperation. Very patient because everyone works a little short handed or has six #1 priorities. So every once in a while you get someone to raise an eyebro w or something like but we just get together and say Wer e all on the same team, so lets resolve it and make sure it doesnt go outside the four walls of the department. The lack of standards planning and enfor cement within the city has affected the technical knowledge of the municipality. IT area employees appear to have high levels of knowledge about the technologies that they work with on a day-to-day basis, but seem to be falling behind on general trends within their IT area. Operations Lead B Yes, Im slipping behind. In the (Vendor X) world, no, because we pretty much stay on top of th e latest releases and things like that. Staffing shortages appear to contribute to the reduced levels of technical knowledge as IT department staff members speci alize in specific parts of their IT area. Administrator of End User Applications Here we are so short staffed that people get pigeonholed into certa in areas of responsibility.
173 Operations Lead C Sure seems like certain people get stuck in certain areas for a long period of time. And then they get so depended upon, while in that area. People cant really spare them. While this allows individuals to specia lize to get work tasks accomplished, it has a side effect, it limits organizational change. Operations Lead B Theres very little documentation, its in peoples heads. Thats very important, just knowing what you have. Im trying to get a total cost of ownership number put together for al l software. I dont think anybody has any idea of how much software there is out th ere and what the total cost of it is. I mean you know we pay annual renewal and ma intenance cost as well just for the limited few items Ive got and Im up to a million and a half! Just on renewal. Specialization, while apparently necessary due to staff shortages, appe ars to contribute to limiting environmental scanning to IT area managers. Administrator of Web and GIS Development Innovatio n typically comes from the managers. Theres a group of us thata re plugged into (Vendor X) at a high level, so we draw on them for ideas, we brainstorm with them about every 6 weeks. Administrator of Business Applications Our innovation is unfortunately hero drivenThe culture is status quo. So its up to an indi vidual to drive a train for new innovations like an ERP or changing our methodologies.
174 While many managers seem to be open to information about new technologies and new opportunities, IT area personnel do not appear to be looking for these technologies. Many operations personnel are co ntent to use the technologies assigned to them by their area heads. Network Operations Personnel Management is pretty open, really, to finding the best ideas to fix proble ms. Were open to anything that s out there. Theres so much change in this area. To shut things out and not look at things would not be wise. Development Programmer A lot of what we do is dictated by management and you know where their goals and values are. Perhaps the lack of internal communication at Jackson reinfor ces this behavior, allowing operations personnel to rely upon the hero driven process of adopting new innovations or change. Innovation Factors IT area managers that had adopted OSS thought that the applications had relative advantages over their proprietary equivalents in performance and cost. However this appeared to depend on organizational factor s as the context and the environmental scanning of the individuals influenced their perception of the technology. Operations Lead B Open source te chnology is good, but it depends on the environment and the application that youre looking for.
175 Administrator of Web and GIS Developmen t GAO did an analysis last year studying open source security. They found that open source software is typically safer, more secure than proprietary codebecause you did have hundreds of hackers working to break it over and over again. What appeared to be more important was the compatibility and complexity of OSS as an organizational technology. This me ant that OSS needed to not only function with the other technologies used by Jackson but also needed to have support and training for organizational staff. These were characteri stics that IT area managers were concerned with. Administrator of Business Applications Its not about whether or not we could use open source applications. We could do that, learning new technologies is the same regardless of where they come from. Its about getting the support and training for these technologies to let th e city use them. Where will that come from? Volunteers? Hobbyists? Who knows? Consequently the innovation characteristics of OSS appeared to stand out to some IT area managers, those who could limit th e scope of OSS. For example within the security area only the security ar ea manager used OSS technologies. Security Operations Personnel Im not familiar with open source softwareMy manager does most of the research in our areaI mean he has an open door policy, if I see something I can ta ke it to him, but you know for the most part Im so bogged down in day to day stuf f that I dont have a whole lot of time
176 to go through the stuff on the web or go through the latest magazine and see the latest trends and stuff like that. IT area managers seemed more focused on organizational characteristics of the software that they would adopt, or the avai lability of IT vendors to provide additional services related to sp ecific technologies. OSS Disruption within Jacksons IT Department Jacksons IT department was not di srupted by OSS adoption. Where adopted, OSS technologies did not change processes or skills as the adoption had limited scope, often being used by single members of an IT area. The adoption of the technologies focused on meeting specific, contextual needs, being applied to ne tworking and security tasks. Interpretation of Jacksons Model Factors Coding of Jacksons interviews found 740 instances of all but two constructs infusion and peer adoption. The construct in fusion was not found as the adoption of OSS at Jackson was limited to the as-is level a nd routinization stage. Departmental members simply used OSS technologies they did not participate in development activities. Additionally peer adopti on of OSS was not recorded as th e departmental relations with other municipalities seem to have focused on proprietary technologi es. Figures 12 and 13 highlight the coding of the interviews.
177 Figure 12. Jacksons Codes Figure 13. More Jackson Codes Environmental Factors Jacksons environmental factors appear ed to both facilitate and hinder the adoption of OSS. The effects of these factors appeared to vary base d upon the perspective IT area managers took when looking for new technologies.
178 When IT area managers searched fo r new technologies based upon the functionality or the capab ilities of the technology, environmental communication and technical communities appeared to facilitate the awareness and interest of OSS. These factors followed theory as they informed the managers about the functionality and capabilities of OSS. However, when area managers sought technologies based upon organizational characteristics, or the av ailability of support, training and help implementing technologies, environmental communication, technical communities and vendor relations appeared to hinder the adoption of OSS. Network effects appeared to be cr eated, as the organizations existing technologies, skill sets, and ability to ju stify a technology adoption decision influenced the use of vendor technologies. Conseque ntly, when managers sought out vendor technologies or were closely aligned to ex isting vendor technologies, the awareness and interest in OSS were reduced. Table 25 captu res how environmental factors affected OSS adoption at Jackson.
179 Table 25. Jackson Environmental Factors Factor Theorized Effect on OSS Adoption Finding Influence on OSS Adoption Adoption Stages Influenced External Communication Facilitate adoption by creating awareness and interest in OSS Rejection: IT areas that focused on specific vendor technologies communicated with other municipalities and vendors about these technologies, reducing awareness or interest in OSS. Adoption: IT managers that focused on functionality communicated with a variety of sources, increasing the awareness and interest in OSS. Moderate (Rejection and Adoption) Awareness and Interest Peer Adoption Facilitate adoption by creating awareness and interest in OSS IT personnel consulted with peers about their proprietary technology implementations, hindering awareness or interest in OSS. Moderate (Rejection) Awareness, and Interest Vendor Relations Hinder adoption through switching costs and other mechanisms IT area use of vendor technologies appeared to focus on vendor offerings. This seems to have focused IT areas on the use of vendor technologies. High (Rejection) Awareness and Interest Technical Community Facilitate adoption by creating awareness and interest in OSS IT department members appeared to use technical communities to complete work tasks. Rejection: Those tasks implemented through vendor systems appeared to focus departmental members on vendor technical communities. Adoption: individuals that did not focus on specific vendor technologies appeared to use a variety of technical communities, including those that advocated OSS use. Moderate (Rejection and Adoption) Awareness, Interest, Adoption and Routinization Organizational Factors Jacksons organizational factors were in fluenced by the organizational power of the IT department. Because the IT department was a general fund department, it was beholden to, or responsible for providing se rvices for enterprise departments. Consequently the IT department divided responsibilities to cl arify processes and responsibilities. This resulted in a hierarchical division that separated IT area managers from operations personnel when selecting new technologies.
180 This separation of duties implies a high level of administrative intensity as the responsibilities of organizatio nal roles were clearly defi ned. However the number of technical standards adopted by the municipality highlight how little administrative intensity other areas or functions of the IT depa rtment had. This contextual variation of administrative intensity, clearly defining ro les while not defini ng technology adoption standards, appears to be a di rect result from the weak pos ition of the IT department within the municipality. Other organizational factors were dir ectly influenced by the variations in administrative intensity: environmental scanning, internal communication, technical knowledge, and slack resources Environmental scanning was specifically outlined by the administrative intensity of the department. Operations personnel were expected to focus on work tasks while area managers, who had the initiative to lead change, were expected to search for and implement new technologies. This division in technology sear ch process directly influenced internal communication technical knowledge and slack resources As operations personnel were encouraged to focus on their dutie s it limited what they communicated about, discussing work tasks, and wh at they learned, how to do th e different work tasks. It shifted technology search activities to IT area management, to more efficiently allocate operations tasks to operations personnel, all but eliminating slack resources. Adoption of OSS and other new technologi es appeared to be characterized as hero driven because of the numerous respons ibilities of IT area managers. In most IT areas IT managers worked alongside IT pers onnel to complete work tasks, and as the
181 department was short-staffed, technology sear ch activities, such as environmental scanning, appeared to be second to comple ting work assignments. The pressure to complete work tasks appeared to focus tech nical knowledge on existing standards, as this was how work tasks were completed. It also en couraged static techni cal knowledge as it would require effort to learn new technologies. OSS adoption appeared to be facilita ted by lower levels of organizational wealth As the department suffered from personnel shortages and reduced budgets, technologies that could reduce costs or bridge techni cal standards became highly sought after, encouraging area managers with high need to look beyond their traditional vendors. Wealth and other organizational adopti on factors are summarized in table 26.
182 Table 26. Jackson Organizational Adoption Factors Factor Theorized Effect on OSS Adoption Finding Influence on OSS Adoption Adoption Stages Influenced Internal Communication Facilitate adoption by building consensus around potential new technologies Division of area responsibilities limited internal communication to operations. Area managers did not use internal communication to build consensus about OSS. Moderate (Rejection) Awareness and Interest Environmental Scanning Facilitate adoption as scanning should increase awareness of OSS Environmental scanning was limited to area managers and varied based on individual initiative. Managers individual initiative determined OSS adopti on as high initiative resulted in adoption wh ile low initiative resulted in the maintenance of the status quo. Moderate (Adoption) Awareness, Interest, and Adoption Administrative Intensity Hinder adoption as decision making is consolidated into a few individuals Adoption: Low levels of administrative intensity towards technology standards facilitated OSS adoption by IT area managers. Rejection: clear division of personnel responsibilities focused other organizational factors on existing vendor technologies. Low (Adoption) Moderate (Rejection) Awareness and Interest Technical Knowledge Facilitate adoption as increased knowledge is associated with understanding how to use and apply OSS Adoption: The technical know ledge of area managers allowed them to identify how OSS could align with area needs and to implement and use the technologies. Rejection: Focus on work tasks encouraged IT area personnel to c ontinue to use existing technologies. High (Adoption) Moderate (Rejection) Awareness, Interest, Adoption and Routinization Wealth Facilitates adoption as organizations with more resources can encourage adoption Lack of departmental wealth encouraged IT area managers to look for technologies that would help reduce costs. Low (Adoption) Awareness and Interest Slack Resources Facilitates adoption as employees search for new technologies Lack of slack resources resulted in fewer technology searches. Low (Adoption) Awareness Innovation Factors Jacksons adoption of OSS was st rongly influenced by the innovation characteristics of OSS. The relative advantages of contextual applications, networking
183 and security applications were crucial for a doption. These applications were perceived to have superior functionality within the re lated IT function. However it was difficult to determine where the relative advantages in functionality were separated from compatibility as the areas of networking and secu rity needed to interact with many different technology standards. Compatibility with other technologies appeared to be essential functions in the areas of networking and security as the re sponsibilities of these areas focused on the communication between different technologies Because the compatibility with other applications was an essential function of these areas it questions the nature of the relative advantage of the technologies. Does the rela tive advantage of a technology focus on the main functionality of the program, and if the main functionality of a program is communication, does this make compatibility a fo rm of relative advant age? Perhaps this OSS complexity appeared to hinder OSS adoption. However Jacksons perception of OSS complexity focused on organizational issues, such as support and training, rather than individua l use or knowledge of the technology. This differs from theory as complexity traditionally refers to the need for individuals to learn a new standard. Table 27 highlights how complexity and the other innova tion characteristics affected the adoption of OSS at Jackson.
184 Table 27. Jackson Innovation Characteristics Factor Effect on OSS Adoption Finding Influence on OSS Adoption Adoption Stages Influenced Relative Advantage Facilitate adoption through superior performance The relative advantage of OSS facilitated adoption through superior performance in the security and networking areas. Moderate (Adoption) Awareness, Interest, Adoption and Routinization Compatibility Facilitate adoption by working with other technologies Technical compatibility was essential for the OSS adopted by Jacksons Security and Networking areas as these areas interacted with multiple standards. High (Adoption) Awareness, Interest, and Adoption Complexity Hinder adoption by erecting barriers to adoption Complexity of OSS appeared to be low to many Jackson IT personnel. What was complex were the organizational attributes of OSS such as support and training. Moderate (Rejection) Awareness and Interest Interpretation of Jacksons OSS Adoption Jacksons adoption of OSS appeared to focus on individual managers who were aware of, and who could recognize superior functionality, in OSS a pplications. Adoption of OSS was limited to managers as the opera tions personnel within the department were discouraged from searching for new technologi es. Rather personnel were encouraged to focus on work tasks that seemed to stem fr om day-to-day maintenance and support issues rather than a longer term IT plan. The managers of the networking and secu rity areas, two areas that focus on integrating multiple technologies, identified OSS applications as being superior to proprietary equivalents. Perhaps OSS applic ations were superior at integrating the proprietary applications used by Jackson as the open source applications were not owned by an organization that sought to create network externalities through technical standards. Regardless of the ownership of the OSS applications, the OSS adopted by Jacksons IT department appears to be her o driven. Without indi vidual managers, or
185 heroes who could search for and identify O SS and recognize the contextual application of these programs, Jacksons IT department apparently would not have adopted OSS. Interpretation of OSS Disruption wi thin Jacksons IT Department Jacksons IT department was not disrupt ed by the adoption of OSS. Because the departments adoption of the technology was at the as-is level a nd the routinization stage, the department did not contribute to OSS development or testing nor did the department apply the technologies in unusual or new ways. This allowed the department to adopt OSS without making changes to processes or existing skill sets. It should be noted that the adoption of OSS was limited to programs of limited scope. OSS was used by managers of the networ k and security areas. If adoption were to have been more widespread within these areas, or if OSS had been adopted in substitution for established proprietary appl ications, Jackson personnel would needed to have learned new technology standards which, in all likelihood, woul d cause disruptions within the department. Summary of the Jackson Case Jacksons adoption of OSS appeared to rely heavily on individual managers who could recognize and implement OSS technologies into their IT areas. Additionally these technologies appeared to be limited in thei r scope, as most of the OSS adopted by Jackson was well established or purchased fr om OSS providers. Hero driven adoption of OSS appeared to require area managers to have higher levels of technical knowledge and environmental scanning. Manager technica l knowledge was needed to learn how to
186 apply the innovation into the work context wh ile environmental scanning was necessary to identify the innovations themselves. Jacksons adoption of OSS appeared to be hero driven because a number of factors that appeared to interact. These factors included multiple technology standards that most assuredly came from decentrali zed municipal IT resources. Municipal IT resources seem to be fragmented because of a number of reasons that include the low organizational power of the cent ral IT department, high turnov er of central IT department leadership and other municipal departments with their own IT resources that are resistant to change.
187 Bowling Green Best of Breed Overview of Bowling Greens Case Study Bowling Greens adoption of OSS was great ly influenced by the departments Best of Breed approach to IT. According to the Administrator of IT, being Best of Breed meant that the department looked for and adopted recognized industry leading IT products. The Assistant Administ rator of IT described this as focusing the department on cutting edge technologies, or hardware and software that was recognized by industry as leading technologies, as opposed to bleedi ng edge technologies, which were emerging software and hardware that are unpr oven, but may have great potential. Being Best of Breed, or implementing industry recognized IT, consolidated IT adoption activities into the hands of select managers. Because these managers adopted industry leading technologies, their adoption tied th e department very closely to their vendors. This influenced many model fact ors, including administrative intensity, technical knowledge, technical communities and environmental scanning. Of these factors, administrative intens ity and technical communities acted to reinforce vendor influence on Bowling Green s IT adoption by focusing technical knowledge and environmental scanning on ve ndor technologies. Figure 14 highlights these factors and their relationships towards OSS adoption. What is remarkable about this case is that these factors, traditionally asso ciated with IT adopti on, acted to hinder OSS adoption as they focused the IT department on established vendors. Only when an OSS was recognized by industry as being cutting edge , or the flagship technology for that IT area, was it adopted. And in the case there is only one such technology, in the security
188 area. The remainder of the case highlights how the Best of Breed approach influenced environmental, organizational and innovati on level factors in the IT department. Figure 14. Bowling Greens OSS Adoption Description of Bowling Green Bowling Green, an economically diverse community of over 75,000 citizens, is a growing community. Economically Bowling Green is a recognized leader in citrus and phosphate production with strong ties to regi onal and national light manufacturers, distribution centers, and corporate centers. The city itself is comprised of more than fifteen departments. In 2007 these departments spent over 535 million dollars on th e salaries of more than 2000 employees, as well as the goods and services needed to provide local government to the residents of + / + / + / + / + / + / + / + / + / Vendor Relations Technical Communities Environmental Scanning Technical Knowledge OSS Adoption Stage/Level Administrative Intensity Best of Breed Philosophy + /
189 the municipality. See appendix item E for a co mparison of Bowling Green to the rest of the case participants. Five key area goals, an economic, co mmunication, fiscal management, growth management and quality of life, guide the c ity management, which is led by a hired city manager and a professionally hired staff. In turn, the professional city management staff is directed by an elected board of officials, the leader of which is called the city mayor. Description of Bowling Greens IT department One of Bowling Greens departments is the information technology department, which recently became the sole IT resource in the city. Located two bureaucratic layers away from the mayor and city commission, the IT department consists of more than 70 members and has had increasing revenues over the last three years. The main duties of the IT department focus on supporting best of breed technologies which are used by the functional departments of the city. The best of breed approach to IT is more fully explained in the section Open Source Adoptio n Themes at Bowling Green, as it was a key driver of department activ ities as well as OSS adoption. Bowling Green Participants Ten members of Bowling Greens IT depart ment were interviewed for this study. IT department personnel came from every area within the IT department and had varying levels of tenure. The majority, seven, of the individuals interviewed had more than fifteen years of departmental experience while the other three individuals had been with the organization for under three years. Personnel titl es and responsibilities are generalized so as to not identify the individuals.
190 Table 28. Bowling Green IT Department Member Role and Responsibilities Interviewee Responsibilities Administrator of Database Operations Responsible for the citys databases. Part icipates in daily administration of city database. Participates in project pla nning. Responsible for database budget. Manages databa se personnel. Assistant Administrator of IT Respons ible for oversight of IT operations Participates in project planning, project management and departmental budgeting. Administrator of Network Operations Responsible for the citys networks. Partic ipates in daily administration of city networks. Participates in project pla nning. Responsible for networking budget. Manages network personnel Administrator of Security Operations Responsible for the security of the citys electronic information. Participates in project planning. Mana ges security personnel Senior Database Operations Personnel Responsible for daily administrati on of select city databases. Program Operations Personnel Res ponsible for programming and supporti ng select city applications. Development Systems Analyst Respons ible for gathering business requirements and presenting them to programmers. Responsible for managi ng a group of programmers and the applications that they support. Administrator of Technical Support Responsible for supporting end-user com puting outside of the IT department. Participates in project planning. Ma nages the citys support specialists. IT Support Operations Specialist Responsible for assisting m unicipal employees with day to day operations of IT. Responsible for trouble-shootin g computer problems/bugs. Administrator of IT Responsible for the operation of the IT department. Participates in project planning, project management, and departmental budgeting. Open Source Adoption at Bowling Green Of the IT departments participating in th is study, Bowling Greens IT department had adopted the least amount of OSS. The adopting areas within Bowling Greens IT department are summarized in Table 29. Table 29. Bowling Greens adoption of OSS by area Departmental Area Applications Adopted Influential Model Factors Adoption Stage Adoption Level Impact on IT Function Security Nessus*, Nopix, Backtrax, Airsnort, Nmap Administrative Intensity, technical knowledge, environmental scanning, compatibility, relative advantage Routinization As-is Routine Server Linux variants Slack resources, technical knowledge, environmental scanning Evaluation, choice, interest As-is Routine
191 Security The security area at Bowling Green had adopted several open source security applications. These applications were perceived to be cutting edge or outstanding applications in the security context and theref ore fit with the departments best of breed IT philosophy, which is covered in the next section. Because these open source applications were routinely used by the security area without modifications or contributions to the OSS, the areas a doption of OSS was clas sified as having a routinization adoption stage and an as-is adoption level. The effect these computer applications had on the department was ro utine as they did not alter or disrupt departmental processes. Server The server area at Bowling Green had adopted Linux variants at the evaluation/choice/interest adoption level. Perhaps this is due to the timing of the areas experimentation with OSS technologies. The server personnel reported experimenting with Linux and other OSS server platforms be fore the city consolidated municipal IT resources into a single IT department thr ee years ago. However, during the last three years the server area personnel had not progres sed with their adoption of OSS. Perhaps this is because of a lack of slack time, a changing of duties or because of the second major theme in Bowling Greens IT department human resources turnover. This theme is also discussed in the next section.
192 Open Source Adoption Th emes at Bowling Green Bowling Greens adoption of OSS technol ogy appeared to be influenced by two departmental themes. The first theme is the IT departments best of breed philosophy the second is a high rate of human resources turnover. The best of breed approach to IT led the city to adopt computer applications that were perceived to be industry leading technologies wherever possible. Consequently OSS was routinely adopted by only one IT area, the security area, which identified select open source applications as industry leaders. The other theme that appears to influe nce OSS adoption at Bowling Green is employee turnover. Because Bowling Green trains its IT departmental members on industry leading applications many of them leave after a short tim e in the department. This has left the department in a hiring cycle as the IT department is continually hiring, training, and then watching personnel leave the city. However this hi ring cycle seems to be ending as the department has adopted new policies towards training new employees. At the time of the study Bowling Greens Model Factors Coding of Bowling Greens model factors revealed that three constructs, design level adoption, infusion stage adoption and awareness of peer adoption were not identified at the site. Figure 15, highli ghts the 352 codes f ound in the interview transcripts.
193 Figure 15. Bowling Greens Codes Environmental Factors Bowling Greens environmental factors appe ared to be heavily influenced by the departments best of breed philosophy. B ecause the department looks for industry leading applications, or the be st IT to meet city needs, Bowling Greens IT department focuses on vendors technologies. Consequently IT de partment personnel appeared to have the largest amount of external communication with IT vendors and vendor related technical communities Vendor relations affected which websites and Internet resources IT personnel used, as Bowling Green IT personnel almost exclusively used vendor related sites to troubleshoot problems or find solutions to work tasks. The importance that Bowling Greens IT department places on their relationship to vendors appeared to be summed up by the Assist ant Administrator of IT when he said: Were an active member with FLGISA (F lorida Local Government Information Systems Association), because of our rela tionship with some of our vendors, we
194 are a targeted site for participation and other government agencies coming to us and talking to us about what were doing with our vendors. This statement highlights how important Bowling Greens vendors are to the IT department. It also stresses that the relati onships between Bowling Greens IT department and IT vendors are stronger than their muni cipal IT department peers. Strong enough that other municipal governments ask Bowling Gr eens IT department for advice when selecting vendor technologies. Meanwhile peer adoption played little role in Bowling Greens technology adoption decisions. The IT depart ment had little interest in what technologies their peers were using and, according to the Assistant Administrator of IT, Bowling Green was accustomed to having peer governments approach Bowling Green for assistance with IT vendors. Not the other way around, with Bow ling Greens IT department approaching other municipalities for help with IT projects. Organizational Factors Bowling Greens organizational themes ha d a strong impact on the organizational factors in the model. The best of breed approach reflected high levels of administrative intensity regarding technology adoption. This philosophy was enacted to reassure other municipal departments that municipal IT resources w ould have industry leading functionality. This reassurance was necessary because of the origin of Bowling Greens IT department. Like most municipalities, Bow ling Green did not create a centralized IT department when the city began using IT. Inst ead city departments, like the Water or the
195 Police department independently purchased and implemented information technologies. Consequently these departments had their ow n IT areas that provi ded support, training and implementation for these technologies. The best of breed philosophy was critical for the consolidation of IT re sources as it reassured munici pal departments of receiving industry leading functionality. High levels of administrative intensity were required to implement the best of breed technology adoption philosophy. Conseque ntly searches for new technologies were highly formal, involving multiple partie s and centered on providing industry leading IT functionality for the municipality. This cultivat ed an attitude of IT as a service within the IT department. Were a service. We are servants to the business areas that we serve. Administrator of IT. We never say You cant have that.(to ot her city departments) We say Thats one option, let me show you a couple of others. Assistant Administrator of IT Organizational wealth appeared to be a major focus for the IT department. However the focus on wealth was the conserva tion of resources by finding cost savings through IT consolidation within the city. The Director believes that this is the low hanging fruit is getting so me efficiency in how we go through identifying (software) (this allows us to ) keep costs as low as I can. It is pretty easy for me to demonstrate (savings)H ey weve got eight d ifferent departments in the city that need to cut work orde rs. I can buy eight different systems and try
196 to support them all, and give everybody exa ctly what they want. Your costs are going to go way up. Or we can buy one syst em, everybody gets 80% of what they need, but I keep the cost dow n. Administrator of IT This perspective was supported by the A ssistant Administrato r of IT who said: We try to stay very consistent. We stay with, you know two operating systems, one being for risk based processors HP UNIX and the other being Intel based processors being Windows, and we stay with, on the server side one set of hardware. Because the city relied on vendor technologies for best of breed standards organizational model factors appeared to be biased towards vendor technologies as opposed to OSS. Environmental scanning and technical knowledge seem to focus on vendor offerings to reduce costs and increase the perceived quality of the technologies implemented by the department. Wego to third party vendors for trai ning. Administrator of Database Operations on site internal training and sending th em (our staff) to training paid professional training. Assi stant Administrator of IT We had a pretty informal relationship with the sales rep for XX. A lady named Michelle, Ive talked with her on quite a few occasions and sh es pointed me in
197 good directions to get some input and some ideas of where to get some information. Program Operations Personnel Being best of breed also indire ctly influenced departmental wealth and slack resources by increasing employee turnover. Be cause Bowling Green employs industry leading IT, new employees, after completing th eir training, have opportunities to leave the municipal IT department to chase higher sa laries in industry. The Administrator of IT appeared to summarize this when he said We get someone in, they ge t them trained up, they go el sewhere. So you always have somebody who is being trained up, and always have somebody whos trained them, it leaves just a handful of people to actually get the job done, and you got work that st arts to pile up. Employee turnover was echoed by many othe r individuals in the department. If I keep a programmer three to five years if I get them five years Im really happySomewhere between two and three years theyre going somewhere for more moneyThe last two or three yea rs we averaged 20-25% vacancies in the application development and DBA environment. Assistant Administrator of IT one guy that left here in October and I took over his projects Program Operations Personnel When I came here we had six DBAs, we were down to two, but now were up to three. Senior Database Operations Personnel
198 This seems to have created the organizational cycle that the Administrator of IT talked about, experienced departmental me mbers spend their time training new hires. This leaves few individuals to perform the work within the depa rtment. Consequently, workstarts to pile up. According to the Assistant Administrator of IT, at last estimation the department had a thirty si x (36) month backlog on IT projects. This affects organizational wealth and slack resources. Because the department has committed itself to being best of breed it spends large portions of its budget licensing proprietary technologies Wealth available to experi ment with new technologies is reduced, decreasing the eff ect of wealth on technology a doption decisions like those made to adopt OSS. Additionally slack resources are greatly reduced. Because some senior employees appear to be training newer empl oyees their environmental scanning seems to be reduced. They focus on completing their work tasks and training new hires up to speed. However slack resources appeared to be responsible for an experimental implementation of OSS. Members of the serv er area had implemented an instance of Linux to determine if the technology would work in their environment. Unfortunately the members of the server area reported that they had not had time to experiment with the technology due to employee shortages and new work tasks. The human resources cycle at Bowling Green also appears to reinforce existing technological knowledge and standards as there appeared to be an underlying sense of urgency to complete existing pr ojects. Employees felt stretched thin and were reluctant to experiment or learn new technologies.
199 Within this environment of employ ee turnover and backlogged projects, internal communication within the department appeared to focus on these tasks as opposed to discussing new ideas or techni cal options. Rather, individual areas and personnel in these areas focused on completing their work tasks. Often areas did not communicate and in extreme circumstances personnel within the same area did not know what each other were doing. For example: Because we forget we have to handle so many databases a lot of times we dont see one really have to address one for a year or more, then all of a sudden they have a problem with it, we have to ge t our cheat sheets out to find out who owns it, you know and how it ties in to other things. Administrator of Database Operations This appeared to reinforce existi ng work processes, narrowing down the responsibilities for individual IT department personnel. Narro wed responsibilities seem to compound reduced environmental scanning, internal communication, and technical knowledge as personnel focused on their ta sks and duties within their area. Innovation Factors Innovation factors appeared to be the only model factors that influenced the adoption of OSS, and this only where OSS wa s perceived to be th e best technology available. The relative advantage and compatibility as predicted by theory, facilitated adoption, while perceived complexity hindered adoption. For example, the Administrator of Security Operations, the only area at Bowling Green that had adopted OSS at a
200 routinization level, stressed that he used OSS only when the tool was considered to be the best and aligned well with existing technologies. a lot of those tools (OSS) still exist and a lot of them still maintained their status as being the best thing still to useYou run it (OSS) when it has a lot of tools already built on ther e, already so you dont have to do any configuring, you dont have to build your own Linux workst ation and stuff, you pretty much boot up to it. Administrator of Security Operations This statement stressed the importance of using the technology, not developing it or learning new skills. Therefore, only where there was high relative advantage and compatibility was OSS adopted. Complexity also followed existin g theory as it decreased the likelihood of adoption and adoption stage. Nearly everyon e within the department was concerned about changing technical standards to OSS as they believed it w ould alter processes within the department. It was summed up by th e administrator of t echnical support who said: It would definitely be a change, and one that I dont know that I would necessarily see happen here. Ad ministrator of Technical Support OSS Disruption within Bowling Greens IT Department OSS adoption by Bowling Greens IT depart ment did not result in any disruptions to the department. Skills sets, maintenance, and implementation of the technologies did not require new knowledge or processes. The best of breed philosophy integrated industry leading technologi es within the municipal framework. This approach
201 downplayed the need to acquire new skill sets or optimize specific functionality in favor of standardized technologies. As previous ly said by the security administrator, a lot of those tools (OSS) still exist and a lot of them still maintained their status as being the best thing still to useYou run it (OSS) when it has a lot of tools already built on ther e, already so you dont have to do any configuring, you dont have to build your own Linux workst ation and stuff, you pretty much boot up to it. Administrator of Security Operations This statement appears to capture the sentim ent of how the IT department would adopt technologies that meet the b est of breed philoso phy while minimizing the configuration and customization of software. Interpretation of Bowling Greens Model Factors Environmental Factors Bowling Greens environmental factors appe ared to be heavily influenced by the departments best of breed philosophy which focuses enviro nmental factors on vendor technologies. Because Bowling Green implem ents industry leadi ng technologies their external communication and use of technical communities focus on vendor technologies. This focus on ve ndor technologies caused exte rnal communication, vendor relations and technical comm unities, to adversely affect OSS adoption and adoption stages as Bowling Greens IT departme nt did not consider OSS solutions. Not only does this reliance upon vendors fo cus Bowling Greens IT department on vendor offerings, but it also appears to have a side e ffect: suspicion of OSS. For example, the Administrator of Network Operations admitted:
202 Im not real comfortable with open source applica tions, operating systems, things like that. Even the Chief Security Officer, the head of the one area that had adopted OSS, expressed concerns about OSS technol ogies in the following statement: GLBA, (Gramm-Leach-Bliley Financial Services Modernization Act of 1999) will not allow it (OSS). They dont want you running open source like Open Office as your desktop productivity and its simply not allowe d and I do agr ee and I do see where its coming from. This perception is in stark contrast to the many open source companies, like Symbiot and MailArchivia, which offer ope n source solutions for organizations to become GLBA compliant. Even peer adoption seemed to focus on vendor technologies. Again, the Assistant Director of IT indicated that Bo wling Green was accustomed to being contacted by peer municipalities for references about thei r vendors. This seemed to indicate that the awareness of the IT department was square ly focused on their ve ndors and their vendor technologies. Consequently Bowling Greens focus on vendors through th e best of breed philosophy appeared to focus environmental f actors on vendor technologies. This seemed to create network effects, opportunity costs, or sunk costs that li nked Bowling Green to their vendors and negatively impacted the adoption of OSS. A summation of how the environmental factors at Bowling Green aff ected OSS adoption is summarized in Table 30.
203 Table 30. Bowling Green Environmental Factors Factor Theorized Effect on OSS Adoption Finding Influence on OSS Adoption Adoption Stages Influenced External Communication Facilitate adoption by creating awareness and interest in OSS As opposed to facilitating adoption by building awareness, external communication appeared to hindered OSS adoption. Employees appeared to focus on vendors and resources associated with vendor technologies as opposed to searching for new technology options Moderate (Rejection) Awareness and Interest Peer Adoption Facilitate adoption by creating awareness and interest in OSS Appeared to facilitate interest as one departmental area wa s aware of another municipalitys use of OSS. Low (Adoption) Awareness, Interest, and Adoption Vendor Relations Hinder adoption through switching costs and other mechanisms Appeared to hinder adoption of OSS as strong vendor relations seemed to focus the department on vendor technologies and standards. High (Rejection) Awareness and Interest Technical Community Facilitate adoption by creating awareness and interest in OSS Seemed to hinder OSS adoption as the department interacted with technical communities that focused on proprietary technologies. This appeared to reinforce the use of vendor standards as opposed to creating awareness and interest in other technologies like OSS. Moderate (Rejection) Awareness and Interest Organizational Factors The best of breed philosophy a ppeared to manifest in the administrative intensity within Bowling Greens IT department It influenced the technology adoption process, focusing organizational factors related to technology adoption on vendor technologies. This focus on industry leading applications appeared to not only overlook most OSS applications, but also create human resources shortage at Bowling Green, as employees gained experience with industry st andard applications they would leave for better paying positions in industry. Conse quently Bowling Greens IT department appeared caught in a human resources cycle in which new hires would be trained by
204 experienced staff members and then leave. Th is left few personnel av ailable to complete work tasks, and appeared to be a primary cau se of the 36 month backlog in IT projects. This human resources cycle reinforced departmental technical knowledge, environmental scanning, and internal communication on vendor technologies as Bowling Green IT staff struggled to train ne w hires and complete existing work tasks. Shifting to a new standard, like OSS, appeared to be a secondary, or unpleasant idea, as the staff would be required to learn new technical standard s on top existing backlogged projects. When asked about such a shift, the Administrator of Technical Support responded: an open source Linux type system, the be st place to start would be something very small and like an island type thing, like a small busine ss. Okay and then grow it out from there. Tryi ng to do something like that with something as large as the City of Bowling Green, I dont think so. Because the department was short-staffed, slack resources seemed almost nonexistent. Even though the department had two test systems, one of which had installed Linux, an OSS operating system installed on it, there did not appear to be sufficient employee time to experiment with these technologies. Meanwhile wealth, while a driver for the consolida tion of IT within Bowling Green, did not appear to affect OSS adoption. As stated earlier, the low hanging fruit is getting so me efficiency in how we go through identifying (software) (this allows us to ) keep costs as low as I can. It is pretty easy for me to demonstrate (savings)H ey weve got eight d ifferent departments
205 in the city that need to cut work orde rs. I can buy eight different systems and try to support them all, and give everybody exa ctly what they want. Your costs are going to go way up. Or we can buy one syst em, everybody gets 80% of what they need, but I keep the cost dow n. Administrator of IT We try to stay very consistent. We st ay with, you know two operating systems, one being for risk based processors HP UNIX and the other being Intel based processors being Windows, and we stay with, on the server side one set of hardware. These statements indicated that the IT department was able to cut IT costs within the city by focusing on using single applications. Perhaps OSS will become more attractive to the IT department once these ope rational efficiencies ha ve been maximized. Wealth and the effects that other organi zational factors have on OSS adoption are summarized in Table 31.
206 Table 31. Bowling Greens Organizational Model Factors Factor Theorized Effect on OSS Adoption Finding Influence on OSS Adoption Adoption Stages Influenced Internal Communication Facilitate adoption by building consensus around potential new technologies Hindered adoption as internal communication focused on completing work tasks, not discussing new technologies. Moderate (rejection) Awareness and Interest Environmental Scanning Facilitate adoption as scanning should increase awareness of OSS Hindered adoption as environmental scanning focused on vendor technologies that met best of breed standards. High (rejection) Awareness and Interest Administrative Intensity Hinder adoption as decision making is consolidated into a few individuals Hindered OSS adoption, technology adoption decisions were extremely formal and limited to select individuals within the IT department. This increased the influence of the best of breed philosophy when choosing information technologies. High (rejection) Awareness and Interest Technical Knowledge Facilitate adoption as increased knowledge is associated with understanding how to use and apply OSS Hindered OSS adoption as technical knowledge focused on using vendor technologies as opposed to the underlying service or problem. Moderate (rejection) Awareness and Interest Wealth Facilitates adoption as organizations having higher levels of wealth are thought to have more resources to implement new technologies Hindered adoption even though departmental budgets are limited and highly monitored Moderate (rejection) Awareness and Interest Slack Resources Positively facilitates adoption as employees with more slack time can search for and experiment with new technologies Facilitated adoption as employees had begun experimenting with OSS Low (adoption) Awareness, Interest and Adoption Innovation Factors The relative advantage compatibility and complexity of OSS appeared to play a secondary role to the departments best of breed philosophy when adopting OSS. The Administrator of Security Operations, the only area at Bowling Green that had adopted OSS at a routinization level, st ressed that he used OSS only when the tool was considered to be the best and aligned we ll with existing technologies.
207 a lot of those tools (OSS) still exist and a lot of them still maintained their status as being the best thing still to useYou run it (OSS) when it has a lot of tools already built on ther e, already so you dont have to do any configuring, you dont have to build your own Linux workst ation and stuff, you pretty much boot up to it. Administrator of Security Operations The characteristics of the technologies app eared to play a secondary role in their adoption as the IT department focused on i ndustry leading vendor products to implement Bowling Green IT. Where OSS mirrored industr y perceptions, such as premier security applications, the IT department adopt ed the technology. However, where OSS applications did not fit with th e best of breed philosophy, the complexity of the innovation was quickly pointed out, that th e technology would require new skills or new processes. The innovation factor s are summarized in Table 32. Table 32. Bowling Green Innovation Factors Factor Effect on OSS Adoption Finding Influence on OSS Adoption Adoption Stages Influenced Relative Advantage Facilitate adoption through superior performance Bowling Green personnel perceived the relative advantage of OSS in the security area as being the best tools to use in this area. High (Adoption) Awareness, Interest, adoption and routinization Compatibility Facilitate adoption by working with other technologies OSS adopted by Bowling Greens security area seamlessly integrated with other technologies used by the area. High (Adoption) Awareness, Interest and Adoption Complexity Hinder adoption by erecting barriers to adoption OSS applications that were not considered to be best tools were thought to be complex and difficult to understand. Departmental members perceived OSS to alter work processes and cause disruptions to operations. High (Rejection) Awareness and Interest Interpretation of Bowling Greens OSS Adoption Bowling Greens IT department adopted OSS applications only where the technologies aligned with the best of br eed philosophy. However, the departmental staffing shortage appears to have interrupted IT departmental expe rimentation with OSS
208 technologies. It is unclear as to what w ill happen if and when new personnel are hired. Additionally, the department appears to have little motivation to change what technologies it is adopting as operational efficiencies are still being found by consolidating different app lications throughout the city. Perhaps once these operational efficiencies have been maximized the IT de partment will begin to look for new areas to find ways to cut costs within the municipa lity. But for now, OSS adoption is strictly limited to best of breed applications within the IT departments security area. Interpretation of OSS Disruption with in Bowling Greens IT Department OSS adopted by Bowling Greens IT de partment did not cause change work processes or require departmental members to learn new skills. Consequently there was no discernable disruption to IT operations by the adoption of OSS in the security area. Perhaps this is because the OSS adopted was very specific, being s ecurity applications, and was only accessed by personnel who underst ood why the application was needed and how to apply the technology within the workplace. Summary of the Bowling Green Case Bowling Greens adoption of OSS appeared to be driven by the best of breed philosophy. This approach seems to be n eeded to gain organizational support to consolidate IT resources around the city. Ho wever it affects OSS adoption by focusing both environmental and organi zational factors on vendors a nd their technologies as opposed to alternative software options like lesser known pr oprietary or OSS vendors. Additionally because Bowling Green uses best of breed technologies, this approach appears to create un intended organizational turnover This reinforces the need
209 for vendor technologies as employees appear to be caught in a cy cle where experienced IT department members are training new hire s and work accumulates. The urgency this creates to complete IT projects seems to reinforce the departments focus on vendor technologies, causing the department to overl ook or reject technol ogies that do not fit with the best of breed philosophy.
210 Chapter 5. Discussion This chapter discusses the results of the study. It is organized as follows; the first section discusses each of th e guiding questions. Within this section the theoretical operation of the constructs or factors ar e discussed, including th e effect of these constructs on adoption stages and adopti on levels. The second section is a general discussion of the theories that the study is based upon. This discusses how the theories appeared to work in the case studies. It is followed by the third major section, a general discussion of municipal gove rnment IT departments and OSS adoption within the municipal government context. Fourth the st udys limitations are covered while the last section projects potentia l future research. Discussion of Guiding Questions To generate the study model, this research synthesized eight existing organizational adoption theories. The relations hips between the model constructs formed the basis for six guiding questions for this study which are summarized in Table 33.
211 Table 33. Study Guiding Questions Study Guiding Questions Finding G1a Do environmental adoption constructs operate in accordance to organizational adoption theory during OSS adoption, facilitating adoption? Mixed support G1b Do organizational constructs operate in accordance to organizational adoption theory during OSS adoption? Mixed support G1c Do innovation constructs operate in accordance to organizational adoption theory? Accept G1d Is the adoption of open source so ftware is best explained by organizational characteristics as opposed to environmental factors or innovation characteristics? Mixed support G2a Do OSS Adoption stages of adoption, routinization and infusion disrupt an organizations IT functions in terms of implementation, operation, and support? Reject G2B Does open source adoption level moderate the disruptive impact of OSS on the organizational IT function, with lower levels of adoption havin g less disruptive effects? Mixed support Like many other qualitative studies this one found that relationships between constructs are seldom simple and often a ppear to interact. Consequently many guiding questions, G1a, G1b, G1d and G2B, had mixe d support. Answers to these questions had evidence that could either facilitate or hi nder the fundamental question. Several accepted organizational constructs had instances that contradicted theory, but also had instances that supported existing theory. For example answers to question G1a, wh ich focused on environmental constructs of external communication, vendors, peer adoption and technical communities, had instances of some constructs that both fit w ith and contradicted existing theory. G1b, the guiding question that focused on organizational constructs had similar instances of some constructs that both fit and contradicted existing theory.
212 Additionally G1d had mixed s upport. While organizations were the focus of this study, it is difficult to definitively claim that organizational characteristics were of the most importance in determining the adoption of OSS. In many instances environmental factors and innovation attributes appeared to be as critical as, if not more important than, organizational factors for OSS adoption. Guiding question G2B, open source adop tion level moderates the disruptive impact of OSS on the organizational IT f unction also has mixed support. Because no disruptions were observed due to OSS and because only two adoption levels were observed in the case studies, the eviden ce provides mixed support for this guiding question. Nearly all OSS implementations were at an as-is level. But OSS implementations may not cause any disruptions within IT departments as one of the case sites had adopted OSS at a design level, a level thought to facilitate OSS disruptions. Therefore this guiding question, like G1 a, G1b, and G1d has mixed support. Guiding question G1c was the only ques tion that was fully supported. Innovation constructs were the only theoretical constructs to consistently operate in accordance with existing theory. Meanwhile, because disruptive effects were not observed at any of the participating sites, guiding question G2a app ears to have sufficient evidence to be answered negatively, it appears that at the time of this study the different levels of adoption do not disrupt orga nizational processes. Perhaps this highlights the temporal nature of organizational disruption as none of the organizations was in the process of adopting these technologies. Or perhaps the adoption of OSS by municipal IT departments simply does not cause disruptions. As IT
213 departments they may be able to handle addi tional complexity or knowledge needed and the activities that might disrupt municipa l end users do not disrupt IT department members. Regardless, evidence from the case studies appears sufficient to answer G2a in the negative, that an OSS adoption stage greater than implementation will not cause disruptions to an organizations IT func tion. The remaining sections more closely examine each guiding question, discussing th e individual factors that comprise the constructs, teasing ou t the richness of th e case study method. Theoretical Operation of Environmental Factors G1a Do environmental adoption constructs operate in accordance to organizational adoption theory during OSS adoption, facilitating adoption? Existing theory proposed that environmen tal factors of external communication, vendors, peer adoption and technical commun ities would facilitate the organizational adoption of OSS. While there were many in stances of environmental factors conforming to theory, facilitating the a doption of OSS; environmental factors, primarily vendors and associated external communication and t echnical communities, were also observed hindering OSS adoption. This provides mixed evidence for G1a as many instances of environmental factors had positive influences on OSS adoption as well as negative effects on OSS adoption. While the theories of network external ities and technical knowledge and knowhow identify technology sponsors, like vendors as active proponents for the adoption of their technologies, these theories do not pr edict that technology sponsors would actively hinder the adoption of rival innovations. Interv iews from the case studies highlight how
214 vendors and vendor related technical communi ties highlighted the short-comings and risks of OSS to promote their own technologies. This is not surprising as marketing is a common business practice. But, what was surprising was the ability of vendors to al ter organizational beliefs. For example one security administrator was led to believe th at OSS technologies were not approved for use in GLBA (Gramm-Leach-Bliley Financial Services Modernization Act of 1999) environments. This is in star k contrast to the reality of OSS use in GLBA compliance as there are several OSS vendors who specialize in software and services to facilitate GLBA compliance. Another factor, possibly more important than vendor activities, which appeared to interact with vendor activit ies and environmental factors, was an organizations philosophy or approach to IT. If a municipa l IT department committed to a single vendor to provide an IT area function then environmental constructs, primarily external communication and technical communities, appeared to hinder OSS adoption as the IT areas focused on vendor technologies to accomp lish their work tasks. This appeared to facilitate network effects, encouraging the use of proprietary software over the use of OSS. Bowling Greens best of breed philo sophy most succinctly highlights this phenomenon. The external communication and interaction with technical communities of this department almost exclusively focu sed on proprietary vendor technologies. OSS adoption occurred only where OSS aligne d with the best of breed philosophy.
215 Municipal IT departments or IT areas th at encouraged a broader approach to implementing IT area functions appeared to have external communication and technical communities that facilitated the adoption of OSS. For example Columbuss networking IT area did not commit to any single IT vendor Rather they experimented with multiple networking technologies and adopted OSS t echnologies that alig ned with their IT philosophy of IT Success. Roswell also exemplified how exte rnal communication and technical communities could be used to facilitate OSS adoption. IT department members at Roswell were encouraged to findand pl ay withnew technologies . This philosophy facilitated Roswells IT department to adopt several OSS applications where the technologies aligned with organizational needs. Therefore this guiding question has mixe d support. Some environmental factors facilitated organizational adop tion of OSS while others e ither actively or passively hindered the adoption of this technology. Active hindrance by vendors seemed to occur through misinformation or highlighting the poten tially negative aspects of OSS. However information supplied by vendors only seemed to be evidence for organizations to implement philosophies or beliefs about soft ware. If organizations sought to integrate proprietary vendor technologi es then they focused on proprietary vendors. Adoption Stages Influenced by Environmental Factors As a group of factors within the organi zational adoption model, environmental factors appear to play a major role in one stage, awareness and influence another adoption stage, implementation. Environm ental factors influe nce organizational
216 awareness through communication and work task s. As they do not exist in a vacuum, organizations contact and are c ontacted by others, such as peers, vendors, or technical communities. This communication, as theorized by several organizational adoption theories, appears to generate organizationa l awareness of new technologies. Without environmental factors it is doubtful that or ganizations would become aware of a new technology like OSS. However vendors appear to influence the communication function of these environmental factors. By supplying comm unication channels vendors can market their technologies and create network effects to hi nder the adoption of OSS. Additionally the implementation stage of adoption appears to be heavily reliant upon vendors because municipal IT departments re ly upon vendors to supply and support most of their IT. Consequently the innovation char acteristics of these supplied t echnologies, especially the compatibility, influence which vendor standard s are adopted as information technologies interact and the integration of IT appear to be critical for IT departments. These factors are more fully discussed in the following sections that examine the individual environmental factors. External communication One of the more influential environmenta l factors in the or ganizational adoption of innovations appears to be external comm unication. This factor summarizes how often individuals within an organization cont act and are contacted by people or other organizations outside of their own. The influence of external communication on innovation adoption seems to be dependent upon two different factors, what channels an
217 organization decides to use to gather informa tion and the perspective of that channel on the innovation in question. If an organization chooses to interact with a communication channel that strongly endorses the adoption of an innovation, like OS S, then external communication appears to become a facilitating factor. However, the reverse is also true; if an organization chooses to use a channel that hinders OSS adoption, such as vendors promoting proprietary software, then external co mmunication seems to hinder OSS adoption. As a construct, external communication is generally accepted as being an overall positive influence on an innovations adopti on. This study confirms that external communication often operates in this manner. When a posi tive communication channel is contacted it typically facilita tes the adoption of an innovation But prior theory identifies network effects which appear to influen ce organizational communication channels, in turn effecting organizational perspective. For example if an organization chooses to contact a communication channe l that has a negative persp ective about an innovation, external communication seems to become a hindering factor, not a facilitating one. Because this construct appears to opera te in both a facilitating and hindering manner in the adoption of OSS, external communication seems to have a much more complex role in the adoption of organiza tional innovations than previously thought. Further investigation into this construct ma y be needed as the originating source of external communication, i.e. an organizatio n initiates communication or an external organization starts communicati on, appears to affect the influence of information.
218 Additionally how organizati ons choose communication channels and the influence different channels have on organi zational adoption appears to vary. External communication also had an effect on the adoption stage of OSS. Because these constructs were used for information gathering purposes, it should come as no surprise that the awareness and interest adoption stages were influenced by environmental factors. What was surprising wa s that environmental factors appeared to influence latter stages of O SS adoption, primarily adoption a nd routinization, as technical communities surrounding OSS became a part of the IT support processes. These technical resources were used to train IT personnel and update or support OSS. The integration of technical communities into organizational activities appears to highlight organizational reliance or outsourcing of IT activities. The only stage that did not appear to be influenced by external communication was infu sion as an organizati on needed to identify organizational specific activities for the technologies to achieve this stage of adoption. Table 34. External Communication Site Finding Influence on OSS Adoption Adoption Stage Influenced Roswell Personnel contacted a variety of sources about technologies in general. This facilitated the adoption of both OSS and proprietary applications. High (Adoption) Awareness, interest, adoption, and routinization. Columbus Columbus focused on contact ing existing vendors of proprietary technology, hindering the adoption of OSS Moderate (Rejection) Awareness, interest, adoption and routinization Decatur Rejection: more experienced IT personnel focused on established relationships with existing vendors, hindering OSS adoption Adoption: new hires contacted both traditional and OSS vendors about IT produc ts, facilitating adoption Moderate (Adoption and Rejection) Awareness, interest, adoption and routinization Jackson Jackson focused on existing vendor offerings, hindering the adoption of OSS. Moderate (Rejection) Awareness, interest, adoption and routinization Bowling Green Bowling Greens Best of Breed IT philosophy appeared to limit IT adoption to industry Best solutions. This facilitated OSS adoption in one area while encouraging rejection of OSS in the other four areas. Moderate (Rejection) Awareness, interest, adoption and routinization
219 Peer adoption This study reveals that or ganizational peers can be a communication channel that organizations can use to gather informa tion about an innovati on like OSS. As a communication channel peers appear to pr ovide information about how a technology operates within the municipal context, or within city operations. When used, peer adoption seems to be a valuable perspective as the context of a peer more closely aligns with a potentially adopting organization than an organization outside of the organization. However, like vendors, peer adoption seems capable of taking on a spectrum of roles, from facilitating to hindering organiza tional innovation adoption depending on the perspective or percep tion of OSS of an or ganizational peer. Like other forms of external communicat ion the perspective of the peer on the innovation appears to determine the faci litating or hindering effects of this communication channel. For example Columbus was aware of another municipality using OSS to lower costs. As Columbuss IT department was also interested in cutting costs, this information appeared to facilitate OSS adoption. Meanwhile Jackson did not communicate with their peers about OSS tech nologies. Rather the IT department in Jackson focused on discussing proprietary tech nologies with their peers, hindering OSS adoption. Peer adoption in the municipal context appears to take on a third form of influence, that of non-influe nce. Many municipalities view themselves as being unique. These municipal IT departments seemed to ignoring the innovations adopted by their peers. The influence that peer adoption has on an organizations adoption of an
220 innovation like OSS seems to increase when that information aligns with an organizational value or goal. Two of the m unicipalities in this study had implemented OSS applications based upon peer usage when th eir goals aligned with the characteristics of the technology. The actions of these two departments seem to indicate that the influence of peer adoption, as a construct in the organizationa l adoption of innovations, may be dependent upon organizational goals, philosophy or values. This seems to be the source for the variation in influence that peer adopti on had among the cases, ranging from a facilitating, to neutral, to hindering factor. Table 35. Peer Adoption Site Finding Influence on OSS Adoption Adoption Stage Influenced Roswell Roswell personnel were largely unaware of other municipalitys use of OSS. This appeared to neither facilitate nor hinder the adoption of OSS. Neutral None Columbus Columbus appears to have adopted one OSS application parallel to existing proprieta ry software because of the cost savings another muni cipality has experienced. Moderate (Adoption) Awareness and Interest Decatur Decatur IT personnel appeared to be largely unaware of OSS implementations at other municipalities, neither facilitating nor hindering OSS adoption. Neutral None Jackson Jackson IT personnel appeared to consult with their peers about proprietary information systems as opposed to OSS. This seemed to hinder OSS adoption. Moderate (Rejection) Awareness and Interest Bowling Green Bowling Greens awareness of another municipalitys use of OSS led to an experimental implementation of an OSS that was not recognized as being Best of Breed. This innovation was experimented with but not deployed for use. Low (Adoption) Awareness and Interest Vendor Relations Vendor relations appear to be a critical en vironmental factor in the organizational adoption of innovations. Like peer adoption, vendors provid e an external communication channel for organizations to learn about i nnovations like OSS. Ho wever, unlike peer adoption, vendors do not appear to be an optional source of information. As IT
221 departments rely on vendors to provide hard ware and software to implement municipal information systems, vendors are a necess ity. Consequently the information IT departments receive from ve ndors focuses on the capabili ties of their technology, focusing communication on the be nefits of organizational a doption of their technology. As with many marketing activ ities this often downplays comp eting innovations like OSS. Like peers, vendors appear able to f acilitate or hinder OSS adoption. Vendor facilitation of OSS seems to be predicted by network externality theory as OSS vendors supported their technologies. However vendors that offered proprietary technologies hindered OSS adoption in favor of their own pr oducts and services. This hindering effect was not predicted by network externality theo ry, but should come as no surprise as marketing activities that highlight the w eaknesses of competitor products are common. The strength of vendor re lations as a communication channel on organizational adoption of innovations seemed to vary base d upon organizational goals, philosophies or values. Communication strength appeared to be linked to th e vendors relationship with the municipality which seemed to fall into one of three categories, those vendors currently employed by the munici pality, vendors offering tec hnical standards similar to those currently employed by the municipality and vendors who offer technical standards radically different from those curr ently employed by the municipality. Of these three different vendor groups th e relationships between municipalities and the vendors whom they have existing rela tionships with, i.e. vendors who supply the current technologies used by th e municipal IT department, s eemed to be the strongest. The strength of these relationships is unclear as it was not the focus of this study. But
222 several factors in the research model appear to be linked to the strength of existing vendors. Perhaps existing vendors were more influential as their technologies were perceived to seamlessly integrate, or were mo re compatible, with the existing IT function of an organization. Or maybe existing vendors established stronger in terpersonal relations with the management of a municipality. A third reason may stem from the technical knowledge and know-how of a mu nicipal department that al ready knows how to use a vendors products. Regardless of the underl ying reason, the case st udies highlight how important existing vendors are to municipal IT departments. Meanwhile the influence of vendors who offer similar technical standards or vendors who offer radically different technologi es was unclear. While it seems that these two groups of vendors appear to have di fferent effects on or ganizational innovation adoption it is unclear as to how organizati ons perceive these comm unication channels to operate. The information gathered in this study does not appear sufficient to characterize these relationships. Adoption stages influenced by vendors ranged from the awareness stage to the routinization stage. While most proprietary vendors provided negative information about OSS products, OSS vendors became instrumental in offering services for organizations. Roswell used vendor training and support to mo re effectively utilize their OSS adoption. Most IT departments focused on proprietary vendors who provided negative information about OSS technologies, hindering the adoption of OSS. Table 36 highlights the impact of IT vendor relations on adoption and adoption stage.
223 Table 36. Vendor Relations Site Finding Influence on OSS Adoption Adoption Stages Influenced Roswell Roswells vendors, both proprietary and open source, facilitated technology adoption when the functionality of the technologies aligned with organizational needs. Because Roswells thin-client thick-server architecture facilitated the use of OSS, many OSS vendors appeared to offer best-fit solutions, leading to OSS adoption. Moderate (Adoption) Awareness, interest, adoption and routinization. Columbus Columbuss use of vendor technologies focused departmental technology s ourcing on vendors, creating switching costs in terms of licensing, processes and technical knowledge, hindering OSS adoption High (Rejection) Awareness and interest Decatur Decatur vendors focused on proprietary technology offerings, biasing Decatur IT solutions towards these vendor offerings. This seems to have limited many OSS implementations to new proj ects or technologies that seamlessly integrated with existing vendor standards. High (Rejection) Awareness and interest Jackson IT area use of vendor technol ogies appeared to focus on vendor offerings. This seems to have focused IT areas on the use of vendor technologies. High (Rejection) Awareness and interest Bowling Green Appeared to hinder adoption of OSS as strong vendor relations seemed to focus the department on vendor technologies and standards. High (Rejection) Awareness and interest Technical Communities This study identified technical commun ities as a third communication channel that organizations can contact for information about new in novations like OSS. Similar to peers and vendors, technical communities are an environmental factor that many theories recognize as positively impacting the organizational adoption of innovations. Technical communities are theorized to provide organiza tions with knowledge about the capabilities or characteristics of an innovation, increa sing the awareness and interest in a new innovation. By influencing these adopti on stages, communication with technical communication is thought to promote an innovations adoption. The case studies reveal that municipal IT departments used seve ral different types of technical communities in the theoretically predicted manner. Most individuals at each case site said that they used a variety of websites and other technical groups such as the
224 CACM, to keep their fingers on the pulse of industry. Individu als describing such relationships appeared to be keeping with theory, and these technical communities seem to have the positive impact pr edicted by theories (i.e. incr easing technical knowledge and know-how as well as exposing municipal IT workers to new innovations) concerning organizational adoption of innovations. However paramount to municipal IT depa rtments are technical communities that are routinely accessed to complete work ta sks. Websites linked to work tasks are commonly associated with a specific ve ndor or vendor technology. These websites appear to act as extensions of vendors, and act as network externalities for organizations and vendors. Because technical communities linked to work tasks are critical for completing the services IT departments prov ide, vendor driven technical communities are capable of hindering organizational adoption of innovations like OSS. This indicates that technical communities, like other communicati on channels, appear to have a range of effects on organizational adoption of innovations from facilitation to a neutral effect to hindering the adoption of a sp ecific innovation like OSS. Therefore the orientation or origin or focus of technical communities appear to moderate how technical communities behave during the organizational adoption process. Technical community orientat ion or origin or focus se em to be grouped into two categories, vendor supported and non-ve ndor supported techni cal communities. As stated above, vendor supported tech nical communities appear to act as extensions of a vendor. These technical comm unities act as an outlet for vendor goods and services as well as information about the use and support of vendor and competitor
225 products. Because these sites supply ma ny different types of information, from advertisements to technical support and training, they a ppear to influence several different adoption stages in the innovation adoption process. These stages include awareness, interest, adoption and routinizat ion as information details not only innovation characteristics, but also innovation operati ons. Information provided by vendor sponsored websites can be generalized in favor of the vendor. So if the vendor sponsored website is an OSS provider it should facilitate the adoption of OSS, othe rwise vendors tend to promote their proprie tary technologies. Non-vendor related technical communities appear to se rve a similar function in the organizational adoption of innovations. These communities also provide information about potential new technologies and inform ation about work task solutions and innovation maintenance. However these sites do not appear to have a motivation to lockin an organization to a particul ar product or technical standard. It is difficult to assess the influence theses communities have in the or ganizational adoption of innovations as they range in influence or prestige, some sites are sponsored by experts or provide technical code while others reflect opinions or simply serve as online advertisements. Regardless of whether tied to vendors or not, techni cal communities are an important communication channel that influences many adoption st ages. Because these communities provide information about new products or services they have the potential to increase awareness and interest in new technologies. But these communities also provide information about the operation and support of new technologies, facilitating the adoption and routinization
226 of a technology. Table 37 highlights the effect that technical communities had at the case sites, and how these communities could both facilitate and hinder OSS adoption. Table 37. Technical Communities Site Finding Influence on OSS Adoption Adoption Stages Influenced Roswell Facilitated adoption as technical communities not only increased awareness and interest of OSS, but also participated in software development High (Adoption) Awareness, interest, adoption and routinization Columbus Use of technical communities appeared to focus on work tasks associated with vendor technologies. This appeared to hinder awareness and interest in OSS. Moderate (Rejection) Awareness and interest Decatur Adoption: Like external communi cation, newer hires appeared to focus on technical communities that would accomplish a task or provide a service, regardless of its fundamental source. This had the effect of increasing OSS adoption by facilitating awareness and interest in the technology. Rejection : Older employees appeared to focus on vendor communities to solve establis hed work routines. This served to limit their exte rnal communication to vendor related sites. Moderate (Rejection and Adoption) Awareness, interest, adoption and routinization Jackson Focus on vendor resources to support vendor technologies when completing work tasks. Moderate (Rejection and Adoption) Awareness, interest, adoption and routinization Bowling Green Seemed to hinder OSS adoption as the department interacted with technical communities that focused on proprietary technologies. This appeared to reinforce the use of vendor standards as opposed to creating awareness and interest in other technologies like OSS. Moderate (Rejection) Awareness and interest Theoretical Operation of Organizational Factors G1b Do organizational constructs operate in accordance to organizational adoption theory during OSS adoption? This question, like the other questions form ed from the model relationships, seeks to examine if organizational factors perform consistently with theory in OSS adoption. Like G1a, G1b also has mixed support. Many of the organizational factors were observed to operate as theory predicts, for exampl e higher levels of administrative intensity increased the formalization and centralizati on of technology adoption decisions, resulting
227 in a decreased adoption of OSS. But there were also instances in the case studies when many of these constructs acted contrary to theory. Administrative intensity was also observed to increase environmental scanning ac tivities in some IT department areas, an activity not accounted for by ex isting theory. Other organi zational constructs also exhibited these mixed behaviors. Adoption Stages Influenced by Organizational Factors As a group, organizational constructs ap pear to influence every stage in the adoption process. However not every organizatio nal factor seems to effect every adoption stage. The factors appear to be divided into three main groups, those constructs needed to become not only aware of an innovation, but interested in how the innovation could affect IT department operati ons. A second group of factors appears to be involved in implementing the innovation in the organizati on while a third group of factors seems to facilitate a transition from adoption to routin ization or infusion. Interestingly several of the factors appear to overlap these thre e areas, primarily technical knowledge and administrative intensity. The effects indi vidual organizational factors have on organizational adoption examined by this study are more fully discussed in the following sections. Internal Communication Although it is an organizationa l factor, the case studies indicate that internal communication appears to be a fourth communi cation channel available to organizations. Unlike peers, vendors or technical comm unities, internal communication is a communication channel that focuses on the or ganizations specific context and needs.
228 Where organizations have high levels of internal communication, municipal IT department members discuss ideas like OSS a doption in the context of the existing IT infrastructure. This includes insight as to how changes could benefit or hinder departmental efforts by discus sing costs in terms of learni ng and resource consumption. Like other communication channels, intern al communication appeared to have a range of adoption effects, from positive to neutral to negative, for organizations in the adoption process. Internal co mmunication appeared capable of working as a facilitating factor in OSS adoption when more organizatio nal members were involved in discussing OSS adoption. Larger discussion groups appeared to promote in-depth discussions of the technology that seemed to access more comm unication channels, i.e. peers, vendors and technical communities, and account for more organizational roles. Facilitation of OSS adoption appeared to occur when a critical mass of organizational members decided that adopting OSS would benefit the organizatio n along some organiza tional axis, i.e. innovation cost, maintenance, functionality This factor also seemed capable of hindering OSS adoption when a group of individuals decided to reject the technology. Motivations for rejec ting the technology appeared to vary. Some individuals, especi ally those at Bowli ng Green, cited strict enforcement of organizational technology standa rds. Other individuals seemed hesitant to learn new technologies or interf ere with existing work processe s. Still others appeared to have genuine concerns about the capabilities about OSS. Regardless of the motivation, internal communication appeared to work as a hindering factor when a critical mass of organizational members decide d to reject the technology.
229 As a construct, internal communication seemed to follow theory. It appeared to facilitate consensus within the organiza tion towards an innovation. However this consensus could be positive or negative ba sed upon a variety of organizational and individual motivations. Additionally internal communication appear s to be one of a handful of adoption factors that seemed to influence multiple adoption levels. Internal communication appeared to be an essentia l activity in moving from one adoption stage, such as awareness, to the next, such as interest. And this factor did not seem to lessen in importance as organizational adoption levels increased as internal communication appeared critical for work processes needed to advance adoption stages beyond adoption. Table 38 highlights how internal communi cation operated at the case sites.
230 Table 38. Internal Communication Site Finding Influence on OSS Adoption Adoption Stages Influenced Roswell Roswell had high levels of internal communication that appeared to build consensus around new technologies. High (Adoption) Awareness, interest, adoption, routinization and infusion Columbus When administrative intensity was low, internal communication appeared to operate as theorized, facilitate adoption by building consensus around OSS. High levels of administrative intensity appeared to reduce the influence of internal communication as decisions about technology adoption was limited to individuals with specific beliefs. Low (Adoption) Awareness, interest, adoption and routinization Decatur Adoption: New hires that formed project teams had moderately high levels of communication within their teams. This served to build consensus around OSS technologies, facilitating OSS adoption. Rejection: Traditional IT areas with more established personnel seemed to have in ternal communication that focused on work tasks, reinforcing existing technology standards, hindering OSS adoption. Moderate (Adoption and rejection) Awareness, interest and adoption Jackson Internal communication appeared to have three different levels that had little interaction with one another: operations personnel and managers within an IT area, IT department areas within the IT department and the IT department within the greater municipality. These levels of communication seemed to form barriers around technology adoption decisions, hindering consensus or awareness of new innovations. Moderate (Rejection) Awareness and interest Bowling Green Hindered adoption as intern al communication focused on completing work tasks, not discussing new technologies. Moderate (rejection) Awareness and interest Environmental Scanning The construct of environmental scanni ng appears to summarize organizational activities surrounding the active pursuit of information gathering. This characterizes environmental scanning as an internal soci al process that interacts with external communication channels. Because environmen tal scanning, like external communication, bridges the gap between an organization and th e environment, environmental scanning is linked to many other model factors, prim arily communication ch annels like peers,
231 vendors and technical communities, but also admi nistrative intensity as this dictates who should be actively scanning for new technologies. Communications channels heavily influe nce environmental sc anning as they determine what information is passed on to organizational decision makers about a new innovation. This includes environmental f actors, like vendors, peers and technical communities, as well as inte rnal channels formed through internal communication. Administrative intensity is another model factor that influences environmental scanning. This factor determines the centralization and formalization of information gathering activities. As centralization and fo rmalization increase, or as administrative intensity increases, environmental scanning seems to center on meeting these processes as opposed to information gathering. This ap pears to change the focus of information gathering activities from a fl uid process that can consider any communication channels, to a more mechanistic process, one that focuses on meeting specific goals or requirements. This appears to be a limiting factor on innovation as organizations that can quantify what they are looking for seem to pur sue a routine or incremental innovation as opposed to a radical or disruptive one. A third factor appears to affect organi zations environmental scanning, but it is neither a model factor nor an organizatio nal characteristic: individual differences. Because individuals perform environmental scanning their own motivations for scanning the environment from new technologies appe ars to influence what information they gather for their organization. Organizational role, the hier archical level within the organization and departmental affiliation ap peared to affect individual technology
232 searches. Individual differences in environmen tal scanning appear to moderate the effects of administrative intensity. Even though se veral individuals inte rviewed in the case studies were not required to scan the environment for new technologies, their individual habits or curiosity drove them to have highe r levels of environmental scanning than their peers. As a construct, environmental scanning appears to follow existing theory as it seems to be positively linked to organizationa l adoption stages, especially awareness and interest. However, environmental scanning al one does not appear to guarantee that an organization will move through adoption stages when looking for new technologies. Additionally environmental scanning seems to be dependent on a number of organizational and individual factors that, in turn, may be affected by organizational goals or philosophies.
233 Table 39. Environmental Scanning Site Finding Influence on OSS Adoption Adoption Stages Influenced Roswell Roswell had high levels of environmental sc anning. These activities appeared to be part of routine work processes as opposed to slack activities. High (Adoption) Awareness, interest and implementation Columbus As theorized environmental scanning appeared to facilitate adoption by increasing the awareness of OSS. However environmental scanning differed by employee role and administrative intensity. Those employees with lower administrative intensity and a higher organizational role had higher levels of environmental scanning. Higher levels of administrative intensity and operations roles had lower levels of environmental scanning. High (Adoption) Awareness and interest Decatur Project teams had mode rately high levels of environmental scanning as they looked for lowe r cost alternatives to city technologies. This appeared to increase awareness of OSS within these teams, increasing the likelihood of adoption. Meanwhile IT areas seemed to have limited environmental scanning as they focused on work tasks. Moderate (Adoption) Awareness and interest Jackson Environmental scanning appeared to heavily rely on individual initiative and work load. Within this context, two area managers, the security and networking leads, displayed high levels of environmental scanning that appeared to contribute to their adoption of OSS. High (Adoption) Awareness and interest Bowling Green Hindered adoption as environm ental scanning focused on vendor technologies that met best of breed standards. High (rejection) Awareness and interest Administrative Intensity Administrative intensity, or the degree to which innovation adoption decisions are consolidated and formalized, appears to be the key organizationa l construct as it influences several model factors. This factor appears to affect se veral model constructs, primarily environmental scanning, internal communication, external communication, peer adoption, vendor relations, and technical comm unities. Administrative intensity appears to affect so many model constructs because it is linked to assigning duties to IT departmental members. This can influen ce which organizational members search for information about new innovations as well as what tasks organizational members are held accountable for.
234 Higher levels of administrative intensity s eem to reduce the numb er of individuals involved in information gathering activities. Centralization or th e consolidation of information gathering activitie s to fewer individuals and fo rmalization, or restricting information gathering activities to specifi c areas or features, limits organizational information gathering as it puts constraints on wh at information is thought to be pertinent in a technology search. Higher levels of administrative intensity we re also present in organizations that were more likely to dictate technology sta ndards to their IT ar eas, often hindering OSS adoption. Perhaps high levels of administ rative intensity hinder OSS adoption because consolidation of adoption decisions to ar ea or department managers highlights organizational characteristics, such as technical support or the reputation of the developer, rather than innovation characteri stics, like process operations or technical efficiency. Lower levels of administrative intensit y, or including more sources and having more discussion about technol ogy adoption decisions, seemed to facilitate OSS adoption. Unlike higher levels of administrative intensity, more information channels and individuals discussing OSS app ears to highlight the technical and operational aspects of OSS, and how they fit within the organi zation, often resulting in their adoption. This difference in innovation focus, high le vels of administrativ e intensity appear to focus on organizational characterist ics of innovations while low levels of administrative intensity appear to focus on operational characteristics of innovations, appears to be affected by organizational values or or ganizational philosophy. These
235 values can favor organizational characteristics, such as IT support or the developer of a particular piece of software, or they can favor operational characteristics, such as work processes or technical efficiencies. As a construct administrative intensity appear s to be critical in the early stages of technology adoption. It seems to influen ce which organizational members access communication channels to gather information about potential technologies. In turn, this limitation of information appears to influence the internal communication, or the internal discussion the organization has about the can didate technologies. B ecause it influences what information is discussed about potential innovations, administrative intensity seems to be a highly influential m oderating factor in the early ad option stages. This influence appears to diminish in the la ter adoption stages as administ rative intensity seems to focus on centralizing and formalizing awar eness generating activities. Finally, it is generally accep ted by theory that the centralization and formalization activities will hinder the orga nizational adoption of tech nologies. This effect was observed at four of the five cases. Howeve r, of the four sites where administrative intensity was observed to decrea se the adoption of OSS, two sites had observations where centralization and formalizati on increased the adoption of OSS. Columbus and Decatur both had high levels of administrative inte nsity surrounding innovation search activities but allowed for flexibility in accessing inform ation sources. Additionally one of the five case studies, Roswell, highli ghted how administrative intens ity promoted OSS adoption. These findings appear to indicate that ad ministrative intensity was linked to an organizational characteristic, a goal or objectiv e or philosophy that caused the individuals
236 involved in the technology search to focus on specific types of technologies. This is contrary to theory which predicts that the simple activities of formalization and centralization will lead to re duced adoption of an innovation. Table 40. Administrative Intensity Site Finding Influence on OSS Adoption Adoption Stages Influenced Roswell Administrative intensity appeared to fluctuate based upon the stage in the adoption process. There were high levels of administrative intensity at the requirements gathering and testing phases, but low levels of administrative intensity in idea generation and physical design. Moderate (Adoption) Awareness, interest, adoption, and routinization Columbus Adoption : Low levels of administrative intensity allowed areas with successful track records to make technology decisions that drew from more information sources. Rejection: High levels of administrative intensity, present in areas with less successful track records, consolidated technology adoption decisions within the IT department. These areas had less input into the technologies that they used. High (Adoption and rejection) Awareness, interest, adoption, and routinization Decatur Adoption: Project teams appeared to have lower levels of administrative intensity as th ey discussed and experimented with a wide variety of technolog ies. This appeared to increase adoption. Rejection: Established IT areas appeared to have set IT standards to reinforce task completion. This seemed to hinder OSS adoption as these IT areas focused on existing standards and technologies. Moderate (Adoption and Rejection) Awareness, interest, adoption, and routinization Jackson Low levels of administrative intensity appeared to fragment technology adoption decision making within the city. This allowed municipal departments and IT areas to select technologies as they saw fit. Several of these technologies did not integrate or communicat e with one another. Moderate (Rejection) Awareness and interest Bowling Green Hindered OSS adoption, technol ogy adoption decisions were extremely formal and limited to select individuals within the IT department. This increased the influence of the best of breed philosophy when choosing information technologies. High (rejection) Awareness and interest Technical Knowledge As a construct technical knowledge a ppears to be critical in nearly all organizational adoption stages. Technical knowledge helps organizational members understand how an innovation ma y fit with organizational pr ocesses, increasing the likelihood of interest, it helps organizatio nal members understand how to use an
237 innovation, facilitating adopti on and routinization and te chnical knowledge appears critical for understanding how to appl y an innovation in new and unusual ways, facilitating infusion. Because technical know ledge manifests in adoption stages in different ways it appears pres ent to have many components, and not be a single factor. These components seem to include tech nical knowledge, or the operation of a technology, application knowledge, or understa nding how a technology aligns with or can enhance existing organizational proc esses, and support know ledge, understanding how to maintain and exte nd technologies over time. All three components of t echnical knowledge seem to be intimately related to technical standards, which can facilitate or hinder the adoption of OSS. Individuals who have technical knowledge of the standards used by OSS appear to be able to adopt OSS with relative ease, even if the technology is not a recognized organizational technology. Several individuals were observed who ha d adopted OSS applications to enhance proprietary software used by the organization, often without their peer s or area managers knowledge. Meanwhile technical knowledge of standards not used by OSS seems to be able to hinder OSS adoption. Organizations that focus on non-OSS st andards appear to have related technical knowledge and the learning of OSS sta ndards appears to be a cost as individuals need time and materi als to learn these standards. Organizational technical knowle dge observed in this study appears to differ from existing theory in that technical knowle dge seems to be comprised of multiple components and does not always act as a positive influence on technology adoption. Because technical knowledge seems to focus on specific technology standards there are
238 opportunity costs associated with learning a new technical standard when another is already known. The willingness to absorb op portunity costs appears to vary among individuals and organizations occasionally allowing exis ting technical knowledge to hinder the adoption of a new standard like OSS. Perhaps the different components of technical knowledge have differing effects on organizational adopti on of innovations and explain the variations in how technical knowledge affected the adoption of OSS. Table 41 highlights how technical knowledge was observed in the case sites. Table 41. Technical Knowledge Site Finding Influence on OSS Adoption Adoption Stages Influenced Roswell Roswells adoption of OSS appeared to rely heavily on technical knowledge. Their understanding of open source communities, open source standards and open source software seemed to form the basis of their open source adoption. High (Adoption) Awareness, interest, adoption, routinization and infusion Columbus As theorized, increased technical knowledge helps departmental members evaluate and implement OSS. The department appears to rely on new hires to acquire new sources of technical knowledge as opposed to developing existing employees. High (Adoption) Awareness, interest, adoption, and routinization Decatur Adoption: Project teams displaye d a wide breadth of technical knowledge that appe ared to facilitate the adoption of OSS. Rejection: IT areas appeared to focus on technical knowledge concerning vendor technologies and work routines within these technol ogies. This appeared to reinforce vendor standards, hindering the adoption of OSS. High (Adoption) Moderate (Rejection) Awareness, interest, adoption, and routinization Jackson Technical knowledge appeared to focus on the application of proprietary tec hnologies to IT area tasks. This seemed to decrease the adoption of OSS as departmental members focuse d on technical knowledge that would allow them to complete their tasks. In the instances of OSS adoption the technical knowledge of the individuals adopting the technologies appeared to play a major role in their implementation. These individuals more readily r ecognized how OSS could be applied to benefit their IT areas. High (Adoption) Moderate (Rejection) Awareness, interest, implementation and routinization Bowling Green Hindered OSS adoption as te chnical knowledge focused on using vendor technologies as opposed to the underlying servi ce or problem. Moderate (rejection) Awareness and interest
239 Wealth While many of the model factors showed mixed effects, wealth is the only model factor to consistently operate contrary to theory. Organizations with less wealth or undergoing economic hardships appeared to be more interested in, and more likely to adopt OSS than those organizations with more wealth. Perhaps this is due to the lower end disruptive nature of OSS; the innova tion itself appears lik ely to cut costs. Organizations consistently id entified reduced cost as a relative advantage of OSS. However, this implies that organizations have a priority or goal when adopting innovations that can be affected by their orga nizational context, of which organizational wealth appears to play a major role. Regardless of its cause, or ganizational wealth does not appear to operate as theoretically predicted in the adoption of OSS. Because orga nizations expressed interest in OSS primarily because it reduced organizationa l costs, it appears that the nature of an innovation, such as a lower-end disruptive innov ation, may influence how it is perceived by an organizations current context. Duri ng this study the state of Florida was undergoing a period of economic hardship that increased the appeal of cost cutting innovations like OSS.
240 Table 42. Wealth Site Finding Influence on OSS Adoption Adoption Stages Influenced Roswell Facilitated adoption as th e department sought out technologies that reduced costs associated with IT. High (Adoption) Awareness, interest, adoption, routinization and infusion Columbus Low levels of departmental wealth increased interest in OSS, but lower funding restri cted how the department experimented with OSS. Low (Adoption) Awareness, interest, adoption and routinization Decatur Decaturs wealth appeared instrumental in the adoption of OSS as the department looked for options to reduce costs. Although the depa rtments budget was held constant for two years the department was asked to take on more IT projects, essentially resulting in a net budget cut. In most instances where OSS was adopted it was selected to reduce IT costs. High (Adoption) Awareness, interest, adoption and routinization Jackson Organizational wealth appear ed to be divided by the nature of the department, t hose that generated their own revenues and those that drew from the municipalitys general fund. The IT depart ment drew from the general fund and appeared to have limited resources. These limited resources seemed to focus the department on critical or immediate needs, not allowing the department to plan for longer periods of time. By focusing on solving immediate needs the department appeared to lower interest in new technologies like OSS. Low (Rejection) Awareness and interest Bowling Green Hindered adoption even though departmental budgets are limited and highly monitored Moderate (rejection) Awareness and interest Slack Resources Slack resources did not appear to play a major role in the adoption of OSS. Nearly every individual interviewed at all of the case sites did not report having slack time. Perhaps this was due to a participant belief th at they would be reported as wasting time. But each case site had several positions with in the IT departments that were unfilled at the time of the interv iews. These responsibilities appear ed to be passed out among the remaining IT department members. The m unicipal IT departments at Decatur and Bowling Green had IT project backlogs of over 18 months. As most staffs were short-handed th ey did not have slack time to perform environmental scans or to examine non-rout ine communications channels to increase
241 their awareness of innovations lik e OSS. Rather the lack of sl ack time appeared to have little positive effect on the adoption of OS S adoption. Rather organizational members appeared to dislike th e idea of learning new technologies as they seemed to prefer to focus on existing work tasks. Table 43. Slack Resources Site Finding Influence on OSS Adoption Adoption Stages Influenced Roswell Roswell seemed to have low levels of slack resources. This did not appear to affect search and testing activities as they appeared to be part of routine work activities. Low (Adoption) Awareness and interest Columbus The IT department had few slack resources as it was currently understaffed by three positions. Search es for and experimentation with new technologies did not appear to be dependent upon slack resources. Rather these activities seemed to be tasks given to IT department members. Neutral None Decatur Slack resources appeared to have lit tle impact on technology adoption. Most employees reported no slack time as the department had an 18 month backlog on projects. Rather environmental scanning appeared to be a part of new IT projects. Project teams appeared to actively search for technologies that could redu ce organizational costs while maintaining appropriate levels of quality. Neutral None Jackson The department had few, if any, slack resources. Consequently there were not enough instances of slack resources at Jackson to determine how this characteristic influenced the adoption of OSS in the city. Neutral None Bowling Green Facilitated adoption as employees had begun experimenting with OSS Low (adoption) Awareness and interest Theoretical Operation of Innovation Factors G1c Do innovation constructs operate in accordance to organizational adoption theory? Innovation diffusion theory promotes the idea that organizations adopt innovations for their characteristics. Si mply put, the communication of these characteristics, through diffe rent communication channels, results in the adoption of innovations. The three innovation character istics examined by this study, relative advantage, compatibility and complexity, do indeed appear to be linked, as theory predicts, to organizational a doption of OSS. However simple awareness of an innovation
242 characteristic does not appear to be sufficient to drive orga nizational adoption. Rather it seems to be the alignment between innovati on characteristics and organizational goals that determine the adoption of an innovation like OSS. Adoption Stages Influenced by Innovation Factors The case studies provide strong evidence that innovation charac teristics influence the interest and implementation stages of a doption. Organizations appear more interested in an innovation when one or more innovation ch aracteristics align with an organizational goal. For example with OSS most municipal IT departments were in terested in reducing departmental costs. Therefore the reduced cost of OSS highly appealed to municipal IT departments. However it appeared that the cost advantage of OSS was not sufficient for organizations to adopt the innovation. The ab ility of OSS to integrate with other technologies, or its compatibility, and the tim e it takes to learn how to use the innovation, or an innovations complexity, seemed to m oderate how an innovation is perceived by an organization, which in this study, affected the adoption of OSS. The case studies provide some evidence th at OSS characteristics also influence later adoption stages of routin ization and infusion. These stages of adoption seem to be more process oriented, routinization mean ing that an organiza tion has adopted an innovation to commonly handle or implement one or more processes, while infusion implies that an innovations use has been extended to handle one or more processes that it was not originally intended to perform. Both levels of adoption are dependent upon organizational processes, which in turn seem to be affected by innovation characteristics. Without appropriate characteris tics an innovation could not ha ndle the process or the new
243 tasks that constitute the infusion level of a doption. However, routinization and infusion, like other organizational processes, also a ppear to be dependent upon organizational members. Organizational member buy-in or par ticipation appears to be critical in these latter stages of adoption. The remaining parts of this section discusses each of the three innovation characteristics examin ed by this study, relative a dvantage, compatibility and complexity, and highlights their role in the organizational adoption of OSS. Relative Advantage The relative advantages of OSS applicati ons, or the functions and characteristics that were perceived superior to peer technology app eared to be motivating factors for the adoption of OSS where the relative advantag e aligned with organizational goals or philosophies. Organizations in the case stud ies sought OSS applications that did one or more of three things that aligned with organizational goals; performed existing tasks better, faster or cheaper than the technologies they currently used. Being a better application appeared to m ean one of two different things. First the innovation itself, or the innovati on characteristics, could ha ve functions or associated procedures superior to proprietary equivalent s. These functions were either more easily understood or provided contextual functionali ty that could not be found elsewhere. Innovation characteristics seemed to include the functional nature of OSS including resource consumption, support and technica l improvements. Many OSS applications consumed fewer technical resources, such as processing power or data storage, allowing the organization to more efficiently apply these resources.
244 The second form that relative advant age took related to the organizational characteristics of the innovation. This focused on the organizational costs associated with adopting and using an OSS. OSS price and related services, including customization, support and training, appeared to be the focus of organizational characteristics regarding OSS. The OSS organizational characteristic th at most IT departments were most concerned about was the cost of OSS. Lowe r IT costs appealed to local governments during the time of this study as all the pa rticipating local gove rnments were undergoing budget reductions. The ability to substitute OSS, a lower cost technology, for a higher costing proprietary technology aligned with organizational needs. Substitution of OSS for proprietary technologies appeared to drive the adoption stages of awareness, interest and adoption. However cost reduction did not appear to drive adoption stages of routinization and infusion. These stages appeared to rely upon the surrounding OSS communities as these organizations enabled customizations and new applications of OSS technologies. For example Roswell was able to get cu stomizations implemented as standard functionality for an OSS th rough interaction with the community. Additionally Roswell was able to use bounties, or the practice of getting members of an OSS community to program specific functionality for an applicat ion, to extend or enhance existing programs. These organizational characteristics of OSS a ppeared to drive the adoption stage of the OSS, moving from adoption to routinization, as the technology beca me standard within the organization, to infusion, as new uses for the technology were discovered.
245 Table 44. Relative Advantage Site Finding Influence on OSS Adoption Adoption Stages Influenced Roswell Perceived relative advantages in security, licensing, maintenance, and resource consumption facilitated adoption. High (Adoption) Interest, adoption, routinization and infusion Columbus Columbus personnel perceived one major relative advantage of OSS, the reduced cost of the innovation. High (Adoption) Interest and adoption Decatur Decatur personnel perceived one major relative advantage of OSS, the reduced cost of the innovation. However, other re lative advantages, such as circumventing technology purchasing and high quality were perceived by some members. High (Adoption) Interest and adoption Jackson Relative advantage appeared to depend on IT context. Security and ne tworking applications seemed to have a higher fit than other IT applications. Moderate (Adoption) Interest and adoption Bowling Green Bowling Green personnel perceived the relative advantage of OSS in the security area as being the best tools to use in this area. High (Adoption) Interest and adoption Compatibility While the costs of OSS, or the relative advantage of purchasi ng OSS, appeared to drive interest in the technology, the ability of OSS to integrate with an organizations existing technologies, or the compatibility of OSS, appeared critical for adoption. Compatibility was a critical construct as it appeared to operationalize in two different forms: technical and procedural compatibilit y. Both types of compatibility appeared to influence adoption stages of interest and adoption. The technical compatibility of OSS a ppears to describe how the innovation integrates or interfaces with other tec hnologies. For example how two computer programs communicate or how software co mmunicates with a piece of hardware. Meanwhile operational compatibility focuses on the operation and use of the technology. Does the technology seamlessly integrate with existing processe s; utilize current technology standards and skills?
246 As a construct affecting organizational a doption stages, compa tibility seemed to mainly affect interest and a doption. These two stages appeared tightly coupled in regards to compatibility as municipal IT department s did not adopt OSS that caused disruptions to their operations. Organizational interest was spiked when an OSS application could work with an organizations exis ting technologies and procedures. Adoption was more likely where compatib ility with existing technologies was high and a relative advantage of the technology aligned with an orga nizational goal. This circumstance, reliance upon a relative advant age of the technology, appeared to make compatibility less important than relative advantage. But because no organizational IT department had adopted an OSS solely on a relative advantage, the priority for organizations between the two constructs is difficult to understand and may be the focus for future research. Table 45 highlights how compatibility was observed to influence adoption at the case sites. Table 45. Compatibility Site Finding Influence on OSS Adoption Adoption Stages Influenced Roswell Integration with other OSS applications facilitated adoption. High level activities were similar with proprietary equivalents, but actual commands and execution were substa ntially different. High (Adoption) Interest and adoption Columbus OSS adopted at Columbus s eamlessly integrated with other technologies. High (Adoption) Interest and adoption Decatur OSS adopted at Decatur seamlessly integrated with other technologies, no modifications or customizations were needed for the software. Moderate (Adoption) Interest and adoption Jackson Technical compatibility was essential for the OSS adopted by Jacksons Security and Networking areas. However compatibility appeared to extend to organizational functions such as support and training. High (Adoption) Interest and adoption Bowling Green OSS adopted by Bowling Greens security area seamlessly integrated with other technologies used by the area. High (Adoption) Interest and adoption
247 Complexity OSS complexity also influenced the adoption of the innovation. The construct operated according to theory, hi ndering the adoption of OSS. Li ke relative advantage and compatibility, OSS complexity appeared to be multidimensional, having two levels or dimensions: one focusing on the innovation its elf and another centering on organizational aspects of the innovation. These two dimensions of complexity appeared to primarily affect early adoption stages interest and adoption. The interviews revealed that complexity related to the innovation focused on how individuals used the technol ogy. This involved understandi ng technical standards and functions needed to operate the innovation. Mo st IT department personnel did not believe that OSS was complex, it was just perceived to be a different technical standard. IT personnel did believe that O SS would be complex to thos e unfamiliar with similar technologies and disrupt business proce sses outside of the IT department. Meanwhile the organizational aspects of OSS complexity appeared to be more daunting to municipal IT depa rtments. This focus on trai ning, support and third party assistance was of primary concern to muni cipal IT department members. A common belief was that OSS changed the operation or pr ocesses associated with routinely used IT. Because IT department personnel believed that OSS alters the suppl y and support of the technology, shifting from a business organi zation to a community of developers. Common among IT departments was concern that such a standard shift or change would cause a major backlash, disrupting IT opera tions. Not only did IT department personnel believe that support would be inconsistent, they were con cerned that OSS adoption would
248 strain interpersonal relationshi ps, create extra or unwanted work, and increase overall illwill towards the IT department. However where OSS was used the organi zational support of the technology did not appear complex to IT department personne l as most OSS applications were provided by IT vendors. Vendors appeared to shie ld municipal IT departments from any unnecessary complexity as they bridged the gap between the open s ource community and the municipal IT departments. This allowe d the IT departments to use OSS like other vendor offerings. As a construct in the or ganizational adoption of i nnovations, OSS complexity appeared to influence the interest and a doption stages. These a doption stages were negatively linked to complexity as theory predicts. Apparently organizations had less interest in a technologies perc eived to be complex as organi zations thought that the time invested in learning the tec hnology would either cause major disruptions in operations or greatly decrease operational efficiencies. Ta ble 46 highlights how complexity affected OSS adoption at the case sites.
249 Table 46. Complexity Site Finding Influence on OSS Adoption Adoption Stages Influenced Roswell Complexity appeared to facilitate adoption as it created a knowledge barrier or filter surrounding what technologies they would implement. High (Rejection) Interest, implementation, and routinization Columbus Many OSS applications were not considered technology options as the complexity associated with those technologies was pe rceived to alter work processes and cause disr uptions to operations. High (Rejection) Interest, implementation, and routinization Decatur IT areas considered OSS applications as being complex, changing work processes and activities, hindering OSS adoption. IT project teams did not considered OSS to be complex as their perceptions of what IT department me mbers varied from their IT area peers. Moderate (Rejection) Interest, implementation, and routinization Jackson Complexity of OSS appeared to be low to many Jackson IT personnel. What was complex were the organizational attributes of OSS such as support and training. Personnel questione d where these functions would come from. Moderate (Rejection) Interest, implementation, and routinization Bowling Green OSS applications were considered to be complex and difficult to understand. Departmental members perceived OSS to alter work processes and cause disruptions to operations. High (Rejection) Interest, implementation, and routinization Theoretical Operation of Adoption Perspective G1d Is the adoption of open source softwa re is best explained by organizational characteristics as opposed to environmenta l factors or innovation characteristics? While the organizational adoption of i nnovations is clearly dependent upon an organization, the dominance of the organizati onal perspective of OS S adoption is difficult to state. The question itself questions what is organizational adoption? Does organizational adoption focus on the last two stages of or ganizational adoption, routinization and infusion? There is little que stion that organizational characteristics best explain the routinization and infusion of technologies. How else can an innovation become routine or infused within an or ganization if not thr ough an organizations processes i.e. an organizations operationa l characteristics? However if organizational adoption includes the stages of awareness, in terest and adoption then it is difficult to
250 definitively state that organizational characteris tics dominate this process as third parties play major roles in these first three stages. All of the organizations examined in th is study had shifted some organizational processes, which included environmental sca nning, training, or support to external third parties. Shifting these activities outside of the organization cha nges how organizations view new technologies. Rather than focusi ng on an innovations ch aracteristics or an organizations own ability to utilize an innovation, organizations become reliant upon third parties. Third parties create network effects that influence how organizations behave. Third parties were extremely influential to both the adoption and rejection of OSS. Roswell, the site w ith the most OSS adoption ro utinely employed vendors to support their OSS. OSS vendors su pplied training and IT support, either new versions or patches of the programs. Without these vendors could the IT department continue to use their OSS? The answer is likely no, as ve ndors allow the department to operate with fewer personnel who can focus on different ta sks. Without the OSS vendors it is highly likely that Roswell would not have had intere st in the technology in the first place. Indeed the availability of third party ve ndors is the reason why other municipal IT departments limited their OSS use; they need ed their proprietary technology vendors to help operate their IT. Perhap s this highlights how vendors pl ay an increasingly important role in organizational activities. One orga nization, Bowling Green, had even shifted environmental sensing, traditionally an organizational characte ristic reliant upon organizational members, outside of the orga nization. Because they had adopted Best of
251 Breed technologies Bowling Gr eens IT department reli ed upon industry experts to evaluate existing IT options, and then adopted technologies recommended by IT experts. The integration of vendors in to IT operations appears to reduce the importance of organizational characteristics; shifting respons ibilities and expectati ons to vendors rather than internal personnel. Therefore this question has mixe d support. While IT department characteristics clearly influenced OSS a doption and were the defining factors for routinization and infusion, it is not clear that organi zational adoptio n could happen without third party assistance. Theoretical Operation of Adoption Stage on Innovation Disruption G2a Do OSS Adoption stages of adoption, ro utinization and infusion disrupt an organizations IT functions in terms of implementation, op eration, and support? Because OSS is a disruptive technology, the development, distribution and support of this technology are radically different from proprietary software; this research proposed that the adoption of OSS at the adopt ion, routinization or infusion stages would disrupt the organizational IT function. Evidence from the cas e studies contradicts this perspective as OSS adoption stages of adoption, routinization, and infusion did not appear to disrupt an orga nizations IT functions. The case studies provide three possibl e explanations for the observed nondisruptions. First the nature of the disruptions caused by OSS may be limited to segments of the value chain outside of the adopting fi rm. Second the compatibility of OSS adopted by IT departments may be such that it alig ns or fits with existing technical and
252 operational processes with adopting organizat ions. Finally, as the third guiding question states, the adoption level of OSS may influence the di sruptive effects of OSS. Because OSS disrupts fundamental software processes, such as development, distribution and support, these three software processes may be disr upted outside of the scope of adopting organizations. Consequent ly, by using OSS vendors or third parties, organizations appear to be shielded from the disruptive effects of OSS. Because organizations focus on use, a feature of OSS th at does not appear to cause disruptions in IT operations, organizations are shielded from the disruptions associated with OSS. Perhaps municipal IT department use of OSS has matured or had enough time to cause disruptions in the IT function. Maybe it is only a matte r of time before the support of the technology; an activity that is disruptive to softwa re in general, alters IT department functions. But, where critical, OSS was purchased from OSS vendors like Red Hat Inc. These vendors provide support li ke traditional software companies, and seem to provide an additional layer of insulation from the disruptive nature of OSS. This implies that the disruptions cause d by OSS technologies may be outside of an organizations operations or scope of use of the technology. If thought of in terms of the value chain, the inbound logistics and af ter sale support ac tivities are the only processes influenced by the t echnologys open nature. The othe r stages in the value chain surround the internal applica tion and use of the technolo gy and do not appear to be affected. Along this line of reasoning may also be the nature of disruptions caused by OSS technologies. Disruptions in operations do not appear to last forever, eventually these
253 innovations become the new organizational norm. This may also account for the lack of disruptions observed. Each site had alrea dy overcome the disruptive effects of the technologies. The compatibility of OSS may also influen ce the lack of disruptions observed in the case sites. While not used for every IT function, where it was used, OSS appeared to seamlessly integrate with other technologies. Th e standards and interfaces of OSS did not necessitate the purch ase of new equipment or othe r technologies. And while some individuals needed to learn ne w processes or ways to execu te tasks through the software, the concepts implemented by OSS were not ne w. This appeared to have high alignment with existing procedural knowledge, or what activities were being done, in the organization. This seamless integration into the existing architecture may be due to the technical knowledge of the adopting sites or due to a selection bias as every case site had adopted OSS in some form or fashion. Perhap s a site that did not adopt OSS in any IT function would have different results. Finally disruptions caused by OSS may be linked to the adoption level of the technology. The third guiding question specifical ly addressed this possibility and is discussed in the next section. Theoretical Operation of Adoption Level on Innovation Disruption G 3 Does open source adoption level modera te the disruptive impact of OSS on the organizational IT function, with lower levels of adop tion having less disruptive effects?
254 Another explanation for the non-disruptive effects of O SS on IT operations at the participating IT departments is the third guiding question: that open source adoption levels moderate the disruptive impact of the technology. This question has mixed support as four of the five sites had only adopted OSS at an as-is level; these as-is adoptions were most often standard versions or vendor supplied versions of OSS. Because participating municipal IT departments did not exhibit disruptions to the IT function it is likely that an as-is level of adoption allows IT departments to treat OSS like proprietary software; especially where OSS vendors ex ist to provide thir d party services. Meanwhile the fifth case study, Roswell, had extensively adopted OSS, even having some instances of infusion adoption st ages. While the majority of Roswells OSS adoption was at a design level, the IT depart ment also participated in the development and extension of a select group of OSS applications. This qualifies as OSS adoption at the design level. Design level adoption appeared to lead to activities, such as OSS development or testing and the use of code bounties with O SS groups, which may have been considered disruptive at the other case sites. However the IT department did not consider these activities to be disruptive as these activitie s were commonly used. Perhaps the use of bounties or OSS development may have on ce caused disruptions in Roswells IT department. There is some evidence of this as the CIO of Roswell, a recent hire by the city, implied that it took him a year to adjust to the OSS environment. But once the adjustment was made to th e OSS technologies and processes, these activities became commonplace. Maybe this is what happens with OSS technologies that
255 are adopted at a design level or an infusion adoption stage; the disr uptive procedures or activities normalize over time. Regardless of the explanation, no disruptions were observed at the participating IT departments, providing poten tial negative answers to the second and third guiding questions of this study. Discussion of Adoption Theories While no theory claimed to fully explai n organizational adop tion of innovations the theories seem to describe parts of an organizational process th at has both social and technical elements. The theories used for this study seem to mirror a fable, the six blind men from Indostan. Like the six blind men who tried to describe an elephant by touching the animals different parts (see appendix item D), the theories touch on different parts of organizational adoption. However unlike th e blind men, the organizational adoption theories make no final claims about the pheno menon and appear to in tegrate together to accurately highlight different parts of the adoption process. The theories were difficult to fit into a doption stages and adoption levels as most organizational adoption theories focus on the entirety of organizati onal adoption, trying to explain various stages of adoption through specific c onstructs. Combinations of theories that included both social and tec hnical and organizational processes appear to best predict the organizational adoption of OSS. The following sections highlight what parts each theory identified and their a pparent predictive powe r on the organizational adoption of innovations.
256 Innovation diffusion theory By describing both social and technical f actors that influence the organizational adoption of innovations, innovation diffusion theory (IDT) appears to be the most complete organizational adoption theory. Key to IDT is the idea that an adopter needs information about an innovations characteris tics. This information is communicated through some kind of social channel. IDT al so recognizes the importance of a new innovations characteristics. How these charac teristics compare to existing innovations is of central importance. This high lights a need to align or fit with the existing technologies used by the organization. The case studies indicate that these factors, communication channels and innovation characteristics, play a major role in the organizational adoption of innovations. However IDT appears to be incomple te as it does not pr ovide an explanation for variations in adoption st ages, even though the theory itself recognizes different adoption stages. Finally IDT appears to li mit adoption to the implementation stage, overlooking the routinization and infusion of innovations. By itself, IDT predicts that organizatio ns should adopt similar technologies at similar stages and levels as organizations became aware of new technologies. This does not appear to happen in the case studies as fi ve similar organizations had adopted OSS in a variety of different departments and capacitie s at two different leve ls and a variety of stages. Perhaps these differences in adoption st age and adoption level can be explained by organizational knowledge, which was found to differ among the case sites.
257 Alternatively an organizational philosophy or objective appears to provide the best explanation for these variations. Columbuss use of OSS was driven by the need to succeed; Bowling Greens use of OSS was dr iven by the best of breed philosophy, and Roswells use of OSS optimized the netw ork of the city. The two organizational characteristics, knowledge and philosophy, varied among the participating IT departments and, when combined with IDTs other constructs, appear to provide more accurate insight as to why adoption stages a nd levels varied among the IT departments. Despite the difficulty in predicting adoption st ages, IDT appears to be the most complete organizational adoption theory as it recogni zes the importance of social as well as technical elements. Technical knowledge and know-how Attewells theory of technical knowle dge and know-how (TKKH) does not claim to fully explain the organizational adoption of innovations. Rather this theory focuses on explaining knowledge gaps associated with new technologies like OSS. By itself this theory does not appear capabl e of explaining organizationa l adoption of innovations as several key elements of adoption are ove rlooked; TKKH does not recognize the importance of an innovations characteristics. Rather Attewell focuses on third partie s providing knowledge through a social channel to enable organizat ions to overcome knowledge ba rriers to use innovations. Attewells theory that adoption is affect ed by an organizations knowledge and the organizations ability to lear n and apply new innovations app ears critical to explaining later adoption stages, especially routinization and infusion.
258 If combined with IDT, the theory of technical knowledge and know-how appears to explain different adoption stages among th e case sites. Although not explicitly stated, if Attewells stages of knowledge supply or use are subs tituted for adoption stages then this theory, when combined with IDT would seem to be a more complete theory for adoption. This perspective discounts the im portance of an organizational goal or philosophy towards technology adoption; a critical factor present at nearly all of the case sites. Organizational Resources Like Attewells theory, Da manpours organizational resources theory did not try to explain the entirety of organizational adoption. Rather this meta-analysis accurately identified and refined many constructs that contribute to orga nizational a doption of innovations. The theory focuses on social fact ors inside and outside of the organization that influence the a doption of innovations. Social factors, both internal and external to the organization, and organizational factors that influenced these social factors, such as administrative intensity and slack resources, were identified as being critical to Damanpours theory. The case studies also acknowledge the importance of technical knowle dge. All of these factors were found to be important in the OSS adoption observed in the case sites. But most importantly this theory seems to hint at or suggest an organizational philosophy or object towards innovation adop tion. Factors like ma nagerial attitude towards change and managerial tenure appear to indicate that these beliefs and values influence innovation adoption. However a philosophy or missi on characteristic was not
259 formally identified in this theory. Add itionally Damanpours orga nizational resources theory never postulated relationships between the various factors he identified. Without these relationships it is difficult to identi fy which factors influe nce different adoption stages or adoption levels. Managerial fashion Managerial fashion, like most of the orga nizational adoption theo ries, did not seek to explain the entirety of orga nizational adoption of innovations. Rather it highlighted the importance of external communication cha nnel by focusing on organizational peers and perceived experts, such as c onsultants or vendors. By exam ining managerial trends and the interactions between organizations, Abrahamson highlighted how these social channels were influential to orga nizational adoption of innovations. Abrahamson stated that the social ch annels had varying affects based upon organizational knowledge and vision. His theory appears to be alone in that it seems capable of explaining some va riations in adoption stage or adoption level. The knowledge and vision of an organization affects or ganizational adoption. In some situations organizations appear to have sufficient knowle dge or vision to avoid influence by peer actions. In other circumstances Abrahamson notes that organizations are vulnerable to the actions of their peers or industry leaders. Th is theory highlights th e importance of social and organizational processes but downplay s the importance of the technology to be adopted and the adopting organizations techni cal infrastructure as Abrahamson appears to overlook these factors.
260 Network externalities Network externalities theory is anothe r organizational adoption theory that highlights the importance of social channels This theory focuses on communication and service networks formed between vendors an d their customers. The theory highlights how important vendor support in the organizatio nal adoption process. Katz and Shapiros theory appears to be the first theory to identify innovation characteristics beyond the functionality of an innovation or its ability to integrate with other technologies. Third party support appears to play a critical role in technology services and adds additional functionality that is valuable to an organi zation. Indeed many of the case sites only used vendor versions of OSS that were supported and maintained through service contracts. This theory appears to refine social as pects of organizational innovation adoption which are critical in determin ing organizational adoption. By highlighting the importance of third party support, Katz and Shapiro id entify innovation characteristics linked to the innovations vendor rather th an the technology itself. Critical mass Unlike other adoption theories, critical ma ss theory focuses on the usefulness of a given technology relative to the number of adopters. In the case studies critical mass effects were not observed. Peer adoption did not affect the usefulness of OSS within the different IT departments. As critical mass e ffects were not observed, this theory appears to lack explanatory power in the adoption of OSS.
261 IT Context Like many of the other organizational a doption theories, Swan sons IT context theory did not try to explain the entirety of orga nizational adoption. Ra ther this theory proposed that there were differe nt types of applications w ithin an organization. This theory appears to have high explanatory power in examining the organizational adoption of OSS as nearly all OSS implementations were in the IT area. Very few OSS applications were adopted outside of the IT area. This indicates that these technologies are likely affected by organizati onal IT contexts including co ntextual knowledge or goals of different organizational functions. Despite the accuracy of identifying adop ting organizational areas, the IT context theory does not appear capable of predicti ng organizational adoption stage or adoption level of the participating sites. Because of these shortcomings it appears necessary to combine the IT context theory with other adop tion theories to explain adoption. It appears that IT context may be a function of or ganizational knowledge, rather departmental knowledge. As such it is possible that Atte wells theory of technical knowledge and know-how may be a stronger explanation for contextual factors a ffecting adoption of OSS. Routine versus Radical Nord and Tuckers theory of routine a nd radical innovations appears to support several parts of the proposed organizati onal adoption process. Their study, which examined the adoption of a single innovation by multiple organizations, found that some
262 organizations considered the innovation to be routine while ot hers perceived an innovation as radical. Several organizational variables, both inte rnal and external to the organization, appeared to influence both the adoption of the innovation and explain the variation in the perceived nature of the innovation. Variab les included domain area expertise, or knowledge, existing technologies similar to th e innovation being adopted, and the use of outside consultants. These factors appear to support an ongoi ng process that has both technical and social elements, including the presence of different network externalities, such as consultants, organizational knowledge, and an existing technical infrastructure. Additionally the research explai ns variations in the percei ved nature of the innovation through different combinations and le vels of organization variables. This theory appears to integrate well w ith what was observed at the case sites. OSS was often adopted where it aligned with existing techni cal knowledge or standards, such as Linux adoption where Un ix versions had been used. Discussion of Research Questions This study sought to answer two resear ch questions about the organizational adoption of disruptive innova tions. The first question, how does the adoption of a disruptive innovation result in disruptions to the adopting organizati on, appears to remain unanswered. Because OSS did not seem to cause disruptions in the organizations examined it is difficult to state that the technology did not cause disruptions to the
263 adopting organizations. There ar e three possibilities as to why the investigation at the municipalities did not answer this question. The first explanation appears to be overl y simple: OSS is not disruptive to IT departments. Although OSS has been labe led a disruptive innovation, Christensen himself calls the technology disruptive; perh aps it is only disrup tive to the software industry. Because IT departments routinely wo rk with different technologies, supporting and enhancing organizational software, O SS may just be another technology. The nuances in support and development do not a ffect adopting organi zations. Again this explanation appears to be overl y simple, and there is some evidence in the case studies that this is not accurate. The CIO at Roswell, the heaviest adopter of OSS, stated that it took him a year to become accustomed to OSS technologies. This gives rise to the second possibility that disruptions caused by disr uptive technologies are temporal and the changes they require eventually become routine to the adopting organization. Because this study was not longitudinal it is quite possible that any disruptions or changes caused by OSS were integrated into pr ocesses before the interviews. It is likely that IT department members had grown accustom ed to using OSS and at the time of the interviews the technologies had become routine. There is strong support for this possibility as absorptive capacity, or the ab ility for organizations to integrate new innovations into their processes is an accepted organizational characteristic. The third possibility stems from OSS adop tion level. Perhaps OSS adoption level, as the third guiding question proposes, do es moderate disruptions to adopting organizations. Because four of the five adopting organizations had limited their OSS
264 adoption to the as-is level, maybe OSS opera tes like proprietary software. Indeed even the most radical adopter, Roswell, employe d OSS vendors and appeared to limit their software development to mission critical a pplications, leaving their adoption of many OSS applications at the as-is level. These three possibilities indicate that the first research question, how does the adoption of a disruptive innovation result in disruptions to the adopting organization, while investigated, remains elusive. Evid ence suggests that disr uptions caused by OSS are not permanent. Organizations adapt to new technologies and pr ocesses. Perhaps a definitive answer could be achieved by a l ongitudinal case study. An organization or group of organizations, seeki ng to adopt a disruptive tec hnology could be followed over time. By understanding how an organizations perceives the radica lness of OSS before, during and after a given period of time, could better answer this question. The second research question, which adopti on perspective, environmental factors, organizational characteristics or innovatio n characteristics, best explains the organizational adoption of disr uptive innovations also remain s partially unexplained. As G1d sought to answer, no single perspective appears to hold the key to organizational adoption of an innovation. Because organizatio ns segment their processes and outsource IT services it is difficult to definitively state that organizational characteristics best explain the entire organiza tional adoption process. The latter stages of orga nizational adoption, especially routinization and infusion, are heavily influenced and best explained by organizational charact eristics. But because organizations rely upon vendors and third part ies for information about new technologies
265 and for services, like tr aining and support, it is difficult to separate the importance of third parties in the early stag es of adoption, from awarene ss and interest to adoption. Rather evidence suggests that organizati onal adoption of innovations appears to be a combination of social processes and t echnical functions. Soci al processes include internal and external communication that the organization participates in. Meanwhile technical functions highlighted by the different theories include the characteristics of the innovation to be adopted and the organizati ons existing IT functi on. Table 47 highlights how these different factors appear to influe nce organizational adoption stages. Factors are rated either high or low base d upon their perceived influenc e in organizational adoption but these factors do not appear to influenc e the different sites equally. If they did adoption stages predicted by IDT would be found in the cas e sites. A motivation for adoption appears to be missing. Table 47. Factor Effects on Adoption Stage Awareness Interest Adopti on Routinization Infusion Innovation Characteristics Low High High Low Low External Social Processes High High High Low Low Internal Social Proce sses High High High High High Internal IT Function Low High High High High The organizations examined in this research appeared to be guided by an organizational goal or philosophy. The a lignment between a new innovation, an organizations goal or philosophy and the existin g IT function appear to best explain how organizations adopt new innovations. How orga nizations determine an innovations fit or alignment with their goals is highly contextual as these fact ors appear to influence one another.
266 In conclusion the answer to the second research question, which perspective best predicts organizational adoption of innovations appears to be yet more questions. Is adoption found in the latter stages? Or are th e early stages of adoption of concern? There is no doubt that the organization plays an inst rumental role in the adoption of innovations at all stages, but the most influential role in all stages is questioned. Because of the segmentation of IT department services, including environm ental scanning, training and support, the influence of envir onmental factors appears to be growing. Perhaps this is indicative of the invasive and converging natu re of IT on business practices. Regardless, this study highlights how rich the or ganizational adoption process is.
267 Chapter 6. Findings and Contributions This chapter discusses the findings and c ontributions of the st udy. It is organized around the two research questions. The first pa rt discusses what was learned about the adoption of OSS, a disruptive innovation. This is followed by a section that examines what was found about organizat ional adoption pers pectives. After th ese sections the studys limitations and future re search conclude this study. The first research question sought to unde rstand when the adoption of a disruptive innovation causes disruptions in an adopti ng organization. Evidence from this study indicates that no organization was disrupted by simply adopting OSS. No disruptions were observed in the participating IT departme nts, especially organi zations that used OSS as provided by the OSS developers. This leads to one of two possibilities, fi rst disruptions may be temporal, meaning that they last only for a limited amount of time. Perhaps the interviews were conducted after the IT departments had grown accustomed to the OSS technologies. And while there was some evidence that OSS changed organiza tional processes, the interviews failed to indicate any ongoing disruptions in IT operations. Any changes appeared to be absorbed into operations. Alternatively OSS may not disrupt IT depa rtment operations at all. Because many of the adopting IT departments used OSS in the same manner as proprietary software, purchasing it from a vendor, it is possible that disruptive technologies may only affect their market of origin. In the case of OSS th is would mean that onl y software providers,
268 or organizations that create and sell software, would be the organizations feeling the disruptive effects of the technology a nd not the adopting organizations. The second contribution of this study is a better understandi ng of the different perspectives of organizationa l adoption theories. By testing a model that synthesized eight different organizational adoption th eories, organizational adoption is better understood. No single perspective or adopti on theory appears to best explain this organizational process. Rather these theories all appear to touch on or identify different parts of the organizational adoption process. Additionally the strengths of these different constructs appear to change during the adoption process. During the beginning of organizati on adoption, environmental constructs and innovation characteristics appe ar to influence orga nizational awareness and interest. However, once identified, orga nizational constructs, such as knowledge and administrative intensity, seem to beco me more important. The importance of organizational constructs gradually increases until they ultimately determine the routinization or infusion of an innovation. Based upon the examination of the eight different organizational adoption theories, this study highlights how organizationa l adoption can be divided into social and technical processes. Socially, communicatio n within and outside of the organization seems to impact an organizations awareness and interest in new technologies. Technical processes, such as support, a nd technical fit, appear to infl uence later stages of adoption. Table 48, Theoretical Fit with organizationa l adoption highlights how these different theories appeared to influence adoption stag es during the organizati onal adoption of OSS.
269 Table 48. Theoretical Fit of Adoption Theories Theory Alignment with Adoption Stages Explanation of Organizational Adoption Level Innovation Diffusion Theory Had significant influenc e on organizational adoption as it identified social process and innovation characteristics that influenced adoption Awareness Interest Adoption Routinization Infusion High High Moderate Low Low Technical Knowledge and Know-How Had significant influenc e on organizational adoption as all adoption stages were affected by organizational knowledge Awareness Interest Adoption Routinization Infusion Moderate High High High High Organizational Resources Had substantial influe nce on organizational adoption as organizational characteristics were influential in all stages of adoption Awareness Interest Adoption Routinization Infusion Moderate Low Moderate Moderate Low Managerial Fashion Had little influence on or ganizational adoption as participating organizations did not appear to be concerned with their peers or industry trends Awareness Interest Adoption Routinization Infusion Moderate Moderate Low Low Low Network Externalities Had significant influenc e on organizational adoption as externalities, such as third party support, often determined the adoption of OSS by an organization Awareness Interest Adoption Routinization Infusion High High High Moderate Low Critical Mass Had little influence on or ganizational adoption as participating organizations were not subjected to critical mass effects Awareness Interest Adoption Routinization Infusion Low Low Low Low Low IT Context Had substantial influe nce on organizational adoption as the majority of organizations had adopted OSS only within the IT department Awareness Interest Adoption Routinization Infusion Moderate Moderate Moderate Low Low Routine vs. Radical Had moderate influence on organizational adoption as participating organiza tions were less likely to adopt OSS that was perceived to be radical Awareness Interest Adoption Routinization Infusion Moderate High Moderate Low Low This research also contributes to orga nizational adoption of innovations by testing existing organizational adoption constructs. Ma ny theories propose that constructs work
270 in one way, either positive or negative, in organizational adoption. However this research confirms that network effects can alter how organizational adoption constructs operate. Constructs like communication channels such as peer adoption, vendor interaction and technical communities, often have both positive and negative effects on the adoption of innovations. This research hi ghlights how these constructs often align with existing theory, acting as positive forces for adoption. But occasionally these constructs work to hinder the adoption of innovations like OSS. Apparently many of these constructs are influen ced by different entities that have their own goals or objectives that can either ali gn with or against the adoption of new innovations like OSS. Organizational level construc ts examined also exhibi ted varying effects on the adoption of OSS. Many of these constr ucts, such as technical knowledge or environmental scanning, were believed to facilitate the adopti on of new innovations. However existing technical standards, or ne twork externalities caused by the knowledge of existing standards, caused the need to learn new technol ogies to apparently increase the adoption cost of OSS. This was interesting as the learning costs appeared to influence some personnel to say that these constructs had a negative influence on their adoption of OSS while other personnel examined reported that these cons tructs had a positive influence on their OSS adoption. Individual differences in attitudes to wards learning apparently play major roles in the adoption of new technical standard s. Organizational cons tructs, like social constructs, are often influenced by an obj ect or driving motivation that may cause organizational constructs to facilitate or hinder th e adoption of innovations.
271 This study also identified constructs that were not part of these eight different organizational adoption theories. The first is an organizational philo sophy or objective. The participating IT departments were gu ided by philosophies or approaches to technologies as well as department goals and objectives that influen ced their adoption of new technologies. While Damanpours meta anal ysis of organizational adoption hints at this construct through administra tive intensity and ma nagerial tenure, an IT philosophy or goal is not identified. The identification of th is construct, an orga nizational perspective on IT, extends theory and facil itates understanding va riations in adoption stages. Previous organizational adoption theories focused on th e fit between the communications of an innovations characteristics with organizationa l leaders. But if adoption were merely determined by the communication of characteris tics, why were there so many variations in OSS adoption? Organizational beliefs or objects appeared to influence which technologies were chosen. A second construct identified is the exis ting IT infrastructure. While implied in innovation diffusion theory through a compatibili ty characteristic, this implication does not recognize the importance of an existin g infrastructure on the adoption of an innovation. IT infrastructures have existing processes and associated knowledge that alters the compatibility char acteristic of an innovation. Therefore innova tions not only need to be compatible with existing techno logies but also with existing processes and organizational knowledge. This research also makes contributions beyond the original research questions. Because most OSS studies have examined the adoption of a specific OSS, like Linux, this
272 study contributes as it examined how entire IT departments comprised of many IT areas adopted OSS. The interviews show that many areas within the IT department, primarily the security, networking and servers areas, adopt OSS. Perhaps this is because many of these technologies are perceived to be mo re mature than their OSS peers as their communities are well established. Or maybe the highly technical functions of these areas, hidden from most end users, allow these de partments to adopt O SS more easily than other IT department areas. Re gardless, this res earch highlights how the participating organizations adopted a diverse range of OSS across many IT department areas. Additionally this research contributes to the understanding of OSS by confirming two of four OSS adoption levels propos ed by Grand, Von Krogh, Leonard and Swap (2004). Grand et al proposed th at organizations can adopt OS S at four different adoption levels. This research observed two of these levels, as-is and design. It did not identify instances of hybrid or busine ss model adoptions. The absence of these levels may be due to the non-profit nature of m unicipal governments. Because these organizations do not create or sell an informati on technology, combinations of proprietary and open source technologies to create a product for sale ma y not be found. Additiona lly adoption levels of open source business models may be abse nt because of the non-profit nature of municipal governments. They simply do not create a product. Limitations This study, like all research has several lim itations that may influence the scope or the application of the research findings. Thes e limitations stem from the source of the data and the research methods used to gath er data for the study. The remainder of this
273 section will address these two areas and high light how they may influence the research findings. Municipal government information tec hnology departments s upplied the context for data collection in this study. These IT de partments may limit the fi ndings of this study as they all belong to municipalities, nonprofit organizations, which volunteered to participate in this study. Perhaps the non-profit nature of municipal IT departments, when combined with municipal unions creates a work environment that mo st businesses do not mimic. Because municipal IT department wo rkers did not receive workplace incentives and were protected by union contracts they may have been less i nnovative than business IT departments. Additionally only IT depa rtment personnel were interviewed. Their perspective may not accurately represent what the city as a whole believes as the IT department and its activities ar e central to their concerns. The participating municipal IT departments also volunteered to take part in this study. These five locations may be very di fferent from the other six municipal IT departments that were invited to participate in the study. Perhaps this is a self-selecting group as each of the municipal departments beli eved that there were areas within their IT department that excelled or stood out among ot her municipal IT departments. This may indicate that these IT departments are lead ers within the municipal government context, placing them at the cutting edge of technology. If this is the case, then it would be unlikely that other municipalities would follow the trends found in this research. Finally the municipal cont ext may have altered findings as the years 2007 and 2008 were economically tough for th e state of Florida. Each of the municipalities that
274 participated in this research had their budge ts affected by lower tax collection and other revenues. This may have altered the research findings as all of the departments were looking to cut costs while mainta ining current service levels. The second area of limitations stems from the research method of using multiple case studies. These studies relied upon structur ed interviews as the principle means of collecting data. Interviews provided a snap s hot of what these indi viduals thought of on a single day. Rare events or participant mood or relationship with the researcher may have influenced findings. Additionally the researchers own bias, a favorable opinion of OSS, could have influenced the interpreta tion and coding of transcript data. Future Research This dissertation investigated the orga nizational adoption of OSS, a disruptive innovation. While the research contributes to existing theory in three different areas, organizational adoption, disruptive innovations and open source adoption levels, it raises many questions about these three topics that could serve as future research projects. One potential research project could mo re closely examine environmental or organizational adoption constructs. Prior to this study existing theory has had deterministic beliefs about the influences that these constructs have on the organizational adoption process. External communication so urces were thought to be beneficial for innovation adoption as were technical know ledge and environmental scanning. This study identified situations in which these constructs appeared to hinder OSS adoption as well as circumstances where these constructs facilitated OSS adoption. Therefore these
275 adoption constructs appear to operate with paradox, making them ripe targets for future research. Additionally this study highlights how di sruptive innovations are not inherently disruptive to adopting organizations. Perhaps a closer examination of the value chain of OSS, from creation to distribut ion to application, could rev eal where this technology is disruptive and better understa nd how disruptive innovations affect business markets and organizations. Finally this research investigated open source adoption levels, a unique adoption characteristic to OSS technologies. The study confirmed that two of the four different adoption levels, as-is and de sign, exist in municipal government environments. Further research could confirm or disprove the existe nce of the other two a doption levels, hybrid and business models. This research could add to the understanding of OSS technologies and the potential changes they can bring to software development and usage.
276 List of References Abrahamson, E. (1991). Manageri al Fads and Fashions: The Diffusion and Rejection of Innovations. The Academy of Management Review, 16(3), 586-612. Attewell, P. (1992). Technology Diffusion and Organizational Learning: The Case of Business Computing. Organization Science, 3(1), 1-19. Ball, L.D., Dambolena, I.G., Hennessey, H.D. (1987). Identifying Early Adopters of Large Software Systems. Database 19(1), 21-27. Bagozzi, R., Dholakia, U. (2006). Open Source Software User Communities: A study of participation in Linux user groups. Management Science 52(7), 1099-1115. Benkler, Y. (2001). The battle over the institutional ecosystem in the digital environment. Association for Computing Machin ery Communications of the ACM 44(2), 84-90. Bergquist, M., Ljungberg, J. (2001). The power of gifts: organizing social relationships in open source communities. Information Systems Journal, 11, 305 320. Bower, J., & Christensen, C. (1995). Di sruptive Technologies: Catching the Wave. Harvard Business Review 73(1), 43-53. Bucher, P., Birkenmeier, B., Brodbeck, H., and Escher, J.P. (2003). Management principles for evaluating and introducing disruptive technologi es: the case of nanotechnology in Switzerland. R&D Management 33(2), 209-230. Chau, P. Y. K., Tam, K. Y. (1997). Factors affecting the adoption of open systems: An exploratory study. MIS Quarterly 21(1), 1-24. Christensen, C., & Raynor, M. (1997). The Innovators Dilemma, When New Technologies Cause Great Firms to Fail Boston, MA: Harvard Business School Press. Christensen, C., & Raynor, M. (2003). The I nnovators Solution. Creating and Sustaining Successful Growth, Boston, MA: Harvard Business School Press. Cohen, M., & Levinthal, D. (1990). Absorptive Capacity: A New Perspective on Learning and Innovation. Administrative Science Quarterly 35, 185-215.
277 Cooper, R.B., and Zmud, R. W. (1990). Information Technology Implementation Research: A Technological Diffusion Approach. Management Science 36(2), 123-139. Cusumano, M. A. (2004). Reflectio ns on free and open software. Communications of the ACM 47(10), 25-27. Dahlander, L., Magnusson, M. G. (2005). Rela tionships between open source software companies and communities: Observations from Nordic firms. Research Policy 34, 481. Damanpour, F. (1991). Organizational Innovati on: A Meta-Analysis of Effects of Determinants and Moderators. Academy of Management Journal 34(3), 555-590. Danneels, E. (2004). Disruptive Technology Reconsidered: A Critique and Research Agenda. Journal of Product Innovation Management, 21, 246-258. DeSanctis, G., & Poole, S. ( 1994). Capturing the Complexity in Advanced Technology Use: Adaptive Structuration Theory, Organization Science, 5(2), 121-147. Dewar, R., & Dutton, J. (1986). The Adoption of Radical and Incremental Innovations: An Empirical Analysis. Management Science 32(11), 1422-1433. Eveland, J.D., and Tornatzky, L.G. (1990). The Deployment of Technology. In The Processes of Technological Innovation, e d. LG. Tornatzky and M. Fleischer. Lexingon, MA: Lexington Books. Franke, N., von Hippel, E. (2003). Satisfying heterogeneous user needs via innovation toolkits: the case of Apache security software. Research Policy, 32, 1199. Fichman, R. (1992). Information Technology Diffusion: A Review of Empirical Research, Proc. Thirteenth International C onference on Information Systems, Dallas, TX 195-206. Fichman, R.G., Kemerer, C.F. (1997). The Assi milation of Software Process Innovations: An Organizational Learning Perspective. Management Science 43(10), 13451363. Fichman, R.G. (2000) The diffusion and a ssimilation of information technology innovations. In Framing the Domains of IT Management: Projecting the Future Through the Past. Pinnaflex Educatio nal Resources, Cincinnati, OH.
278 Fitzgerald, F. (2006). The Transformation of Open Source Software. MIS Quarterly 30(3), 255-283. Glass, R.L. (2004). A Look at the Economics of Open Source. Communications of the ACM 47(2), 25-27. Goode, S. (2005). Something for Nothing: Management Rejection of Open Source Software in Australias top firms. Information and Management 42, 669-681. Grand, S., von Krogh, G., Leonard, D., and Swap, W. (2004). Resource Allocation Beyond Firm Boundaries: A Multi-Level Model for Open Source Innovation. Long Range Planning 37, 591-610. Hars A., Ou, S. (2002). Working for Free? Mo tivations for Participating in Open-Source Projects. International Journal of Electronic Commerce 6(3), 25-39. Hicks, C., Pachamanova, D. (2007). Back-Pr opagation of User I nnovations: the Open Source Compatibility Edge. Business Horizons 50, 315-324. Free Software Foundation Philosoph y (2008). Retrieved March 2008, from: http://www.fsf.org/licen sing/essays/free-sw.html GNU Open Source Philosophy (2008). Retrieved March 2008, from: http://www.gnu.org/philosophy/freesoftware-for-freedom.html Open Source Market Forecast (2008). Retrieved March 30, 2008, from: http://www.researchandmarkets.com/r eportinfo.asp?rfm=rss&report_id=575362 Katz, M., Shapiro, C. (1986). Technology Adoption in the Presence of Network Externalities. Journal of Political Economy 94(4), 822-841. Koch, S., Schneider, G., Effort. (2002). Co-O peration and Co-Ordination in an Open Source Software Project: GNOME. Information Systems Journal 12, 27. Kuk, G. (2006). Strategic Interaction and K nowledge Sharing in the KDE Developer Mailing List. Management Science 52(7), 1031-1042. Lakhani, K. R., von Hippel, E. (2003). How ope n source software works: free user-touser assistance. Research Policy (32), 923. Lerner, J., and Tirole, J. (2002). Some Simple Economics of Open Source. The Journal of Industrial Economics L(2), 197-234.
279 Linux corporate sponsors (2008). Retrieved March 30, 2008, from http://www.linuxsymposium.org/2007/sponsors.php Lyytinen, K., & Rose, G. (2003). The Disr uptive Nature of Information Technology Innovations: The Case of Internet Computing in Systems Development Organizations. MIS Quarterly 27(4), 557-585. Markus, M.L. (1987). Toward a "Critical Mass" Theory of Interactive Media: Universal Access, Interdependence and Diffusion. Communication Research 14(2), 491. Markus, M.L., Manville, B., Agres, C. E. (2000). What Makes a Virtual Organization Work? MIT Sloan Management Review 42(1), 13-26. Meyer, A.D., and Goes, J.B. (1988). Organi zational Assimilation of Innovations: A Multilevel Contextual Analysis. Academy of Management Journal 31(4), 897923. Microsofts 10Q. (2008). Retrie ved March 30, 2008, Web site: http://investor.news.com/cnet?Page=SEC&Ticker=msft Moore, G., & Benbasat, I. (1991). Developm ent of an Instrument to Measure the Perceptions of Adopting an In formation Technology Innovation. Information Systems Research 2(3), 192-222. Nilakanta, S., & Scamell, R. (1990). Th e Effect of Information Sources and Communication Channels on the Diffus ion of Innovation in a Database Development Environment. Management Science 36(1), 24-40. Nord, W., & Tucker, S. (1987). Implemen ting routine and radical innovation, Lexington, MA: Lexington Books. Peng, Z. (2004). Linux Adoption by Firms. Raymond, E. (2001). The Cathedral and the Bazaar OReilly, Sebastopol, CA. Rogers, E.M. (1995). Diffusion of Innovations New York: Free Press, 1995 Shah, S. K. (2006). Motivation, Governance and the Viability of Hybrid Forms in Open Source Software Development. Management Science, 52(7), 1000-1014. Spinellis, D., Szyperski, C. (2004). How is ope n source affecting software development? IEEE Software 21(1), 28-33. Sood, A. & Tellis G. (2005). Technologi cal Evolution and Radical Innovation. Journal of Marketing, 69, 152-168.
280 Srinivasan, R., Lilien, G., Rangaswamy, A. (2002). Technological Opportunism and Radical Technology Adoption: An application to E-Business. Journal of Marketing 66(3), 47-68. St. Laurent, A. (2004). Understanding Open Source and Free Software Licensing OReilly Media. Swanson, E. B. (1994). Information Sy stems Innovations among Organizations. Management Science, 40(9), 1069-1092. Tornatzky, L.G., and Klein, K.J. (1982). Innovation Characteristics and Innovation Adoption-Implementation: A Meta-Analysis of Findings. IEEE Transactions on Engineering Management 29(1), 28-45. Tornatzky, L.G., and Fleischer, M. (1990). The Processes of Technological Innovation Lexington, MA:Lexington Books. von Hippel, E., von Krogh, G. (2003). Open Source Software and the "PrivateCollective" Innovation Model: Issu es for Organization Science. Organization Science 14(2), 209-223. West, J. & Dedrick, J. (2006). Scope and Timing of Development: Moderators of Organizational Adoption of the Linux Server Platform. International Journal of IT Standards and Standardization Research 4(2), 1-23. Zahara, S. A., and George, G. (2002) Absorptive Capacity: A Review, Reconceptualizati on, and Extension. Academy of Management Review 27(2), 185-203. Zhu, K., Kraemer, K., Gurbaxani, V., & Xu, S. (2006). Migration to Open-Standard Interorganizational Systems: Networ k Effects, Switching Costs and Path Dependency. MIS Quarterly 30, 515-539.
282 Appendix A. Coding Schema Factor Construct Code Description External Communication E-C Communication with parties out side of the organization about OSS. Including, but not limited to, magazines, websites, other organizations. Peer Adoption Effectiveness E PAE Knowledge of a peer that has implemented an OSS to better solve a problem or solve a problem with better performance Peer Adoption Managerial Fashion E PAM Adoption of an OSS because a peer has adopted the same technology Vendor Services V-S Use of vendors to provide knowledge, support, or other services to the IT department Vendor Standards V-VS Use of vendor products to faci litate information system integration Environment Technical Community TC Communication with OSS development/support community Structure Internal Communication S-IC How communication is structur ed within an organization either formally or informally Structure Administrative Intensity S-AI How the organization dictates aspects of the IT function, from standardization of software to training to hardware to how work is done. Characte rized as either high or low Knowledge Environmental Sensing K-ES If the employee engages in evaluations of technologies outside of the organizations to better perform organizational tasks coded either as yes or no Knowledge Absorptive Capacity K-AC An aggregated construct based off of the number of different technologies an IT department has adopted Knowledge Technical Knowledge K TK The number of technologies the individual develops, implements or supports as well as different standards that they are familiar with Size Specialization S-Sp The number of different specialty areas within the department Size Wealth S-W The budget of the department Organization Size Slack Resources S-SL The amount of time employees have to search for new solutions or experiment with new technologies Relative Advantage context RA The characteristics of an OSS that are better than a proprietary OSS for the same context and application Compatibility values C-V How congruent an OSS is with existing values Compatibilitytechnical standards C-TS How readily an OSS meets existing technical standards Compatibility Radicalness C-R How similar an OSS is to existing departmental technologies Innovation Complexity C How difficult OSS is to understand Awareness AS-AW If organizational members are aware of OSS technologies Interest AS-I If organizational members are interested in OSS technologies Adoption AS-AD If organizational members have adopted OSS technologies Routinization AS-R If organizational members consider the use of OSS technologies standard or routine Adoption Stage Infusion AS-I If organizational members have applied OSS technologies to new uses As is AL-A If organizational members use an OSS distribution without modifying it Adoption Level Design AL-D If an organizatio n has adopted an OSS design Disruptive D-D If an OSS technology has disrupted the IT function Disruptive Effects Routine D-R If an OSS technology has not disrupted the IT function
283 Appendix B. Understanding OSS as a Disruptive Technology OSS as a Disruptive Technology Experts agree that open source softwa re (OSS) licensed under the GPL is a disruptive technology (Raymond 1999, Spinel lis and Szyperski 2004, Hicks and Pachamanova 2007). Linux and other communa lly developed programs licensed under the GPL appear to radically shift how software is created, used and maintained. However, it is not enough for this study to simply labe l OSS as a disruptive technology to determine how OSS is being adopted by organizations Therefore this section reviews existing definitions of disruptive technologies to understand how OSS is disruptive and can potential affect organizations. Disruptive innovations have been defined at two different conceptual levels. They have been defined at the industry level and at the information t echnology (IT) innovation level. These disruptive definitions are then reconciled to identify open source software as a disruptive innovation. Environmental-Level Definition s of Disruptive Technologies Bower and Christenson, the originator s of the term disruptive technology, originally distinguished disr uptive innovations from other innovations by examining their characteristics which in turn affected their market posi tions (1995). Those innovations that change or alter the status quo of an i ndustry are considered to be disruptive, while innovations that embrace traditional market stra tegies are routine as they sustain industry status quo.
284 These researchers further refined market entry strategies by characterizing them as either new-market or low-end disruptiv e technologies (Bower and Christenson 1995). New-Market innovations are aptly named as th ey create new markets. Rather than alter existing industries these innovations offer so mething new, solutions or services for problems or opportunities that were not bei ng addressed before the innovation. Because they create new possibilities as well as new markets, it is easy to understand how newmarket innovations can be seen as disruptive. At first glance OSS does not appear to be a new-market di sruptive technology. Although some OSS applications like the Apache web-server, have created new markets, most OSS applications are diffe rent versions of existing prop rietary computer programs. Because most open source applications mi rror existing computer programs they appear to be low-end innova tions. Christenson distinguish es low-end innovations from new market innovations in their market en try strategy. As opposed to creating a new market, lower-end innovations enter existing markets by focusing on specific market segments (Bower and Christenson 1995). After establishing a presence in these segments, an organization follows a low-end strategy by moving into anothe r, preferably more profitable segment. This is accomplished by innovating and improving their original product. This incremental improvement is repeated, creating an emerging product which eventually disrupts the status quo of an industry. OSS appears to fit the mold of incremental lower-end disruptive technologies. These applications have typically begun as a hobby or an intellectual itch of a computer programmer (Raymond 1999). Because the software is released under a GPL-like license,
285 the applications source code and the rights to use it are freely available. As a free product, OSS enters a low-prof it segment of the computer software market. Over time OSS have been shown to mature and attract a community of developers (Raymond 1999). These developers continue to incrementally improve the application until one day the application becomes a viable software alternative. This trend has resulted in several open source applications, like Linux, MySQL, or Firefox, that now directly compete with their proprietary equivalents. This competition appears to be di srupting the status quo of the software industry as new business mode ls have emerged around OSS technologies. Traditionally proprietary software orga nizations, like Microsoft, rely upon the licensing of their software to generate revenues. Microsof ts 10Q filed in 2008 reveals that 80% of the organizations revenues we re generated through software licenses at original equipment manufacturers (OEM) like Dell computers and Hewlett Packard (10Q). These revenue streams are challeng ed as open source applications pursue alternative business models that do not rely upon the licensing or purchase of a software license. Rather business models that use OSS focu s on services or a dd-ons to generate revenue (Markus 2000). Services range from support to implementation to contextual applications to create a lternative revenue streams (M arkus 2000). Add-ons include hardware or software that extends the f unctionality of an OSS (Markus 2000). These business models disrupt the software industry as they eliminate the costs associated with licensing software (Benkler 2001, Cusuma no 2004). Christensons definition of disruptive technologies highlights the importa nce of an innovation disrupting industry-
286 level factors, or environmental factors. OSS ap pears to meet the criteria for this definition as it alters the revenue structure of the so ftware industry, transitioning from licensing to services and add-ons. Innovation Level Definitions of Disruptive Technologies Disruptive innovations have also been defi ned at the innovati on level. Lyytinen and Rose (2003) specifically defined disruptive IT innovations as thos e technologies that are both pervasive and radically different fr om their predecessors (Lyytinen and Rose 2003). Pervasive is defined as an innovation simultaneously and necessarily spanning new services and new types of developmen t processes. Radicalne ss is determined by whether or not an innovations adopter need s to engage in behaviors that depart significantly from exis ting alternatives (Lyy tinen and Rose 2003). OSS meets both of these characteristics as the development, distribution, and support of OSS create new orga nizations that use new pro cesses which depart from traditional proprietary software activities. Table 1a highlights how these activities differ between the two types of software. Table 1a. Differences between GPL Based Open Source and Proprietary Software Category Reference GPL Based Open Source Proprietary Software Development Hars and Ou (2002), Koch and Schneider (2003), Kuk (2006), Shah (2006) Paid and / or volunteer developers with differing motivations Paid developers working within a single organization Distribution Raymond (1999) Source code is available according to license the most common being GPL v2 which is free to download Licensed distributions Software Support Raymond (1999), Lakhani and von Hippel (2003) Traditional Relian ce upon volunteers and support groups; new corporate participation with differing motivations Paid developers and virtual communities working with a single organization
287 The first item in the table, software development is disrupted by GPL-like licenses in two major ways. The characteristic of OSS changes who is allowed to participate in development activities. Propr ietary software traditionally restricts development to a select few individuals. While OSS development is not open to the public, there are project leaders who determin e what is and what is not allowed in a project, the source code is freely available. Anyone, free-lance contractors, volunteers, or salaried programmers, are free to solicit ideas and source code to an OSS project. This can create a community of developers who may or may not have the same motivations for developing the software (Raymond 1999, Bergquist and Ljungberg 2001, Hars and Ou 2002, Franke and von Hippel 2003, and Roberts, Hann and Slaughter 2006). These community members directly interact with the individua ls responsible for modifying and supporting the application (Koch and Schneider 2003, Bagozzi and Dholakia 2006, Kuk 2006). Because OSS project s are closely linked to their communities there is no exclusive source of project exper tise. Individuals with differing motivations across multiple organizations tend to be involved with an OSS project. If a project fails to answer to their user communities, forking can occur. Forking, though rare, occurs when a user community becomes disgruntled enough to separate. An independent group forms to support a separate version of an OSS (D ahlander and Magnusson 2005 and Koch 2002). The forking developers simply take the latest version of an OSSs source code and begin their own separate version of the program. Again, this is a rare event as the open source community sees this as a waste of time a nd effort. However it serves an important
288 governing mechanism as OSS projects that ig nore their communities may fork in a new direction. GPL-like licenses can also di srupt the distribution and organizational acquisition of software. Organizations have traditiona lly acquired software through licenses from software vendors. While some vendors, like RedHat and MySQL, provide OSS services and distributions, GPL-based OSS provides organizations with a new alternative; organizational members can simply download an application. The freedoms granted by GPL licenses allow users to copy, modify, or redistribute versions of the application allowing organizations to take independent ac tion to acquire an OSS. Not only does this potentially disrupt the software industry, but it also alters how organizations can acquire software. OSS and their GPL licenses also pervas ively change software support. While proprietary software relies upon the near-exclusive use of salaried deve lopers within their organization to make changes to the app lication and help customers troubleshoot, GPLbased OSS uses a much more diverse group of stakeholders to support OSS. At one time OSS support consisted solely of volunteers and user groups (Lakhani and von Hippel 2003). Like its development, these volunteers ha d varying motivations for participating in OSS support. Differing motivations for softwa re support remain a challenge as major players in the software and hardware i ndustries have started supporting OSS. AMD, IBM, Intel, Cisco are but a handful of software vendors who are actively supporting open source applications (http://www.linuxsym posium.org/2007/sponsors.php). However vendor involvement in supporting OSS appears to be tightly coupled to their business
289 models and corporate support for new open s ource applications is far from common. This fragmentation of support radically depa rts from traditional proprietary models. Because OSS pervasively and radically changes the development, distribution, and support of software it meets the criteria th at Lyytinen and Rose laid out for disruptive IT innovations. Meeting this defi nition appears to indicate th at OSS is disruptive not only to the software industry, but is also in and of itself a disruptive IT innovation. Open Source Software as a Disruptive Technology OSS appears to fit both th e industry-level and innovati on-level definitions of a disruptive technology. As a lower-end disruptiv e innovation OSS appear s to disrupt many industry level factors such as suppliers, vend ors, partners or third parties. At the innovation-level the definition of a disrupt ive IT innovation highlights several IT processes associated with IT that are di srupted. The development, distribution and support of OSS are all significantly diffe rent from proprietary software. Defining Open Source Software The previous section has shown that OS S is a disruptive IT innovation. But what is it? What makes an application an opens source one versus a proprietary one? This section answers this question to identify O SS innovations for this study. OSS is not a new phenomenon as its origins date back more than forty years (Markus 2000, Lerner and Tirole 2002, Glass 2004). Despite this history many researchers have found this type of software difficult to define (Fitzgerald 2007 ). This is in part because of the many different parties, both academics and practitioners, who have defined this type of
290 software. This section examines these definiti ons, taking elements from each to arrive at a working definition for this study. The first section examines open source licenses. This is followed by definitions that advocacy groups use and hist orical perspectives that ha ve been used by researchers to define OSS. These perspectives are combined to arrive at a definition of OSS for this study. Open Source Software Licenses Software licenses are critical in determining if an application is considered open source or proprietary. They do so by outlining what rights are granted to the user of a computer application and its s ource code. Almost any aspect of use, from who can use the software, to how it is deve loped, to how contributions ar e recognized, to a softwares distribution can be legally outlined in a license. The standard for open source licenses is GNUs GPL. This license is used as a benchmark by open source advocacy groups when considering if a license is an open source or not (St. Laurent 2004, Fitzgerald 2007). To date over 50 different licenses appear to be similar enough to the GPL to be considered open source (http://www.opensource.org/licenses). This indi cates that the freedoms inherent in a license as identified by the Free Software F oundation, as outline in Table 4, are critical for an application to be considered open source. Therefore this study will incorporate rights and uses of applications in the definition of OSS.
291 Open Source Advocacy Definitions Open source licenses are strongly tied to open source advocacy groups. There are two main open source groups, the Open Sour ce Initiative (OSI) and Free Software Foundation (FSF). Each group defines OSS di fferently. The OSI definition of open source software is based on te n criteria which set guideli nes for access, modification, recognition and distribution of OSS. Fundamentally this group approaches OSS as a new development method (http://www.gnu.org/philosophy/fr ee-software-for-freedom.html ). Meanwhile, the Free Software Foundation (FSF) defines OSS through freedoms, or what actions users are allowed to take with the software (http://www.fsf.org/licen sing/essays/free-sw.html). The FSF appears to believe that OSS is a social movement rather than a new fo rm of software development. The two groups definitions are detailed in Table 2a. Although the definitions differ, both seek to adhere to th e main principles of the GPL. Both advocacy groups center on the ability to for anyone to access, modify and/or redistribute an application at the source code level. Therefore these definitions not only define OSS by whether or not it adheres to GPL-like licenses, but also highlight the importance of developer pa rticipation as both defi nitions center around including developers from all backgrounds. Anyone, rega rdless of race, creed, sex, or application intentions should be allowed to participate in the develo pment of an OSS. The OSI accomplishes this by using ten specific rules to explicitly state who has access to the source code. Meanwhile the FSF accomplishes n early the same goal by ascribing generic freedoms through the GPL.
292 Table 2a. OSI and FSF Definitions of Open Source The Open Source Initiatives 10 Cr iteria of Open Source Software Criteria Description Free Redistribution The license shall not restrict any party from selling or giving away the software as a component of an aggregate software dist ribution containing programs from several different sources. The license shall not requ ire a royalty or other fee for such sale. No Discrimination Against Fields of Endeavor The license must not restrict anyone fro m making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being us ed for genetic research. Source Code The program must include source code, and mu st allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfus cated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed. License Must Not Be Specific to a Product The rights attached to the program must not depend on the program's being part of a particular software distribution. If the pr ogram is extracted from that distribution and used or distributed within the terms of th e program's license, all parties to whom the program is redistributed should have the sa me rights as those that are granted in conjunction with the original software distribution. Derived Works The license must allow modifications and derived works, and must allow them to be distributed under the same terms as th e license of the original software. Distribution of License The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties. Integrity of The Author's Source Code The license may restrict source-code fro m being distributed in modified form only if the license allows the distribution of "pat ch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modifi ed source code. The license may require derived works to carry a different name or version number from the original software. License Must Not Restrict Other Software The license must not place rest rictions on other software th at is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software No Discrimination Against Persons or Groups The license must not discriminate ag ainst any person or group of persons License Must Be Technology-Neutral No provision of the license may be predicat ed on any individual technology or style of interface The Free Software Foundations Necessary Freedoms of Open Source Software Criteria Description Freedom 0: Users should be able to r un the program, for any purpose Freedom 1 Users should be able to study how the program works, and adapt it to your needs Freedom 2 Users should be able to redistribute copies so you can help your neighbor Freedom 3 Users should be able to improve the progr am, and release your improvements to the public, so that the whol e community benefits
293 Historical Definitions of Open Source Software Social scientists have used two differe nt approaches to define open source software. The first method has focused on identifying and describing the different generations, or stages, of the software. This historical perspective examines the different legal and social events that have affect ed the open source phenomenon (Raymond 1999, Lerner and Tirole 2002, von Hippel and von Krogh 2003, Fitzgerald 2007). When these different historical perspectives are combined four different stages or generations of open source software can be identif ied. Table 3a highlights thes e different periods of time, highlighting different trends and events that occurred during these periods.
294 Table 3a. Identifying Open Source Software Generations Examination of Table 3a reveals that the eras overlap. For example Cygnus Solutions, the first company created to s upport OSS, was created in 1989. But it would take almost ten years for other organizati ons to pursue open source business models. Generation overlap may be caused by the lack of a single governing body that has the power to label how specific events influe nce the community. Or perhaps generational overlap indicates that the open source community is simila r to other groups in that it takes time for new ideas to diffuse through a population. Time line Characteristics of Generation Specific Event Year Unix development begins 1969 Lawsuit forces IBM to separate its hardware and software 1969 1960s1980s (Shareware) Aopyrighted software packages. Arpanet developed 1969 Kermit development begins 1981 Sendmail development begins 1981 MIT Commercialization of some source code 1984 Free Software Foundation founded 1985 GPL created 1985 Perl development begins 1986 1980s-1990s (Free Software) Commercialization of copyrighted software packages. Beginnings of open source movement Cygnus Solutions founded 1989 Linux development begins 1991 Apache development begins 1994 RedHat founded 1995 1990s (Free and Open Source Software) Volume and diversity of OSS contributions increases exponentially with the Internet use. Most open source projects limited to infrastructure and utilities. Open Source agreed upon term for the software movement 1998 Netscape adopts OSS 1998 Opens Source Initiative founded 1998 NASA experiments with open source solutions 2000 1990s-2000s (Open Source Software 2.0) Open source business models gain greater traction in traditional organizations More visible open source applications emerge. Brazilian government adopts open source software solutions 2005
295 Regardless of why eras overlap, resear chers agree that there are over-arching trends (Lerner and Tirole 2002, von Hippe l and von Krogh 2003, Fitzgerald 2007). This is useful to define open source software since it indicates th at the open source community changes over time. It also highl ights the importance of a community and communication within the community, as well as the absence of a single governing body. Therefore the generational approach extends the definition of OSS to include not only a license and a group of developers but also a changing community that has imperfect communication and a decentralized struct ure, as being essential to OSS. Defining Open Source Software The three different sources examined in this section have each highlighted important characteristics of what open source software is Integrated, they create a working definition of OSS for this study. The first part of the definition focuses on the license. To be considered OSS, an application must have a GPL-like license. This is in keeping with the OSI and FSF as these groups use the GPL as the benchmark to certify other licenses as being open source or not. The second part of this studys definition incorporates aspects from open source activists. Both the OSI and FSF believe that it is essential to allow a group of individuals to be able to access, modify, and redistribute an OSS. This differs from the license itself by requiring a group of people to be associated with the technology. Finally the generational or historical perspective that academics have used to define OSS emphasizes the need for change. OSS apparently changes over time, in
296 development, application and in personnel. Th erefore, this research defines open source software as an application licensed under the GPL which provides a developer community the opportunity to extend or modify the appli cation. This definition ties together aspects from licensing, OSS Activis ts and academic perspectives. It also recognizes that open source softwa re is an evolving IT artif act intrinsically linked to a community of developers.
297 Appendix C. John Godfrey Saxe's (1816-1887) version of the famous Indian legend It was six men of Indostan To learning much inclined, Who went to see the Elephant (Though all of them were blind), That each by observation Might satisfy his mind. The First approach'd the Elephant, And happening to fall Against his broad and sturdy side, At once began to bawl: "God bless me! but the Elephant Is very like a wall!" The Second feeling of the tusk, Cried, -"Ho! what have we here So very round and smooth and sharp? To me 'tis mighty clear This wonder of an Elephant Is very like a spear!" The Third approached the animal, And happening to take The squirming trunk within his hands, Thus boldly up and spake: "I see," quoth he, "the Elephant Is very like a snake!" The Fourth reached out his eager hand, And felt about the knee. "What most this wondrous beast is like Is mighty plain," quoth he, "'Tis clear enough the Elephant Is very like a tree!" The Fifth who chanced to touch the ear, Said: "E'en the blindest man Can tell what this resembles most; Deny the fact who can, This marvel of an Elephant
298 Is very like a fan!" The Sixth no sooner had begun About the beast to grope, Then, seizing on the swinging tail That fell within his scope, "I see," quoth he, "the Elephant Is very like a rope!" And so these men of Indostan Disputed loud and long, Each in his own opinion Exceeding stiff and strong, Though each was partly in the right, And all were in the wrong! MORAL. So oft in theologic wars, The disputants, I ween, Rail on in utter ignorance Of what each other mean, And prate about an Elephant Not one of them has seen!
299 Appendix D: Interview Questions for Semi-Structured Interview Introduction: To start us off I was curious if you underst ood what we are doing here? We are here on behalf of the city to look at knowledge management and innova tion best practices here in the IT department. We have an agreement with the city, not onl y to come and interview you, but to remain anonymous. In other words you will not be named directly nor will the city in any report or writing that we do. Additionally the city will remain anonymous when create any larger reports or articles. With that being said, please tell us your name, job title and how you got here! I. Knowledge Management What is the city philosophy towards IT What is the philosophy of the IT department What is the most effective way to incr ease effectiveness and efficiency here? Are there any motivations fo r reducing budgets/spending here? Are there any new strategi c initiatives going on here? Do you communicate the career oppor tunities here at the city? How does the city of use vendors? What are vendors used for? How important are vendor s to IT operations? Does the department use Systems Development Lifecycle project methods? a. Training/Skills development Does the department subsidize or promote employees to get certifications or further education? How does the department identify new skill sets or training for employees?
300 Does the department reward or recogni ze individuals who develop themselves? Are employees rotated throughout the areas of the department? b. Blogs or document repositories Does the department keep existing record s or documentation on existing systems? Are these records updated to refl ect changes to the systems? Are these records used to determine future enhancements or directions for the system? Does the department have blogs or message boards to help members accomplish tasks or report what happened on a project? If so, does anyone manage these boards? Is it easy to find materials or le ssons that others have learned in the departmental records? Have you found anything in the records or blog that has actually been helpful? Would you use a blog or web page that cap tured prior projects and technical help? c. Mentoring Does the department have a mentoring program? Does the department participate in external mentoring programs? Do you have any peers who help you with your work? If so, how do they help you? d. HR practices How does the department identify employees to fire or hire? How long does it take the average department memb er to get up to speed? What is involved in finding an employ ee who is a good fit for the department? Does the department have an internship program? Has anyone retired or been let go who was a gr eat loss because of their familiarity with the system?
301 II. Knowledge types a. Technical What computer languages are comm only used in the department? How many different oper ating systems are used in the department? How many different softwa re packages are used in the department? For the technology that you use/develop/s upport where do you get training/skills development and ongoing support? b. Contextual Do you know of any departments that have th eir own IT staff? If so, which ones. Why do you think they have their own staff? Are there departments that have complex opera tions that need consultants or specific feedback to work on their systems? If so, which ones? Who generally participates in these projects or tasks? III. Innovation a. Lead user In your opinion, who is the most innovative or creative member of the IT department? If you were in trouble with a tec hnical problem who would you turn to? If you needed some advice to come up with a new idea or solution to a problem who would you turn to? b. Reengineering/Tasks Are employees ever given time to examine wh at they do and to see if they could do it better? Does the department give you enough time to plan or come up with new ideas to meet your responsibilities? How does the department identify replacemen t technologies for existing hardware or software?
302 c. New Initiatives When the department identifies a project or new need, who gets involved in the process of analyzing, designing and implementing the solution? When given an assignment or project how much flexibility do you have? Are you given an objective to achieve or are you given a technology to implement? How are new capabilities, such as GIS, approved by the city government? How are new projects approved by the city government? How are new projects or initiatives imple mented? Are they phased in? Are they mandated? Are they locally deployed? Are they optional (by individu al, by department)? e. Idea generation How does the department find out about new technologies and how they compare to old technologies? How does the department come up with new ideas to meet its goals? Who is involved in coming up with new ideas or projects to help the department? Where do most new ideas come from? Uppe r management? End users? IT staff? f. Purchasing How does the department identify new technolog ies (hardware or software) for purchase? How does the department purchase new hardware or software? Are there any strategies in making these purchases? How often does the department replace its hardware or upgrade its software? Open Source Does the department use open source software? Has the use of open source software changed anything in the department?
303 Would the department have a local resource to draw on to start an open source initiative? (I.E. is there someone in the department th at supports Open Source and promotes its use?) Fads and Fashion Would the city need to see an exam ple to implement OSS in the city? Does the city know of any OSS implementations in the area? Technical knowledge In your opinion how different a knowledge ba se, i.e. coding, implementation, training, support, and use, would open source software be for the city? To shif t to OSS equivalents of the operating system and enterprise packages (office, email) would this be a radical or routine implementation? Attitudes and culture How open to new ideas and to chan ge is the city IT department? How much do the different city depa rtments share with one another? If OSS is used and they have worked in non-governmental setting could you comment on the fit between organizational va lues and the values of OSS. Knowledge externalities Who do you consider your professional network? Do you read any technical or trad e magazines? If so, which ones? Do you attend any IT conferences for the c ity IT department? If so, which ones? Do you interact with your organi zational equivalent from other city IT departments? If so, who? How often? When? Formally or informally? How would you feel about following advice or suggestions from members of other city IT departments? How would you describe the department s use of consultants and vendors? Does the department utilize any free res ources on the Internet? If so, which ones?
304 Does the department partic ipate in any open source comm unities? If so, which ones? Cost Management In your opinion, how could the department cut costs? Are there any initiatives, such as energy management initiatives, that havent been considered? If your department cuts cost s does the annual budget shrink? Are there any incentives for a department to cut costs? Are there any incentives for a department to minimize the number of vendors it has relations with? Are there any incentives for a department to increase the number of vendors it has relations with?
305 Appendix E Municipal and Muni cipal IT Department Sizes Table 1. Participant Size Characteristics City Name 2007 City Populati on 2007 City Budget* City Em ployees City Departments Jackson 250,000+ 725+ 4,000+ 30+ Columbus 250,000+ 550+ 3,000+ 30+ Roswell 75,000+ 125+ 900+ 15+ Bowling Green 90,000+ 535+ 2,000+ 15+ Decatur 150,000+ 725+ 3,000+ 25+ *Millions of dollars Table 2. Case Site Budgets and Employees City Surname 2007 IT Departme nt Budget* IT Department Employees Tenure of Centralized IT Department Jackson 13+ 80+ 10+ years** Columbus 10+ 60+ 10+ years** Roswell 2+ 20+ 20+ years Bowling Green 12+ 60+ 2+ years Decatur 15+ 60+ 10+ years** *Millions of dollars **Not sole IT department within the Municipality
306 About the Author Del received a Bachelors Degree in Management Information Systems from the University of Alabama and a Master of Sc ience in Management Information Systems from Texas Tech University. Before his doctoral studies he was a competitive swimmer, racquetball player, martial ar tist and an avid gamer.