Abstract
Understanding and evaluating systems for open collaboration depends, in part, on appreciating their normative and institutional contexts. In this article, I examine press-public collaboration by tracing how and why news organizations both distance themselves from and depend on networked actors outside the newsroom to achieve professional and organizational goals. I situate contemporary press-public networks within infrastructure scholarship, review their relationship to models of the public sphere, and trace the motivations and assumptions embedded within news organizations’ application programming interfaces, software toolkits that let those outside the newsroom access and repurpose journalistic data.
Keywords
Part of understanding why diverse actors collaborate—and the impacts such collaborations can have—entails tracing the historical, ideological, and institutional conditions under which their relationships develop.
In this article, I focus on one site of collaboration: news organizations’ motivations for designing, deploying, and regulating application programming interfaces (APIs). These APIs are essentially software toolkits that give programmers outside newsrooms with relevant interests and skills the chance to create new, derivative applications that analyze and represent news data and stories. In a sense, an API’s “openness” is relational, a negotiation between news organizations and interested programmers. If the news organization designs the API—its technical architecture, terms of service, documentation, community of practice, database content and metadata—in ways that match the terms under which programmers can and will participate, then the API can become a “generative” (Zittrain, 2006) tool with the leverage, adaptability, masterability, and accessibility desired by both news organizations and interested programmers. When the conditions of participation align and generativity is possible, news APIs become “platforms” (Gillespie, 2010): material places to see disparate actors communicating about and creating novel remixes and representations of news organization content, engaging with an infrastructure’s affordances and constraints as they create new artifacts. They can facilitate the kind of collaborations that scholars of commons-based production say are crucial for realizing the Internet’s social, economic, and political potentials (Benkler, 2003; Lessig, 2008) and help the press achieve its ideal role as a public-facing institution that enables and encourages the formation of robust public spheres.
Understanding what open and collaboration mean for news APIs, though, means situating them within a broader scholarship of how and why the press negotiates its relationships to publics. Essentially, understanding whether APIs “work” as systems for open collaboration means unpacking what openness and collaboration can or should mean between news organizations and nonemployee participants.
News APIs are contemporary markers in a long history of press-public collaboration in which news organizations have attempted both to distance themselves from and to rely on audiences. That is, while asserting their institutional independence and journalists’ roles as expert professional communicators, news organizations have also carefully and conservatively tuned their work to what they think audiences want, looking to the public for signals that they are fulfilling their roles as providers of information vital to democratic life. Today, APIs are new sites to see this double-sided notion of autonomy being worked out—where the press and software designers experiment with different meanings of public and press freedom.
To trace these negotiations, I use conceptual models borrowed from science, technology, and society (STS) studies—infrastructure, trading zones, boundary objects—to see how news organizations use APIs to mediate collaboration outside their newsrooms. Such APIs are examples of what I call “newsware”: infrastructures that structure the press’s collaborations with nonjournalist software designers I call “programming publics.” How is collaboration and control embedded in the design and use of news APIs? What rationales do news organizations offer for creating and regulating such systems, and how do these arguments both reflect and challenge norms of the traditional, mainstream press? Most broadly, how do these two seemingly disparate cultures of professional journalism and software design come together through news APIs to leave evidence of their hybrid identities, norms, and ideologies? To better appreciate the implicit, normative understandings of public embedded within networked news systems and practices, scholars of both online journalism and open collaboration might benefit from seeing their sites of inquiry though the analytical lenses of STS and its conceptual understandings of partnership, meaning making, and negotiated autonomy.
Public-Press Collaboration
Studies of press-public collaboration have historically focused on empirical and normative questions: what the press does and should do, how journalists work or should work. Some describe mechanistic and uncritical work: Journalists are people who “systematically keep a public record of events in a given time frame” (Zelizer, 2005, p. 66) at locations where people expect news to happen (e.g., during natural disasters and crimes, in city halls and police stations, or anywhere large numbers of people are gathered) in ways that are accurate, fair, and balanced (Bennett, 2007, p. 189). Others see journalists as trusted sources and public “sense makers” with obligations “to verify what information is reliable and then order it so people can grasp it efficiently” (Kovach & Rosensteil, 2001, p. 19). They are less watchdogs and more cultural curators, creating and making visible perspectives on the world essential for constructing, maintaining, and repairing the shared knowledge and “common sense” social life requires (Campbell, 1991, pp. xxii, 9).
Still others view journalists strategically, as skilled communicators who subtly engage in “multilingual, code switching from neutral interpreters to guardians of social consensus and back again without missing a beat” (Schudson, 2000, p. 193). They are hybrids, shifting easily between objective reporting and commonsense critiques, sharing readers’ implicit senses of fairness, moral outrage, and civic mission (Ettema & Glasser, 1998). Most fundamentally, journalists are expected to be both objective, professional communicators and attuned, individual interpreters (Carey, 1969/1997) who report what the public understands to be facts, never straying too far from status quos, established norms, or public expectations (Gitlin, 1980).
Implicit in these various identities are assumptions about what collaboration means—or should mean—between the press and publics: the people news organizations are expected to collaborate with and what kinds of products are supposed to emerge (Christians, Glasser, McQuail, Nordenstreng, & White, 2009, pp. 196-218).
The first and perhaps simplest model of collaboration is a representational one in which journalists act as “self-appointed and unaccountable audience representatives” (Gans, 1979, p. 238). They are akin to avatars who stand in for readers and publics, monitor power, expose abuses, and channel empathy just as readers would if they could. This model assumes Watergate-era ideals in which journalists are dogged investigators who uncover and explain corruption to a public that is assumed to share the journalist’s ethics. In practice, though, reporters often describe this kind of representational role as daunting and unrealistic. They describe a “fear of the audience,” a preference to write for friends and family instead (Gans, 1979, p. 235). And when they do encounter members of the public, journalists describe their letters to the editor and blog comments as “insane” (Wahl-Jorgensen, 2002), irrelevant, poor quality, or overtly personal (Thurman, 2008) and requiring strict journalistic oversight (Hermida & Thurman, 2008; Singer, 2010). Essentially, journalists prefer not to think about “the public” at all—and when they do, there are few positive feelings.
The second type of collaboration sees the press as responsible explainer. In this model, readers accept that journalists have access to power, people, events, and knowledge that are beyond them. They understand that journalists are specialists on their respective beats and that a certain amount of collaboration between the press and sources of power is required. For example, in wartime, reporters embedded with military units are expected not to reveal information that might be valuable to an enemy (Pfau, 2004); and investigative reporters should sometimes withhold information deemed too sensitive or damaging to an individual or state interest (Baquet & Keller, 2006). This model of collaboration reflects long-standing relationships between the press and the state, for example, postal subsidies, labor law exceptions, reliable access to elite governmental sources, and public-sector investment in the creation and regulation of press infrastructure, such as radio spectrum and the Internet (Cook, 1998; Fishman, 1980; Sigal, 1973).
But this type of collaboration has also been found to work against the press’s presumed watchdog role, making it more likely for the press to simply “index” (Bennett, 1991) existing debates and tie “story frames to the range of sources and viewpoints within official decision circles, reflecting levels of official conflict and consensus” (Bennett, Lawrence, & Livingston, 2006, p. 468). If elite sources are not debating an issue, a too closely collaborative relationship between the press and state makes it virtually impossible for news organizations to act as independent, critical explainers. To do so would mean acknowledging that the press has interests separate from the power sources it covers—that the press understands for publics, rather than simply presenting information with which they form their own opinions.
A third type of collaboration is qualitatively different from the first two and involves the press acting as a public infrastructure, creating and sustaining the conditions under which public spheres function. Historically, this has meant protecting principles of free speech in courts cases (Bollinger, 1991), structuring the institutional design of commercial broadcasting spaces (Streeter, 1996), or sponsoring studies of the press (Commission on Freedom of the Press, 1947; Knight Foundation, 2009). Today, this means designing not only news workflows to manage online conversational spaces (Domingo, 2011; Reich, 2011) but also more-experimental steps to reveal to publics how the press distributes reporting resources or decides story topics (e.g., consider the Guardian’s “Open Newslist” experiment showing how reporters are assigned stories; “An Experiment,” 2011) or shares with other media organizations and citizen journalists responsibility for creating, fact-checking, or disseminating news (e.g., consider CNN’s “iReporter,” NewsTrust’s “Truthsquad,” the Huffington Post’s “Off the Bus” initiatives, the Washington Post’s “Social Reader” Facebook app, or Lavrusik and Cameron’s [2012] guidance for driving web traffic from Facebook to news sites). This model has ideological connections to aspects of the public and citizen journalism movements, a way of seeing the press popular in the 1990s that attempted to reorient news work toward what the press imagined that publics wanted from news by creating new organizations and reporting styles that attempted to substitute “the community’s judgment, however defined, for the judgment of journalists” (Glasser, 2000, p. 684-685).
Essentially, this model collaboration entails the press working with publics through systems out of which public interests might emerge. The press’s role is more procedural (Habermas, 1996): Its focus is not on representing the reader to himself or herself or on explaining power to readers for unspoken public benefit. It is instead on creating, debating, and sustaining the systems, norms, skills, and regulatory regimes underpinning particular understandings of the public sphere. It is this third type of collaboration—the press as public infrastructure—that has most relevance to the study of news APIs. It is here that one can trace how the very idea of the online press emerges from sociotechnical dynamics that both depend on and are rendered within networked infrastructures.
Online Collaboration, Boundary Work, and the Public Sphere
If one is to understand how this third type of collaboration works, one needs to see the contemporary networked press as contingent, public infrastructure that depends on design moves. That is, there is no single way to create public spheres from networked materials—we know that public spheres rely on, reflect, and influence the sociotechnical actors who shape and inhabit them. Benkler (2006), for example, foregrounds a type of online, networked collaboration in which private individuals self-organize in commons-based arrangements to create the information and relationships arrangements that best reflect the needs and interests of assembled, participating individuals. Similarly, Lessig (1999, 2008) emphasizes that collaborative online systems should recognize the power different types of constraints (architectures, norms, laws, markets) have to regulate culture by structuring how networked information can be created, shared, and remixed. Benkler, Lessig, and other advocates of commons-based, free-culture production regimes are right to critique traditional models of intellectual property and private markets not designed for the Internet. However, if one considers not only self-organized individuals or free-culture producers but, additionally, the public interest the press ideally supports, then one is left with the question of how information infrastructures might be designed to support public spheres, not only spheres of self-organized collective action. Essentially, my unit of analysis here is not individual content producers or self-selected participants but, rather, publics who rely on infrastructures that are difficult to see, understand, or change—systems in which people may not choose to participate but that nonetheless affect civic life.
Seeing the contingent and often invisible nature of public spheres helps cast the press as part of communication infrastructure, what Bowker and Star (1999) call “scaffolding in the conduct of modern life” (p. 47). More precisely, this infrastructure is
embedded within “other structures, social arrangements and technologies,” (Star & Ruhleder, 1996; p. 113)
transparent to use without requiring reinvention or assembly for each task,
scoped beyond a single event or site of practice,
learned as a member of a group that agrees on its taken-for-grantedness,
shaping and shaped by conventions within communities of practice,
embodied in standards that define the nature of acceptable use and replication,
built on an installed base of other infrastructures with similar characteristics, and
visible only when it breaks down (Star & Ruhleder, 1996).
Infrastructure is what runs “underneath” (Star & Bowker, 2006, p. 151) to connect, regulate, and enable action—a fundamentally relational concept that, today, depends on how the Internet’s actors and materials intersect.
That is, one cannot assume the a priori existence of “collaborative” or “social” spaces as if their boundaries and constitutions were intended or are static (Latour, 2005). Rather, sociality emerges from actor-network assemblages that shift over time, seem distinct, and assume different meanings when viewed from different perspectives or through different histories. These assemblages serve as “boundary objects” (Star & Griesemer, 1989) through which communities of practice assemble, cohere, debate, and create—experimenting with different identities and interpretations as they create and revise materials that scaffold both strategic ambiguity and clarity among actors (Barley, Leonardi, & Bailey, 2012). For example, in his study of theoretical and experimental physicists (who often assert and defend their differences), Galison (1997) found evidence for what he calls “trading zones”: local contexts in which seemingly disparate ideological and epistemological communities not only coexist but create shared value and commensurability among activities and outputs. There is no universal currency or standard exchange rate of collaboration but ongoing nuanced coordination and meaning making that enables both collaboration and distinct identities. Such actor-networks, boundary objects, and trading zones reveal dependencies within and among systems, showing how communities think collaboration can—or should be—distributed and judged successful.
But acknowledging the contingent and relational nature of infrastructures gets one only so far; descriptive and procedural accounts of how collaboration within public spheres works are largely silent on how they should work. If such models are to be applicable to the design and critique of the press as public infrastructure infused with democratic meaning, one needs to ask, normatively, what kind of public sphere do I want to emerge from infrastructures, actor-networks, boundary objects, and trading zones?
There are many types of public spheres, all of which are tightly linked to theories of free speech and assumptions about how democratic institutions, such as the press, should work. A public sphere may be a
truth-seeking, inclusive space in which differences are bracketed, rationality and procedure are paramount, discussion focuses on matters of common interest, and the “media are used to create occasions for consumers to identify with the public positions or personas of others” (Calhoun, 1992, pp. 13-26; Habermas, 1989);
“weak” space in which “deliberative practice consists exclusively in opinion formation” (the goal is to develop a stance) or a “strong” space “whose discourse encompasses both opinion formation and decision making” (the goal is to know what one thinks and to reach a conclusion) (Fraser, 1992, p. 134; emphasis added);
decentered “sphere of publics” (Haas, 2004) that “includes differently situated voices that speak across their difference and are accountable to one another” (Young, 2000, p. 107), not a “comfortable place of conversation among those who share language, assumptions, and ways of looking at issues” (Young, 2000, p. 111);
counterpublic that is “by definition, formed by their conflict with the norms and contexts of their cultural environment” (Warner, 2005, p. 62) and that has “at some level, conscious or not, an awareness of subordinate status” (Warner, 2005, p. 56); or
market in which competitive forces select some ideas over others, truth is “produced by its collision with error” (Mill, 1859/1974, p. 76), and individuals’ rights to self-expression and notions of negative liberty (the freedom of individuals to be left alone to speak and hear) are of paramount concern.
Each model represents different theories of democracy, in turn making different demands on a networked press. If the press is meant to be something different from a marketplace of speech—an institution that lets publics (not self-selected, self-organizing individuals) hear diverse perspectives that self-interest, friends, markets, or algorithms may not surface (Baker, 2001; Emerson, 1981; Meiklejohn, 1948)—then one must ask what kind of public spheres networked collaborations between the press and publics assume and create.
The sociotechnical relationships of any infrastructure reflect the kind of public a particular “we”—users, designers, journalists—creates. There is a rich literature tracing and critiquing values embedded in built environments and networked information systems (Flanagin, Flanagin, & Flanagin, 2010; Friedman, Kahn, & Borning, 2006; Giroux, 2011; Klein & Kleinman, 2002; Nissenbaum, 2009; Winner, 1993), numerous studies of how well Internet-based communication supports deliberative democratic ideals (Dahlberg, 2001, 2007; Davies & Gangadharan, 2009; Shaw & Benkler, 2012), and emerging work analyzing the networked press’s relationships with audiences in terms of algorithmic information systems (Anderson, 2011), prosumer boundary work (Lewis, in press), and sociotechnical collaboration (Fortunati & Sarrica, 2010). There are, though, only a relatively few recent examples of scholars of human-computer interaction and computer-supported cooperative work connecting designers’ infrastructures, practices, and products to questions of the public sphere (e.g., Le Dantec et al., 2012; Lindtner, Chen, Hayes, & Dourish, 2011).
One needs to better understand connections among designers’ assumptions about what public means (often used as a synonym for visible or not private and focused on information or individuals), features of information infrastructures meant to support networked public spheres, people’s use of these systems for public-facing communication meant for broad audiences, and the types of public spheres that emerge when networked infrastructures encode democratic communication. The press’s networked infrastructures, and news APIs in particular, are places to see system design in tension with public sphere ideals because they bring journalists, system architects, hackers, and reading publics into conversation, collaboration, and tension.
APIs, Open Collaboration, and Newsware
An API is an interface: a set of rules by which one software program can access the resources of another software program. It is “middleware”
positioned between the operating system and the application. Viewed abstractly, [it is] a “tablecloth” that spreads itself over a heterogeneous network, concealing the complexity of the underlying technology from the application being run on it. (Puder, Romer, & Pilhofer, 2006, p. 21)
To computer scientists, an API is an abstraction that makes system design and maintenance easier, more reliable, and less costly. It is technique by which programmers can
hide and make inaccessible data or details of a system while simultaneously sanctioning and easing access to other parts of a system;
reliably plan and create new systems that combine multiple data sources;
design programs in modular, distributed ways, making it easier to isolate and test functions;
speak a common language and organize work, signaling what kind of functions and systems can be designed; and
reuse and refine code, making it less likely that work will be duplicated.
Most fundamentally, a news API is system of rules by which a distributed set of actors can build new online applications and services using data that is produced, vetted, and distributed by news organizations. It is essentially a structured and controlled way for people outside news organizations to access information created or evaluated within them. Simultaneously, it is a way for those in news organizations to experiment with technological and organizational innovation (Aitamurto & Lewis, 2011), share information beyond their normal distribution or syndication networks, and establish themselves not only as people who tell stories to audiences but also as professionals who certify data and help others to create work with that data. It is essentially one place to see how news organizations depend on and distance themselves from those outside the newsroom.
What kind of press-public collaboration is assumed in the design of and discourse around these news APIs? How do they act to encourage and constrain nonjournalists as they view and use information created and vetted by news organizations? How does the press differentiate itself from publics through these systems, and what can such distinctions teach us about how the press understands its role in a democratic, networked public sphere?
Tracing Collaboration in News Application Programming Interfaces
The Study
To answer these questions, I examined three leading news organizations’ APIs: The New York Times (NYT), the Guardian, and NPR. Between August 2010 and January 2011, I built a data set of approximately 300 publicly available documents, including
terms-of-service agreements for each API;
entries on API blog sites that are maintained by each news organization;
secondary blogs and news stories about each API;
public presentations given by news organizations and independent developers, including slides, videos, and transcripts of public talks;
code documentation for each API; and
user forums and support groups in which both developers and news organization staff ask and answer questions about the APIs.
I conducted a close, critical reading of the data set using a “categorical aggregation” technique in which the goal is to “seek a collection of [categorical] instances from data” (Creswell, 1998, p. 154) to form larger, issue-relevant meanings that connect the data to the research framework (Jones, 1996, pp. 128-129). Essentially, my goal was to trace how the press regulated its interactions with publics through the design and use of their respective APIs. This involved “reading” the APIs as technological, public-facing artifacts: analyzing their final forms, terms of service, and surrounding public discourses. Instead of tracing API design decisions and competing alternatives from within news organizations (a complementary study that would shed light on how APIs are produced), I focused on addressing the questions: How do news organizations describe their APIs, why do they say they offer them, and who do they think will use them?
Findings
Each organization describes its API as a way to access data but with slightly different emphases. NPR states that its API is a “structured way for other computer applications to get NPR stories in a predictable, flexible and powerful way” [1], positioning its API as a way to access NPR news outside of its website or member stations. NPR’s “architectural philosophy” sees the story as the “atom” of its API, as it attempts to ensure that a story can be “created once and published everywhere” [4]. The NYT API similarly describes its Developer Network API as a “premier source of data” that allows “you to programmatically access New York Times data [emphasis added] for use in your own applications” [5]; this is distinct from its main NYT.com site, which it describes as an “unparalleled source of news and information [emphasis added]” [2]. The Guardian’s Open Platform API describes itself most expansively as not just a collection of stories and data but as a “suite of services for developing digital products and applications . . . a framework for offering content, data, tools and rich user experiences” [3].
Although all three APIs offer structured and predicable ways for programmers to access information, there are three ways to distinguish among them: (a) news-focused APIs that give access to professionally produced stories and public comments on those stories (e.g., NPR), (b) data-focused APIs that are reliable storehouses of vetted and standardized information (e.g., NYT), and (c) systems-focused APIs that not only provide structured and vetted data but also serve as online communities and platforms through which programmers may maintain relationships and share resources, expertise and revenues (e.g., the Guardian).
Similarly, each organization differs in how it explains why it offers these APIs and who it envisions using them. NPR developed its API to be an “open and extensive way for our users to share and mash-up our content” [6] for two reasons, related to its member-based, publicly owned organizational structure. First, “it is critically important for NPR to provide content and services to our Member stations. The API will enable stations to get NPR content on their sites” [7]. Second, the API is critical to
NPR’s Mission to “create a more informed public.” By offering both local and national content in our API, enabling users to mash it up and use it in ways that we have not thought of or don’t have the resources to execute, we hope to reach and inform new audiences. [7]
NPR’s API is thus rooted in its desire to exchange content with its network of member stations, its organizational mission to inform publics, and, as then NPR CEO Vivian Schiller described it, a desire to capitalize on the creativity of audiences:
Imagine, really, a future where you have this incredible network where information and data could be mashed up in ways we can’t even imagine, because there are coders out there that can think about things that I will never think of. [15]
NPR sees four major types of users of its API: the open-source community of programmers interested in building applications with NPR news feeds, NPR member stations intent on differentiating themselves within the network and among other news organizations, NPR partners and vendors who index and serve NPR stories (e.g., Google News and Yahoo!), and internal developers and product managers prototyping news experiences for visitors to the main NPR.org site. “In essence, all of NPR’s distribution efforts are now based entirely or in part on the API” [13]. Thus, NPR’s API is ideally envisioned as a way of creating a more informed public and providing content to its member stations, but the API is also a strategic tool for NPR to maintain relationships with other organizations and organizes its internal operations.
In announcing its Open Platform strategy and accompanying API, the Guardian listed three motivations: to extend its organizational reach, to distribute journalistic work, and to build an advertising revenue network. Tim Brooks (then managing director of the Guardian News and Media) stated, “It’s been 10 years since guardian.co.uk launched. . . . Pre-web we would reach, about 6 million readers with our journalism. In a good month now, we will reach 33 million people with our journalism. We are inviting the developer community in” [10]. And as Mike Bracken (then Guardian director of technology development) stated, “We can’t do everything ourselves. It’s one of the motivations for opening up the site to external developers” [10]. Similarly, then director of digital content for the Guardian Emily Bell explained the Open Platform primarily as “as a way to spread its content and build an ‘eco-system’ around its content. But obviously, there is the hope with the as yet to be built ad network that it will also develop new revenue” [10].
Similar themes emerged when the Guardian announced its “Data Store” project (a repository of data from around the world that it vets and organizes through its API):
Every day we work with datasets from around the world. We have had to check this data and make sure it’s the best we can get, from the most credible sources. But then it lives for the moment of the paper’s publication and afterward disappears into a hard drive, rarely to emerge again before updating a year later. So . . . we are opening up that data for everyone. Whenever we come across something interesting or relevant or useful, we’ll post it up here and let you know what we’re planning to do with it. [11]
And as the official Guardian description of its Open Platform states, the Guardian recognizes that its strategy depends on attracting collaborators, that it lacks the personnel and resources to fully realize its organizational vision: “We could never deliver on our own all the ideas people have had for using the Guardian brand and assets in the digital world” [12].
Across its various stated motivations for developing its Open Platform API system, the Guardian foregrounds its desire to have relationships with developers. It intends to become a trusted broker of data such that it might enlarge its web traffic, differentiate itself from competing news organizations, partner with organizations and programmers that need and value reliable data, and earn income from those building viable revenue-generating applications with its API. The Guardian created the
Open Platform to serve anyone who wants to use our content and tools in a way that is mutually beneficial by creating access tiers that include free, ad-supported and bespoke options. We are particularly keen to talk to organisations and individuals who want to build commercially beneficial applications with us. Our principle focus for commercial relationships will be with media agencies, their creative agencies, advertisers, web development agencies, mobile phone application developers and publishers. And we continue to offer as much free-to-use and self-serve content, data and tools as we can for anyone with an idea that we might be able to support. [12]
Largely absent from the Guardian’s stated reasons for developing its API and supporting the developer community are explicit connections to statement of public service, beyond those presumed to emerge from the public provisioning of vetted data. It seems to see a de facto public value in its data and those who create systems with it without clearly stating (or prescribing) the kind of publics it intends to support or create through its data-heavy focus. In a sense, the Guardian asserts its identity as a professional press through data: charging itself with delivering reliable and high-quality raw information, organizing a community of developers around its tools, and creating sustainable revenue models for continued growth. Mostly missing, though, is a critical sense of who exactly its end public is (as different from its development and commercial partners), what journalistic mission its API serves, or whether there are public priorities separate from data provisioning.
The NYT offers a similarly multifaceted reason for creating its Developer Network API, which it designed “for the web developer community, [although] all noncommercial users are welcome” [14]. First, it offers a service- or market-oriented motivation, arguing that when readers who previously only consumed news begin to program with news, “we learn more about what our readers want and gain insight into how news and information can be reimagined. We’re hoping you’ll show us what’s next for The Times” [8] Second and similar to NPR, it states that
we also have a simpler, more compelling reason: journalism. To inform the public or tell a story, we use articles, photos, videos, interactive graphics, slideshows and more. Data has always been the primary force behind those features, and now it can become a feature in its own right. Our APIs help us fulfill the newspaper’s journalistic mission by putting more information in the hands of the public—and they also expand that mission by giving users the ability to find and tell their own stories. [8]
In addition to these two publicly stated reasons—learning what readers want and giving people data—Derek Gottfrid (NYT senior software architect and product technologist) offered other reasons for developing the API at the NYT’s Open Hack NYC symposium (a forum the NYT manages for API programmers).
1
In answer to the question “What’s the business model here; how is this useful to you?,” he stated,
I think it’s pretty obvious. The honest answer is that it fulfills our core mission of extending the reach and influence of the Times, to make sure that our brand is out there, everywhere. So, people have remixed our stuff since the beginning, from papier-mâché to cutting stuff out and pasting it in their windows—they’ve been doing this. So we want to enable people to continue to do this, but in a digital world, closing the virtual circuit. When you see that piece of content on the other website, that’s good for our brand, that brings people back to our website. And really, once they come back, that’s how we monetize them. [9]
Not surprisingly, part of the NYT’s motivation for offering the API is to maintain its online brand and earn advertising revenue by encouraging people to return to the main NYT.com site through as many channels as possible. The NYT thus relies on programmers using its APIs and users visiting the sites these programmers create to build and maintain its own online reputation, garnering for the NYT new web traffic and revenue.
Relatedly, in the same public talk that Gottfrid thought was unrecorded, in answer to the question “What do you show your bosses as an example of why you’ve invested so much into the API?,” he responds,
I mean, look, we just show them the [example] website and say, look, it was built on top of APIs. Yah, I mean, we don’t—there’s a lot of smoke and mirrors . . . I think, in general, our senior management has been very supportive, overall, with everything that we’ve done. While they don’t exactly understand everything that we’re doing, they have trusted us or turned the other way. . . . I think a lot of this [API work] is just bottom up, developers that were having fun, and, you know, we want to go home and have access to the same stuff and we want to build stuff that’s even crazier than the kind of stuff that we need to build for work. And so we wanted to be able to actually build it and show it off and, you know, have some fun. . . . We looked at places like Yahoo! and the stuff they’ve done and said wouldn’t it be cool if we were cool, too? I think it’s really driven by the developers. [9]
There are two elements to note in Gottfrid’s answer: the way in which the identities of developers and engineers working for a news organization are distinguished from those of the organization’s management and the differences between the motivations developers may have for doing their work versus the goals of management.
Reminiscent of Boczkowski’s (2004) study of newsrooms’ transitions to electronic publishing regimes, Gottfrid’s response—when coupled with the official motivation offered by the NYT—suggests that news APIs show how the professional makeup of the newsroom itself is changing. That is, it is insufficient to ask why news organizations have offered the public APIs without relating APIs to the internal, professional dynamics within news organizations. APIs serve as sites to see that the motivations of managers and journalists and editors may differ from those of software designers and engineers. Although newsroom practices and cultures always intersect with technological innovations (Dooley, 2007; Russell, 2011), this new breed of technological actors occupies a position of power, as they both create the systems that mediate publics and presses and as they evaluate themselves in relation to software design colleagues from non-news organizations.
Among the three news organizations, then, one sees a variety of reasons for offering APIs. NPR emphasizes the educational nature of its member network and envisions its API as delivering professionally produced content that supports its public mission and network members. The Guardian stresses its API’s ability to be a central repository of vetted data around which developers and strategic partners might organize that will, in turn, support its advertising goals and financial health. The NYT describes its API as a trusted data source, fulfilling its journalistic mission to inform the public and creating a developer community to help drive traffic to NYT.com and earn revenue. The NYT’s publicly stated motivations also point to less visible aspects of APIs: their structuring of intraorganizational relationships among software engineers, traditional newsroom workers, and news management staff. That is, there is a need to create contemporary accounts of how actors within news organizations (journalists, editors, owners, and publishers—and their new colleagues, system designers and software programmers) differentiate themselves and their motivations and to see news organizations in terms of hybrid labor markets that exist beyond the newsroom and the traditional, institutional press.
Indeed, further study should see APIs in relation to professional cultures and production logics within newsrooms, complicating the mostly unidirectional nature of APIs (giving access to internal data to those outside the newsroom) to ask how news organizations’ internal practices are affected by what programmers do with news APIs. What evidence is there that APIs engender or represent multidirectional collaboration or change within news organizations? How have the systems built by news API programmers—and readers or users who visit those systems—changed how journalists think about the conditions under which publics can or should be involved in different aspects of news making?
Conclusion
Collaborations between the press and publics have always depended on the circumstances in which they encounter each other. Today, these circumstances are defined, in part, by a new kind of infrastructure: the networked technologies and practices of APIs that make it possible for programmers with interests and skills to work with news organizations that provide access to data and internal systems.
Essentially, APIs represent the idea that the traditional press by itself cannot achieve the kind of results that contemporary, networked news work seems to entail: inventing new forms of storytelling and explanation to diverse audiences, creating “cool” technologies that attract advertisers and readers and that differentiate among competing news sources, vetting and disseminating vast storehouses of information that news organizations themselves cannot analyze and represent, and most broadly, fulfilling public missions and reaching audiences that span networks and technologies more numerous and diverse than any single news organization can reach on its own. These APIs are examples of a new class of “newsware” infrastructure: networked technologies, algorithms, interfaces, practices, and norms that constitute the shared, embedded and largely invisible set of material and ideological conditions and logics governing press-public interactions online.
And this infrastructure is being shaped and used by a new community of people within and outside of news organizations with the skills and interests creating the conditions under which journalists and nonjournalists collaborate. These “programming publics” are responsible for creating the conditions under which publics might be recognized or brought into being through networked communication. That is, when news organizations design their APIs—deciding how and which parts of their internal information systems to open, what kind of software interfaces to offer to programmers, what communities of practice to support, which elements of their organizational missions to encode—they create starting points for programmers. These starting points influence the design paths along which programmers work, thus affording and constraining their designs and the experiences of end users.
Dewey (1927/1954) stated that the public’s essential problem is “perceiving in a discriminating and thorough way the consequences of human action (including negligence and inaction) and of instituting measures and means of caring for these consequences” (p. 21). If the press’s primary, ideal responsibility is to sustain public spheres—recall the diverse meanings of this phrase—then an overarching question at the intersection of system design and journalism scholarship is What kind of social consequences and means of caring can be imagined and realized in networks for open, press-public collaboration? One way to understand and evaluate how news organizations share the work of representing, educating, and mobilizing publics is to critique the motivations, practices, and normative assumptions underlying newsware and programming publics.
Footnotes
Appendix
Acknowledgements
The author thanks the editors of this special edition and the anonymous reviewers for their valuable feedback.
Declaration of Conflicting Interests
The author declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.
Funding
The author disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: This research was partially supported by the Pierre Elliott Trudeau Foundation, Stanford University, and Microsoft Research.