I have been using the username silvertje for several services and multiple social media platforms for years and people have been asking me where my username comes from. The answer is IRC. When I first came online, somewhere in 1995, I quickly discovered IRC and became an avid user :)
In contrast to current social networking sites and social media platforms there was no way to “register” a username on IRC. This meant that you either had to hope no-one else would use the same name, or have a very unique username, or be online all the time and “claim” your username through persistant onlineness. Being on a 14K4 dail-up connection which cost over 5 Dutch Guilders (about 5 dollars) per hour I had a clear disadvantage compared to the American and Finnish IRC users who were able to be online all the time for free through their universities. So every time I used IRC I had to dail-up, get online, get on IRC and hope no one was using my username. The first username I picked was ‘sliver’ (after the Nirvana song) but that one was taken very often. Then I decided on ‘_sliver_’ but that one was also often taken. Then I chose ‘slivertje’ to create a Dutch diminutive but apparently another Dutch user thinking the same thing. Finally, I settled on ‘silvertje,’ which means little silver in Dutch, which never seemed taken on IRC and I have happily been using it ever since (although I am not on IRC anymore).
Over the past couple of weeks I have joined a variety of new services including App.net, State, Branch, Medium, Kippt, Buffer.
I recently backed my first kickstarter-ish project ever and decided to join App.net (AppDotNet or ADN). People keep asking me if I think it can ever compete with Twitter or will it ever reach critical mass or if it will stay a ghost town like Google+? For me the question is not whether ADN will be able to “replace” Twitter but rather I see it as a reflection of the current zeitgeist. ADN is not simply an ad-free alternative to Twitter. Instead, alternatives to major platforms such as Facebook and Twitter are increasingly gaining momentum. ADN is definitely not the first, think for example of Diaspora (launched as a Facebook alternative) and Identi.ca (formerly Status.Net) which calls itself “a stream oriented social network service” (FAQ). Both services never really went mainstream, maybe because they were both ahead of their time.
ADN, at a first glance, seems similar to Identi.ca but there is one important distinction which also differentiates it from Twitter because with Identi.ca “You can install the StatusNet software that runs Identi.ca on your own servers, since it’s Free and Open Source software. You can make groups, and share privately with those groups.” This allows you to run Identi.ca on your own server, a decentralized model, while both Twitter and ADN rely on a centralized model. ADN follows a centralized model which is very common for the current era of social media platforms. As a platform, ADN is operating as software as service, “a software delivery model in which software and associated data are centrally hosted on the cloud,” and offers an API for developers. The API is the main core of ADN and alpha.app.net is only one possible way of how an ADN application or service can look or function. Two great write-ups deal with these issues: First, Dan Wineman describes the relation between the social graph, publishing and aggregation and how social platforms like Twitter and ADN deal with these differently, and second, Orian Marx describes what ADN is, could possibly be and how it is different from its alternatives. Yes, ADN costs 50 dollars (or 100 if you are a developer) and it is still a centralized service but I can’t even begin to describe what has been developed with the ADN API in less than three weeks.
ADN isn’t the only thing that is currently brewing as an alternative to Twitter which is increasingly shutting out other services and third-party developers. Dave Winer hypothetically proposes a “A microblogging server that’s a simple install on EC2 or Rackspace or any other easy cloud-based server“ in other words, a decentralized easy self-install Twitter alternative in the cloud. Another initiative that is currently buzzing in the blogosphere is Tent.io “a protocol for open, decentralized social networking” which looks interesting but Winer reminds us that “What matters is what software is supporting the protocol, what content is available through it and how compelling is the content.” There is also critique on Tent.io developing Yet Another Protocol while it could use existing protocols, which reminded me of the following XKCD comic on standards:
My username is @silvertje if you would like to contact me on ADN. I have created a Google Doc which lists about 80 other Dutch ADN users, @adrianus has built Appnetizens streams, a “Tweedeck” like interface for ADN (for which I did some CSS-color-advice) with multiple column-view and tons of other features such as a “Netherlands” view with all known Dutch users, @frankmeeuwsen has started a blog titled Appdotnet Culture which documents ADN’s early developer and user culture and @richardk writes about ADN developments. I’ve also created an IFTTT recipe that allows you to cross-post selectively from Twitter to ADN whenever the tweet contains the hashtag #adn.
I started using Buffer to cross-post some messages from Twitter to ADN using an IFTTT recipe I created: Send Tweets with Hashtag #ADN to App.net via Buffer However, IFTTT just added ADN as a channel to their service so I don’t have to pipe everything through Buffer anymore, so until I find another use for this service I am putting it on pause.
At the first glance State looks like a Netvibes made for the platform & cloud era. It’s not simply a service to aggregate your streams because State also allows you to interact with your streams. In other words, you can reply to your Tweets and ADN posts and when you click on a user it brings you to the user profile displayed within State. However, not all actions that can be performed on objects within these platforms are available yet. You can also add RSS feeds but it is not immediately clear how this works. You can “search” for a feed, where it seems to search the web for your query and then grabs the feed from these results. When I ego-search for myself I get feeds for my Flickr photos, Quora profile etc but I cannot seem to find the main feed for my own blog. Adding a custom feed by URL would be a great option. I’ve only used it for a few hours but I love it so far and ReadWriteWeb calls it “A Streams App Of The Future“. It looks clean, minimal and good and they respond very quickly to feature suggestions (they implemented a reply to Instagram photos function after I suggested it on Twitter!), always a bonus :)
Update: Joshua from State kindly answered my question concerning the RSS feature. State is currently using “Google’s Feed API (https://developers.google.com/feed/) to search for feeds using the text you type into the box” which interestingly enough brings up the feeds for my presence elsewhere but not my own blog.
Branch, Medium, Kippt
Branch, Medium, Kippt are three more new platforms I joined recently for publishing, discussing and link sharing but so far I have merely glanced at them, as one can only spend so much time online.
On a final note, I’m happy to contribute as a female to the all these new services which are dominated by “alpha geeks” aka white males according to BuzzFeed’s latest article on the early adopters of these platforms.
The Institute of Network Cultures, Eva van den Eijnde and myself would like to welcome you to the official book launch of Geert Lovink’s new book Networks Without a Cause. A Critique of Social Media. Thank you very much for being here. Today I would like to start with a brief introduction to Geert’s new book and how it relates to his previous work. Afterwards Geert will talk about his new book, followed by a few questions and comments from Eva van den Eijnde and myself, and of course questions from the audience.
Networks Without a Cause is the fourth book by Geert in his series of studies into critical internet culture. For those unfamiliar with Geert’s work, the first book in this series is Dark Fiber (2001) which deals with early internet culture, from cyber culture to dot.com-mania. His second book My First Recession (2003) describes the aftermath of the dot.com mania and looks at the transition period of the dot.com crash to the early blogging years. His third book Zero Comments (2008) looks back on the blogging hype that has commenced since and addresses blogs as an unfolding process of “massification” and blogging as a “nihilistic venture.” It also looks at the Web 2.0 hype or Web 2.0 mini-bubble that echoes the dot-com era but also differs from it as described by Geert. His new monograph, Networks Without a Cause (2012), continues where Zero Comments has left off by describing the late Web 2.0 era.
The introduction of Networks Without a Cause starts with the important umbrella question “How do we capture Web 2.0 before its disappearance?” The rise of the real-time signifies a fundamental shift from the static archive and handcoded HTML websites toward “flow” and the “river” as metaphors of the real-time, where the software, social media platforms, are automatically generating content flows from the input from their users. Blogs and blog software have played an important role in this shift, with the reverse-chronology of blog entries and the river of fresh content produced by RSS feeds. Real-time is a key feature of social media platforms such as Facebook with its news feed and Twitter with its timeline, where content flows by, begging the question for researchers how to capture and archive this flow in order to be able to analyze it, and for Geert also the question of “why store a flow?” related to the notion of users no longer saving their files for offline retrieval but instead moving, storing and syncing everything in the cloud (think for example about Gmail and Dropbox) but also the question of identity management because “how do you shape the self in real-time flows?” (p. 11) These and many other questions posed throughout the book are part of a “Net criticism” project that seeks to develop sustainable concepts as individual building blocks that through dialogues and debates “will ultimately culminate in a comprehensive materialist (read: hardware- and software-focused) and affect-related theory.” (p. 22)1
Question 1: Web 2.0 versus social media
Is it a coincidence that a number of books dealing critically dealing with “social media” are coming out at the same time? This book Networks Without a Cause with its subtitle A Critique of Social Media, also The Social Media Reader a volume on the topic with contributions by well-known authors on the subject where, in the introduction the term Web 2.0 is called a buzzword, that on the one hand has been “emptied of its referent, it is an empty signifier: it is a brand.” (p. 4)2 but on the other hand encapsulates an aspect of the phenomenon of social media. And finally, the upcoming book by Andrew Keen called Digital Vertigo that addresses the threat of the social and the tension between the collective social and the individual in “today’s creeping tyranny of an ever-increasingly transparent social network that threatens the individual liberty.”3 Geert also addresses related issues in his book when describes “The social as a feature.” He describes how “Social media as a buzzword of the outgoing Web 2.0 era is just a product of business management strategies and should be judged accordingly.” (p. 6)
Is Web 2.0 a thing from the past? As a lecturer in the first year of Mediastudies at the University of Amsterdam I was surprised to learn this year that my students were not familiar with the term Web 2.0 at all! Everyone had heard of social media, everybody except for one privacy conscious student, was a member of Facebook, but none of them had heard of the term Web 2.0. This is also illustrated in the following image:
What is the relation between Web 2.0 and social media when thinking not only about terminology but also about software, practices and critiques?
Question 2: Comment cultures
While in Zero Comments Geert focused on the average blog with its zero comments, in Networks Without a Cause he focuses on the other end of the Power Law diagram and looks at blogs that have reached a critical mass. In the introduction he writes how in Web 2.0: “Current software invites users to leave short statements but often excludes the possibility for others to respond. Web 2.0 was not designed to facilitate debate with its thousands of contributions. […] What the back-office software does is merely measure “responsiveness”: in other words, there have been that many users, that much judgment, and that little debate.” p. 19
While blogs offers a form of facilitated debate by offering the possibility of comments, it is highly hierarchical due to the strict separation of content and comments. On top of that bloggers are continuously debating how to improve the old blog comment infrastructure in order to deal with the “tragedy of the comments” that have caused some bloggers to shut down their comments.
Geert argues that thinking about the software-architecture to design the comment ecology is important because software co-produces a social order. Could you further elaborate on current comment cultures, your ideas to go beyond taming the commentators, and the increasing splintering comment ecology with the conversation also moving to social media platforms such as Twitter and Facebook with no proper way to connect all these distributed comments back to the original text?
- Lovink, Geert. Networks Without a Cause. A Critique of Social Media. Polity Press, 2012.[↩]
- Mandiberg, Michael (editor). The Social Media Reader. New York University Press, 2012.[↩]
- Keen, Andrew. Digital Vertigo: How Today’s Online Social Revolution Is Dividing, Diminishing, and Disorienting Us. Forthcoming, May 2012.[↩]
Last year Erik Borra, Taina Bucher, Carolin Gerlitz, Esther Weltevrede and I worked on a project “One day on the internet is enough” which we have since referred to as “Pace Online.”
The project aims to contribute to thinking about temporality or pace online by focusing on the notion of spheres and distinct media spaces. Pace isn’t the most important question, respect for the objects and the relation between objects and pace per sphere are also of interest in this study. Both in terms of how the engines and platforms handle freshness, as well as currency objects that are used by the engines and platforms to organize content. Moving beyond a more general conclusion that there are multiple presents or a multiplicity of time on the internet, we can try to start specifying how paces are different, and overlap, empirically. The aim is to specify paces and to investigate the relation between freshness and relevance per media space. The assumption is that freshness and relevance create different paces and that the pace within each sphere and plattform is internally different and multiple in itself. (continue reading on the project wiki page)
I was reminded of the project when I read Rethinking the Digital Future, a piece by in the Wall Street Journal on David Gelernter and the lifestream. Gelernter describes a particular relationship between streams and pace when talking about the worldstream and an individual stream. In this subset of the worldstream things move at a slower pace because individual objects are added less frequently than when looking at the aggregate, the worldstream. We argue something similar in Pace Online, where – translated into Gelernter vocabulary – this worldstream consists of different spaces with different paces. Zooming into a space, such as Twitter or Facebook or Flickr, creates a subset within the worldstream. There are numerous subsets of subsets that may be created as one can zoom into the stream of Twitter and then further zoom into this stream based on a hashtag or an individual user profile where each of these subsets of streams have different paces.
In “Time to start taking the internet seriously” (2010) David Gelernter describes a shift from space to time and with it the lifestream as the organizing principle of the web: “The Internet’s future is not Web 2.0 or 200.0 but the post-Web, where time instead of space is the organizing principle.” Interestingly enough he does see a history in the fleeting stream: “Every month, more and more information surges through the Cybersphere in lifestreams — some called blogs, “feeds,” “activity streams,” “event streams,” Twitter streams. All these streams are specialized examples of the cyberstructure we called a lifestream in the mid-1990s: a stream made of all sorts of digital documents, arranged by time of creation or arrival, changing in realtime; a stream you can focus and thus turn into a different stream; a stream with a past, present and future. The future flows through the present into the past at the speed of time.” A stream with a past is something rare, for example you cannot go back to your first tweet if you have published over 3200 tweets on Twitter and you cannot search for tweets over 14 days old. While Twitter partner Gnip announced “Historical Twitter Data” yesterday, this history of tweets is only 30 days old. It also points to an interesting relation between the past, present and future of a stream as it offers the past because we cannot anticipate the future:
We have solved a fundamental challenge our customers face when working with realtime social data streams,” said Jud Valeski, Co-Founder and CEO of Gnip. “Since you can’t predict the future, it’s impossible to filter the realtime stream to capture every Tweet you need. Hindsight, however, is 20/20. With 30-Day Replay for Twitter, our customers can now replay history to get the data they want. (Gnip Blog)
After the introduction to APIs and API critiques Bernard Rieder talked about APIs from the perspective of “Variation and Change.” This transcript is compiled from collaborative notes by the Digital Methods Initiative.
API: a means and protocol for two systems to exchange data and functionality.
APIs can be seen as data sources and as objects of study that can be historicized, analyzed, critiqued, etc. Before taking the API as a research object we also need to get a better understanding of “what we can get” out of APIs and asses our level of confidence when researching. The API can be used as a means to study a service and possibly the evolution of the Web?
Andrew D. Birrel and Bruce Jay Nelson, Implementing Remote Procedure Calls, ACM Transactions on Computer Systems 2(1):39-59, February 1984.
Webservices, SOA – XML-RPC, SOAP, WSDL – B2B, e-commerce
Google SOAP Web API: 2002 (Java, .NET), Amazon Web Services: 2002
Flickr (feb 2004), API (aug 2004): Easy to use API. Less about transactional integrity.
Google maps (feb 2005). The Housing Maps project (march 2005) used two scrapers. Google Maps was reverse-engineered to extract the tiles (the individual images that make up the map). Next, he scraped the data from Craigslist and combined the two. After this, Google hired the guy and implemented the API a few months later (June 2005).
Programmable Web has a API directory and lists the most used APIs which allows for historical comparison on APIs. For example, in 2007 there are no social networks and Google maps is 1st and Flickr is 2nd. Now, in 2012, Google maps is still 1st but Twitter is 2nd and Facebook is 6th.
The turn also entails a shift from a hard heavy business logic, to a soft logic.
Lines of variation and change
An investigation into synchronous/diachronous lines of variation and change can serve as API critique or historical analysis. Questions may concern:
- technical structure and use (how?) – how similar is the tech infrastructure for developers to the platform’s view?
- intended audience, intended use (who?) – audience: both developers and end-users
- economic model (why?)
- restriction and tolerance (legal, technical, transparency, etc). Restrictions: Explicit or not
- developer relations (communication, support, etc). Questions: How do their organize there documents? How do they communicate it? What does it say over there relationship with users? How does it change over time?
- publicness and authentication (privacy, ego-view) – Facebook has an open API, the search API. There are variations of authentication.
- coverage and discrepancy (API, “user view”) – The API and frontend often do not have the same results
- read/write capacities (location in the flow) – and possible use of this information to infer how the service views itself vis-a-vis other systems
From 25-27 January 2012 we held our fourth annual Winter School with the theme “Interfaces for the Cloud: Curating the Data.” The first day consisted of paper presentations and responses/feedback. The second day we collaboratively kicked off a workshop on API critique where I started with an introduction to APIs and API critiques, followed by Bernhard Rieder on API variations and change, followed by Richard Rogers introducing project ideas for the next day and a half. This blogpost contains the slides and a pointy transcript of the morning session.
Anne Helmond – Introduction to API critique
What is an API?
An application programming interface (API) is a source code based specification intended to be used as an interface by software components to communicate with each other. An API may include specifications for routines, data structures, object classes, and variables. (Wikipedia)
“set of tools that developers can use to access structured data” (boyd and Crawford 2011)
“Machine-interfaces for your application” (Bell p. 331)
“software interface to your website” (Bell p. 332)
“weaving the Guardian into the fabric of the web “(Bell p. 331)
In Building Social Web Applications Graham Bell describes how being on the web was the cry of the 90s where companies were rushing to get on the web to establish their presence. However “Today a website is more than a brochure, it is a data repository with multiple interfaces to the content” (p. 331) and these interfaces are enabled through APIs. On top of that “API usage may exceed the normal HTML access for pages” as illustrated with the case of Twitter where about 20 procent of the traffic was web-driven and eighty percent of the traffic was API-driven (p. 332). Twitter has multiple interfaces to its content because of the numerous third-party applications built on top of Twitter, although this number is decreasing due to increasing restrictions to access Twitter data.
APIs, Web 2.0 and platforms
APIs are closely related to the idea of Web 2.0 as ” one of the central technical characteristics of Web 2.0 is the reliance on APIs, on customized software programs that rearticulate protocols in different ways.” (Langois et al 2009) and the idea of the web as platform where “historically, some types of software like desktop operating systems have been called ‘platforms’ because through their APIs they provide the foundation on which other programs are built. The phrase ‘web as platform’ refers to fact that as web sites start providing their own APIs, they too are becoming a platform on which other programs can be built.” (Programmableweb) In Web 2.0 as “The Internet as Platform” (2005) O’Reilly saw two kinds of architectural platform models within Web 2.0. Those who built on the protocols and open standards of the Internet and those who seek to lock-in their users – abiding by the rules of the PC software era – by exerting control over their users via proprietary software APIs (2005). Google is often described as the prototypical platform that ‘understands’ the rules of Web 2.0 as the web as platform (Graham 2005) by building its services on top of the open standards of the web. Looking at Marc Andreessen’s statement “If you can program it, then it’s a platform. If you can’t, then it’s not” (in: Bogost and Montfort 2009) the question arises if in Web 2.0 an API is a pre-requisite to be a platform.
APIs and mashups
APIs enable mashups where the data of two services are combined to create a new service. The website ProgrammableWeb not only collects and lists APIs but it also mashups. A popular new service that lets users combine different APIs through a graphical interface is if this then that in order to “Put the internet to work for you.” Iftt has been called “Awesome Web Mashup API” and “API Automation for the Masses” because it does not require any technical knowledge. Users can combine services by defining tasks in the form of “when something happens (this) then do something else (that)” by selecting from pre-defined options in the interface. Users can make API ‘recipes’ with limited ‘ingredients.’ Ifttt makes defining API calls for the average web user easy by predefining the fields and only asking for a parameter, for example name of a tag, that must be monitored. It masks the actual API call by making the code invisible. It hides the process of the apps “talking” to each other and requesting and exchanging data.
Literature on APIs mainly deals with manuals, design books and how to’s. How else can we study APIs and are there any API critiques? The following is an incomplete list of articles/books/blog posts that address APIs:
- In relation to user interface/programming interface: Cramer and Fuller 2008
- In relation to the reliance of Web 2.0 on APIs: Langois, McKelvey, Elmer and Werbin 2009
- In relation to the volatility of methods: Helmond and Sandvig 2010
- In relation to proprietary API calls: Berry 2011
- In relation to Big Data: boyd and Crawford 2011
- In relation to data gathering skills: Manovich 2011
- In relation to scraping: Marres and Weltevrede 2012
#1 limited API calls
Twitter explicitely states that “There are limits to how many API calls and changes you can make. API usage is rate limited with additional fair use limits to protect the platform from abuse” in its blogpost Things Every Developer Should Know. But not only Twitter developers, also Twitter users may encounter these limits when they are cut off from the platform when tweeting too much, or following too many people in a short period of time. During a conference Twitter user @latelyontime wrote about his encounter with rate limits that “latelyontime has been barred from twitter. in this world, to be prolific is to be a spammer. ;) #CPOV.” Reaching the API limit often marks you as a spammer.
#2 Changing APIs
“This document and the APIs herein are subject to change at any time. We will version the API, but may deprecate early versions aggressively.” Delicious
The second strand of API critiques mainly concerns developer critiques of changing APIs. Developers build third party applications on top of platforms using web APIs that may no longer function if the platform changes its API. As APIs and structures change over time, all the services using it also have to change it accordingly. If platforms do not inform their developers in time this will cause the third-party app to stop functioning and it will lead to complaints from developers, see for example Twitter Changes API, Fails to Notify Developers, Nick Bradbury on The Long-Term Failure of Web APIs and Dave Winer on Breaking web APIs. It not only affects the developer, it also affects the user whose application may no longer work and it may also affect researchers using APIs to retrieve data. In The Volatility of Methods Christian Sandvig and I addressed some of the issues of working with APIs as a researcher.
#3 APIs and control
APIs allow for carefully regulated dataflows between platforms in the form of open APIs or proprietary APIs. This is related to the idea of the politics of dataflows as in the case of the Facebook where all links and social activities are rerouted through the Open Graph API which – despite its premise of Open – uses proprietary API calls. What goes into the platform and out of the platform is defined by proprietary formats. See also API: Three Letters That Change Life, the Universe and Even Detroit on open/closed APIs.
#4 APIs and access
“Register for a free API key and get 133% more queries/day.” Topsy
Different APIs may provide different levels of access to data, for example the streaming API only gives access to 1% of the firehose. The firehose (“all” tweets) is available through payment or partnership deals with Twitter. This has the following implications for researchers:
Twitter Inc. makes a fraction of its material available to the public through its APIs. The ‘firehose’ theoretically contains all public tweets ever posted and explicitly excludes any tweet that a user chose to make private or ‘protected.’ Yet, some publicly accessible tweets are also missing from the firehose. Although a handful of companies and startups have access to the firehose, very few researchers have this level of access.Most either have access to a ‘gardenhose’ (roughly 10% of public tweets), a ‘spritzer’ (roughly 1% of public tweets), or have used ‘white-listed’ accounts where they could use the APIs to get access to different subsets of content from the public stream. It is not clear what tweets are included in these different data streams or sampling them represents. It could be that the API pulls a random sample of tweets or that it pulls the first few thousand tweets per hour or that it only pulls tweets from a particular segment of the network graph. Given uncertainty, it is difficult for researchers to make claims about the quality of the data that they are analyzing. Is the data representative of all tweets? No, because it excludes tweets from protected accounts. Is the data representative of all public tweets? Perhaps, but not necessarily. (boyd and Crawford 2011)
#5 ethics: APIs “versus” scraping
The restrictions to access and the different levels of access to data pose an important ethical question for researchers: how do you gather you data? “There are different data gathering methods: The API is the polite way of gathering data and scraping could be considered the impolite way of harnessing data: “You can arrange digital research methods on a spectrum of niceness. On the one hand you use the industry-provided API. On the other you scrape Facebook for all it is worth.” (Helmond & Sandvig 2010) Scrapers have a complex relationship with APIs (Marres & Weltevrede, forthcoming).
How can we study or critique APIs from a humanities perspective? One way in is by reading the developer documentation. When working on the Like Economy with Carolin Gerlitz we noticed a discrepancy between the number of Likes retrieved from the API and the number of Likes on the Like button after retrieving data from the Facebook API. By reading the API Developer Documentation we learned that the Like button number actually is a composite metric that displays not only likes but Likes, Shares, Comments and the amount of times it has been shared by Private Message. Another way would be to track changing rate limits, are platforms increasingly shutting down access or opening up?
A next post on the winterschool will contain a short transcript of Bernard Rieder’s talk on “APIs: Variation and Change.” In the afternoon we started working on projects related to the theme of “Interfaces for the Cloud: Curating the Data.” The project pages can be found on the Digital Methods Winterschool 2012 wiki page.
Winterschool participant Jean-Christophe Plantin wrote a blogpost inspired by the winterschool on “The Internet as a software: repurposing API for online research.”
Bell, G (2009). Building Social Web Applications. Sebastopol: O’Reilly Media.
Berry, D. (2011). The Philosophy of Software: Code and Mediation in the Digital Age. New York: Palgrave Macmillan.
Bogost, I. and Montfort, N. (2009). Platform Studies: Frequently Questioned Answers. Proceedings of the Digital Arts and Culture Conference, 2009.
boyd, d. and Crawford, K. (2011) Six Provocations for Big Data. A Decade in Internet Time: Symposium on the Dynamics of the Internet and Society, September 2011. Available at SSRN
Cramer, F. and Fuller, M. (2008) Interface. in: Fuller, M. (ed). Software Studies: A Lexicon, Cambridge: MIT Press.
Helmond, A and Sandvig, C. (2010). ‘On the Evolution of Methods.’ Workshop “Research Methods in the Digitally Networked Information Age” organized by The Berkman Center for Internet & Society and the University of St. Gallen in Brunnen, Switzerland from 10 to 12 May 2010.
Langlois, G., McKelvey, F., Elmer, G & Werbin, K. (2009). Mapping Commercial Web 2.0 Worlds: Towards a New Critical Ontogenesis. Fibreculture 14.
Manovich, L. (2011) ‘Trending: The Promises and the Challenges of Big Social Data.’ Debates in the Digital Humanities, edited by Matthew K. Gold. The University of Minnesota Press, forthcoming 2012. PDF available at http://lab.softwarestudies.com/2011/04/new-article-by-lev-manovich-trending.html
O’Reilly (2005). ‘What is Web 2.0.’