SEARCH

SEARCH BY CITATION

Keywords:

  • programming cultures;
  • race and multiculturalism;
  • freedom;
  • India;
  • Germany

Abstract

  1. Top of page
  2. Abstract
  3. Introduction
  4. Eros and the office
  5. Indian programmers and the production of semiotic-capital
  6. Code is free, why aren't we?
  7. Bad commenting
  8. Appropriating code's freedom and the ownership of code
  9. Acknowledgements
  10. References

This article explores how Indian IT workers who have been hired on short-term contracts in Germany negotiate their racialisation as fast, cheap and disposable. They elaborate modes of freedom that take advantage of the pace of work and its varied temporalities while simultaneously developing a critique of corporate coding as limiting mobility. Their critique upends the usual way that freedom and ownership are conceived, since they try to own the code they write rather than making claims for ‘open’ or ‘free’ software. Indian IT workers’ strategies demonstrate the need for a reconsideration of the meaning of freedom within corporate coding economies and neoliberal knowledge regimes more generally. This article develops a concept of ‘proprietary freedom’ to do so.


Introduction

  1. Top of page
  2. Abstract
  3. Introduction
  4. Eros and the office
  5. Indian programmers and the production of semiotic-capital
  6. Code is free, why aren't we?
  7. Bad commenting
  8. Appropriating code's freedom and the ownership of code
  9. Acknowledgements
  10. References

Srinu leads me through a maze of hallways, turning right, then left, then right again until I lose my way in the thickly padded grey corridors unfurling before us. Conference tables sit in well-lit, generously windowed niches, where large television screens silently await presentations; round tables with high stools await impromptu acts of creative exchange. These spaces are part of the open design of Infotech's new offices, where Srinu is employed on a two-year computer-programming contract.

Infotech's offices are located in a refurbished light-bulb factory in an edgy neighbourhood straddling the border between East and West Berlin. The firm provides software platforms for industries across Europe, in the USA, Asia and Australia. It employs 5,000 people in its Berlin headquarters, with another 1,000 employed in satellite offices around the world. Infotech is one of seven offices I visited during fieldwork, ranging in size from one dozen employees to a few thousand. Infotech is a well-established German firm producing software packages for use in business. Of the firms I observed, some produced software for other businesses that would help these firms manage their data and processes, others made and maintained original pieces of software that were specialisations to existing software packages made by large firms, some were start-ups trying to market new products directly to consumers, still others were vendors that ran a small part of a client-oriented business for another firm, such as a mobile phone company. These offices were chosen for variety of size, while at the same time I was restricted to those firms where I could gain access.

Access to firms was mostly facilitated through networks of management professionals I cultivated in early days of fieldwork by attending regional and national technology fairs and conferences. Sometimes, Indian short-term programmers I met were able to introduce me to their managers, as was the case with Infotech. Much more often, however, I was careful to respect Indian programmers’ worry that bringing me into the office might jeopardise their reputation with their bosses. I therefore worked within the time limits of observation with which my interlocutors felt comfortable, which varied according to personal disposition and evaluation of individual job security.

My fieldwork in offices ranged from periodic office visits to month-long observation and interview with follow-up visits. At Infotech, I spent two weeks observing Srinu's team and then returned for site visits every few months. This office-intensive fieldwork was one part of an 18-month long project in which I followed a core group of 20 programmers from India both at work and after work. I was introduced to six programmers at an event at the Indian Embassy in Berlin; the rest I met over the course of several months at group events and outings. In addition to this core group, I interviewed 32 additional German, American, Australian and Indian managers and programmers I met in offices, through mutual contacts and at trade fairs. Most Indian programmers I interviewed were upper caste and mostly Hindu. Of the 50-plus programmers I interviewed, four were Muslim. Approximately two-thirds of the programmers were from the South Indian state of Andhra Pradesh. The rest were from North and West India. About one-third were women.

These programmers are distinctive for the short-term (1–2 years) nature of their work and for the fact that they took jobs in Germany, which most saw as a stepping stone to either a permanent position in the country or a better position in the USA, Canada or India (Amrute 2010). They were thus faced with a particularly sharp version of the paradox of contingent software work: demonstrating the skill-set necessary to the job at hand yet proving while working their capacity to move into management.

In 2004, I was doing fieldwork on the emergence of a new ‘guestworker’ programme for high-tech labour.1 Although not meant to be targeted towards a single country, this visa programme (called the ‘German Green Card’) and the debates surrounding it were consistently enacted through the figure of the Indian programmer. During fieldwork, I was often struck by how the worth of Indian coders became a matter of continuous speculation in office spaces like Infotechs’. These calculations were part of a flexible means of control that simultaneously encouraged ‘culture talk’ as a way to produce new ideas and open new markets, and corralled short-term, migrant programmers in dead-end jobs. I witnessed how the reputation of Indian coders for hard, fast and cheap programming met with the suspicion that they were only capable of doing coding tasks that needed little creativity or initiative.2 I also was struck by how frequently the Indian coders who are the protagonists of this story resisted these stereotypes.

In this essay, I focus on the strategies that some Indian programmers use to circumvent their cultural branding as disposable workers by exploiting different temporalities of programming and by mobilising a critique of office culture that puts limitations on code and coders. As used here, ‘cultural branding’ describes the way that the place from which a programmer comes is laminated on their perceived abilities in writing source code and maintaining systems, and onto long histories of racialisation of immigrants to produce divisions of labour within the office. The cultural branding of Indian programmers inclines towards conceiving of them as spiritually motivated, able to work long hours with little recompense and incapable of doing creative work, except in exceptional cases.

Eros and the office

  1. Top of page
  2. Abstract
  3. Introduction
  4. Eros and the office
  5. Indian programmers and the production of semiotic-capital
  6. Code is free, why aren't we?
  7. Bad commenting
  8. Appropriating code's freedom and the ownership of code
  9. Acknowledgements
  10. References

Srinu's project manager sits in a corner office with a window overlooking a cobblestone courtyard that still evoked the horse-drawn carriages carrying supplies to and from the old factory. Its walls are lined with awards – here, a carved glass boulder proclaiming an on-time software release, there, a plaque recognising Java or C++ programming competencies. Above all of this hangs an oversized scarf from FC Bayern, displaying the occupant's allegiance to his favourite football team while simultaneously announcing his Bavarian roots. ‘Call me Sören’, he says, as he shakes my hand and bids me sit. Sören has a ready smile and a charismatic presence. He jokes about his considerable size, his Munich accent and his love of ‘currywurst’, a local delicacy of sausage topped with curry-flavoured ketchup sold from nearby food carts. He marvels at my German, commenting that ‘it is really quite good’ and noting that ‘“other Indians” do not bother to learn a word of the language’.3 He seems eager to talk to me and before long tells me why. ‘Is it worth it’, he asks, ‘for me to hire people like Srinu?’ He could hire Srinu for much cheaper if he stayed in India, of course. But he has decided to hire people directly into the company in Berlin. ‘With Srinu's experience [in India]’, Sören explains, ‘I thought it would be worth it to have him on site.’ Sören believes that as an Indian who is studying the IT industry, I can best tell him his Indian workers’ real worth. Of course, it is worth it to hire people like Srinu, I tell him. ‘Having them on site certainly improves the seamlessness of operations’, I say, using one of the bits of technoeconomy slang I've picked up from my programmer friends. Sören seems to consider my words carefully and nods. The value of Indian IT workers depends on an ongoing calculus of cost and coding experience, of Indian coders’ cheapness and their skills. How do migrant IT workers respond to this calculus of worth that makes judgements based on the ‘difference’ of Indian coders?

Programmers manoeuvre within the constraints of corporate work to create a space for what I call, following Berardi's (2009) appropriation of eros, the good and pleasurable life.4 Berardi takes up the notion of eros from Marcuse (1974), who in Eros and Civilization argued that, in Kevin Floyd's clear terms, ‘instrumental reason had so saturated all of civilised culture – not just work but also leisure, not just production but also consumption – that a nonrepression of primal sexuality … is an indispensable precondition’ of human liberation (Floyd 2001: 104). Marcuse called that life-affirming sexuality ‘eros’. Berardi reworks eros away from the idea that primal sexuality is being repressed by suggesting that in the current climate, hyperexpressivity rather than repression is a mode of domination. According to Berardi's analysis, we are incited to share and be open to multiple kinds of impulses. However, these impulses are directed towards a particular idea of happiness rooted in accumulation. It is this sense of eros as opening up to other modes of happiness and more universal notions of the good life that I take up here.

Sometimes, programmers use one particular property of the code they write, namely, its ability to work across contexts and applications, in any environment, and to solve any problem (its executable state, as Alexander Galloway calls it), to open a wedge between the conditions of work that they experience and the potential that their work should afford (Galloway 2004: 166). They then try to extend their relationship to that work to hold on to their jobs longer than their given contracts. In doing so, they develop a theory of freedom and code that makes use of proprietary forms – that is, they turn the strategy of creating ‘private’ property into a means of affirming the good life, or eros. Although freedom in coding worlds is usually articulated through an ideology of lack of ownership and freedom from restriction, Indian programmers may open a space for private ownership that is subsumed within eros. Thus, and rather spectacularly, Indian programmers often take up both sides of the debate on freedom and property in software and other forms of intellectual property. They claim both the right to own what they write, and the right to travel freely across the boundaries. This dual sense of freedom is established by analogy with code that should transcend proprietary protections. The double right they claim suggests an alternative theory of freedom that is based on the right to live a good life rather than on freedom from restriction. This freedom could extend the freedom of movement to people at the same time that it recognises the universal right to eros.

Freedom in digital worlds is often described as freedom from restriction. Battles over regulation, intellectual property and privacy online have pitched those who describe code as free speech against those who describe it as ownable property. These debates largely revolve around whether or not knowledge and communicative acts can be owned, since ‘knowledge is not just a good or resource, defined and delimited like standard goods produced and exchanged on the markets, but a dynamic entity and a cognitive tool pertaining to social groups that is crucial to both the individual and to social action’ (Gosseries et al. 2008: 78). This ‘second enclosure movement’, or making of knowledge a kind of alienable (or separable) property, has required the development of legal instruments and persuasive moral arguments to fine-tune knowledge as property (Boyle 2003; Gosseries 2008: 3; Woodmansee and Jaszi 1994). Accordingly, the politics of free software, indigenous knowledge rights, and intellectual commons have pitched ownership against fair and free use; the gradual enclosure of formerly shared knowledge behind corporate walls abetted by pro-business legislation (Ramello 2008).

The ‘polymorphous collaboration, unrestrained plagiarism, and extraordinary cultural productivity’ (Jaszi 1994: 55) celebrated in open source coding projects often takes as its intellectual foil precisely the kinds of knowledge-owning practices that proliferate in the corporate worlds where Indian programmers work (Ghosh 2005; Kelty 2008; Galloway 2004: 170). Indeed, at many points in their narration of their lives, these programmers agree with this basic critique of corporate coding and suggest that the association between coding projects and bottom lines inhibits both their free play and creativity as coders and their ability to move freely through the world, hampered as they are by migration legislation. In equal measure, however, programmers fight for ownership of their time and their projects within the space of the office. These strategies suggest that, in practice, ownership and egalitarian sharing are not radically opposed but are entangled (Graeber 2012: 101). At the same time, these coders’ practices of owning code suggests that the question of ownership and property needs to be reassessed from the perspective of privacy in a milieu that generally elicits the sharing of knowledge with the company. As Kant drew the distinction, coders work in the gap between what he described as freedom from interference and freedom to actively choose a course of life. If for Kant freedom was to be defined as ‘a warrant to obey no external laws except those to which I have been able to give my own consent’, and thus a positive freedom to decide on the law, in the current milieu, the negative freedom from interference that Kant rejected provides the general baseline against which (and through recourse to ownership), more erotic (that is, containing polymorphous kinds of happiness) forms of freedom can be pitched (Kant 1991 [1795]: 99; Hart 2010).

Before further describing how these programmers understand, interpret and respond to their categorisation within IT workplaces, it is useful to trace out how a workplace might function as a factory of ideas, producing knowledge that should spawn new avenues for monetisation.As I finish my interview with Srinu's boss Sören, I am shepherded towards the company cafeteria where we will continue our discussion. Along the way I take note of the architecture of this converted factory, so emblematic of the new economy principles that make of interaction and communication a resource in the creation of surpluses. The office is arranged so that workers can maximally share ideas, thoughts and snippets of conversation. By producing new ideas and sharing packets of language, the office can take advantage of new information, generate new leads and be ready to respond quickly to new impulses. The floor plan is open, desks are clustered together at intervals, cubicles have no doors, groups of engineers move through the spaces like schools of fish among the shoals. The on-going and continuous exchange of ideas is necessary to cognitive work.

As Paulo Virno puts it, ‘the dialogic world is seated at the very heart of capitalist production’ (2004: 106). Yet, at Infotech, everywhere there is a space of congregation, there is a sign warning people to please keep their voices down and to not engage in overly loud chatter. I notice that despite all the architectural exhortations to communicate, the floor is quiet. Some signs get the point across by showing ‘STOP’ in big red letters, with a message in English informing passers-by they are in a work area. Some use a large printout of a smiley face emoticon saying ‘shhh’, holding an index finger over closed lips. Pinned to one divider is a bright yellow triangle with an exclamation point, the text underneath reminding the potential loud talker, Leute arbeiten hier, bitte woanders plaudern, ‘There are people working here, please chat somewhere else.’ In a hushed voice, I ask Srinu about the presence of all these signs. He replies, ‘Much of the business here goes on over the phone in talking to clients or to people in other locations. So they need quiet. And when the programmers are working on a particular problem, they need to concentrate.’ The conference centres, meant to bring people together and to stimulate new ideas, he thinks, may need to be reconsidered. The signs get thicker as we approach the lunchroom, as does the hum of talk. Those cognitive workers who sit steps away from this most communicative space in the office, where the concentration required of minds and bodies always ready for new impulses can temporarily be broken by the more banal rhythms of the stomach and palate, the ringing of phones and tapping of keyboards replaced by the clink of silverware, practically have papered-over their cubicles with missives urging quiet against the noise.

The architecture of these offices mirrors the anatomy of a control society, described by Deleuze as a modulation of pre-existing ways of life. In his analysis of societies of control, Deleuze diagnoses the waning of what Foucault called disciplinary societies. Institutional enclosures for the moulding of docile subjects have given way to managing ‘states of perpetual metastability’ that in corporations ‘operate through challenges, contests, and highly comic group sessions’ (Deleuze 1992: 4). For Deleuze, the corporation, as opposed to the factory, represents the spirit of societies of control. Following on descriptions of control societies that re-work Foucault's disciplinary analyses, Røyrvik and Brodersen call corporate surveillance a ‘polyopticon’, stressing the ‘decentralized, relational networks type of reciprocal surveillance’ that is prevalent in new economy workplaces (2012: 647). No longer panoptic, the flattening of office hierarchies inclines towards mutual surveillance, inciting, as they write, a desire to be watched.

In Srinu and Sören's workplace, the open spaces are designed to foster communication and creativity, thereby incorporating the critique of cubicle culture as inhuman directly into the design of the office (Ross 2004). The hope is that if workers are given free and open spaces, they will devise creative solutions to work problems and help open new markets that could not be thought of if the workers were disciplined more closely. At the same time, the proliferation of signs suggests a tension in office surveillance and observation. The smiley faces and warning signs, post-it notes and stern admonitions to move conversations elsewhere try to create spaces of quiet fixity in an otherwise observant office, attempting to re-establish clearly demarcated boundaries between kinds of activities in a new economic order where the emphasis is on blurring borders. Importantly, knowledge workers themselves make the signs; it is not just an adjustment to the ideal of a transparent office imposed by management. The signs suggest that resistances to the kind of control Deleuze describes may come in the form of trying to deflect ‘perpetual metastability’ away from the individual worker, at least temporarily, and at least in some corners of the office.

As knowledge workers, programmers capitalise both on their skills in writing code and the skills external to strict job descriptions that may be called on at any time. This essay minimises focus on code-writing to direct theoretical attention to the role stereotypy plays in corporate software projects, where, I argue, assumed qualities of migrant culture crosscut everyday practices of work and employee evaluation. For Indian coders who are the protagonists of this story, these extra job skills are often cultural and linguistic capacities that their employers value, like those that Meena -- a 26-year old graduate from Hyderabad's Indian Institute of Management -- uses when she translates the bosses’ demands into discrete jobs that other programmers can execute. Meena has been hired specifically to act as a linguistic and cultural liaison between project managers and two programmers from Delhi who speak little English. She enjoys the work and works under a project manager from Australia. She hopes to move up in the firms and eventually become a manager herself. IT workers like Meena must create and retain their value in these post-Fordist high-tech economies by making themselves indispensable to their employees. Sometimes, this balancing act requires that they counteract their positioning in a firm as culturally exotic labour by using the (counter)example of how code travels to unravel and critically apprehend the claims of technoeconomy control.

Indian programmers and the production of semiotic-capital

  1. Top of page
  2. Abstract
  3. Introduction
  4. Eros and the office
  5. Indian programmers and the production of semiotic-capital
  6. Code is free, why aren't we?
  7. Bad commenting
  8. Appropriating code's freedom and the ownership of code
  9. Acknowledgements
  10. References

I found that many people in Berlin's IT industry thought the world of code and the everyday world should line up according to the principle of performative action, that is, the world should behave as clearly or straightforwardly as code – the code does what it says and so should people and machines do what they are supposed to. But they often differed in their interpretations of how code behaved. Indian programmers on short-term projects stressed the freedom of code to move across boundaries and do many things, a condition they contrasted with their own constrained mobility. German managers and Indian managers who had successfully moved beyond the short-term work contract stressed that code was reliable and expected their employees to be the same. In their opinion, the code was something that should function in a timely manner and as promised, and they often analogised this expectation to Indian coders on short-term contracts. Karin Knorr Cetina argues that the relationship between persons and objects of expertise (like code) has at least two facets. It can be construed as instrumental, and it can be open to being continually redefined (Knorr Cetina, 1997: 12). Similarly, Indian coders can be likened to instruments that are ‘an available means to an end within a logic of instrumental action’ (Knorr Cetina, 1997: 10). Or, they can be part of a ‘mutual communicative partaking’ with the code they write (1997: 18). In this latter sense, they are kindred with code, they take on what code provides them, namely, an example of how to move effortlessly through the world, to the extent that they immerse themselves in coding worlds. The former relationship was often stressed by managers in IT offices, while the latter relationship was often stressed by the Indian short-term coders with whom I spoke.

Most often, the critique of cognitive work pits freedom of creative agency against the channelling of that impulse. Tiziania Terrranova, for example, writes that cognitive capitalism locates control ‘at two ends of the process: at the beginning, when a set of local rules is carefully put together and fine-tuned; and at the end, when a searching device or a set of aims and objects aim at ensuring the survival of the most useful or pleasing variations’ (2004: 118). The creative impulses that came out of the workers’ movements of the late 1960s, according to this critique, produced the potential for unprecedented modes of sharing and public organisation located outside the sphere of capitalist production. But this human capacity, while very much still with us in posse, has been largely sequestered within what Virno calls ‘a thick net of hierarchical relations’ (2004: 68). In the critique of cognitive labour, freedom would be signalled by the production of ‘unrestrained invention […] which hinges on a kind of latent wealth, or an exuberance of possibilities’ (2004: 76). While in no way wanting to diminish the call for exuberance, which has undergirded many positive critical social movements, the antinomy between unrestrained creativity and creative control is clearly overstated. This becomes especially clear when we consider that office culture explicitly encourages blurring boundaries and producing communicative acts that may lead to further productive activity in future. In light of this fact, it may be that freedom is found in small acts of privacy that workers try to create when the company formally owns everything from their time to their ideas. In a very different context, John Jackson's study of public space in Harlem makes a similar point. Describing the way that sidewalk space is used in everyday life by different manner of Harlemites from old-time residents to new townhome developers, he writes:

residents’ paths to and from, say, laundromats and corner bodegas, Chinese or Senegalese restaurants, their children's public school, and so on, become tiny patches of peripatetic privacy within an overdetermined landscape of market-based privatisation. […] These intimate paths through public space are not equivalent to individual ownership in any simple sense. If anything, it is an ownership of space that money cannot actually buy. (Jackson 2006: 204)

I think of the signs asking for quiet as establishing temporary privacy within the workspace that is not overdetermined from the start in terms of its uses. In other words, these islands of privacy are often used to complete something on deadline or drown out the exuberant creativity (and surveillance) of free-flowing conversation in order to control human activity and make it productive as a source of value to capitalism. But these private moments might also be pools of concentration that a coder may use to work on a problem away from the pressure of deadlines, or for an office worker to check email, read the news, chat with family and friends, and do many of the things not directed towards productivity. Creating pools of quiet might be a strategy to keep errant matter errant, that is, precisely to not make knowledge immediately appropriable by the office at large. Rather than their being a pure antinomy between capital and its resistances, these temporary private moments both point to the need to disambiguate kinds of privacy within neoliberalism, as Jackson suggests, and to pose resistance as a counter-conduct, emanating from the same techniques of freedom and privacy that knowledge work has built up as a tactic of capitalist accumulation, but moving in a radically different direction (Foucault 2007: 355).

In the next two sections, I turn to how the two sides of debates of intellectual property in software are mirrored in the practices of Indian coders to critique and strategise in the spaces of their labour. They critique their limited ability to purse work projects by comparing their lives to the possibilities inherent in the code they write, and they try to create small areas of temporary ownership of code throughout the workday. Of course, in the IT office, unlike on the street corners Jackson discusses, the space is already unambiguously bought by the company. In such a situation of clear ownership, where knowledge lists towards the owners of production, these private moments both mimic and redirect technologies of corporate control.

Code is free, why aren't we?

  1. Top of page
  2. Abstract
  3. Introduction
  4. Eros and the office
  5. Indian programmers and the production of semiotic-capital
  6. Code is free, why aren't we?
  7. Bad commenting
  8. Appropriating code's freedom and the ownership of code
  9. Acknowledgements
  10. References

I often heard Indian software engineers describe code in similar terms to the ones Meena uses one day, as ‘a set of instructions that tell a computer to do something’. Similarly, she goes on to suggest, ‘it is the job of the IT worker to produce instructions that work in the time allotted for a given project’. In conversation with one another and with me, however, they often voiced the opinion that those who do not really understand how coding works often hinder them in this task. On this day, at the end of a long working week, Meena and Mihir are talking about their jobs and their job chances. Mihir is a 25-year-old programmer from Mumbai who works for a cell phone company debugging ringtones. He agrees that like a computer, the job of the programmer is to get the work done, but points out the ways the ‘bosses’, as he calls them, get in the way. Mihir says, ‘with our skills we should be able to go anywhere to do the job. But we are not allowed’. They disagree about the bosses’ role. Meena tells him that ‘the bosses have to answer to the clients and we have to do what they ask of us’. But Mihir, working in a small shop of twelve people and with in his opinion an unfriendly boss, is less sympathetic. ‘We are free to do the work,’ he ends the conversation, ‘but we are not free to move up.’ Meena aligns herself with the manager by stressing the unpredictability of client demands, thereby creating solidarity within the firm. Mihir, on the other hand, believes that Indians are continually frustrated by unfair migration regimes (a topic Srinu discusses below) and arbitrary glass ceilings. In making this critique, Mihir uses what he thinks of as the inherent properties of code as a negative example to illuminate his own restrictions. Many Indian coders I spent time with implicitly and explicitly make the argument that they too, like the code, should be able to go anywhere and use their skills to solve problems. They point out a contradiction between the freedom of code to cross boundaries and their inability to do so by aligning themselves as experts with the knowledge embodied in code.

Srinu, who was the subject of Sören's speculations of worth, sits with me on the short train ride from the neighbourhood where we both live, called Wedding, to his office near Humboldt University. He talks about how he'll have to adapt if he is to have more than a temporary job at his company. ‘I really enjoy the engineering side,’ he says, ‘but you get labelled an expert in a particular area.’ If you get pigeonholed as only a coder, it marks the end of your upward mobility. Many Indian IT workers, he says, instead of ‘moving up’ are ‘moved out’ to further short-term jobs or back home without a job at all. ‘I used to write code on the weekends just for fun,’ continues Srinu, ‘but I now spend my time studying marketing and using PowerPoint’. He misses what he calls geeking out. ‘It's the fate of the manager’, he says, describing his future work. ‘As you go up, you can't go into detail.’ He is willing to pay the price of leaving behind his geeking-out days because he wants to stay with the firm, get a better position and salary, and above all, move from a temporary to a permanent position.

As he readies himself to leave the train, Srinu leans over to me and says, ‘I have a story for you that you can put in your notebook.’ He promises to tell me at the end of the day. When we reconvene later at Meena and Rajeshwari's apartment it is nearly 10 o'clock, Srinu looks exhausted as he takes off his smart overcoat and puts down his briefcase. He hasn't eaten, but Meena and her roommate Rajeshwari, 28 and completing her Master's in computer science at the Technical University Berlin, always remember to leave some food aside for him. After filling his plate and wolfing it down hungrily, he turns to me and asks if I am ready for his story.

Two people, researchers and friends, both from India, are both trying to go to a conference in the USA, in New Orleans. They both have similar background and qualifications. And they both apply for a visa to go to the conference. They are kept waiting until the last minute, each has bought a ticket for the trip and has prepared a paper. In the end, one gets the visa and the other does not. ‘With no explanation,’ says Srinu, ‘it's perfectly arbitrary and has nothing to do with reason or logic’. His eyes are twinkling as he tells me that, and as he asks, ‘Can you explain that? Will your work help solve that kind of problem?’ I have to answer that I cannot really explain it, according to logic, nor will what I write do much to change the situation. For Srinu, this is a clear example of the difference between how people and how ideas are allowed, even encouraged, to travel.

As if to round out his examples of the way technoeconomies actually frustrate and prohibit people from pursuing what makes them happy, Srinu mentions yet another example of lacking freedoms. Walking to the subway the next morning, Srinu turns to me and says, ‘You are working on migration and intermixing, but in my opinion, there is no real intermixing here. Real assimilation would mean people marrying each other and choosing to live and raise their families in different places’. Srinu has in mind both the way the Indian programmers are treated in the office where they work as cheap labour and as reservoirs of knowledge about India, and the restrictions his family will place on him to marry someone from home. I notice how his remarks link the person, the politics and the job as all arbitrary blockages in the expression of eros.

Like the code that could be used to solve any problem, given enough time, resources and talent, high-skilled migrants represent boundless potential that is restricted by arbitrary laws and people (such as visa-dispensing bureaucrats and business-oriented project managers) who lack the expertise to appreciate the importance of technical work. IT workers can create and command code, but they cannot partake in code's disembodied universal logic – its ability to go anywhere and solve any problem. The logic of code's unrestricted travel leads coders to think along parallel tracks: in terms of updating skills in what they think of as continuous résumé-building and in terms of both reinforcing and evading the cultural, racial and third-worldist suppositions that make Indian coders desirable as temporary workers. As Mihir tells me on a night when I sit with him late into the evening, ‘With our skills in programming, we should be able to go anywhere we are needed, and we can solve many problems. All this, our work, our excursions, our travel, are, in some way or the other, limited.’

While the short conversation between Meena and Mihir indicates considerable disagreement when evaluating management strategies, programmers were more in agreement about evaluating the inhibiting logic of migration laws. Although I recognise the speculative nature of some of the conclusions I reach here, I believe that often, by using code to think about the conditions of their own lives, programmers expose a neoliberal model of achievement that simultaneously rewards expertise wherever it is found and sequesters subjects within the concrete realities of embodiment and place in the name of rationalising expertise. The reputation of Indian coders for having good backend skills (that is, being able to code for long periods of time and get the job done quickly) often helps Indian programmers get their foot in the door in IT firms. At the same time, it can limit what they can accomplish there. The strategies they use to move out of short-term jobs and move beyond this reputation at once recognise and disavow the unjust logic of neoliberal apportioning of difference and merit, which binds Indian coders and a particular type of coding. These strategies seek to move Indian coders out of the back room and into management positions.

One link between ‘real-life’ limits and the ‘virtual’ world of programming is in the term migration itself. In programming jargon, ‘migration’ means moving from one system or program (or version of a program) to another, as in, moving from an Apple operating system to a Windows environment. Migration, when large accounts and worldwide companies are involved, is a tricky operation requiring multiple-month planning and coordination. I followed one large-scale migration scheme that involved a seemingly simple update to a popular reference management platform. The project was held up at several points because of the tricky matter of making sure that all dates, periods and commas continued to render correctly in the new version, with the result being that the release date for the new version was pushed back six months. The migration of knowledge workers might incline towards a similar treatment: while on the surface the issue seems to be moving qualified workers to the jobs where they are needed (regardless of place), in practice, worker mobility is caught up in making commensurable: law, attitude towards immigrants and the politics of native job protection.

The paper began by wondering how programmers who are positioned within such complicated migration schemes and within the politics of labour divisions within a ‘polyoptic’ office culture find room for manoeuvre within the office. In the following example, writing bad comments takes advantage of the overriding desire on the part of project managers to get a piece of coding done on deadline to insert a programmer as irreplaceable expert on a project.

Bad commenting

  1. Top of page
  2. Abstract
  3. Introduction
  4. Eros and the office
  5. Indian programmers and the production of semiotic-capital
  6. Code is free, why aren't we?
  7. Bad commenting
  8. Appropriating code's freedom and the ownership of code
  9. Acknowledgements
  10. References

‘One’, says Bipin in his characteristically staccato delivery style, as he began to outline the problems with ‘spaghetti code’, ‘it's an imposition on the next person who's going to have to pick that work up’. ‘But two’, he continued, gesturing towards the multiple, open windows on his screen, ‘software, as it gets bigger, as more and more functionality that's interrelated is added, it becomes what programmers call a “ball of mud,” or “spaghetti code,” just impossible to disentangle.’ I was shadowing this 34-year old coder from Hyderabad in the office where he worked in the former East Berlin. It was after 9 pm and he was still moving through a section of code that according to the testers was not operating correctly. Bipin was one of the few married programmers I met in Berlin. His wife, Madhu, also a programmer, had managed to secure a job in another firm in the city. As Bipin tells it, it is Madhu who has the hard-core programming skills and is highly sought after, so it is relatively easy for her to get a job. On the other hand, because he trained in IT management, he has been able to move into a fairly secure position managing his own team. Bipin and Madhu do not plan to settle permanently outside of India. Instead, they want to simply make enough money abroad to be able to buy their own apartment back in Hyderabad.

On this evening, Bipin leaned back in his chair, taking a break from moving back and forth between the code and the comments that accompanied it, and took a long and satisfying gulp from the milky, sweet, scalding hot tea that always seemed to hover somewhere near his right hand. He explained to me why the job was taking so long. Someone had failed to put in complete source code documentation. According to Bipin, code should ideally be commented on so that it is legible and provides useful insight into the work that was done for subsequent teams continuing the project. The negative consequences of messy code that is not properly commented on can become monumental over time. Once you reach a ball of mud or spaghetti-code level, it becomes very difficult to change one piece without changing all others. It is hard to maintain correctly functioning code because all parts of the system are so interconnected. Over time, unregimented commenting can lead to a breakdown of the entire infrastructure of programming for a firm. Bad commenting leads to what E. Gabriella Coleman has aptly described as ‘the world of thick, unmanageable constraints’ on the performance of code (Coleman 2013: 97).

Hearing the way bad commenting can build up over time and conscious of how late and tired Bipin is, I imagine he must be really annoyed about the bad comments, and ask him if he plans to talk to his group about them and try to find the culprit. Bipin however is surprisingly laidback about it. According to the system of classification that many programmers I interviewed deploy, programmers come in many different ‘types’. Most divided programmers into planners and executors as a first cut into the different kinds of work style. One friend distinguished between ‘programmers’ and ‘coders’, saying that in fact, programmers are those who have overview and plan strategically and coders are those who just write code. He then flipped this metaphor in terms of value, saying that he preferred to call himself a coder, because the programmers don't really do anything. For him, coding is what is worthwhile, although he says that in a corporate atmosphere it is programming that receives all the glory. This division is further recursively made between programmers who work by the seat of the pants, fix code and move on (sometimes called duct-tape programmers) and those who try to make beautiful, easy-to-read and efficient code (perfectionists). These two categories embody very well the office conflict between getting work done on time and getting work done that can be extended, built on and create a robust infrastructure for a company. At the same time, flipping the valence of worth suggests that within the hierarchy between planner and executors, or programmers and coders, there is room for manoeuvre, strategy and the elaboration of a counter ethics of work and the enjoyment of life.

Bipin is in charge of a team that adds on to an already existing software platform his company developed. His team is building more functionality into this platform and making it work with other types of software. There are weekly and monthly deadlines he must meet, and he has an official ‘scrum’, or team meeting, every Wednesday where he reports on his progress and hears from other teams about theirs.5 The ball of mud impedes his progress and sets him back. Yet Bipin is quite sanguine on the bad comments he has to wade through. He juxtaposes commenting with the ticking clock. ‘One,’ he begins again, ‘Comments are important in the long run, but they often ask us to do things we don't know if we can actually do as fast as they want it. When it comes to putting in comments, they can be sacrificed to the pace of the job. And two,’ Bipin continues, ‘If the boss sees we are getting the job done, that is more important.’ Finally, he links bad commenting to extending a work contract. ‘Three, although leaving code is a courtesy to other coders, doing so means you are also more replaceable. In a commercial environment, there is a disincentive to leave comments. You're more irreplaceable if you don't explain what you've done!’

Restricting documentation can be a subversive way to extend labour contracts. Because workers are on short-term contracts (most less than two years), if their work becomes tied closely with themselves as unique individuals through code that works and is produced on time rather than code that is well documented, they become harder to replace and consequently more valuable. If a coder fails to comment then she is the only one who can understand the code and has become irreplaceable by virtue of making a very tight link between this section of code and her personhood. For Indian coders, the potential for further opportunities at a firm is in tension with the discipline of notation.

Bipin narrates the failure to comment comprehensively on coding as both a strategy for drawing out a work project and a by-product of the pace and expectations of migrant programming jobs. Bad commenting is a strategy that helps mitigate the risks of being removed from a project even while contributing to its overall instability. Bipin reminds us that the boss must see the work accomplished. In other words, the coder must produce code and must perform according to the standards of the project manager. Because of this, Bipin says, there is not time to leave good comments. But this time-constraint is improvised on and used by coders as a means of holding onto their jobs for a little while longer. Failure to comment becomes a way of garnering longevity in a short-term labour market.

Bad commenting is a strategy for militating against replace-ability that depends on exploiting the pace of the job to create a wedge between the organisation of work through the exploitation of short-term work contracts and the expertise of coders. ‘The management of time’ in IT offices, as O'Carroll explains, ‘occur[s] within the constraints of externally imposed deadlines. However, unpredictability, the non-repetitive nature of the tasks, the dependence on technology or on others can lead to tasks taking much longer (or indeed much less time) to complete than expected, making it difficult to “plan according to the clock”’ (2008: 188).

That very unpredictability, which ‘pits the task-oriented time of programming jobs against the homogeneous time of client-driven deadlines’ (2008: 188), is used by some Indian programmers to create two levels of ‘work’. On the face of it and to management, they get the work done on time, whenever possible. Within the project and for the sake of their own position in the firm, they put in devices that may help them ‘own’ the work they do going forward, so that a tie is created between themselves and the project and they become irreplaceable.

The exploitation of time pressure is not a strategy that is exclusive to Indian programmers, but is rather endemic to an industry that, as O'Carroll writes, relies on two radically different kinds of time, corporate, clock time and the lived time of creative work: ‘The limits of the IT workplace are the limits to how fast, how often, how continuous the creative effort is, yet the creative effort is a process that resists compression’ (2008: 180). There were moments, for instance, in which Indian programmers made promises of finishing projects quickly without knowing in advance if the project could be completed at all. Asking one programmer about these decisions, she suggested a disconnect between the pace of the industry, the bosses’ evaluation of her work and her place within the company. ‘Often you don't know’, this programmer suggested, ‘whether you can do a project until you start it. But in order to get a contract, the bosses have to say it is possible, so we too tell them it is possible.’ Some programmers complained about their managers, who really had ‘no idea’ of what was possible and what was untried. ‘They make all sorts of promises to the clients’, Mihir often lamented, ‘but weren't themselves sure if the company could follow through.’ In turn, the programmers make promises to the managers they themselves aren't sure they can fulfil. Mihir continued, ‘There is a lot of misunderstanding about what the client actually wants, what is possible. You can't always tell in advance how long a project will take.’

Despite the general contradiction between client-driven deadlines and project-time, Indian programmers are particularly tasked with bringing work in on time, since they were especially hired for this purpose. This translates to staying very late at work. Mihir for instance, is the only one other than his boss who has a key for the small firm in which he works. He is expected to come in after hours and on weekends. He tells me that his German friends at work often ask him why he works so hard. And he is quite at a loss for what to say. He does work hard. All programmers note at one time or another that the German workforce works very hard but has very strict coming and going times. At 3 pm on Friday, the office is deserted. ‘Indian programmers’, says Meena, ‘have a habit of working hard. But it is also what bosses expect’. It was not rare to hear from Germans in the IT industry that Indians were suited to long hours at work, were better at abstract thinking and did not mind the kind of asceticism that comes with those hours. They called them ‘the computer experts’ and the ‘IT-Indians’ [IT Inder], highlighting their function as workers who program and their expertise at producing code. There is a complex kind of Orientalist thinking that undergirds such assumptions that deserves its own treatment. I note here that such thinking links India with meditative religious practice, which has its roots both in scholarly conceptions of the difference between East and West and everyday ways that the ‘difference’ of Indian programmers is represented in media discourse (Marchand 2010). The long work hours and abstract processes of computer work are clearly an expectation that falls disproportionately on Indian programmers precisely because they have been brought in as a labour force to produce reliable and on time code and because the history of Indian spirituality in the West provides an ex post facto justification for these expectations.

Appropriating code's freedom and the ownership of code

  1. Top of page
  2. Abstract
  3. Introduction
  4. Eros and the office
  5. Indian programmers and the production of semiotic-capital
  6. Code is free, why aren't we?
  7. Bad commenting
  8. Appropriating code's freedom and the ownership of code
  9. Acknowledgements
  10. References

In their definition of freedom, many Indian coders describe it as a positive freedom enabled by their propriety knowledge of code – the ability to move anywhere in the world pursuing their version of a good life. This position is simultaneously racially democratic, in that it provides a critique of migration controls, and profoundly elitist, in that the freedom of movement it prescribes is apportioned according to the merit one has as a programmer. Indian coders participate in a general culture of programming that balances sharing and cooperation with ‘an elitist stance that places an extremely high premium on self-reliance, individual achievement, and meritocracy’ (Coleman 2013: 106). Once they are elite, these workers will be in the position of getting the contracts. Ironically, they will then hear the same phrases from the new ‘not yet elite’, telling them they can do the job on time and under budget. Some, like Bipin, will make allowances for the exploitation of time for the sake of security, while others will suggest that these workers have not lost their ‘Indian’ mind-set, thereby forgetting the very practices that they themselves engaged in to get ahead. As Radhakrishnan says, ‘Indian IT workers … offer a powerful embodiment of a new India in which each advances according to his or her individual merit rather than parochial categories.’ Such an ideology ‘gloss[es] over the inequalities of the elite education system in India and understand[s] their own status as a result of their own hard work, talent, and effort’ (2011: 90). Yet, this moment of possible erasure in which the structural critique of freedom and its limits gives way to the promotion of success as individual achievement is also the moment that can generate an alternative mode of freedom as eros, as in Srinu's comments about marriage.

The argument for code as free speech is undergirded by a legal argument stating that because code is a form of communication that is written and can have artistic properties, its expression, like that of speech, cannot be restricted. The argument for freedom of movement says that because in the real world code is relatively unrestricted in where it can go, digital worlds are an example of a possible world in which people, too, are unrestricted in where they can go. In many cases, this latter line of argument has been dismissed as cyberutopian or cyberlibertarian (Lessig 1999: 4–5), because it suggests that virtual worlds are inherently freer than embodied worlds. But for Indian programmers, the claim is not so much libertarian as utopian in the sense of responding to an existing set of constraints with a set of better, but still imperfect, possibilities (Weeks 2011: 210–13). It is a call that takes the premise of a borderless world promised by information technologies and tries to make it real and concrete in practice. Rather like calls for true equality in situations of structural discrimination despite juridical equality, it calls out the hypocrisy of a system that so depends on the work of migrant coders but does not treat them as well as it does the programs that they produce.

As Kavita Philip outlines in an important article, the major stakeholders in the free software/open software movement have become conservative over time, relying now on distinguishing between good and bad piracy. Piracy that must be defended is the creative reuse of ideas; that which must be policed is piracy that simply copies. But, as Philip, quoting Laurence Liang, notes, piracy that is not creating something new is nevertheless ‘providing an entry point into the material for a large number of people who otherwise would have no access to it’ (2005: 213). Philip notes that in such moments, ‘the possibilities of being a subject in this sphere are detached from the requirements of unique authorship [… and] the appropriative function is foregrounded’ (2005: 213). In other words, thriving in the world of knowledge production requires for those made marginal to it, appropriating the code in ways that official avenues of production would disapprove of, in large part because this appropriation does not correspond to prevailing modes of doing good work.

Bipin's understanding of bad comments has this kind of sensibility about it. Such ‘duct tape’ code is not the kind of programming that would make most coders proud. As he mentioned, it leads to ‘spaghetti code’, code that is impossible to untangle. Such programming practices are not something that would be claimed by an author as would clear, agile and well-written code. But it is a practice of appropriating the symbolic properties of code for oneself that provides continued access to the goods of the global technoeconomy for those who use this tactic.

Against the backdrop of the flexible workplace that encourages innovation and tries to channel it productively, Indian IT workers must strategically deploy the stereotype of the good Indian coder without allowing themselves to be reduced to being merely cheap, fast and replaceable workers. At issue here is both making use of the ideological connection between India and IT work and making sure not to be ‘trapped’ by the way it has been articulated.6 Often, Indian coders do so by trying to personalise their labour, by making the code they write part of themselves even in the midst of producing it for their firms. This is a form of proprietary freedom that is liberating and not reducible to the freedom of the market. In fact, it works precisely against such a neoliberal idea of freedom of exchange by holding something back from exchange on the market.

The creation of illegible comments is one instance of a different kind of autonomy, one that does not resist the management of work itself, but rather re-channels that work away from its serial exchangeability and towards an anchoring of the properties of code in the body of the Indian IT worker herself.7 In this way, it ‘de-virtualises’ programming, pointing the temporary ownership of code back towards precisely those workers who otherwise cannot claim to own what they write. Like the conversations on the sidewalk, claims to temporary ownership of a commonly held good can be done in the name of increased access and equalising social relations.

This strategy is nevertheless double-edged. In the long run, making code inalienable from the coder can lead to obsolescence. If Indian coders become branded as workers who, by definition, fail to comment, then their skills will cease to circulate as a labour commodity; the code that they command will be locked up within individuals who are quite literally beyond compare (as the only ones who can understand what they have done) and, therefore, unmarketable in an arena where cheap cognitive labour is the brand that works.

Similarly, the claim some programmers make, that they should be able to circulate as freely as the code they write, comes up against the limits of freedom as defined in liberal digital worlds, where a difference between program and person is maintained as a way of staying within the bounds of a speaking liberal subject as the legal grounds for freedom of speech (Philip 2005: 216). Sociological and anthropological studies of free software unfortunately often follow this lead, taking the ‘code as speech’ anti-property argument as synonymous with freedom (Alleyne 2011; Söderberg 2008). This lacuna limits freedom to the particular and culturally local idea of maintaining an intellectual commons.

On the other hand, the mismatch between the ability of code to circulate and the ability of bodies to do so arises out of how Indian knowledge workers are situated in IT offices as expendable back office labourers. Their demands for expanded visas or better quality of work are excluded from the demand for freedom of software precisely because admitting to these differences would widen the scope of freedom to such an extent that the very premise of free speech (without free people) as a legal precept would be questioned. The proprietary freedom evidenced here responds to the contradiction between Indian embodied difference as an expansive and proliferating sign and Indian bodies as needing to be managed, controlled and limited in their movements. It holds on to a little piece of code not to monetise it but to bootstrap on that area of privacy and redirect its energies towards pursuing a good and satisfying life.

Acknowledgements

  1. Top of page
  2. Abstract
  3. Introduction
  4. Eros and the office
  5. Indian programmers and the production of semiotic-capital
  6. Code is free, why aren't we?
  7. Bad commenting
  8. Appropriating code's freedom and the ownership of code
  9. Acknowledgements
  10. References

Research and this writing for this paper was generously supported by: the Berlin SSRC Program, the Fulbright IIE Fellowship, and the Simpson Center for the Humanities at the University of Washington. I would like to thank the many programmers and managers I met with and followed around in Germany for being so generous with their time and welcoming me into their many, busy worlds. I would also like to thank Sasha Welland, Daniel J. Hoffman, Gabriella Coleman, and the anonymous reviewers for Social Anthropology for their valuable feedback on this piece.

  1. 1

    On the legacies of the German guestworker programme, see Ewing (2008).

  2. 2

    Software engineers in India who have 5–10 years’ experience earn approximately 109,340 rupees/month (www.paycheck.in/main/salary/swlary-checker-1 (accessed 5 March 2012), or US$2,049 per month.

  3. 3

    I am not Indian, though I am of Indian origin. Throughout the course of fieldwork, I routinely was taken to be ‘Indian’ in the same way that the Indian programmers were taken to be ‘Indian’.

  4. 4

    Eros is found in and inflected through sites of work, while the sites of pleasure can become training grounds for the office. See also Postone's (1993) critique of the singular and totalising capitalism proposed by Marcuse and others in his Time, Labor and Social Domination.

  5. 5

    The ‘scrum’ is a regular meeting designed to keep track of smaller segments of a large project. It is part of what is called an ‘agile’ software development process, where regular check-ins with teams on their progress should lead to meeting more deadlines and heading off problems earlier in a development process. The term ‘scrum’ is adapted from rugby, where players lock arms at the beginning of play.

  6. 6

    Indeed, Indian coding is a standard narrative element of ‘Brand India’. As an advertising banner for IT services in the Indian state of Kerala I saw at a trade fair declared: ‘Kerala: God's Own IT Country’. This slogan is a play on the state's tourist tagline, ‘Kerala: God's Own Country’.

  7. 7

    The ‘standing reserve’ enunciated by Heidegger is thus simultaneously turned inward and opened up to social action. Rather than human potential becoming a resource to be consumed by technological production – pace Heidegger – the body in reserve here is an ability to make code stand still and be diverted to new deployments (Heidegger 1977).

References

  1. Top of page
  2. Abstract
  3. Introduction
  4. Eros and the office
  5. Indian programmers and the production of semiotic-capital
  6. Code is free, why aren't we?
  7. Bad commenting
  8. Appropriating code's freedom and the ownership of code
  9. Acknowledgements
  10. References
  • Alleyne, B. 2011. ‘Challenging code: a sociological reading of the KDE Free Software Project’, Sociology 45: 496511.
  • Amrute, S. 2010. ‘Living and praying in the code: the flexibility and discipline of Indian information technology workers in a global economy’, Anthropology Quarterly 83(3): 51950.
  • Berardi, B. 2009. The soul at work. Boston: Semiotext(e).
  • Boyle, J. 2003. ‘The second enclosure movement and the construction of the public domain’, Law and Contemporary Problems 66: 3374.
  • Coleman, G. E. 2013. Coding freedom: the ethics and aesthetics of hacking. Princeton: Princeton University Press.
  • Deleuze, G. 1992. ‘Postscript on the societies of control’, October 59: 37.
  • Ewing, K. 2008. Stolen honor: stigmatizing Muslim men in Berlin. Palo Alto: Stanford University Press.
  • Floyd, K. 2001. ‘Rethinking reification: Marcuse, psychoanalysis, and gay liberation’, Social Text 66 19(1): 10328.
  • Foucault, M. 2007. Security, territory, population. New York: Picador.
  • Galloway, A. R. 2004. Protocol: how control exists after decentralization. Boston: MIT.
  • Ghosh, R. 2005. CODE: collaborative ownership and the digital economy. Cambridge: MIT.
  • Gosseries, A. 2008. How (un)fair is intellectual property?, in A. Gosseries, A. Marciano and A. Strowel (eds.), Intellectual property and theories of justice. London: Palgrave Macmillan, pp. 326.
  • Gosseries, A., Marciano, A. and Strowel, A. 2008. Intellectual property and theories of justice. London: Palgrave Macmillan.
  • Graeber, D. 2012. Debt: the first 5,000 years. New York: Melville House.
  • Hart, K. 2010. ‘Kant, “anthropology” and the new human universal’, Social Anthropology 18(4): 4417.
  • Heidegger, M. 1977. Questioning concerning technology. New York: Garland.
  • Jackson, J. L. 2006. Gentrification, globalization, and georaciality, in M. K. Clarke and D. A. Thomas (eds.), Globalization and race: transformations in the cultural production of blackness, 188205. Durham: Duke University Press.
  • Jaszi, P. 1994. On the author effect: contemporary copyright and collective creativity, in M. Woodmansee and P. Jaszi (eds.), The construction of authorship, 2956. New York: Columbia University Press.
  • Kant, I. 1991. Perpetual peace: a philosophical sketch, in H. Reiss (ed.), Kant: political writings. Cambridge: Cambridge University Press.
  • Kelty, C. 2008. Two bits: the cultural significance of free software and the Internet. Durham: Duke University Press.
  • Knorr Cetina, K. 1997. ‘Sociality with objects: social relations in postsocial knowledge societies’, Theory, Culture, and Society 14(4): 130.
  • Lessig, L. 1999. Code and other laws of cyberspace. New York: Basic Books.
  • Marchand, S. 2010. German orientalism in the age of empire: religion, race, and scholarship. Cambridge: Cambridge University Press.
  • Marcuse, H. 1974. Eros and civilization. Boston: Beacon Press.
  • O'Carroll, A. 2008. ‘Fuzzy holes and intangible time: time in a knowledge industry’, Time & Society 17: 17993.
  • Philip, K. 2005. ‘What is a Technological Author? The pirate function and intellectual property’, Postcolonial Studies 8(2): 199218.
  • Postone, M. 1993. Time, labor, and social domination. Cambridge: Cambridge University Press.
  • Radhakrishnan, S. 2011. Appropriately Indian: gender and culture in a new transnational class. Durham: Duke University Press.
  • Ramello, G. B. 2008. Access to vs. exclusion from knowledge: intellectual property, efficiency and social justice, in A. Gosseries, A. Marciano and A. Strowel (eds.), Intellectual property and theories of justice, 7393. London: Palgrave Macmillan.
  • Ross, A. 2004. No-collar. Philadelphia: Temple University Press.
  • Røyrvik, E.A. and Brodersen, M.B. 2012. ‘Real virtuality: power and simulation in the age of neoliberal crisis’, Culture Unbound 4: 63759.
  • Söderberg, J. 2008. Hacking capitalism: the free and open source software movement. London: Routledge.
  • Terranova, T. 2004. Network culture: politics for the information age. New York: Pluto Press.
  • Virno, P. 2004. Grammar of the multitude. Los Angeles: Semiotext(e).
  • Weeks, K. 2011. The problem with work. Durham: Duke University Press.
  • Woodmansee, M. and P. Jaszi 1994. The construction of authorship. New York: Columbia University Press.