SciELO - Scientific Electronic Library Online

vol.10 issueESPECIALQuels médias pour se ré-approprier une voix? L'investissement d'internet par le mouvement dalitLa red como cronotopo: Internet y prácticas políticas en el Movimiento Estudiantil Colombiano Mane y Occupy São Paulo author indexsubject indexarticles search
Home Pagealphabetic serial listing  

Services on Demand




Related links

  • Have no similar articlesSimilars in SciELO


Observatorio (OBS*)

On-line version ISSN 1646-5954

OBS* vol.10 no.Especial Lisboa June 2016


Is There an App for Everything? Potentials and Limits of Civic Hacking


Ksenia Ermoshina*

* PhD Candidates at MINES ParisTech, PSL Research University, CSI - Centre de sociologie de l’innovation, i3 UMR CNRS, Mines ParisTech 60 boulevard Saint-Michel, Paris, France, (



The present article analyzes potential and limits of crowdsourcing software (mobile and web applications) as tools for civic participation. Based on an empiric study of six Russian and French civic applications, developed in response to a particular public problem (corruption, electoral falsifications, police violence and urban problems), the article proposes to address the problem of digital asymmetry from the perspective of pragmatism, STS and software studies The author focuses on the phase of design, coding and testing, and analyzes the procedures of standardization and classification necessary for developing the interfaces. While standardization seems inevitable from the technical point of view, it produces a particular form of asymmetry between the lived experience of a “trouble” and the categorical grid. Developing a civic application, coders propose a certain definition of a public problem and rectify it in the interface. The article argues that an active participation of users in the improvement of the application may help to overcome the limits and asymmetries.       

Keywords: crowdsourcing, civic media, participation, software studies, public problems, mobile applications.



“We’re hearing from the mayor’s office like,

‘a cat got stuck in a tree, can we have a hackathon to get it down?'”

Emily Badger

On the 13th of June 2013 a curious event is held in Paris, with a provocative title « Au code, citoyens » / « To code, citizens »1. Referring to the French Revolution2, this international workshop aims at presenting programming code as a new kind of « weapon », while hackers, makers and users of ICT are turned into a new kind of revolutionary citizens. This rhetoric, promoting a specific ethos of civic hacking, seems to be part of a global trend, with similar events being organized worldwide: “Make code not war”, “Code 4 Humanity”, “Code 4 Cause”, “Hack against Corruption”, “Hack for Refugees” etc. This new culture of civic hacking tends to engage publics into using ITC and the programming code to address problems that have been previously delegated to human agents, social movements or well-identified political institutions. These events put together professionals of code and social activists, marginalized populations and social entrepreneurs, who prototype digital tools in response to contemporary political and social challenges.

In order to frame and facilitate the cooperation between programmers, citizens, NGOs, public administrations and start-ups, a bunch of special programs have been launched, such as Code4America, Code4Paris, Code4Europe, Apps For Democracy, Hack4Good. These intermediary organizations host civic hackathons,3 unconferences, barcamps, workshops, fellowship programs, aimed at producing “both technical and political innovation that helps to mobilize broader publics around important challenges” (Allard, Blondeau, 2010).

The civic hacking movement is a transnational phenomenon firstly experienced and institutionalized in USA4 but rapidly adopted in Europe, Russia (Ermoshina, 2014), India (Irani, 2015), and is progressively expanding in Africa with the appearance of fablabs and local innovations (such as, for instance, the 3d printer “W.Afate” entirely assembled of e-waste)5. The term “civic hacking” has progressively become institutionalized with the creation of National Day of Civic Hacking in 2013 gathering about 11 000 people all around US (Baranuik, 2013). With the second edition in 2014 the event overflew national borders and engaged communities and experts from all over the world.

The organizers of the National Day of civic hacking define a civic hacker as follows: “Civic hackers... are technologists, civil servants, designers, entrepreneurs, engineers - anybody - who is willing to collaborate with others to create, build, and invent to address challenges relevant to our neighborhoods, our cities, our states and our country. To us, a hacker is someone who uses a minimum of resources and a maximum of brainpower and ingenuity to create, enhance or fix something”6.

In this definition, the word “hacker” refers to the practices of bricolage that are not reserved to the professionals of code, but make a room for the amateurs, for the non-technical experts. The term “hacking” is here expanded beyond the universe of programming and becomes an epistemological position, a method to resolve problems using instruments at hand. According to “Hacking” in the phrase civic hacking means “perverting something’s original purpose to solve a problem”, so the best hacks are simple, creative solutions to interesting problems. And this meaning “is a source of pride among programmers and geeks and actually was the original meaning of the word before it also became used to mean cybercrime”.

Still in the perspective of bricolage, George Dafermos and Johan Soderberg, offer an interesting definition of hacking that I found relevant to my research: “In our use of the term hacking, we mean the act of taking a preexisting system and bending it to serve a different end from that for which it was originally intended” (Dafermos, Soderberg,2009: p. 55).

Chris Baranuik tends to problematise this change in the definition of the term “hacker” from a word with a strong criminal connotation to a notion that helps to grasp and describe a certain approach to problem-solving: “While some hackers are criminals, the term hacking is often simply understood as the process of improving and rebuilding technology via unconventional means. Gabriella Coleman (…) who studies the anthropology of hackers, has shown how, for many, the term is a badge of honor that denotes the ability to derive clever and unexpected technical solutions to a problem” (Baranuik, 2013).

This will to redefine and decriminalize the notion of hacker was expressed by one of the actors I interviewed, the organizer of Hack4Good hackathons and the co-founder of GeekList, a social network for developers. He affirms:

“For me to hack things means to rapidly put something together any way you can. Hack 4Good and the idea of a hacker for us is that they try to solve a problem any way they can do it… hacking is more about utilizing whatever resources you have to make things work and solve the problems. And in our case the problems are social problems »

(Interview with Reuben K., Hack4Good organizer)

Given the definitions quoted before, I am focusing precisely on this understanding of civic hacking as a specific epistemological and methodological position. The civic hacking movement is driven by a belief that programming code can change the way our institutions function and propose new and ingenious solutions for important challenges. It is believed that code can restructure usual practices of civic participation such as alerting authorities about urban problems, mapping natural disasters, communicating in times of urgency, voting and advocating (Eyler-Werve, Carlson, 2012). Lilly Irani claims it in her recent article, the civic hacking movement is not only about producing software prototypes, but (also) a specific ethos: « they manufacture urgency and an optimism that bursts of doing and making can change the world. Participants in hackathons imagine themselves as agents of social progress through software… » (Irani, 2015: 2).

Piotr Steininger, one of «Code 4 Europe» coordinators, gives an original definition of code: « Code is somewhere between technology, people and problems. Code is a lubricant for problem-solving as it helps to adjust and make smoother the articulations between different actors of the world…» (field recording, workshop « To code, citizens », 13.06.2013) This link between code and social good seems to be direct for the advocates of civic hacking. But how exactly, with the help of which particular operations does this translation happen? How to make a transition from a social or political cause to strings and functions of Python, Java or C++? Is every social problem “codeable”? Can there really be an app for everything?

An important body of critical research questions the Internet hegemony and criticizes the technological optimism. Evgeny Morozov, in his book “To Save Everything, Click Here” (2013) shows the limits and the dangers of the so-called internet-centrism and technical solutionism. Beyond the strict “diffusion approach” that considers digital divide as caused by an uneven access of populations to the ICT, two kinds of asymmetries appear that need to be thoroughly analyzed. The first one, related to the classical digital divide problem, is the asymmetry between those who manage the code and those who are reduced to the role of the users. The second kind of asymmetry, that I would call “asymmetry-by-design” is a much less visible one (as it is “hiding” in the interface) and a much less studied. This asymmetry is related to the problem of standardization and classification: if some social problems (especially the “urban” problems) seem to be successfully solvable with the help of a mobile or web application, others resist to any standardization and translation into check-lists, menus, categories and standards.

The goal of the present article is thus to question the omnipresent belief in programming code and ICT as agents of social good. This article is based on an empiric study of several Russian and French civic applications, apps for web and mobile developed in response of a particular social problem. I propose to address the problem of asymmetry from the perspective of STS and software studies (Fuller, 2008).

Inspired with the design-oriented approach (Badouard, 2014; Akrich, 1999; Simondon, 1958), I focus on the phase of conception and design of interfaces, as well as on the process of testing. As Simondon puts it, technical objects “translate a number of notions and principles into matter” (1958, p. 46). It is in order to de-script this translation that I followed the work of programmers, UX-designers and social activists, and analyzed the materials they produced (code, mailing lists, blog posts, paperwork).

In what follows, I will firstly present my cases. Secondly, I will focus on the design phase of civic applications and will distinguish several fundamental operations that transform public problems: standardization, classification and translation. In the third part, I will speak about the overflows of this technical framing, giving examples of how the empirical experience of a trouble (Emerson, Messinger, 1977) resists the standardization imposed by digital interfaces. To conclude, I will underline the outcomes of civic apps for the civic participation.


Case-studies and fieldwork

An impressing number of mobile and web applications have been developed recently with a mission to address important social and political challenges. Only by 2012, 272 civic apps were developed in Russia by various NGOs and individual activists (according to the report of Greenhouse of Social Technologies7, an agency specialized in promoting civic technologies in Russia). However, this research focuses only on the most used and the most original applications. The table below sums up the cases of civic applications that have been studied.


Case studies



All these cases use the principle of crowdsourcing, giving a multitude of users a possibility to report on their individual problems, and by doing it, to participate in a mass movement. Among 40 different definitions of crowdsourcing (Asmolov, 2014) presented in actual research on crowdsourcing technologies an important body of studies insists on a problem-solving potential of these tools (see for example Brabham D. C, 2008). This is recognized by developers and designers of crowdsourcing tools, who are rather reflective on the social aspects of the software they build.

Vitaliy V., developer, organizer of “Spb Data Hack”, annual civic hackathon in Saint-Petersburg, defines crowdsourcing as “the way a large number of persons can help you to solve your problems when you share your problems and your knowledge”. This definition seems interesting as it mentions “your problems” twice. It insists on the importance of a personal experience as well as on a sort of an ownership or attachment that people have with “their” problems. Organizers of civic hackathons would even speak of “problem owners” when identifying these non-tech participants who bring their challenges and ask for technical solutions.

By consequence, to design a crowdsourcing problem-solving tool means to translate specific experiences in a series of micro-tasks that could be potentially delegated to a multitude of anonymous actors who experience the same kind of problems. By accomplishing small-scale actions, these users can contribute and co-construct a body of data on a variety of important social issues. When no official data is available, as in case of such controversial social problems as corruption, electoral falsifications or police violence, these crowdsourcing tools become, for the citizens, a means to construct a civic expertise of these issues. Engaging a particular kind of digital labor (cf. for example studies of Amazon's mechanical turk in Kitter, Chi, Suh, 2008) crowdsourcing supposes production of value and meanings out of a multitude of micro contributions.

But how precisely do developers come from experiences to code? How does this transfer occur? In what follows I will focus on the operations of problematisation, standardization and categorization that precede and accompany the coding itself.

From an experience of trouble to a user experience: coding public problems

“To describe in a different way

is to open a possibility of a different world”

Daniel Cefai

Observing elections, denouncing ethnic profiling, alerting on leaking roofs… Is there something in common between these civic applications besides their technical format? The inquiry shows that all of the cases have some striking similarities, not that of structure, but that of experience. In fact, the authors of the applications started from an experience of a trouble: something was going wrong, and traditional methods of problem-solving did not give satisfying results. The working group composed both of tech experts and social activists had to look for a means to understand and re-describe their situations, to re-attribute responsibilities and inscribe troubles into “problematic fields”. The idea of coding an app appears in a certain moment when a group of “problem owners” has gathered a certain critical mass of experiences of trouble, and the operation of “naming” (Felstiner, Abel & Sarat, 1980-1981) has already been undermined: a step has been made in understanding the link between an individual trouble and the global situation. A problem has been recognized as a public one. The initial trouble had gone through a reflexive transformation and resulted in a production of new ways to describe, categorize and make public the problematic situation, producing a new account of it, as H. Garfinkel and H. Sacks would say. These operations of categorization of experiences, classification and standardization of troublesome cases are, in all the case-studies, an essential operation that makes possible a translation of trouble experiences into code.

The technical format of an application is based on the so-called “check-lists”, represented as lists of categories, questions to answer, checkboxes and fields to fill. This specific architecture supposes that a problem has already been redefined, and its essential elements have been distinguished and classified. The check-list acts as a filter, both technical and communicative. Technical, as it helps to produce homogenous data that could be represented on a map, visualized, analyzed, reused. Communicative, as it provides users with a means of putting-into-words their individual troubles. Transformed by the technical device, the accounts of experiences are standardized and represented with a public language. These lists and tables are, as Jack Goody argues, also forms of thinking and organizing reality. They help to reorganize data and come back to it at any moment. They also give people a certain power over the information (Goody, 1977).

However, before actually being able to code the check-lists, actors launch inquiries, in a pragmatist sense of the term. They need to re-describe the problem, to produce a different account of it. They aggregate knowledge from different sources: laws, personal stories, general culture and common sense, technical norms and standards. They also produce intermediary devices, such as tables and questionnaires on paper, SMS or telephone hotlines, printed handbooks or guidelines, mail, pages on social networks. The actual mobile or web application often comes last, incorporating all these tools, capitalizing on this information and synthesizing efforts and knowledge. Digital applications do not subsist to other tools but offer different functionalities.

In what follows, I will give several examples of interface development presented as a dynamic process of testing, experimentation and inquiry.


Putting discrimination into code: an app against ethnic profiling

When a trouble is experienced at the same time as intimate, physical, corporeal, and as public or even as political, as it touches the values of human dignity, equality and identity, the operation of translation and putting-into-words is especially complicated. How to make codable such an intimate experience? How to extract essential elements from an experience of suffering and humiliation in order to present it in form of check-lists and fields to fill? The example of the app “Stop Le Contrôle au Facies” app (later – SLCAF) is fascinating in this context, as it aims to respond to a very particular kind of trouble, that of facing physical and verbal violence, experienced as illegitimate. This violence comes from the representatives of an institution that is supposed to be protecting the social order and justice. The aim of SLCAF collective was thus, in this context of institutional dysfunction and mistrust, to give people touched by ethnic profiling a new system of coordinates, a possibility to put into words their experiences and to find other people concerned by the same problem. The collective used a bunch of web-based tools - the app, pages on Facebook and Twitter, Youtube account, flashmobs and “memes”. It helped the members to construct a public understanding of causes and consequences of ethnic profiling, and to propose a reform of the ID control and police deontology.

The authors of the idea of this app were members of several local associations against discrimination situated in suburbs of Paris (Zonzon93, Brigade Anti-Negrophobie, Collectif Contre l’Islamophobie, Urgence Notre Police Assassine etc). They witnessed or experienced police violence and ethnic profiling themselves. They worked with two developers for several months. The task was to make personal experience translatable into user experience and to build an interface that would take into consideration the different situations and problems that can occur during ID-control.

This kind of collaborative work made possible a truthful transfer from a personal face-to-face regime, often invisible, as the controls tend to happen at night without or with few witnesses, to a public register. Sihame, the moderator of the app, lawyer and the spokesperson of the SLCAF, explains it:

“We started as a group of associations against discrimination, we organized meetings in different districts (of Paris and suburbs) speaking with young people and explaining them what to do and what to say when you are controlled. You have about 11 times more chances to have your ID controlled when you’re a young black or Arab, then if you are a white person. We all had like ten, twenty controls a year, and even more (…) One can’t easily speak about it, as it can be humiliating, and you don’t know to whom you should address to, and how… So we started with this SMS number, and then with the app, so that we can keep track of all this and use it in the court if we get in trouble”.  (Interview with Sihame, moderator of SLCAF)

The application itself was not a starting point, but a result of an inquiry and a reflection over personal experiences. A series of experimentations with different technical and legal formats was deployed. The first format was an SMS alert system, accessible from any phone, without a necessity to have a 3G or Wi-Fi connection. One has only to send a word “control” on a specific number in order to get a call back and an assistance from a moderator of SLCAF hotline, and be connected with a lawyer or a doctor, if necessary. The usage of the SMS number was promoted with the help of a web-documentary “My First ID Control” realized by SLCAF with popular hip-hop artists, sportsmen, graffiti makers and other public figures who shared the experience of their first discriminative control. The major task was to find a way to make people speak about these controls.



The web-series was distributed on Youtube8 and seen about 2 million times. A special Excel table has been developed, that contained different elements necessary to build up a solid account of a control. An account that could be potentially used later in the court. The information about place, date, time of control, as well as number of policemen, their attitude, physical or verbal violence used and other criteria were incorporated into an Excel table that was filled manually by moderators of the hotline. After first hundreds of “control”-stories gathered, the activists introduced another format, - a paper version (prototype) of a receipt of ID-control. This little A5 sheet was distributed to local SLCAF activists who were supposed to use it when controlled by a policeman. These sheets were not used massively (only half a hundred of these sheets was finally gathered by the local activists), but served as a first prototype for the future check-list of the app.

Check-list with following fields: “Name, surname, Birth date, Sex, Address; Type of ID (passport, driving license, resident card…); date, time and place of control; ID number of policeman; motif of control, type of intervention (none, palpation, visual control of personal belongings, other); result of control (without consequences, warning, verbalization, interpellation, other); precisions; commentary of the controlled person; signature of the controlled person”.

Another important document was the “Guide du Contrôlé”, a guidebook accessible for downloading on the Website of SLCAF9 and distributed by local activists of SLCAF to the persons who are susceptible to be controlled. The guide has been developed on the base of two years of experience of SLCAF and with the help from legal experts and rights defenders. With a subtitle “Know your rights, act together”, the guide enumerates the types of ID control, the features that distinguish the practices of ethnic profiling from non-abusive controls, gives several cases of an ethnic profiling control, tips to communicate with the police, typical letters of complaints, contact information of legal organizations.

Though the “Guide” turned out to be an efficient handbook, it could not gather data about the cases of control. It was a one-to-many communication device, only giving information without gathering data from people who experienced control. Therefore, the webapplication was prototyped in order to gather and centralize stories about abusive cases of ID control.

The development of the app started only in late 2013 and the app came out publically in 2014, three years after the creation of the SLCAF association. It was developed for free by two young programmers, Vincent and Emilien, members of hackerspace in Montreuil, known for its solidary approach, with an idea to give an equal access to hacker practices and education to less privileged populations. The app was developed in html5 as a webapplication, in order to be accessible on any support, web or mobile and was based on a check-in with a series of questions.



Pictures 2, 3: screenshots of the application SLCAF

On the left: “Police agent’s ID (Impossible to pick up); given motif for the control; type of ID presented (identity card, passport, driving license, resident permit).

On the right: “Have agents of control shown violence? (No, verbal, physical) if yes, please precise); Have the agents of control used discriminative discours? (No, yes) If yes, please precise)”.

An individual experience when shared with a standardizing and centralizing interface, becomes a part of a bigger process of a construction of a public problem. On a political level, the web-based technologies of crowdsourcing serve for SLCAF as an instrument to make pressure on the French government and support their struggle for the reform of ID-control. But it is also a means of communication that gives voice to a silent population, and a source of renewal for the repertoire of actions for NGOs and associations:

“We create a new dynamic within the associative movement. French associations try to speak in behalf of persons whose rights they pretend to defend. We are willing to give them a voice to express themselves, whether with the help of a web-series, SMS number or a webapp…We give them an instrument of action, a capacity to act, a dignity”.  (Interview avec Sihame)


Making transparent the black ballot box: a Russian app for observing elections

It is as well from a common experience and from a collective work of problematization and categorization that the idea of “WebNabludatel” app was forged by a group of independent developers and activists, formed ad hoc around the project. They all witnessed, either directly, or thanks to the thousands of videos accessible on Youtube, the massive falsifications of elections on the 4th of December 2011 by the people from the “United Russia”, Putin’s party.

In the context of forthcoming presidential elections of 4th of March 2012, an idea of a mobile application for observers was proposed by Ilya Segalovitch10 on the, the most used IT-professionals’ forum in Russia. Segalovitch, one of the opinion leaders of RuNet of that time, published a post11 on the 22nd of December 2011 proposing the idea of an “electronic observers’ diary”. In only 48 hours the post was liked 117 times and commented 398 times. Users started spontaneously sharing their personal experiences of witnessing fraud, violence and discrimination while being electoral observers. About forty stories were posted by users who worked as observers and faced difficulties during the elections, for instance:

User 1: “The cops kick you out (from the voting station) without any explanations: “first you get out, and then we’ll bring you your papers”. They wrote me “Was interrupting the work of the electoral commission… Violation of the Federal Law #51” This is certainly a lie. And I had lots of witnesses and a video recording I made”

               User 2: “Have you complaint about the fraud?

User 1: “Yes, sure. I complaint to TEC (Territorial Electoral Commission), to the court, to “Citizen observers” and “Demvybor” (NGOs specialized in observations). All complaints normally should be addressed to TEC, and they have, according to the law, to treat immediately every complaint they get, as soon as they got it. I brought my first complaint to TEC at noon. They told me they would examine it in one hour. Firstly, I was just naively waiting, then I spit and came back to the voting station. When I came to see them next time (at 23:30 in the evening) I found out that they had not treat any complaint and any declaration at all”.

 (From an online discussion, posted on 22nd of December at 14:31)

These accounts of inefficiency of existing controlling institutions (TEC) coexisted in the same space with first spontaneous technical design specifications, ideas of the application interface and check-list. The back-and-forth between stories about fraud and design solutions contributed to build connections between an experience of trouble (material and legal reality of electoral observations) and a “user experience” (how to put these heterogeneous accounts within an application).

In a few days after the post of Ilya Segalovitch, the working team was constituted, counting 12 active members and 5 more people engaged on different stages of the development to help with particular aspects, for example, legal consulting or betatesting. The whole story of WebNabludatel's creation can be seen as an example of a “stigmergic collaboration” (Ermoshina, 2014 b), the concept used by several scholars to describe a spontaneous self-organization within open-source and civic hacking communities based on indirect incentives (“artefacts”) and mutual aid (Heylighen 2007; Eliott 2006; Robles and al. 2005). The whole coding work was volunteered and free, with an “absolute” deadline of the 4th of March 2012 (the day of the presidential elections). It only took one month for the team to come up with a website with a collaborative map of frauds, data visualizations and two working mobile apps (Android and iOS). The team was united by experience, with 4 of the 12 active members of the team being themselves electoral observers, sharing their stories on early stages of the collective work on the app, and orally during the brainstorming sessions when the team physically gathered together to discuss first ideas of the future check-list and interface.

The development of the interface needed a complex work on categorization of fraud and classification of voting practices. The team decided to inscribe a certain temporality in the application and structure the user experience around a standardized “scenario” of elections: from the opening of the voting bureau to the voice count in the night. In order to realize this standardization, both technical and legal expertise were required, in order to provide a coherence between the code and the law. It is with the help of several members of the NGO “Golos”12, specialized in electoral code and in the training of observers, that the team of “WebNabludatel” was finally able to elaborate a simple 6-screens menu based on legal norms.

As in the case of “SLCAF” app, the digital interface was based on several legal documents and guides. First of all, it was the so-called “Roadmap of an Observer”, a document printed out on A4 paper and normally distributed by NGOs to independent observers before the day of elections. This document serves as a guide and is presented in a form of a table with fields to fill and check-boxes. The basic categories of data are: “Controlled event”, “Where to write a complaint”, “Which law is regulating it?”, “What is the sanction for this?” and “Useful links”13.

Another document that served to build the check-list was the Electoral Code of Russian Federation. Alexey P. explains this translation from law to code:

“In the beginning we had a very big text of electoral code that should be about 200 pages I think. So… me, our designer and Gregory M., lawyer from “Golos”, sat together and made a kind of a draft of our menu. It had to be easy – imagine, you are an observer, you come to the voting office in the morning, so… what should you do right from the start? You should verify if the urns are empty, if the papers are here and so on… So we made a list of questions for every step. This list was in about 20 pages long I think and our designer said – it is not possible to put all this text in a mobile app, we will just be lost inside it. So she managed to reduce these materials to only 6 screens with essential questions, and everything is based on the law”.

(Interview with Alexey P., coordinator of WebNabludatel, developer)



Pictures 4, 5, 6: screenshots of WebNabludatel app.

On the left: “Log in using Facebook or Twitter; name, email, telephone number, status”.

In the center: “Status: voter, observer at a PEC (Precinct Election Commission); observer at a TEC (territorial election commission); member of TEC with a deliberative vote, member of TEC with a casting vote;

On the right: « Step: Preparing of the voting station. Questions: Information on candidates is rightly presented (“yes-no”); sample of a ballot presented (“yes-no”); enlarged copy of a protocol presented (“yes-no”); propaganda materials closer than 50 meters from the voting bureau (“yes-no”);

The questions of this check-list channelize the activity of an observer. Tatiana, UX-designer, underlines the necessity to guide the observers:

“The process of control of elections is rather sophisticated. Normally, people spend several weeks learning how to react to the situations of fraud in an appropriate way… Our goal was to make that the rules would be literally in your hand, so that you could consult them rather quickly and understand immediately how to react in this or that situation”

(Tatiana M., designer of user interface of WebNabludatel app)

The application also considers the risk of aggression and a possibility to be expulsed from a voting bureau, thanks to an SOS button incorporated into the interface. Even the specific kind of buttons is chosen to fit at best the situation of urgency. As Tatiana M., interface designer, explains it, “instead of checking a box that supposes pushing on a small icon, which is difficult to do on a touch screen of a smartphone, one has only to move a finger from left to right or vice versa, it is a usual gesture for smartphone users”. The user experience is fully rationalized to correspond to the experience of electoral observation, with its specific temporality and spatial organization.

While the observation takes place in a context of urgency, the questions of the check-list have to be simple and clear. Therefore, the check-list is based on a set of closed questions with three possible answers (“yes”, “no”, “no data”). According to the answers to these questions, the system automatically detects if a fraud has taken place. The code of the app supposes the “if” equations, and in case of giving a certain answer, it can calculate and refer to a corresponding legal text (article of the Electoral code). For example, “Are there any propaganda materials in the perimeter of 50 meters around the voting station?” If yes, than: violation of the Article 54, point 10, of the Electoral Code of Russian Federation. The activity of verification is thus delegated to the machine and to external norms and laws, while the observers’ activity is focused on the attention, perceptual activities and alert (Chateauraynaud, Torny, 2002). This kind of electoral observation is an interesting example of a distributed cognition: while human agent acts as a sensor, the machine works as a storage system and as an analytical device that can keep track of the human observations, analyze and represent them in an intelligible form.


Struggle against potholes as a struggle against corruption: Urban applications

As we’ve seen it on the example of the inefficiency of TEC, unable or unwilling to treat complaints and control the fraud, a civic application can become a means to overcome the existing dysfunctions in communication between citizens and official institutions. As Daniel Cefai notes it (2013), the construction of a public problem supposes producing a critical account of power relations in the problematic field. During the phase of inquiry into a public problem and collective construction of a new description (account), the actors redefine the attribution of responsibilities, questioning the monopoly of official institutional actors to serve as referents to a certain kind of problems.

The four “urban” applications listed in the table on the page 12 (RosYama, app against potholes; RosZKH, app against housing problems; Krasiviy Petersburg, app that treats 12 kinds of urban anomalies, and Zalivaet.spb, app against leaking roofs) have all emerged out of an experience of an unsuccessful communication with city services. While “typical solutions for typical problems” (Schutz, 1944) did not work, the idea to develop digital instruments for communication of problems appeared as a necessity.

However, as in the two previous cases, the actual digital format of a web or mobile app was been preceded by inquiry and experimentation. Actors had to redefine their problem, find out the best addressee (the institutions to whom they can address their inquiries and complaints), the kind of vocabulary to use and the legal texts to mobilize in order to make the message stronger and understandable for the administrations. The story of Dmitry L., founder of “RosZKH” application, illustrates quite well this initial trouble of communication, as well as the inquiry and the solution he found:

“I was graduating from the faculty of law, Moscow State University, and I had a problem in my yard. Several neighbors had installed barriers on the parking space which was normally free and public. They “reserved” spots for themselves. I wanted to do something about this. First of all, I went to see the person responsible for ZKH14 in my district, but he sent me back home, as happens to all citizens in this country in all ZKH offices. I was tired of public services doing nothing, and I wanted, using any legal means, to understand what they are supposed to do and how to make them do it. So I found the specific institution responsible for my problem, the Inspectorate. I wrote to them and it worked. I shared my experience with friends and relatives and then created the project, where I have put the texts of typical letters to be sent to the Inspectorate, with a list of addresses”.

(Interview with Dmitriy L., lawyer, author of the concept of RosZKH app)

Dmitriy, just like the founders of the other three urban apps, started to deal with his problem using traditional instruments – letters of complaint to local services. However, it turned out to be inefficient. In this quote, an interesting transfer is made from an individual problem with parking lots to an assertion of a global problem: inefficiency of ZKH services everywhere in Russia. As the trouble is inscribed into a public field, the algorithm of the application should be accessible to a potentially large public all over the country, integrating the legal experience and know-how that Dmitriy managed to accumulate. We can speak about this case in terms of micro-politics of trouble as described by R. Emerson and S. Messinger (1977): the difficulties we face in our everyday life happen within more or less stabilized “problematic fields”. We are looking for “typical solutions of typical problems” but when these solutions are no more accessible and do not work, a “trouble” can progressively take the form of a problem, assign the solutions and the “troubleshooters” (Cefai, 2013).

For the urban apps I’ve studied, this new solution was to build up a very different scheme of communication with authorities by re-attributing responsibilities. Instead of using direct communication with local technical services, the authors of the four apps came up with the same kind of algorithm: send the complaints “up there”, to the top of the hierarchy.

“Finally after five or six visits (to the municipal council) I decided against going there and found the website of the central city administration on the internet. I started sending them my appeals directly. Actually it turned out to be efficient because when you send letters “up there”, they trickle down to local officials, and they are so willing to get a good reputation and are so afraid of their superiors that they start working and remedy your problems. This became the basis of the mechanism that we now use in Krasiviy Peterburg. We are sending everything to the very top – to the Mayor of the city – and then they send it to the local administration”.

(Interview with Krasimir V., founder of Krasiviy Petersburg app)

I call this communicational scheme “long network” as opposed to “short network” scheme used by the official applications, developed and financed by city administrations (for example, “Dans Ma Rue” developed by the IT department of the City Hall of Paris, or “Mobilnaya Priemnaya” developed by the City Hall of Moscow). In the case of short chains, the alert comes from a user directly to a responsible worker. While civic apps built by independent developers and activists use indirect or long chains. These prolonged networks engage new intermediary actors in the treatment of a particular case. While the individual complaints “travel” from the Major’s office to local officials through the ramified pipelines of Russian administration, they obtain a certain institutional weight on every level of the administration, as they are printed out, signed, stamped, scanned, resent from one official to another. This indirect or long network makes the administrative hierarchy act as a sort of an API15 that redirects complaints from a service to another and by this “empowers” individual stories.

As in previous cases, the digital application appeared only after a series of experiments and inquiries. For instance in the case of the application Krasiviy Petersburg, the activists started with paper letters, emails and pages on social networks. In the very beginning of their work, in the fall of 2012, they organized several “photowalks”, a format of collective inspection of a particular district of the city, where all members are equipped with smartphones or photo cameras and observe the city space looking for “anomalies”. Every time they notice something that attracts their attention, they take a photo of the problem (for example, a pothole, an illegal advertising, a broken street lamp or an illegal parking), take down the location of the problem and then come back home and write a complaint about it to the City Hall.

In the beginning the activists used only a page on (Russian Facebook) and were writing all complaints manually in form of letters or emails. But when they had accumulated several thousands of anomalies, they decided to build a webapplication. They also invented a “table of anomalies”, a printed A4 sheet distributed during photowalks in order to keep track of all anomalies noticed. This “table” – useful because it could be transportable during photowalks - was later replaced, or, better say, complemented, by a smartphone application for Android and iOS. The application was developed only in 2014, two years after the actual creation of KP movement. As in the case of “Web Nabludatel”, the advantage of having a mobile app was to accompany the users while they move in the city, giving them an opportunity to take pictures, geolocate and describe problems with the same tool. Moreover, the description of the problems was already built-in, with the system of a check-list (list of categories of urban anomalies and a few fields to fill in).



Pictures 7, 8, 9: screenshots of “Krasiviy Petersburg” app.

On the left: “Step: creating an appeal: “Trottoirs, Green spaces, Roads, Facades of Buildings, Advertisement and trade, Pillars and Cables, Cycling, Monuments, Hatches, Public transport stations, Garbage…”

In the center: “Step: Green spaces. Sub-categories: “Parking on a lawn, Infractions in parks and squares, Need for planting a greenery, Damage of a lawn, Make an ecoparking, Broken trees”

On the right: “Creating an appeal. Region, District, Street, Number, Exact place; Additional information: Create a track for the pedestrians; Put limitations to prevent parking on the lawn; Put or repair border stone”

As in the previous cases, the development of the interface of the app demanded an operation of classification of problems, standardization of anomalies. The urban apps proposed a check-list based on legal norms and technical standards. In order to define what is a fault or a problem, developers collaborated with lawyers to bring the app into accordance with technical documents and standards such as “Highway code”, “The housing code”, “Norms and rules for technical uses of the housing fund”, “Norms on the provision of public services and utilities”, “GOST” (State Standard) and other legal and technical texts. For example, in order to build the classification of anomalies and the list of categories to chose from, the developers of RosZKH relied on the text of “Norms and rules for technical uses of the housing fund”:

“Actually, a fault is everything that deviates from the ideal state of things, and this ideal state is very well described in the “Norms and rules…” For example, they specify that all metal door accessories, like door handles or door hinges, must be polished and shiny. So, anything that is not in these norms is a fault and we have the right to report it because we pay for it every month”.

(Interview with Dmitri L., lawyer, author of RosZKH)

The Krasiviy Petersburg application uses categories of public services both in its menu and in the texts generated by the app. “We have to speak the same language as the administration, otherwise they do not understand what is really going on. So we used legal texts to identify expressions for the app. For example, we must say “green spaces” (zelenye nasajdeniya) and not grass or flowers,” - Steve K., one of the creators of the Krasiviy Petersburg app, explained. Actors thus see the translation of ordinary experience into official terms as a necessary operation that leads to a successful dialogue between app users and civil servants.

Proposing a media that describes ordinary experiences in a different way, civic applications open a possibility for a different world. As Françis Chateauraynaud and Didier Torny argue in their book on whistleblowers, citizens’ vigilance begins with basic acts of direct perception of what is going wrong – walking in the city, seeing, smelling, touching “the anomaly” (2013). Recent researches on mobile technologies and mapping show how locative media and mobile applications transform our perception of the city space (Farman, 2012). The apps channelize users’ sensing activity and observation: they attract attention to a range of problems that have earlier been in the background of perception.

But, Chateauraynaud and Torny argue that the perceptual vigilance is only the first step towards the actual act of whistleblowing: citizens must than translate their perceptions into a narrative, or, better say, into a code. The application, with its system of categorization and classification, translates experience into an event and makes experiences tangible, quantifiable and communicable to others. An anomaly that is at first a bodily experience is passed through the techno-juridical filter of a civic app, and turns into a transcoded alert, formatted, translated and expressed in a code used by the actors of the institution whom it addresses. And for the civil servants, “it is the code itself that constructs the event” (Chateauraynaud & Torny, 2002, p.38).

The classification is an operation largely analyzed in STS-literature. As Bowker and Star notice it, classifications and standards are important as “sites for mediation between the technical requirements of the systems developer and social and political requirements of the community” (1998: p. 232). In the cases of the civic apps I’ve analyzed, the categorization and standardization were indeed inevitable from both technical and social points of view. Technically, it is important for the developers to have a set of elements, unities to which they can attribute a certain logic or values (for example, “true” or “false”). The categorization makes it possible to quantify electoral fraud, as in the case of the WebNabludatel’s app, but also to measure corruption or efficiency of the city services. It is technically complicated to code an “app against corruption” as such, taken as an abstract and general notion. However, it is much easier to split this problem in a set of elements and identify a sequence of small tasks or questions that can be delegated to a multitude of users. Realizing these small tasks, users would participate in a collective aggregation of data that can be useful to evaluate the scale of corruption, its geographical distribution and other characteristics.

Socially, or politically, the categorization is important as it translates the indignation into an account that can be transmitted publically, to official institutions or press. As Cefai puts it, “one can be a miner suffering from silicosis, an irradiated citizen, a beaten woman or a discriminated black, but one is nothing until there exists an enunciation device to see or tell it publically – that means, a language, a place of an enunciator and a recipient” (Cefai: 2013, p. 19)

The categorization modifies language of complaints, for example, by limiting number of characters in the description of a problem, by generating automatic legal references, by reminding a user about important details of his or her experience, by taking emotions and personal experiences out of the account (as the developers of RosZKH put it, emotions do not help to resolve a problem). As Cefai argues, the categorization and standardization of experiences helps to “select a context of description, to specify a problem by reducing its contingency and normalizing it, comparing it with others and attributing to it some general characteristics. It means to “inscribe it in a practical field, determining “who is affected” and “who has a capacity to react” (Cefai, 2013: p.7).

However, the classification and standardization of anomalies into code does not work for all cases. The reality of public problems turns out to be richer and more complex than their representation in code.


Overflowing classifications: the limits of apptivism

«Recall one of those forms you have filled in

 (we have all experienced one)

which do not allow you to say what you think…»

(Bowker, Star, 1998 : p. 242)

In fact, the limits of classification have already been underlined by a number of researchers in STS (Bowker, Star, 1998), for whom standard and category valorize some point of view and silence another. The moving and changing reality can surprise and transform the existing classification models, and make developers rewrite the check-list, adding new categories. None of the civic apps is technically capable of automatically detecting a problem and it is up to human agents to decide whether this or that event must be reported with an app.

This leads to debates among users and teams of developers on how to distinguish a fault from the norm. Thus, during my observations of the already mentioned photowalks, on several occasions I saw users debating a specific case and deciding whether the case at hand is a real fault. For example, a pothole, according to legal standards fixed in GOST, should not exceed 60x50x5cm. Everything smaller is not considered as a pothole and will not be fixed by city services. The app not being able to measure the dimensions of the pothole, users apply a variety of objects that they have « at hand » in order to measure them, for example, putting their shoe or a kick-scooter inside a pothole.

Real problems that actors often perceive as complex juxtapositions and a mix of several faults, have to be simplified and tagged with only one category from the app’s menu. I remember observing testers of the Krasiviy Peterburg mobile app standing at an unfenced decaying lawn with a big Jeep parked on it. They were deciding how to classify this fault – as a problem with « green space », or missing fencing, or illegal parking. The testers finally agreed on missing fencing, justifying it as “more important because it is a long-term problem, and the Jeep will go away before the police comes, and if we put up a fence, he will not be able to park here again.” After this accident, the developers have added a possibility to add « repair the fence » to both « Illegal parking » and « Problems with green space », transforming the classification of problems.

Transcoding a personal experience consists of standardizing and impersonalizing the particular case, otherwise it is impossible for the app to generate a text of a complaint. The emotional aspect of complaints is also something that the apps tend to control, either by recommendations to users or by technical means. For example, when filling in the form on the Zalivaet.spb app, a user is instructed on how to describe his case: “Set your emotions aside, give us a very brief description of your problem”. The RosZKH app tries to control emotions by technical means, it allows only 350 characters to describe a problem. Dmitri Taralov, the app’s moderator and administrator, explains why such a limitation is necessary:

« In our experience it is enough. Some problems can be described in 140 characters (Twitter standard), 350 is a lot. Secondly, we want to protect ourselves and the administration from people who like writing a lot while saying nothing. You know, there are these people called professional complainers, who enjoy describing their problem on several pages when it is possible to express it all in five to seven phrases ».

This limitation by design challenges the practice of handling grievances and complaint writing that has a long tradition in Russia. The Russian sociologist Elena Bogdanova analyzes petitions to the Russian president Vladimir Putin in terms of justification (as understood by Boltansky & Thevenot, 1991) and demonstrates that the “textual space of a complaint contains the language of both sides (the author and the addressee)”. (Bogdanova, 2013, p.13) In the case of civic apps, the author’s language tends to be replaced by that of the machine. The justification within categories of personal experience is replaced by legitimation in terms of legal and technical norms.

This translation seems to be technically justified: it is necessary in order to enable complaining via web and mobile applications (within closed interfaces and menus), and consequently making this practice universal and replicable. However, lots of users experience it as a form of restriction and control, or, what I call an “asymmetry-by-design” mentioned above. The asymmetry-by-design results of a conflict between the categorical grid (check-list, menu, fill-in forms) and a lived experience. As Bowker and Star argue, “when experience meets the formal-structural, such as when one tries to squeeze one’s complicated health history into a multiple-choice questionnaire, tension usually results” (Bowker, Star: 2007, p. 274).

However, users  tend to overcome these technical limitations by inventing some ruses. For example, Alexey B., a very active user of Krasiviy Petersburg app (with about 400 cases declared), shared with me several of his “hacks”. For instance, in order to join two photos instead of one (the app is limited to one photo per problem), he merges two photos into one using Photoshop or making a printscreen on his mobile phone. He also writes long complaints in Microsoft Word or other text editor and joints them to his complaint in a format of .jpg as if it was a photo, thus overcoming the restrictions of characters imposed by the application.

Users share these kinds of ruses on special pages on and Facebook, producing another kind of expertise that tends to complete the fails and to repair asymmetries caused by standardization. Moreover, as the majority of the civic apps are opensource, user communities participate in beta-testings, actively report bugs and provide feedback. Eric Steven Raymond analyzes this shift in “producer-user” relationship in his canonical text “Cathedral and the Bazaar”, underlying the importance of the users to the opensource projects. He writes: “Lot of users are hackers too.... Given a bit of encouragement, your users will diagnose problems, suggest fixes, and help improve the code far more quickly than you could unaided. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging”. (Raymond, 1996). Indeed, in the case of the civic apps, the community of users becomes a major actor in improving and maintaining the software. In this sense, they seem to counterbalance the user/developer asymmetry mentioned earlier.

While urban apps seem to be more or less efficient and flexible the SLCAF app is a particularly problematic case that shows limits of apptivisation of public problems and asymmetries that it produces. In fact, the application is rarely used as the only tool of reporting on ethnic profiling. Gabrielle M., moderator of the app, shares her experience:

« We only have about 600 cases sent with the app. And people do not fill in all the fields, they do not want to give all the information to the app. They prefer to be called back and talk to a human being. They still prefer to speak to us. We listen to them and write down what they say, as we used to do it before the app ».

(Interview with Gabrielle M., student of law, moderator of SLCAF)

It turns out to be quite difficult to realize the SLCAF’s initial mission to give people a possibility to speak out loud, as opposed to “talking on their behalf”, through an interface of a web-application. A preexisting interface with its grid of categories, with its check-list with closed and open questionnaires changes the way people complain about their experiences: their stories are transformed, filtered and shaped by the app’s interface.

Unable and unwilling to fit their experience in a restricted format, SLCAF users would rather prefer to be called back and to talk to a member of SCLAF association. It is precisely the possibility to talk using their own words that they search. To call a cat a cat, to describe what a policeman was doing with one’s body or belongings, or what he was saying, and not to chose from a list of closed categories (Have you experienced “physical” or “verbal” violence? If yes, then precise).

In this sense, it is interesting to come back to Brabham’s critics of crowdsourcing. For him, in a crowdsourcing project the purpose is already defined by the organization, while the users have a limited degree of freedom in their participation. According to Brabham, on the one hand, “when the locus of control is too much on the side of the organization – the crowd becomes a mere pawn.” On the other hand, “the opposite end of the spectrum when the locus of the control resides more on the side of the community” leads to self-governance, while a situation where “the organization is merely incidental to the work of the crowd” is also not considered by Brabham (9) as crowdsourcing » (Brabham, 2013). In this sense, it is thanks to a variety of different formats (SMS-alerts, telephone hotline, guidebook, web application) that a certain balance can be achieved between technological frame, organization and individual experiences.

This case highlights a paradoxical ambiguity of civic applications: on the one hand, they claim to help users speak on their own behalf and optimize the complaining practices. Though on the other hand the standardization process replaces their language by that of the apps’ authors. As Bowker and Star ironically underline, “helping (people) reclaim the sovereignty of their lived experience has often been seen as an act of heroism… However, this can take the paternalizing form of speaking for the silenced people (what some scholars have called ventriloquism)” (Bowker, Star: 2007, p. 279). This notion of “ventriloquism” refers to the two kinds of asymmetries I mentioned above. Firstly, the divide between coders and users, between those who define the problem, and those who live it. Secondly, the asymmetry produced by the standardization. While the user-developer asymmetry seems to be more or less counterbalanced by the contributive activity of user communities, their ruse and expertise, the danger of the asymmetry-by-design resides in the very interface of the applications. The standardization of individual experiences can provoke an asymmetry between lived experience and categorical grid. The active implication of users into bug-reporting and feedback can keep the grid more flexible, reflexive and adaptive.



The goal of the present paper was to examine the belief in the efficiency of code as a problem-solving tool. More and more civic applications have been developed by social movements, activists, right defenders, NGOs, using crowdsourcing technologies with a hope to empower citizens and build new ways for disadvantaged groups to overcome asymmetry and make visible their problems. While a certain skepticism is present in literature in regards of these tools, a focus on their design process can bring us more elements for an analysis of their limits and potential.

In the article I proposed to follow several case-studies, an application against police discrimination and ethnic profiling, an application against electoral fraud and a bunch of urban apps, dealing with different problems related to urban equipment. Following the genesis of these projects, I found that the design solutions had grown out from a certain activist experience and expertise. Indeed, the interfaces of the applications result from inquiries that actors deployed in order to redefine the trouble and reattribute responsibilities finding the institutions that can be relevant in responding to the given problem. 

During these inquiries actors produce different supports that preceded or accompanied web and mobile applications. These devices, such as paper questionnaires, guides, roadmaps, mail, pages on social networks, SMS-alert system and telephone hotline, are based on a collective work of a community of developers, NGO activists, lawyers, users and keep traces of classification and standardization of knowledge on a given problem.

It is important to underline that these devices are not completely replaced by applications but rather coexist with them. The civic applications do not put an end to the preexisting means of action. On the contrary, the variety of tools gives users a choice and enhances the likelihood to get the problem solved. This multiplicity of “enunciation devices” responds in a certain way to the problem of asymmetry and that of digital divide.

However, civic applications do something new compared to other tools. Thanks to the algorithm of “long networks” the civic applications help users identify the addressee of their complaints and alerts. It is the administration itself that acts as an API, redirecting the alert to the relevant agent. They also standardize the way users complain and alert: the closed check-lists and interfaces guide users and produce perfectly written and legally empowered texts. Civic apps being based on legal texts, they translate law into code and thus democratize the access to legal expertise.

Development of civic apps is based on categorization and standardization: one cannot make an app “against corruption”, however, by breaking a global challenge onto small tasks (microtasking), it becomes possible to build crowdsourcing applications. As Bowker and Star put it, this classification and categorization is necessary both for programming and for communities that produce new accounts of a problem, new descriptions of experiences in a public language. Indeed, civic applications become translating tools that help users to communicate with administrations framing their personal experiences and translating them into more standardized, formalized and encoded accounts.

However, the grid of categories does not cover all the problematic situations. As my research has shown, experiences tend to overflow the classification. A case that is hard to classify questions the interface and opens its black box in order to redefine the grid, make it finer or find new categories that would better suit the new experiences. There is, thus, a constant back-and-forth between code and experience. Users play a crucial role in this process. Not only do they give their feedback upon the overflows and limits of the applications’ design, but they also propose modifications and invent ways to overcome technical restrictions by their own (“hacking” the application).

My research shows that the format of civic applications is more efficient in the cases of problems that can be easily classified and are regulated by a definite legal basis. Urban problems are more adapted for being encapsulated into an app than the problem of ethnic profiling. In the latter case the need to express oneself beyond closed questionnaires and check-lists, to have his or her own voice heard is a constituent part of the issue. The problematic and intimate experience of violence and humiliation seems to be extremely hard to translate into code: it is the human agent who will have the last word, by listening and treating personally every story.

However, regardless these limits, civic applications are still making something special to public problems and to the civic participation. First of all, thanks to the principle of “micro-tasking” and via different instruments, such as collaborative maps, photogalleries, forums of users and archives, they make possible an operation of accumulation and multiplication. While individual cases go through the interface of the apps, they “gain” in power, as they are represented on the same surface (of a map, for example), with thousands of other cases. Represented on a map of RosYama, every pothole becomes part of a struggle against corruption (Ermoshina, 2014: a). The app reinforces particular cases, inscribes them into a bigger movement, helps producing statistics on sensible issues, on which state institutions do not have data or are not willing to share this data with citizens.

The apps help to build a civic expertise of these problems and even to transform political agenda. Thus, SLCAF brings a project of “police deontology reform”,  RosZKH has made several amendments to the Housing code that have been accepted in 2013, RosYama has managed to build a dialogue with Moscow city Road police and developed a common informational system and database of road quality problems. Civic apps can become tools for politicization of ordinary problems. They were for instance used during municipal elections in Saint-Petersburg in 2014, and in Moscow in 2013, the candidates of opposition having built their platform upon their statistics of app usage.

I argue that civic apps are both instruments and products of publicization and construction of public problems. While actors tend to make sense of the trouble they face with and search for the ways to identify, name, normalize and fix it, digital interfaces crystallize this collective inquiry. The crystallization and the following standardization are necessary to build up efficient informational infrastructures and interfaces, but at the same time can become sources of tensions and asymmetries. Without an active implication of users, and the back-and-worth between experience and code, civic apps risk to become tools of monopolization and depersonalization of protest (the ventriloquist effect).


Biblipgraphical References

Akrich, M. (1998). Les utilisateurs, acteurs de l'innovation (Users, actors of innovation). Education permanente, 134, 78-89.

Allard L., Blondeau O., Nouvelles formes de mobilisation et d’innovation politique : le concours

Asmolov G., (2014) Crowdsourcing as an Activity System: Online Platforms as Mediating Artifacts. A Conceptual Framework for the Comparative Analysis of Crowdsourcing in Emergencies, paper published in Proceedings of the Sintelnet WG5 Workshop on Crowd Intelligence: Foundations, Methods, and Practices, Barcelona, Catalonia, 8-9 January,

Badger, E. (2013) Are civic hackathons stupid? article published in

Badouard, R. (2014). La mise en technologie des projets politiques. Une approche « orientée design » de la participation en ligne (Putting political projects in technology. Design-oriented approach to online participation). Participations, 8, 31-54.

Baraniuk, C. 2013 Civic Hackers Reshape Your Goveernment, In New Scientist 2013-06-29 218(2923):36-39, DOI: 10.1016/S0262-4079(13)61625-5

Bogdanova, E. (2013). Complaining to Putin: A paradox of the hybrid regime. Retrieved from:

Boltanski, L., & Thévenot, L. (1991). De la justification. Les économies de la grandeur (On justification. The economy of worth). Paris: Gallimard.

Bowker, G. & Star, S. L., (1998). Building Information Infrastructures for Social Worlds – The Role of Classifications and Standards. In T. Ishida (Ed.), Community Computing and Support Systems (pp. 231–248). Springer.

Bowker, G. & Star, S. L., (1999). Sorting Things Out: Classification and its Consequences, Cambridge, Mass.: MIT Press.         [ Links ]

Bowker, G & Star, S. L., (2007). Enacting silence: Residual categories as a challenge for ethics, information systems, and communication, Ethics and Information Technology, 9 (4), 273-280        [ Links ]

Brabham D. C. (2008). Crowdsourcing as a model for problem solving. An introduction and cases. Convergence, 14(1), 75-90        [ Links ]

Brabham D. C. (2013) Crowdsourcing. Boston, MA: MIT Press.

Cefai, D. (2013) L’expérience des publics : institution et réflexivité. Sur la sociologie des problèmes publics 1/2., in EspaceTemps, Travaux, 04.03.2013

Chateauraynaud, F. ; Torny, D. (1999). Les Sombres précurseurs, une sociologie pragmatique de l’alerte et du risque, Paris, Éditions de l’École des Hautes Études en Sciences Sociales

Chignard, S. (2013). Un hackathon, sinon rien ? An article published on 8 January 2013 at

Costanza-Chock, S. (2003). Mapping the repertoire of electronic contention. Paper presented at the World Summit on the Information Society, Geneva, Switzerland.

Dafermos, G., Soderberg, J., The hacker movement as a continuation of a labour struggle, Capital & Class, 2009 vol. 33 no. 1 53-73

Elliott, M. (2006). "Stigmergic Collaboration: The Evolution of Group Work." M/C Journal 9 (2). 

Emerson, R. M., & Messinger, S. L.. (1977). The Micro-Politics of Trouble. Social Problems, 25(2), 121–134.

Ermoshina K. (2014 a). Democracy as pothole repair: Civic applications and cyber-empowerment in Russia. Cyberpsychology: Journal of Psychosocial Research on Cyberspace, 8(3), article 4.

Ermoshina K. (2014 b). Webnabludatel: a Russian Electoral Observation App, in Civic Media Reader Project, MIT Press,

Eyler-Werve, K., & Carlson, V. (2012) Civic apps competition handbook. O'Reilly Media.

Farman, J. (2012). Mobile interface theory: Embodied space and locative media. New York: Routledge.         [ Links ]

Felstiner L.F.W., Abel R. L., Sarat A., (1980-1981). The Emergence and Transformation of Disputes: Naming, Blaming, Claiming, Law & Society Review, Vol. 15, No. 3/4, Special Issue on Dispute Processing and Civil Litigation, pp. 631-654

Fuller, M. (2008). Software Studies: a lexicon. The MIT Press.

Goody, J. (1977). The Domestication of the Savage Mind, Cambridge University Press

Heylighen, F. (2007). Why is Open Access Development so Successful? Stigmergic organization and the economics of information. In Open Source Jahrbuch, edited by B. Lutterbeck, M. Bärwolff and R. A. Gehring. Lehmanns Media.

Irani, L., (2015). Hackathons and the Making of Entrepreneurial Citizenship, Science Technology Human Values, doi: 10.1177/0162243915578486

Kittur, A., Chi, E. H., Suh, B. (2008). Crowdsourcing user studies with Mechanical Turk. Proceedings of the 26th Annual ACM Conference on Human Factors in Computing Systems (CHI '08); 2008 April 5-10; Florence, Italy. NY: ACM; 453-456.

Morozov, E., (2013). To Save Everything, Click Here: The Folly of Technological Solutionism, New York: PublicAffairs        [ Links ]

Oudshoorn, N., & Pinch, T. (2005). How users matter: The co-construction of users and technology. Cambridge, Mass: The MIT Press.         [ Links ]

Robles, G., Merelo J., and Gonzalez-Barahona J.-M. (2005). Self-Organized Development in Libre Software: a Model based on the Stigmergy Concept, Proc. 6Th International Workshop on Software Process Simulation and Modeling,

Rolfe, B., (2005). Building an electronic repertoire of contention. Social Movements Studies, 4, 65-74.         [ Links ]

Simondon, G. (1958). On the mode of existence of technical objects. University of Western Ontario. Retrieved from:

Tilly, C. (1986). The contentious French. Cambridge, MA: Harvard University Press.

Tilly, C. (2004). Social movements, 1768–2004. Boulder, Colorado, USA: Paradigm Publishers.



1 This workshop was a part of a program of « Futurs en Seine » festival in 2013. web page of the workshop : (visited 14 January 2015)

2 «To arms, citizens» - a famous phrase from the chorus of Marseillaise, the French anthem.

3 Hackathons (from « hack » and « marathons ») are « intense, multiday events devoted to rapid software production » (Irani, 2015). « Civic hackathons » are using the format of hackathons in order to address social challenges and are characterized by a hybrid format, with social activists and developers working together to develop prototypes of soft and hardware solutions.

4 First massive wave of civic hacking events dates back to 2008-2009, presidential campaign of Barak Obama and the rise of so-called “app contests”.

5 During my fieldwork I had a chance to meet the team that built the WAfate and presented it at the hackathon “Space Apps Challenge” organized by NASA in Paris in 2013. It is one of the exciting examples of a “civic hack” – a beautiful translation of a challenge (pollution of Ghana and Togo by electronic waste, dependency of the African continent from Europe in terms of technologies and skills) into an appropriate and low-cost technological solution.

6 «Who is a civic hacker ?» (consulté le 21 juin 2016)

7 (consulted on 14 January 2016)

8 The web-series is available here :

9 Guide d’actions face aux contrôles abusifs : (consulted on the 14th of January 2016)

10 Ilya Segalovitch was the CTO of Yandex at the moment. Yandex is one of the largest Internet companies in Europe, operating Russia's most popular search engine, the 4th largest search engine worldwide:

11  The post is accessible here: (consulted on 22/06/2015)

12 Golos is one of the most well-known NGOs specialized in electoral observation in Russia, founded in 2000. It operates in 48 regions of Russia. Website of Golos:

13 An example of a Roadmap is accessible here: (consulted on 14th of January 2016)

14 ZKH – Zhilishno-Kommunalnoye Hozyajstvo – is a Russian abbreviation for housing and public utilities, local organizations responsible for the in-house services such as electricity, gas, cleanness, elevators.

15 API – Application Programming Interface – is a particular set of rules and specifications that software programs can follow to communicate with each other. It serves as an interface between different software programs and facilitates their interaction, similar to the way the user interface facilitates interaction between humans and computers. In the context above, the administration as an actor-network is compared to an APIs because it acts as a kind of a protocol that redirects complaints and insures interaction between different departments and services.

Creative Commons License All the contents of this journal, except where otherwise noted, is licensed under a Creative Commons Attribution License