The Long Now of Technology Infrastructure: Articulating Tensions in Development*

Journal of the Association for Information S

ystems

Abstract

Designing e-infrastructure is work conducted today with an eye toward long-term sustainability. Participants in such development projects find themselves caught with one foot in the demands of the present and the other in a desired future. In this paper we seek to capture participants’ formulation of problems as they go about developing long-term information infrastructure.

Drawing from cross-case ethnographic studies of four US e-infrastructure projects for the earth and environmental sciences (cyberinfrastructure), we trace nine tensions as they are framed and articulated by participants. To assist in understanding participants' orientations we abstract three concerns – motivating contribution, aligning end goals, and designing for use – which manifest themselves uniquely at each of the ‘scales of infrastructure': institutionalization, the organization of work, and enacting technology. The concept of "the long now" helps us understand that participants seek to simultaneously address all three concerns in long-term development endeavors.

Keywords: Long-term, Sustainability, Cyberinfrastructure, Science, eScience, Infrastructure, Communities, Ethnography, Grounded Theory

Volume 10, Special Issue, pp. 375-398, May 2009

The Long Now of Technology Infrastructure:

Articulating Tensions in Development*

1. Introduction

Infrastructure is intended to last for the long term. In ideal conditions, infrastructure invisibly supports the work of its users, while transparently revealing its functioning and breakdown to a support staff. It is a stable, accessible, and reliable environment (Star and Ruhleder 1994). However, there is something seemingly paradoxical in a long-term plan for information technology (IT). We think of IT as changing at a rapid and ever increasing pace. Yesterday’s novel solutions quickly become today’s staple resources and even more quickly become tomorrow’s relics. This is the challenge of developing e-infrastructure: transitioning effectively from one-off applications, demos, and prototypes to stable and usable informational facilities.

In order to reveal the difficulties encountered in design and implementation, we conducted a cross-case analysis of the work of participants in four e-infrastructure endeavors. We focused on participants' daily work as they went about the task of developing sustainable facilities. Our cases are drawn from projects that seek to support the work of natural scientists, specifically of earth and environmental researchers. In the United States such projects have come to be called cyberinfrastructure (CI).1 CI projects often make claims of revolutionizing research, engendering a paradigm shift or transforming scientific practice (Atkins 2003), yet many of these projects are still in the early stages of planning and development (Lawrence 2006; Lee, Dourish and Mark 2006). Whether the resources and work necessary for permanent implementation and adoption will materialize remains unclear.

Our research has ethnographic goals. We seek to capture and convey the orientation of participants as they go about the daily task of e-infrastructure design, development, and implementation. Because efforts to systematically develop e-infrastructure for the sciences are relatively recent, participants find themselves struggling to identify and articulate their challenges. We have focused on participants’ formulations of problems as tensions; in this paper we trace nine such tensions. Focusing on tensions reveals the conflicting goals, purposes, and motivations of participants. They are not hidden; rather, as a form of sense-making, participants regularly discuss their problems as tensions.

The problems participants articulate span much broader scales than technology development: they speak of encountering difficulties in the spheres of science policy, funding, organizing work and maintaining technical systems. Through our research we have developed the methodological concept of scales of infrastructure to mirror the range of participants’ activities that we have observed. The three scales are institutionalization, organizing work and technology enactment. They are what in Grounded Theory are called sensitizing concepts (Glaser 1978), serving to remind the analyst to follow participants’ activities (Latour 1987) as they work across received boundaries such as policy, management and design.

We also identify three recurring concerns of participants. These concerns manifest themselves repeatedly, but uniquely, at each scale: How can the perseverance of the infrastructure project be ensured, in the face of changing technologies, emerging standards, and uncertain institutional trajectories? How can the continued commitment of participants be secured over the timescales of building and sustaining infrastructure? Finally, how should novel technologies be designed to meaningfully support the work of users? Because studies of e-infrastructure are nascent, we do not seek to advise on how to successfully plan and implement systems meant to be used for decades. Therefore, rather than offering a programmatic response ("how to design for the long term" or “factors in CI success”), we first seek to frame the difficulties actors encounter on the ground and, thus, begin

1

In this paper we will use the terms e-infrastructure and cyberinfrastructure somewhat interchangeably; this said, the terms carry more specific implications that we will try to follow in usage. Cyberinfrastructure is an historically

American institutional configuration, primarily focusing on the sciences, and initially spearheaded by National Science Foundaiton (Atkins 2003). E-infrastructure is a more generic term for information infrastructure (often including spheres of public communication, commerce, or government) that has received stronger uptake in the European Union.

the process of defining researchable questions around e-infrastructure development.2 Just as participants encounter multiple tensions at once, here we inspect the tensions as common concerns across the scales of action. We offer the concept of the long now as an organizing principle for analyzing the work of planning and sustaining infrastructure. Long-term infrastructure is primarily an institutional consideration, beyond the scope of any single project or discipline. The long now ties together the concerns and scales, and encourages a consideration of how today’s planning will effect

tomorrow’s technologies through the practical work of designing, (re)constructing, and then maintaining these systems.

2.

The Long Now of Infrastructure

Design is work done today to enact a desired future. The design of infrastructure is particularly oriented to the long term, embodying goals such as reuse and stability, and values such as inclusion and accessibility. To help understand actors’ goals and tensions, we turn to the idea of “the long now.” The long now is a concept developed by environmentalist icon Stuart Brand and the team of philanthropists, engineers, and activists who together built the Millennium Clock. The Millennium Clock it is designed to tick once a year, chime on the century, and cuckoo every millennium. The designers plan for it to endure ten thousand years. The Clock of the Long Now is a compelling thought-piece, which we adopt to challenge short-term technocratic orientations and push us beyond the frantic pace of continuous technological turnover. To succeed, the designers and builders of the Millennium Clock brought together a collective of humans, machines, and natural resources to enable a sustainable schedule of chimes and cuckoos. Those who crafted and started the clock will not be around to see it in operation. Therefore, they had to design mechanisms that will endure for centuries and that can be replaced when they do not. They also had to find a stable environment for the device that would endure the rise and fall of cities and states, and they had to devise ways to organize maintenance to ensure that future clock tenders are identified, trained, and assigned their tasks. Thus, the long now is the varied compendium of work done today with an eye toward generating a sustainable future.

Thinking of the long term is certainly no innovation. For example, the Annales historians, and particularly Fernand Braudel, are notable for contributing the notion of the longue durée: historical time that stretches beyond individual lives and encompasses institutional and even environmental transformations (centuries and millennia, respectively). Notably, though, the longue durée is a

historiographic device for the analysis of patterns that remain invisible if limited to one or another timeframe. In contrast, Brand’s long now is a normative, materialist, and pragmatic argument: it disavows distinctions between practitioners and analysts, and calls for all to engage today in the thought and work of devising sustainable human-technical collectives. In characterizing the Millennium Clock, Brand observes, “We're going back to the early excitement about clocks. They were big, they were monumental, they were something that a city would organize itself around — the clock in Prague, the clock in Venice” (Brand and Brockman 1998). This formulation takes into account the technology of the clock itself but stretches the analytic frame to include the community and social organization; together these sustained the operation and meaning of early clocks. The kinds of enduring commitments represented by the Millennium Clock are best met through responsibilities that are both institutionalized in the form of human organizations and delegated to cleverly designed mechanisms.

Like the Millennium Clock, infrastructure requires both a more specific and a more expansive conceptualization than “technology.” To render researchable the activity of building infrastructure, we must broaden our analytic gaze across the scales of infrastructure — what in this paper we call institutionalizing, organizing work, and enacting technology — and explore temporal dimensions, particularly “the long term” (Edwards 2003). Infrastructure stretches across multiple scales of action: (i) it is a technological venture, seeking to deploy durable resources to support work, automate tedious tasks, and enable collaboration; (ii) it is a matter of human work, organization, and

2

Earlier versions of this paper were presented at GROUP 2007 (Ribes and Finholt 2007) and eSocial Science 2007 (Ribes and Finholt 2007).

maintenance, or as sociologist Susan Leigh Star reminds us, one person’s infrastructure is another person’s daily routine of upkeep (Star and Ruhleder 1994); and (iii) it is an institutional venture, seeking to provide stable and accessible services to communities at national and international levels. Below we treat each of the scales in turn.

Enacting Technology — Following Jane Fountain’s research on IT implementation efforts in digital government, we describe the practical activity of developing stable, usable infrastructure as

enactment (Fountain 2001). The notion of enactment draws attention to the work that is necessary to shift from experimental technologies to a functioning, stable infrastructure available for everyday use. Within policy and development circles, the technological aspects of information infrastructure have received the greatest research attention. For example, proposals for CI often include extensive discussions of data management and exchange, for example, how to develop tools to effectively share data across generations of participants (Zimmerman 2008), or the scalability problem, i.e., how to ensure that systems can accommodate the demands of increased numbers of users (Rodden, Mariani and Blair 1992). Data integration, metadata, and ontologies (Ribes and Bowker forthcoming; Sheth 1999) help to address the questions of how we will link the heterogeneous databases of the sciences, how we will preserve legacy archives, and how we will communicate across disciplinary boundaries. Research in these areas has produced progress for the persistence of technology, capturing organizational memory (Argyris and Schon 1996), planning for growth, and more generally, thinking beyond months or years. However, the hubris that commonly surrounds these technical solutions often hides complications experienced by developers and users. Novel platforms often do not match the extant needs of users, do not offer the functional stability that daily use demands, or lack the human resources to upgrade and maintain existing technology. Perhaps most importantly, the "immutable mobility” of data — the holy grail of many CI ventures — never persists outside the technical and organizational networks that sustain their meaning (Hackett 2008). The activities which Fountain calls enactment are the work that creates bridges between, for example, experimental and production systems or design intents and user requirements. Such fine grained “deployment” activity is often a detailed fitting process where work is hard to track and rarely acknowledged: what Star calls "invisible work" (1991).

Organizing Work — Infrastructure development (whether planning, design or deployment) is a matter of practical work. Its accomplishment is the ordinary daily activity of members (Heath, Jirotka, Luff and Hindmarsh 1993). Thus participants — particularly those in managerial roles — are regularly concerned with how their internal organizational arrangements serve to motivate participants (or not) and produce outcomes consistent with current developmental goals. Lougher and Rodden note, “The success of most projects is often dependent on the ability to effectively organize the activities of the specialists involved. As projects grow in size, complexity and lifespan this is becoming an increasingly difficult task” (1993:228). In thinking of persistent infrastructure, we must expand beyond the “tubes and wires” of technology to organizational arrangements. Just as Brand’s clock does not stand apart from its community (the clock in Venice), a physical infrastructure is enmeshed with the routines and practical work of its use, upkeep, and repair.

Studies of information systems have primarily approached the long term as a question at the intersection of technology and practice. For example, the long term is often framed as a knowledge management problem: how to develop tools that effectively serve to share information across generations of participants (Lougher and Rodden 1993), or how to preserve and communicate design rationale as individual new members join and old members retire (Lindstaedt and Schneider 1997). However, such approaches narrow the frame of analysis: “knowledge management” becomes reduced to the tools by which it is conducted. In contrast, in this paper we focus on the kinds of work

in which participants engage, such as conducting novel scientific research, developing applications, or hardening and maintaining systems.3 For instance, each of the four infrastructure projects we

3

There have been various commonly identified difficulties within infrastructure development projects. Because many contemporary CI projects are geographically distributed and composed of participants with heterogeneous expertise, much of the research on work in CI development has been around the issues of communication, collaboration, and

explore in this paper has a knowledge management component: technologically-based solutions to support long-term collaboration (Ribes and Bowker forthcoming). However, in these projects, knowledge management technologies are coupled with a concern for sustaining them and their contents over time,what Bowker has called memory practices (2006): organizational arrangements; techniques and routines for preserving and maintaining an accessible archive, repository, or database.

Institutionalizing — Along with the technical work and practical organization, we must further expand the frame to include the goal of these projects to achieve persistent institutional arrangements. Institutionalization of infrastructure is the work of generating sustainable goods and services linked to social or collective purposes, with connotations of permanence, transcending individual lives, interests, or intentions (David and Spence 2003; Selznick 1997). Cyberinfrastructure has just such institutional goals. It is intended to generate public goods through the support of research. It should endure beyond any particular scientific question, and it is often linked to governance and sustained state funding. Like the technical and organizational work characterized above, institutionalizing is a practical activity (Cambrosio 1990). Science policy and the reports of funding agencies are politicized documents with carefully worded programmatic statements that often hide the nuanced debates behind their formulation (Jasanoff 1990). Interviews with program officers at the National Science Foundation4 (NSF) reveal a complex terrain of negotiations with representatives of scientific communities, philanthropic foundations (such as Hewlett and Mellon), and participants in the e-infrastructure projects.

However, we should not assume that working to achieve institutional goals is only a top-down matter for those in policy spheres. We observed that it also became an everyday practical concern for participants in infrastructure endeavors (Pfeffer and Salancik 1974), who regularly sought to secure funding, marshal support from domain communities,5 and transform the norms and customs of their colleagues. The practical work of developing long-term e-infrastructure requires creative attention to issues of sustainable technology, persistent human arrangements, and institutional resources.

***

The scales of infrastructure reflect the range of participants’ activity as they go about the work of research, design, and deployment. However, we do not argue that the scales operate through independent logics. In planning and implementing e-infrastructure, participants link the development of technologies to the work of its enactment and to establishing institutional relations (Callon and Latour 1981). The scales, then, are sensitizing concepts (Glaser 1978): We have generated them from observing actors’ recurrent work. They serve to remind the analyst to look across the full breadth of participants’ activities as they go about the task of enacting infrastructure.

At each scale of infrastructure, our interviews uncovered a persistent set of concerns for long-term sustainability. As with the scales, the concerns are abstractions generated from grounded ethnographic research. Below, we describe our general formulation of common concerns that manifest themselves in particular ways at each scale; we describe these more fully in the empirical sections of the paper as the tensions.

Motivating contribution: How can the project ensure that participants contribute in ways that are meaningful to the achievement of community infrastructure? How can it secure the continued commitment of participants over time?

coordination (Cummings and Kiesler 2007; Finholt 2004; Olson and Olson 2000). In this paper, distanced

collaboration is discussed only to the extent that it relates to long-term sustainability.

4

This is the federal funding body for science in the US. NSF financially supports all of the cases we study in this paper.

5

Within CI circles "the domain" refers generically to the community to be served by IT: in our cases, scientists and engineers. In this paper we adopt this actors' category despite occasional chafing on the part of those labeled by the term.

Aligning end goals: Infrastructure endeavors sustain multiple ongoing goals that often compete. Furthermore, participants in development come from different scientific traditions, with diverging purposes for contributing. How are varying interests to be coordinated? Can multiple goals be satisfied while still developing effective infrastructure?

Designing for use: How can the project develop resources that will be adopted by users and serve in the future work of research? This concern is rooted in an acknowledgement that an infrastructure without users is not infrastructure at all.

The concerns recur at the three scales, but they carry differing implications for each. At the intersection of concerns and scales are the nine tensions in the development of long-term infrastructure (see Table 1). For example, the diverging end goals of individual scientists (whose focus is often conducting novel research) have implications for: (i) the development of IT resources that will serve a broader community (enacting technology); (ii) the division of labor among research, development and maintenance (organizing work); and (iii) how participants' activities can be evaluated within academic reward structures (institutionalizing).

Aligning End Goals

Project vs. facility Planned vs. emergent Inclusion vs. readiness Motivating Contribution Individual vs. community Development vs. maintenance Research vs. production quality systems Designing for Use Communities vs. constituencies Research vs. development Today’s requirements vs. tomorrow’s users

Our research goal is to understand the constitution of a general problem space for long-term e-infrastructure development and maintenance using the context of CI development. The identification of tensions is not to be understood as the prerogative of the analyst, but as the outcome of participants’ orientations as expressed in their work. The tensions are articulated by participants themselves. They express diverging goals, hopes, or desires in the daily work of enacting infrastructure. In short, not everything that could conceivably be characterized as a tension is treated as such by participants. Conversely, many of the tensions we identify are not unique to concerns for long-term sustainability. For example, in her studies of CI, Lawrence (2006) has noted a general

tension between research and development, while Lee et al. (2006) have described permeable boundaries among participants, users, and communities. In this paper, we focus particularly on how participants articulate their problems as tensions relative to the goal of achieving a long-term infrastructure.

3. Cases

and

Study

We focus on four cases of scientific e-infrastructure development. Our cases have been chosen to highlight the different scope of the long term within scientific information infrastructure endeavors. All projects are funded through NSF. Roughly speaking, our cases are drawn from the earth and environmental sciences.6 GEON is the geosciences network, with participants drawn from over 10

6

We consider this both a strength and a limitation of this research. Our cases broadly span the earth and

environmental sciences, adding comparative strength to our analysis by including (sub)disciplines with long and short histories of "informational development.". However, disciplines such as physics have much longer histories of large-scale geographically distributed and collaborative projects (Shrum, Genuth and Chompalov 2007). In contrast, historical circumstances – including levels of funding, the penetration of informational technologies and automated instrumentation – have largely distinguished the trajectories of natural and social sciences. It is beyond the scope of this paper to address how these funding asymmetries came to be; King notes that within the US, NSF purview of

social science came relatively late with the creation of an office in 1957 and a directorate in 1961 (King 1998).

Table 1: Tensions identified by actors in long-term development, parsed according to their persistent concerns and the scales of infrastructure.

disciplinary backgrounds such as geophysics (using data-intense models) and paleobotany (traditionally more observational). LTER is the Long-Term Ecological Research Network, a consortium of 26 sites across the US that seek to collect and preserve data on timescales that match environmental change. LEAD is Linked Environments for Atmospheric Discovery, an atmospheric science research project primarily focusing on mesoscale weather phenomena (e.g., tornadoes), with the hope of providing tools for real-time data analysis. WATERS is the Water and Environmental Research Systems Network, it draws together environmental engineering and hydrology in the development of a large-scale remote sensing network.

All four projects have components that participants themselves call cyberinfrastructure. While their individual goals (as stated in programmatic documents) vary by project, each has the intention of making scientific data available across disciplinary and institutional barriers; in facilitating multidisciplinary and geographically distanced collaboration; and in providing computational and analytic resources for the conduct of science. Table 2 summarizes the cases by their targeted communities, IT development goals, timeline, institutional affiliation, and funding mechanism. These five elements are our primary material for understanding how actors approach problems of the long term.

Table 2: Summary chart of four cases.

Cases GEON (Geosciences Network) LEAD (Linked Environments for Atmospheric Discovery) WATERS (Water and Environmental Research Systems) LTER (Long-Term Ecological Research) Targeted Communities Solid Earth Sciences Atmospheric Sciences and Meteorology Environmental Engineering and Hydrological Sciences Ecological Sciences IT Goals Systems, Knowledge Mediation, Visualization Workflows, Data Integration, Visualization Instrumentation, data archiving, knowledge mediation, integration Instrumentation, data archiving and integration

Timeline 5 yrs 5yrs ~25yrs with

multiple points of funded planning, review and implementation

150yr goals, 10yr program review, 6yr site review

NSF Directorates (Division) Computer and Information Science and Engineering / Geosciences Computer and Information Science and Engineering / Geosciences Engineering / Geosciences Biological Sciences/ Environmental Biology Funding Mechanism Information Technology Research (ITR) Information Technology Research (ITR) Major Research Equipment and Facilities NSF Program

We use the term "participants" to designate those involved directly in the planning, design, implementation, and maintenance of e-infrastructure. This said, the participants themselves are highly heterogeneous. The most common actors' distinction within the projects is between computer and domain scientists; however, both these categories can be further broken down. (For example, computer science includes systems engineers, database specialists, and visualization experts, while the domain scientist category in GEON includes paleobotanists, geophysicists, and metamorphic petrologists (Ribes and Bowker 2008)). Additionally, we focus on those participants, such as data and information managers, technicians, and administrative staff, who often become invisible within

England (1984) tracks some of the controversies among the US Congress, natural scientists, and the National Science Board as NSF came to fund social science (see also Kleinman and Solovey 1995). Both the “more and less experienced” disciplines are strong sites for future research on long-term thinking within the sciences.

infrastructure (Shapin 1989), but are crucial to its upkeep and maintenance.

Our data were generated through ethnographic study, including document collection, and supplemented by targeted interviews. Our main sites for field research were the meetings of principal investigators (PIs), designers, and implementers. These are occasions on which key actors regularly discuss the evaluation, strategizing, and planning of their projects. The time we spent in the field with each project varies from one year (LEAD) to three years (GEON). Additionally, each project granted us access to portions of its email listservs, providing a continuous stream of data; because these projects are geographically distributed, these email discussions often include daily planning and decision making. Finally, we have also been participants in each project, contributing to aspects of planning, proposal writing, social dimensions feedback, user studies, or requirements elicitation (Ribes and Baker 2007).

Our research was driven by grounded theory methodology (Clarke 2005; Star 1999): iterations of data collection combined with testing against substantively generated theory,and comparison across our cases and with historical and contemporary studies of infrastructure (Bowker, Baker, Millerand and Ribes forthcoming). Rather than the formal comparisons used to identify causal variables (as in the methods of difference and similarity, c.f. J.S.Mill), we approach our cases through constant comparisons (Glaser 1978): Insight is generated by contrasting grounded categories (or codes) with multiple instances drawn from the data and historical cases. The process is iterative, leading to continuous revision of those categories. The scales of infrastructure and the three concerns we identify in this paper are our own analytic categories generated through the process of data collection. The concepts of concerns and scales enable us to parse participants’ formulations of tensions. Clearly, participants’ problem identification is not always formulated as "a tension." For example, an earth science junior professor may speak of a need to publish more research in recognizable journals of geology in the hopes of achieving tenure. It is when participants contrast their departments’ demands for publication with the work of developing IT tools that the conflicting demands of infrastructure development become visible to the ethnographic observer, for example when an earth scientist speaks of “wasting” her time on the development of an ontology “when I could be spending my time” publishing in a peer reviewed journal. Articulations as tensions bring forth into discourse the conflicting priorities of participants as they go about their daily work. In this sense, our method is similar to the controversy studies of science and technology studies (Collins 1981; Fujimura and Chou 1994). Of course, science is not “made of controversies” alone (Scott, Richards and Martin 1990); rather, controversies are perspicuous sites of investigation in which assumptions, disagreements and complications are brought to light by actors themselves. Similarly, in our cases not all problems are described as tensions. However, when actors formulate their troubles as tensions, they themselves articulate their conflicting goals and competing interests.

We have found that many tensions are framed by participants in terms that will be familiar to social science readers. For example, the phrases “career trajectory” and “reward structure” – once the jargon of micro economics and the sociology of work, (c.f., (Fairweather 1993; Kling and Spector 2003) – have become part of the vernacular of CI. We argue that some articulations of tensions are drawn from and informed by social science research, because of the close relationship of social science to CI endeavors. Of the projects we study, all have had the direct participation of a social scientist (ourselves and others). The first author (Ribes) worked closely with GEON for three years; LEAD and WATERS benefited from user surveys and requirements elicitation administrated by the second author (Finholt); and LTER has many members from urban sociology. Consequently, it is not surprising to find CI peppered with social science concepts and terms. It is a finding of our studies that the tensions and problems of developing long-term infrastructure have at least partially been framed by actors locally enacting social science concepts and research. For example, social scientists have conducted user requirements elicitation and community surveys in many of the e-infrastructure projects discussed in this paper; these activities introduce the language and values of user-centered design (Mackay et al. 2000; Norman and Draper 1986; Ribes and Finholt 2008) to participants in these projects. While we will not further develop this line of reasoning in this paper, future research will continue to track the lineages of social science findings and concepts as they innovate within CI (see Ribes and Baker (2007) for a more elaborated formulation).

4. Institutionalization

Project vs. Facility

This tension refers to the difficulty in developing e-infrastructures that are intended to persist for decades, but whose financial support comes in increments of years. The majority of CI endeavors today are organized as projects. That is, they were funded under research awards with definite end dates. While participants seek to develop persistent resources, in many cases there is no explicit stipulation for how these projects will be continued following the initial award. Many participants consider this a primary tension in infrastructure design and regularly trace other problems they encounter back to their project status.

The project status and its consequences are particularly apparent for those funded under research grants. For instance, both GEON and LEAD have five-year awards under the NSF’s Information Technology Research (ITR) program. While these projects seek to provide stable resources to the earth and atmospheric sciences respectively, no systematic mechanisms are available for renewing the grant. This places a finite horizon on long-term activities and shifts efforts from developing stable informational resources to securing support for the next period: “In the last year I’ve spent just about as much time putting together presentations, writing emails and meeting with NSF as I have working on other parts of the project!” (interview, 2005).

In projects with such uncertain futures, participants have no clear sense of a preconfigured directionality for maturation (Weedman 1998); they are unable to determine the possible trajectories for shifting from short-term projects to stable systems and then to infrastructures. Instead, they describe efforts to follow multiple opportunities for securing long-term funding by chasing grant opportunities and forming loose couplings with institutions of science, in the hope that these may later become a source of sustainable financial support.7

In contrast with the project status, LTER has established itself as a relatively stable facility. LTER is an NSF program evaluated as a whole every 10 years with clear venues for funding renewal (Hobbie, Carpenter, Grimm, Gosz and Seastedt 2003). As Karasti and Baker have noted in their analysis of LTER, “The longer than usual funding cycles provide a harbor for activities such as multidisciplinary studies, network participation, and community change discussion” (Karasti and Baker 2004). For LTER participants, achieving a longer, readily renewable funding cycle has meant a shift in effort from securing funding to demonstrating effectiveness and building capacity to provide stable resources. Returning to GEON and LEAD, a great deal of effort in such projects is invested in politicking as participants seek to secure something akin to facility status. As the GEON project’s five-year cycle approached closure, one participant remarked that funding for science-centered infrastructure design is notoriously unstable. Specifically, rather than following a model for a persistent facility the “funding model is like any other NSF research project, i.e., relatively unstable!” (email, 2007). Thus, during their five years of NSF funding, GEON participants successfully sought ties to the United States Geological Survey (USGS), an American federal agency. Similarly, LEAD participants cultivated a relationship with the long-term atmospheric data organization Unidata.8 Both projects saw these institutions as a means to secure long-term sustainability, particularly in terms of funding, but also through the “authorization” an institution of science can offer to a nascent (and unpopulated) infrastructure.

7

There is a considerable range in what might constitute an “institution of science,” but it commonly refers to the federal and state funding bodies of science, universities, or consortia of universities, the leading publishers in the relevant field, or philanthropic organizations supporting scientific research. Many of the smaller CI projects will look toward larger or longer-term CI endeavors for institutional support. For example, GEON participants have considered affiliations with the instrumentation facility EarthScope, while LEAD has sought partnerships with Unidata (see below).

8

USGS is a federally supported program for earth science; while Unidata has served the atmospheric research and meteorological communities for over 20 years by brokering access to data.

Thus, the relative stability of funding shapes the sustainability of the emerging infrastructure. We call this tension projects vs. facilities. While projects such as GEON or LEAD seek to become infrastructure, in practice, participants must operate within the finite funding window of an award (often narrow by the standards of technology enactment). The tension is manifested in the need both to produce short-term (research) products and to demonstrate long-term viability. Participants find themselves distributing their time between short-term products that can be cast as “deliverables”9 for upcoming project evaluation and, at the same time, the sustained development of stable, extensible, interoperable CI. How can participants develop long-term infrastructure within funding windows that demand relatively quick turnaround? As we will see, these conditions also manifest as difficulties in effectively organizing participants’ work, which also shape the emerging technologies themselves.

Individual vs. Community Interests

Infrastructure is a community resource. In our cases, it serves the needs of scientists (geoscientists, ecologists, and so on). However, as we have noted, the development of infrastructure is a practical activity conducted by individuals. Participants express a tension between work that will satisfy their individual needs and that will contribute to functional community infrastructure. Most principal investigators are practicing scientists, either in a domain (e.g., geology, hydrology, meteorology) or in computer science. As individuals within academic career trajectories (Fairweather 1993; Kling and Spector 2003), they develop concerns for meeting disciplinary criteria for advancement. In science these usually include research findings, contributions to a base of knowledge, and publications. Career trajectories are said to be institutional in that they are distributed across, for example, scientific norms (e.g., what counts as a significant contribution), the prestige accorded to different types of publication (journal articles vs. web-distributed data vs. metadata), and one's position within an organization (e.g., tenure-track professor vs. research scientist). Developing infrastructure can mean spending time designing or building information technologies, activities that may not directly advance an individual’s research and fall outside traditional career reward systems.

CI projects are often planned to address particular "science questions," in the hope of ensuring contributions to the domain field (Ribes and Bowker 2008). For example, participants in WATERS have identified “grand challenge” science questions driving contemporary hydrology and environmental engineering such as, “How do we detect and predict waterborne hazards in real time?” Meanwhile, the infrastructure itself is intended to serve not narrow or idiosyncratic agendas, but rather the broader community’s diverse research requirements. For example, data should be accessibly catalogued rather than hoarded; tools should support an array of general scientific research tasks rather than the particular needs of a given researcher; computing cycles should be allocated through transparent mechanisms rather than by an invisible college. Since tools developed to engage particular research questions do not automatically translate to those that will support a community’s long-term scientific activity (Greenberg 1991), a tension emerges between career rewards and community interests: while individual needs must be met today, participants must also develop tools that will serve the future research tasks of a community.

The tension is often expressed as a concern for the welfare of junior researchers. For example, many GEON participants are graduate students in the earth sciences. As part of their training, geologists must generate and publish new knowledge about the earth; however, as participants in an infrastructure development project, many of these students have instead dedicated substantial portions of their time to coding metadata for geological databases, or fine-tuning knowledge representations that will later assist in searches or for registering data. While these are clear contributions to the informational resources of the geosciences, many earth scientists would not consider them contributions to geoscience or, in GEON’s common parlance, “something new about the Rockies.” In the future, these graduate students may have difficulty justifying their expertise as “geological” to their doctoral committees, or they may appear less qualified to a hiring agency. How can infrastructure projects reward activities that develop community resources while still furthering the career interests of individual scientists?

9

Very often in the form of demonstration tools (or “demos”) which point to promising future capacities, but which are not of production quality (see below).

General Communities vs. Specific Constituencies

Each of the e-infrastructure projects we have studied has a mandate to serve particular scientific communities. For example, GEON serves the geosciences community. However, we should not take the communities of infrastructure as a given. Participants regularly debate the questions: "What is the community?" and "What does the community want?" Answers to these questions shift substantially over time. As they seek to become facilities, the prospecting activities of project participants lead to shifting alliances. We shall use the term community to refer to the general body of the domain and

constituency to refer to the more particular groups and organizations tied to the project. For example, while WATERS is intended to serve the community of hydrologists, more practically, it is organizationally tied to a consortium of hydrologists at 121 universities called CUAHSI,10 which is the WATERS constituency. Communities are amorphous and abstract entities that come to be represented by constituencies: particular research groups and scientific organizations.

Funding structures and organizational alliances shift over time as infrastructures institutionalize. When such shifts occur, constituencies may be completely overturned. For example, the WATERS network began in 2005 as CLEANER: Collaborative Large-scale Engineering Analysis Network for Environmental Research. CLEANER’s IT resources were to be directed primarily at the environmental engineering community. However, goals for data integration and cost-sharing eventually led to an alliance between environmental engineers and hydrological scientists. The boundary between these two groups of researchers is blurry. Both study fresh water, but within NSF they are funded through two distinct organizational units. Additionally, engineers tend to identify as practically oriented, while scientists tend to emphasize knowledge production. In 2006 CUAHSI was added to the CLEANER team, and the project was renamed WATERS to reflect its plans to serve both constituencies. Participants in WATERS — now including both hydrologists and environmental engineers — asked themselves: "What does the new community of fresh water researchers look like"? A survey was commissioned to begin outlining the shape of the WATERS community, and to elicit requirements that would inform the construction of cyberinfrastructure. Survey and requirements elicitation results showed that many hydrologists and environmental engineers were willing to cross-identify as part of the same community and often published in the same journals. However, the results also showed that particular constituencies wanted access to differing databases, and even that software technologies themselves would have to tailored across these: “tools will need to allow flexibility within the search function so that researchers can find data based on specific measures or variables of interest, whether they are geographic, time based, or some other metric” (Finholt and Van Briesen 2007). While WATERS was always intended to serve researchers focusing on fresh water (community), its changing configuration of partners (constituency) required adjustments in the developmental trajectories of its IT technology.

As participants shape their ties to the institutions of science, their mandated constituencies also come to shift. In turn, this results in a shift in the direction of technological development and in the adoption of community specific data standards or even vocabularies (Bowker 2000). The “communities” of infrastructure are emergent phenomena. They come to be known by methods such as surveys, and their boundaries are continuously renegotiated by community representatives (Latour 2005; Ribes and Finholt 2008). For participants in design, a significant transformation of the constituency means a new set of intended users and work patterns, new kinds of research questions, and new sets of data to integrate. Changing constituencies also mean adjusting research and technological development trajectories is necessary. In the development of infrastructure, its purpose is a moving target.

5. Organizing

Work

Planned vs. Emergent Organization

Larger CI endeavors such as WATERS and LTER rely heavily on project management tools to define, orchestrate, and track milestones (e.g., Gantt charts, organizational charts, work breakdown

10

structures, earned value calculations). Smaller endeavors such as LEAD and GEON have less formalized structures, but still outline their trajectories and timelines, regularly referring back to their funding proposals (Ribes and Bowker 2008). However, CI's novelty often causes it to defy the planning processes used in more familiar arenas, due both to unknowns about the underlying technology (e.g., will something that works for hundreds of users scale to thousands?) and to uncertainty about constituencies and user requirements. As a result, enormous energy can be expended on low-level technical work that never makes it into production infrastructure, or that is rejected on delivery.

This tension links back to the institutionalization of the project: future funding and targeted communities can shift with institutional couplings. For example, as LEAD has increasingly tied itself to Unidata (see projects vs. facilities, above) it has had to align its goals with that institution’s mandates. While LEAD’s informational resources could be useful to biologists or ecologists (as was suggested in their funding proposal), Unidata serves the atmospheric sciences. Referring to Unidata as their future "host," a LEAD participant wrote in an email:

Any broadening of who the infrastructure can target needs to be done within the scope of the community Unidata can and is willing to support. So that necessarily limits the "science-customer" to atmospheric and possibly geosciences. I see the host and customer as tied together — if we venture from one, we necessarily have to revisit the other (email, 2/2007)

Plans are a form of work. Carefully crafted, they involve substantial investments of time. Successful funding proposals require detailed, well-considered plans, while project evaluations often judge performance relative to stated plans. Yet at the same time, infrastructure projects find themselves having to maintain flexibility in the face of unstable funding situations, emerging technologies, or the requirements of their constituencies.

This tension can manifest itself as frustration with the changing priorities of the project. For example, in CI projects we can see shifting relations between computer and domain science participants: as the funding from ITR (which emphasizes novel IT research) comes to an end, projects such as GEON and LEAD have found themselves with stronger institutional ties to the domain rather than computer science. Unsurprisingly, it is geo- and atmospheric scientists rather than computer scientists who find the resources of these e-infrastructures most promising. As GEON and LEAD come to be funded by geo- and atmospheric science institutions, rather than computer science institutions, they will necessarily require a significant downscaling of their IT research elements in favor of domain science. Obviously, this is not only a shift in identity, but also a transformation of the kinds of work done in the project, and thus, the principal investigators based in computer science may not renew their commitment to a project once the IT research budget has dwindled.

As the future trajectory of development shifts, carefully laid plans, divisions of labor and even technological trajectories may be abandoned. Members of these projects signed on to participate in particular ways, but over time, emerging requirements may leave their contributions marginalized or demanding significant reworking.

Research vs. Development

Many participants in CI are scientists. As they describe themselves, scientists’ personal interests, institutionalized career trajectories, and community norms encourage contributions in the form of new knowledge. This applies equally to computer and domain scientists. Furthermore, projects funded as research (such as those under ITR: LEAD and GEON) are partially evaluated on their "science contributions." For example, GEON’s first funding proposal was rejected for leaning too far in the direction of technology deployment and not emphasizing geoscience research; in addition to infrastructure development, GEON participants must also generate original geoscience research. However, committing to infrastructure development means a significant amount of effort devoted to basic technical work or implementation, e.g. writing metadata, debugging, and usability testing. While critical, such work is difficult to frame as science research (even for IT participants). A novel

visualization tool may be interesting for the hydrologist, but it does not count as a contribution to the field; that same tool may be an effective application of IT, but not an interesting piece of computer science research.

These diverging requirements within CI projects make the organization of work difficult and lead to a tension between conductingnovel research and doing the basic technical development work. What is an equitable distribution of such activities amongst participants? In particular, for computer science participants, there is a continuous negotiation of the thin line between supporting tool development and slipping into a service capacity:

Weighted too heavily toward the domain scientists, the focus overemphasizes procurement of existing technologies, and computer scientists become viewed as “merely” consultants and implementers. If the weight shifts too heavily toward computer science, the needs of end users may not be sufficiently addressed, or effort shifts too heavily toward creating new technologies with insufficient attention to stability and user support (Atkins 2003: 4.3-4.4).

As do many participants, the Atkins Report11 frames this tension as a balance: lean too far in one direction, and computer scientists become technical support staff, not creators of novel technologies; lean too far in the other, and the technical systems created by computer scientists may demonstrate elegant algorithms but be too distant from actual work practices to serve domain-science research. For example, the initial LEAD proposal did not include time and resources for requirements elicitation or usability testing. While these are crucial elements in designing systems that users will find accessible and intuitive, such activities do not constitute research for either computer or atmospheric scientists. Because of this, they easily fall out of consideration by science funding agencies; proposal reviewers may even look upon an allotment of resources to such activities as outside the range of research funding. Over time, LEAD found additional resources and personnel to fill these roles, but the effort required to do so was not credited by existing modes of evaluation.

Dividing time between research and development often becomes a problem for the administrative or managerial agents in CI: How can projects organize the work such that participants are both conducting research and performing the more basic technical tasks required to deliver production CI systems?

Development vs. Maintenance

True utility services cannot be available one day and not another. Telephones do not crash; power supplies do not fluctuate; and clocks do not halt (in general). This stability is not only a function of technology but of its everyday human work, of repair and maintenance (Graham and Thrift 2007). Similarly, a computational tool supporting everyday scientific work must be reliable across time; it must be maintained. In the previous section, we described a tension between research and technical development. Here, we further subdivide "technical work" in CI projects to include maintenance. Building CI itself is development, but once that phase is completed the operation of these systems must be sustained. We have already noted that development work falls behind research activities in importance; participants describe the development of new knowledge as their primary interest. Maintenance work usually gets even less attention: In projects without long-term support (such as GEON and LEAD), maintenance is well outside the scope of initial planning. Yet even within a five-year cycle, maintenance, repair, and upgrading will be required. Computing systems today are continuously tweaked, updated, or modified; just to keep up, CI requires maintenance. A tension emerges between the need to develop new infrastructural resources and the continuous work of fixing and updating existing resources.

For example, LTER has the mandate not only to support today’s ecological research, but also to think

11

The Atkins Report is a key programmatic document within Cyberinfrastructure circles. The report set forth a vision

ahead to its future. LTER information managers have described a struggle to balance the everyday “to-do” lists of LTER scientists as they go about accessing data or conducting research, and finding the time to implement new database technologies so as to preserve archives. The tension is often framed as a matter of time management. An LTER information manager, tasked with facilitating access to data but also with planning future archival systems, expressed this as a balance:

On the one hand, I know we have to keep it all running, but on the other, LTER is about long-term data archiving. If we want to do that, we have to have the time to test and enact new approaches. But if we’re working on the to-do lists, we aren’t working on the tomorrow-list (workgroup discussion 10/05).

The tension described here involves not only time management, but also the differing valuations placed on these kinds of work. The implicit hierarchy places scientific research first, followed by deployment of new analytic tools and resources, and trailed by maintenance work. Trigg and Bødker have characterized a dialectic relationship between development and maintenance by identifying organizational members they call “tailors,” who, in the activity of maintaining a technical system, also adjust the organization of work around it (1994). To understand maintenance, Trigg and Bødker tie the work of organizational change to technological transformations, arguing that it is through minor adjustments to both that technological development is conducted. The concept of tailoring partially captures the activities of LTER information managers, but it fails to reflect the work of negotiating competing requirements within information infrastructure design. While in an ideal situation development could be tied to everyday maintenance, in practice, maintenance work is often invisible and undervalued. As Star notes, infrastructure becomes visible upon breakdown, and only then is attention directed at its everyday workings (1999). Scientists are said to be rewarded for producing new knowledge, developers for successfully implementing a novel technology, but the work of maintenance (while crucial) is often thankless, of low status, and difficult to track. How can projects support the distribution of work across research, development, and maintenance?

It is said that the sciences are structured to reward (e.g., recognition, tenure, funding) the production of new knowledge, new data, or new analytic approaches. In the case of infrastructure, however, the range of work required and outputs desired are much broader. One often suggested solution involves transforming incentive structures in the sciences. For example, one could be rewarded, on par with publication, for registering data properly in an accessible database; a new visualization tool could be assessed as a novel methodological contribution; or an ingenious metadata standard could be evaluated as a form of new knowledge. However, altering incentives is a slow and uphill undertaking. The reward systems of the sciences are deeply entrenched within their multiple academic institutions: editorial staff of journals, publishers, funding agencies, and academic departments. Another possibility, then, might be the reconstitution of participants through the design of CI: While most CI ventures are currently spearheaded, managed, and enacted by scientists themselves (domain + computer), responsibility could be distributed to others who are already rewarded for deployment and maintenance work. For example, LTER has a well organized subsection of information managers who maintain scientific databases and the systems for accessing them (Baker, Benson, Henshaw, Blodgett, Porter and Stafford 2000). Another example is LEAD, which did not originally receive funding for requirements collection then sought out additional resources and partners to fill these roles (Lawrence 2006; Lawrence, Finholt and Kim 2006). This strategy does not entail transforming career trajectories and reward systems; instead, new participants (and roles) are added who provide services, perform upkeep, and ensure the usability of systems.

6. Enacting

Technology

Inclusion vs. Readiness

A primary goal of CI is to develop an “umbrella infrastructure” that will serve the research needs of diverse scientists and help foster communication and collaboration across disciplines. For example, WATERS serves both hydrologists and environmental engineers, while GEON serves geoscientists, e.g., paleobotanists, metamorphic petrologists, and geophysicists, to name only a few. In practice, however, participants-in-design find that the various fields differ in their readiness for the technologies

of CI. Resources relevant for one subset are not necessarily relevant for another. Under such constraints, a tension emerges between goals for inclusion and readiness across differently prepared scientific fields.

For example, GEON participants came to understand that seismologists and geophysicists have long traditions of using remote instrumentation and shared databases, while paleobotanists and metamorphic petrologists are field scientists, more familiar with smaller-scale data collection conducted within their own research teams. GEON’s metamorphic petrologists describe their data as distributed in a multitude of publications. This group must begin the development of CI with a process of digitization, database design, and metadata creation; meanwhile, geochemists are much further along in that process, with parallel data integration efforts such as EarthChem, initiated in 2003 with the goal of interoperating three major geochemistry databases.12 Such efforts place the geochemistry community in a better position to take advantage of high-end computing resources offered by GEON. Thus, GEON’s technologies for data integration and knowledge mediation are more relevant for "data rich" geochemistry and seismology than for the field sciences. Thus, from the perspective of CI deployment, the data of some fields are more readily available for federation than others. However, if development efforts are only directed at the "ready" community of geochemists, an uneven deployment of CI may result, leaving (for example) metamorphic petrologists well outside the umbrella infrastructure. Inclusion is also a matter of attempting to distribute CI evenly.

There is a great danger of reproducing divisions between the resource rich and resource poor among scientists -- such divisions will come to be reflected and sustained in technological development trajectories. Among the strongest rationales for CI is its capacity to enable interdisciplinary research, crossing boundaries of method, technical language, or data structure. For example, Olson and Olson (2000) observe that successful adoption and use of CI demands both social and technical readiness. That is, a community must already have an orientation to collaboration sufficient to make enhanced cooperation a (perceived) benefit. Also, where enhanced collaboration depends on technology, the community must have sufficient experience to recognize useful systems and services. Such experience is gained over time, while technology decisions must often be made relatively quickly. A short-term consequence of uneven development of e-infrastructure is the marginalization of participants. Star and Ruhleder (1994) have described such actors as the "orphans" of infrastructure. This is true for access to both the “hard” and “soft” foundations of CI (David 2004): computing and network capacity, on the one hand, and on the other, the community’s experience collaborating or its willingness to share data. Just as some fields are "data rich" (or poor), the ability to work in teams or collaborate across disciplinary difference is a learned skill supported by community resources; some disciplines have achieved greater skills in this respect than others. Within any given spectrum of sciences, developmental gaps emerge between subfields (Nentwich 2003). For example, compared with physics or bioinformatics, the environmental sciences have less experience with technology-mediated collaboration, standardized data collection, remote instrumentation, and data sharing. At a finer granularity, within the earth sciences, we have already discussed the variable readiness of GEON’s participating disciplines to adopt high-end CI. Over the long term, differential development could create an increased “digital divide” as development resources are funneled to those with already established technical bases; Jackson et al. (2007) have warned of the danger that infrastructure may be "captured" as resources accumulate among disciplines with long histories of technical investment.

Today’s Requirements vs. Tomorrow’s Uses

Designing an information infrastructure is a visionary process. CI tools are intended to support the work of scientists not only today, but also tomorrow. Information technology is changing rapidly, as are the scientific practices and instruments tied to those technologies. "The needs of users," then, are a moving target, notoriously difficult to capture through user self-reports, surveys, or ethnographies

12

The three geochemical databases are PetDB, NAVDAT,GEOROC; for more details see: (Walker, Lehnert, Hofmann, Sarbas and Carlson 2005).

(Jirotka and Goguen 1994).13 If development matches users' stated requirements, the results are rarely innovative, while if empirical requirements are disavowed in favor of imagined uses, design innovations face a greater risk of failing to be adopted.

LEAD participants collected user requirements through surveys and interviews. The results from atmospheric scientists showed that members of that community were most interested in tools that would support their use of, for example, spreadsheets to manipulate data (specifically noted was Microsoft Excel). Today, spreadsheets remain a staple tool of atmospheric scientists for arranging and manipulating their data. However, for a high-end technology development project such as LEAD, this simple method based on existing software directly contradicts the vision of "revolutionizing scientific practice" or conducting cutting edge computer science. Nominally, LEAD should facilitate the migration of atmospheric science from "stovepipe" solutions that make data-sharing difficult (such as using spreadsheets to store data) to open and interoperable relational databases. There is a gap between requirements as stated by users, and a future vision of technologically enabled scientific practice.

GEON participants made similar assessments, noting that requirements elicitation is not usually a forward looking activity. When it is, expectations are unrealistic:

There are two results when you ask users what they want: they will either tell you something completely banal that’s completely uninteresting to develop, or they will ask something in the range of science fiction, well beyond the current state of the art (interview 11/2003).

Put simply, the majority of domain scientists inhabit computing environments that operate on the average desktop (word processors, browsers, spreadsheets) along with a handful of specialized domain applications. When asked about a future trajectory of technological development, they respond first with their everyday computing pains, and if pushed will generate digital utopias. They do not reside at the forefront of computer science and are unable to articulate realistic novel applications. Despite this, participants acknowledge that they cannot altogether abandon requirements elicitation. Software engineers are increasingly well versed in the danger of designing systems independent of involvement with users. Paraphrasing Suchman, software that is "tossed over the design wall" (1994) — systems designed without consideration for users' work patterns — often leaves large gaps between work routines and technical capacities. A tension emerges between the constituencies’ demands and forward-looking development. Respecting current work practices is a key feature of successful system design, but this leaves designers with unclear trajectories for transforming scientific practice.

Research vs. Production Quality Systems

The distinction between research and production quality systems is well known within information technology circles (Suchman 1994; Weedman 1998). Research systems are the bread and butter of applied computer science. They serve as platforms for testing novel technologies, but they are renowned for their instability, poor documentation, and relative unfriendliness to the user. For example, experimental tools are often called "demos" and, as one GEON programmer noted, are notoriously limited in their functionality:

They are pretty, they do new and amazing things, and you have to stand by the user the whole time to make sure he doesn’t do a single thing you haven’t supported. Oh yeah, and it usually turns out that’s mostly what they want to do. (interview 11/2003)

In contrast, production quality systems are stable and reliable. They have been hardened through

13

A good example of the gap between explicit articulations of need and technological affordance is the popular introduction of the mouse with the Apple Macintosh computer, to which journalist John Dvorak responded with

incredulity: “The Macintosh uses an experimental pointing device called a ‘mouse.’ There is no evidence that people

want to use these things,” (emphasis added, quoted in Dourish 2004, originally San Francisco Examiner, Feb.19, 1984). In the face of novel technical capacities, what weight should be granted to the explicit articulations of users?

field and user testing, and are designed with concern for usability, with intuitive interfaces and thorough documentation. However, as discussed above, the development of stable, tried-and-true applications is not often considered a "contribution" to computer science. Hardening and user testing are involved, mundane and technical tasks with few research outputs. Under such constraints, a tension emerges between producing systems that qualify as computer science research and creating stable, reliable resources for a community of everyday users.

The rhetoric of cyberinfrastructure usually emphasizes changing the daily practices and methods of scientific research. However, such formulations underemphasize the instability of novel applications. For everyday users, instability of their applications can be a substantial deterrent to uptake. As one LEAD developer noted of atmospheric scientists: “They’re willing to give our stuff a try, but the second time it breaks while they’re using it they’ll never come back… What they want is reliability, and ubiquitous reliability is the critical part” (workgroup discussion 12/06). The consequence may be disillusioned users unwilling to migrate to new infrastructures, leaving a landscape dotted with promising but unpopulated computational architectures.

This tension dovetails with previous problems we have described in this paper, but unlike, for example, the organization of work, technology enactment has direct downstream consequences for users of infrastructure. We have already described the institutionalized reward systems for researchers and the difficulties this raises in organizing development or maintenance work. The resulting dynamic also affects the emerging technology itself as systems are geared to serve either further IT research or

practical uses for domain scientists. How can projects design technology systems with the stability necessary for the average user while also continuing to enable novel computer science applications?

7.

Assembling Heterogeneities: Time, Work, and Technology

It is a notably difficult and often unfruitful undertaking to form hard distinctions between the social and technical aspects of system development. It is best not to ask how they can be demarcated, but rather to trace the practical work that traverses them with impunity. This insight is reflected in the terminology that has come to populate the social studies of infrastructure, concepts such as: “socio-technical” (Hughes 1989), from the history of technology, which encourages the analyst to simultaneously address organization, technology, and context; “heterogeneous engineering,” which emphasizes the diversity of work in design (Law 2002); and “technoscience” (Latour 1987), from the sociology of science, which discourages a priori distinctions between scientific practice and the materials that enable research (e.g., infrastructure). This finding has also been repeatedly emphasized by social scientists collaborating with information technologists in building infrastructure (Ackerman 2000; Bowker et al. 1997; Brown and Duguid 2000; Finholt 2004; Fountain 2001; Kling and McKim 2000; Ribes and Baker 2007; Star and Ruhleder 1994): the “soft” foundations (i.e., organizational and human) of infrastructure will require just as much research and work as its “hard” foundations (i.e., technical).

The long now is a view of technology development that brings multiple concerns, and matters of organization and technology, into the single frame of action that participants encounter on a regular basis. In this section, we return to the three recurrent concerns that manifest themselves at each scale of infrastructure. Practitioners in development projects, or those familiar with the information systems or project Management literature, will find few surprises in the concerns we have articulated in this paper. It is, instead, the differential specificity with which they appear at each scale, and our treatment of them as a single set of ongoing challenges, that are the contribution of this analysis. The same concerns have differing consequences at each of the scales of activity that make up infrastructure, and they are all (with greater or lesser emphasis) simultaneously present within individual development projects.

For example, the concern we call motivating contribution has regularly been discussed as a matter of career rewards (Campbell et al. 2002; Ceci 1988; Musen 1992; Roberts et al. 2003; Stanley and Stanley 1988; Sterling and Weinkam 1990). However, the concept of career rewards is only a particular take on the larger question of motivating contribution: the concept of career rewards usually