by David Hakken

In their call, the editors of this special issue asked authors to engage in a particular kind of intellectual task, to envision a specification of a potential. To specify a potential, one also needs to specify its opposite: In this case, the limits on the kind of activity one is asked to envision, in order to to be clear about what it cannot do or is highly unlikely to be able to do.

In the call, the general kind of activity whose potential is to be specified—critique—is clear. However, there is some ambiguity about the specifics: Is one to assess the potential of a set of kinds of critiques—cultural, practical, and material ones—or that of a single kind of critique, one that is at the same time cultural, practical, and material? The call does give some additional suggestions relevant to this ambiguity. It suggests that Free Software (FS) is already a critique of some organizational forms, particularly the forms that in action are labeled “hierarchy” and certain ideological forms like so-called “intellectual property.” It suggests as well that FS is also a practical alternative to mainstream software (MS). That is, the call presumes that authors already think (as I do) that by its very existence FS critiques aspects of the typical corporate form as well as traditional “waterfall” models of software development. What the call wants authors to grapple with is whether FS’s critique is material.

There are few terms in today’s intellectual discourse whose meaning is as slippery as “material.” My own sense is that it more effectively glosses “powerful” and “meaningful” than “physical.” The narrative of the call suggests a somewhat different focus, however. It suggests that, while FS initially functioned as a practical critique of organizing, things like its adoption by corporations, or the dialectic development of its “Open Source” form, raise legitimate questions regarding how foundational the mere “existence” critique of FS actually remains. By implication, the call suggests that if FS were to critique more deeply the epistemological basis of computing, and/or if it were to critique the premises of software development as a professional and as a research practice, it would amount to a “material” critique. It also implies that any critique that is material would also have substantial implications for social change.

Additionally, while the call only uses the term “Free Software,” its acknowledgement of the existence of the “Open Source dialect” implies a need to consider broader questions, ones about both Free/Libre and/or Open Source Software (FLOSS), not just FS. As the meaning of both “open” and “open source” have metastasized almost as much as “capital,” this makes the requested task more complex. Still, the thrust of the call focuses more centrally on FS than on OSS or FLOSS, and I shall generally keep that focus.

Chris Kelty responds to these challenges with an apparent paradox of the “There is no such thing as Free Software; Long live Free Software!” sort. His point is a more ontological than epistemological one. (While Kelty praises the editors for asking authors to frame their argument in terms of epistemology, he immediately critiques this framing as being both too narrow and too broad.) Stated simply, his point is that Free Software should not be conceived of as a thing with immutable properties but rather something like an underlying but real dynamic that is “constantly becoming” and which takes different “material object” actual forms at different times—what might be called a mutable mobile? While he dismisses the idea that any given actual, particular form of Free Software would necessarily compel foundational, material critique, he effectively accepts that such is the potential for the underlying but real dynamic of principle. While he does not say so explicitly, one infers that at least certain forms of Stallmanite Free software might manifest more of the underlying potential, whereas Raymondite Open Source Software would generally not do so.

The reason for framing the issue of Free Software’s politics in this way is for Kelty the danger of hypostatization or fetishization, the mistaking of a social relationship for a thing. He also suggests that issue of FS’s politics might be cast as whether it implies something more than tactics, but rather an infrastructural or material strategy, and also that FS’s political strength may have something to do with its hybridity (which may also be a source of its evanescent quality, and thus a weakness). That the limits are significant is communicated by his claim that FS was never “anti-capitalist.” In essence, for Kelty, the foundationality of the FS critique is greatly dependent upon, on the one hand, the forms into which computing has evolved and, on the other, the extent to which people bring a politics to FS, not derive one from it.

I find much of Kelty’s arguments quite strong, being especially pleased for reasons of a personal project, that he locates FS’s effective critique in, among other things, discourse over values. I am less convinced, however, of his identification of the increase in the number of people developing OS software within the context of paid employment. In his research on the early source code-revealed game BZ Flag (a first person shooter), for example, John Paolillo noticed that each time a new map was released, several of the earliest ports were to Windows machines, rather than to Linux, etc. Paolillo speculated that this might be because several of the most popular servers on which the game was run were owned by software houses devoted primarily to Windows development. This suggests a more symbiotic relationship among systems than Kelty implies.

Katja Mayer and Judith Simon represent themselves as taking a tack different from Kelty’s. While they see him (appropriately) as stressing the importance of attending to the particularities of each form of FS, they wish to focus on the more theoretical issue of epistemology per se. They first survey a number of scholarly perspectives identifying a critical thrust in FS, then proceed to outline several significant positions on epistemological thinking derived from feminist perspectives. (I particularly like the stress on Longino’s social approach to knowledge, having taken a similar approach myself in The Knowledge Landscapes of Cyberspace (Routledge 2003)). These positions are then illustrated in relation to FS.

While the approach is different, the ultimate position is similar to that of Kelty: That is, the specification of reasons for why the critical element is so immanent in FS. Put simply, there are reasons why a decision to develop software in an explicitly “free” register is likely to lead to critique of standard software development practice, and that appreciation for feminist epistemology helps one understand why this is so. ‘Likely,” rather than “necessarily,” which is essentially the same position as Kelty on how regularly FS is inherently (materially?) critical. So the question remains “under what conditions?” or, in their terms “how is [FS] becoming?”

In line with the initial call for papers, the questions on which I will offer my opinion as “Debate” come down to:

1. Does the practice of FS constitute a critique of the epistemological basis of computing;
2. Does it constitute a critique of the premises of software development as a research practice; and
3. Does FS also critique the premises of software development as a professional practice?

Further, since my answer to these is “yes,” I’ll turn to,

4. Given that FS can in itself constitute a critique of the epistemological basis of computing, under what conditions does it do so; and
5. Does FS do so often enough to conclude that its practice constitutes a material (substantial) critique, one with meaningful implications for social change?

I will deal with each of these in order.

“Does the practice of Free Software constitute a critique of the epistemological basis of computing?” To answer this question, one needs to specify the epistemological basis of non-FS or what I will call mainstream software (MS) development in computing. Again, the call focuses initially on “computing” as the locus of epistemological concern, rather than, for example, on “Computer Science,” “Computer Engineering,” “Information Science,” “Informatics,” or any other term referring to the academic/intellectual practices that surround computing. It later refers to “the understanding of the epistemological implications for computer science and software engineering.” I will take this as justifying inclusion of academic epistemological practices as part of “computing”’ indeed, if computing has an epistemology, its overt form is likely to be most visible in its academic practice. Still, the framing in terms of “computing” implies attending also to the “folk-“ or “ethno-epistemology” of computing, the dominant ideas regarding how to gain knowledge of, how to learn about, “everyday” computing, as well as formal academic approaches to how one knows.

As there are many forms of computing, there are likely many forms of its folk as well as academic epistemologies. I will offer two examples as ways one might think about their shared characteristics. The first is the present interest in “Big Data,” of interest both for the large share of the public attention to computing that it has garnered, as well as its particular appeal to academic programs, framed as “Data Science” by the academy. (Both the School of Informatics and Computing (SoIC) at Indiana University and the Department of Computer Science and Engineering at the University of Trento are developing programs in this area.) There are of course many forms of Big Data interest, but the form with the most obvious epistemological implications is the one that shifts attention away from causal to merely correlational interest. For example, my colleague Johan Bollen in the Complex Systems group at IU SoIC claims to have discovered through “data mining” a correlation between mood on Twitter and movement on the major US stock exchanges, such as the Dow-Jones Industrial Index. He has been funded to develop this discovery, but as a predictive device for stock traders, rather than as the focus of efforts to develop a causal explanation for the correlation observed.

There are numerous other examples of “correlation only” Big Data interest; it seems to me that a narrowed epistemological interest is manifest in most data mining. My intent is to suggest that such active underdeveloping is indexical of a generally undeveloped awareness of the presumptions one brings to research—that is, of one’s epistemology. Further, many Big Data approaches acknowledge that the processes in which they are interested are social. However, either directly or indirectly, they dismiss pre-existing study of such processes by, for example, social scientists, as “non-scientific” since they are not based on big enough numbers. This unwillingness to consider in depth alternative ways of knowing is also indicative of a narrowness of epistemological imagination.

The second take on MS epistemology is Diana Forsythe’s characterization of Computer Science research in Studying Those Who Study Us (2002). Forsythe was one of the first academically trained anthropologists to study CS research ethnographically; in her case, the 1980s-90s Artificial Intelligence Lab at the University of Pittsburgh in the US. Her characterization of CS research, put bluntly, is that it involves:

1. Identifying something that it would be neat to make a computer do;
2. Writing some code which might make it do this;
3. Testing and rewriting the code till it seems to work;
4. Making up some data on which to run the code;
5. Satisfying one’s self that the code works on the made-up data; and then
6. Moving on to the next neat project.

This is of course a caricature, but it does capture another sense in which some CS research is epistemologically underdeveloped. This caricature fits my experience over the years when I asked computer scientists what was scientific about CS; in particular, what its scientific object was. Of the many responses I got, the best answer to the first question was “applied finite math,” which implies that the scientific object was how to express this kind of math in an algorithm and then embody the often repetitive calculation of the algorithm in a machine.

All of this why the term “computer science” has always struck me as a misnomer; that it instead should be labeled “computer engineering.” While one can imagine a descriptive science of engineering practice—that is, a science of computer engineering—it would be wrong to confuse this with engineering itself. This is because the object of engineering is typically an eminently practical one, and thus non-scientific in the normal sense. A good engineer accepts without question a solution space whose parameters are pre-established for her by someone else and then finds the optimum practical solution within the space. It is an often-taken short step from here to “that which makes the most money” as a proxy for “the optimum solution.”

In sum, these musings suggest to me that it is not particularly difficult to critique the epistemological practice typical of computing. However, the critiques outlined above have little to do with Free Software. How FS contributes to this critique is so emerges more strongly when one considers, “Does the practice of Free Software constitute a critiques of the premises of software development as research practice?”

To come to this question I first ask, given that the preceding musings do reflect the academic/everyday epistemology of computing, is there reason to see the epistemological practice of FS, OSS, or FLOSS as fundamentally different? Perhaps, but not to a great extent. The FS projects with which I am familiar don’t equate “most money” with “optimum,” but they are about writing good code, code that makes a computer do “something neat” as elegantly as possible, rather than trying to discover fundamental things about the universe. There is a form of computing, identified by terms like “Structured Programming,” (SP) that perhaps contrasts most strongly with the making of FS. That is, on SP, a coding task is mapped out extensively in the beginning and carried out with a highly developed, often rigid division of labor. Moreover, a la F.W. Taylor, coders are instructed to follow specific, rigid protocols while coding, am SP project being engineered to reject any code that was not generated according to the prescribed practices. SP is described as the most “scientific” way to compute.

In contrast, on Free Software, coders are free to write code in any way they wish, and they do soon their own, without supervision. Decisions regarding the appropriateness of submitted code are made by once-peer-but-now elevated coders, ones whose coding skill and understanding of the overall project have been acknowledged in a meritocratic manner by the network of coders who choose to participate in forming “community opinion.”

While SP and FS coding are different, they strike me as in many ways similar from an epistemological perspective. The object of the two practices is pretty much the same: to write code whose quality is demonstrated when it is run, so writing and running code is the basic epistemological strategy. One might think that an important differentiating feature of SP, in the terms that its advocates and practitioners justify it, is that it is “more scientific.” The SP claim to be “more scientific” seems to me to be a confusion of form with essence, a mistaking the organizational characteristics of “big science” for science tout corps.

One can however still argue that, whatever actual difference there is between what the SP coder is doing and “real” science, what is important is that she thinks she is doing science, where this may be less likely of people involved in FS. Most MS writers whom I have encountered, whatever they do in practice, do think of themselves as doing science. Doing science is equated with following the “scientific method,” the justification of which is, if they think epistemology, what they conceive of it to be.

In practice, most of those doing “mainstream” computing claim to share this commitment to science and the scientific method. However, to the extent that Forsythe’s description is accurate, their actual practice—e.g., making “play” systems—deviates substantially from this ideal. Hence, their perceptual practice is best understood as ideological—in this case, basically a false justification. Further, this justification is deeply problematic for computing, being the source of some of its peculiar split personality—thinking it’s doing science, but actually doing engineering.

This gets to, I think, the main argument one might advance for claiming that FS practice constitutes a fundamental critique of MS development. While to some extent FSers may share this “big science” conception of what it means to do science, they are less likely to see FS development as science. FS projects don’t look like big science, and FSers know this. Further, the scholarship on FLOSS suggests that what is distinctive about it as a form of computing is its distinctly different social character (e.g., Stephen Weber, 2004). The critique of organizing and of property described in the call is something many FLOSS advocates (e.g., Stallman, Raymond) are aware of and integrate into their advocacy, and FS practitioners respond to these critiques. While economists have had trouble with the idea that things like “reputation” are a sufficient motivational substitute for avaricious utility maximizing, many FSers are conscious ofhow their motivation is fundamentally different from that of an employee, and that the organizing of their projects is different from that of the imposed division of labor of big science. Perhaps FSers get the difference between building a cathedral and running a bazaar, while MSers can only conceive of building cathedrals.

So both see the appropriate epistemic model of science to be that of big science. Mainstream coders think they learn scientifically but don’t really. With the possible exception of Structured and similar approaches to programming, I suggest that the typical mainstream coding project is in fact less rigid, more peer-oriented, than mainstream programmers think it is.

FSers carry out a collaborative, peer-oriented practice that they see as alternative to big science, and this is a significant sense in which FS practice constitutes a critique of mainstream epistemological false consciousness and misunderstanding. It is in these differences in the conception of both how and why one codes—in big, hierarchical projects, for money, v. in loosely coupled networks of varying sizes, in order to “have fun” (Linus Torvalds basic characterization)—that FS constitutes an epistemological critique of mainstream software development.

Much of the foregoing addresses research practice in particular, but the considerations are also relevant to another part of the task outlined by the call: Whether Free Software constitutes a critique of the premises of software development as a professional practice. I think the question of the premises of software development as a professional practice is best separated from that of the premises of software development as a research practice. I also find the question of whether there is a difference between FS and mainstream coders with regard to the premises of software as a professional practice an interesting one. On the face of it, it seems clear that mainstream coders accept the notion that most coding activity is and will be mediated by the job form—that is, done by people paid by an organization, typically a for-profit one. At the same time, their experiences at work likely increase their awareness of how the quality of the job is acutely dependent upon its professional standing, both how the coders see themselves and are see by others and important social institutions, like government bodies. This helps explain a contradiction in the Code of Ethics of the Association for Computing Machinery, the coexistence of ethical imperatives both to “blow the whistle” on unethical professional practice and to be “loyal employees.” (This all is why I am less willing to follow Kelty in a blanket critique of coding under the wage form.)

My background in the study of occupations and professions lead me to conclude that computing is not a very well organized profession, not one with, among other things, a strong, clear sense of what constitutes ethical practice. This is how my Informatics students perceive computing; indeed, stressing professionalism is one of the few ways I can get them thinking about ethics. A debate they held this Spring (2013) on the ethics of FS was revealing. The proposition being discussed was whether, when its technical characteristics were as good or better than that of proprietary software for the intended purpose, computer professionals had an ethical responsibility to promote the use of FLOSS. What was interesting was the arguments raised by those opposing the proposition. These were limited to the practical and technical problems that would arise were the profession to take an explicit pro-FLOSS position. In essence, all accepted the basic case for its ethical superiority.

While they did not say this in so many words, I think my students’ sense of the ethical superiority of FS is linked to its being perceived as taking place outside of the job, as not being limited by the condition of employment. This is an important sense in which FS is free—of the wage nexus and thus of organizational hierarchy. I think it not too much to suggest that this positive association between a form of coding and freedom is an important point on which a broader vision of an alternative society—say, one based on common resources managed collectively by the users of the resources—can be built. This fits with the way they appear to want to think of code, as something to be fostered and repurposed for the task at hand. Hence, they agree with the idea that it is wrong to download material over which they have no legitimate claim, but they all cheerfully admit to having done so. It is when this resource is threatened—as, for example, when organizational proprietary claims overreach—that computing professionals are most open to efforts to frame their activities in social movement terms: When the hacker allies herself with the activist. (My students are generally positive about things like WikiLeaks.)

Does the practical critique by FS of mainstream coding constitute a material (substantial) critique with meaningful implications for social change? While MSers and FSers share a conception of how to do science, the former (mis)perceive themselves as actually doing it, while the latter perceive themselves, more accurately, as engaged in an alternative practice. Further, FSers tend to conceive of their activities more collectively and in more social terms, so I think the FS critique can carry substantial implications for social change. This would more likely be the case if the practice critique were accompanied by a sense among FSers of being involved in a social movement—that is, of coding being a collective, even common, task with the objective of changing broader social conditions.

My sense is that FS is seen as a deliberate effort to change things as they are, but that concrete steps to do so beyond writing code are taken only by a distinct minority of FSers. Still, even if only implicitly sensed, such practices can foster a more general sense of how things might be different. This includes the idea that, for example, FLOSS is a harbinger of code’s eventual future, or that code’s fate is likely to follow hardware’s path, to become commoditized. (By “commoditized” I mean here not so much mediation by the wage nexus as ease of access due to interchangeability of code from diverse sources under conditions of open competition (similar to what is the case regarding, e.g., hard drives).)

On such visions, the re-appropriation by corporations of a late 19^th Century doctrine, that there exists “property of an intellectual sort” to justify treating code as proprietary, appears to be a doomed, rear-guard action. This contrasts with use of source code that is “open” to be used by anyone, and it is easier to reuse existing OS code than to have to perform the coding contortions demanded to demonstrate the uniqueness of each new bit of proprietary code. It is in this sense that FS continues to promote a critical view of an alternative professional practice, one with continuing potential to become “material.”

In sum, I am arguing that one particular way in which FS comes to constitute a material critique of computing epistemology is when the act of coding confronts forms typical of the wage nexus. It is then that the absurdities of bending coding to the requirements of the reproduction of capital become most evident, and thus when a “free” ethic is appears in great contrast to a profit motive. In pointing this out, I intend to be taking a small step toward specifying the conditions under which FS practice does indeed become material critique, not just that it can do so.

Works cited

Hakken, D. (2003). The Knowledge Landscapes of Cyberspace, Routledge

Forsythe, D. (2002). Studying Those Who Study Us, Stanford University Press

Weber, S. (2004).The Success of Open Source, The MIT Press