με αφορμή το “Φεστιβάλ των Κοινών” , τη Μαριάννα και τη διδασκαλία των κοινών
Καθένας νομίζω πως θυμάται με ξεχωριστό τρόπο την πρώτη του συνάντηση με το ελεύθερο λογισμικό ή το λογισμικό ανοικτού κώδικα και τις κοινότητες τους.Για εμένα αυτή η συνάντηση είναι συνδεδεμένη με την περιγραφή του Richard Sennet στο βιβλίο του the craftsman (στα ελληνικά “ο τεχνίτης” από τις εκδόσεις ΝΗΣΙΔΕΣ). Ίσως κανείς να μην απαντήσει αλλά θα ήθελα να μοιραστώ την ερώτηση, “εσείς πως γνωρίσατε το ανοικτό λογισμικό;”
απόσπασμα από το κείμενο:
“Τhe Craftsman summons an immediate image. Peering through a window into a carpenter’s shop, you see inside an elderly man surrounded by his apprentices and his tools. Order reigns within, parts of chairs are clamped neatly together, the fresh smell of wood shavings fills the room, the carpenter bends over his bench to make a fine incision for marquetry. The shop is menaced by a furniture factory down the road.
The craftsman might also be glimpsed at a nearby laboratory.
One of the earliest celebrations of the craftsman appears in a Homeric hymn to the master god of craftsmen, Hephaestus.
To understand the living presence of Hephaestus, I ask the reader to make a large mental jump. People who participate in ‘‘open source’’ computer software, particularly in the Linux operating system, are craftsmen who embody some of the elements first celebrated in the hymn to Hephaestus, but not others. The Linux technicians also represent as a group Plato’s worry, though in a modern form; rather than scorned, this body of craftsmen seem an unusual, indeed marginal, sort of community.
The Linux system is a public craft. The underlying software kernel in Linux code is available to anyone, it can be employed and adapted by anyone; people donate time to improve it. Linux contrasts to the code used in Microsoft, its secrets until recently hoarded as the intellectual property of one company. In one current, popular Linux application, Wikipedia, the code kernel makes possible an encyclopedia to which any user can contribute. When established in the 1990s, Linux sought to recover some of the adventure of the early days of computing in the 1970s. During these two decades, the software industry has morphed
within its brief life into a few dominant firms, buying up or squeezing out smaller competitors. In the process, the monopolies seemed to churn out ever more mediocre work. Technically, open-source software follows the standards of the Open Source Initiative, but the brute label ‘‘free software’’ doesn’t quite capture how resources are used in Linux.∞≠ Eric Raymond usefully
distinguishes between two types of free software: the ‘‘cathedral’’ model, in which a closed group of programmers develop the code and then make it available to anyone, and the ‘‘bazaar’’ model, in which anyone can participate via the Internet to produce code. Linux draws on craftsmen in an electronic bazaar. The kernel was developed by Linus Torvalds, who in the early 1990s acted on Raymond’s belief that ‘‘given enough eyeballs, all bugs are shallow’’—engineer-speak for saying that if enough people participate in the code-writing bazaar, the problems of writing good code can be solved more easily than in the cathedral,
certainly more easily than in proprietary commercial software.∞∞
This, then, is a community of craftsmen to whom the ancient appellation demioergoi can be applied. It is focused on achieving quality, on doing good work, which is the craftsman’s primordial mark of identity. In the traditional world of the archaic potter or doctor, standards for good work were set by the community, as skills passed down from generation to generation. These heirs to Hephaestus have experienced, however, a communal conflict about the use of their skills.
The programming community is grappling with how to reconcile quality and open access. In the Wikipedia application, for instance, many of the entries are biased, scurrilous, or just plain wrong. A breakaway group now wants to apply editing standards, an impulse that runs smack up against the movement’s desire to be an open community. The editor ‘‘elitists’’ don’t dispute the technical proficiency of their adversaries; all the professional parties in this conflict feel passionately about maintaining quality. The conflict is equally strong in the generativerealm of Linux programming. Its members are grappling with a structural problem: how can quality of knowledge coexist with free and equal exchange in a community?∞≤
We’d err to imagine that because traditional craft communities pass on skills from generation to generation, the skills they pass down have been rigidly fixed; not at all. Ancient pottery making, for instance, changed radically when the rotating stone disk holding a lump of clay came into use; new ways of drawing up the clay ensued. But the radical change appeared slowly. In Linux the process of skill evolution is speeded up; change occurs daily. Again, we might think that a good craftsman, be she a cook or a programmer, cares only about solving problems, about solutions that end a task, about closure. In this, we would not credit the work actually involved. In the Linux network, when people squash one ‘‘bug,’’ they frequently see new possibilities open up for the use of the code. The code is constantly evolving, not a finished and fixed object. There is in Linux a nearly instant relation between problem solving and problem finding.
Still, the experimental rhythm of problem solving and problem finding makes the ancient potter and the modern programmer members of the same tribe. We would do better to contrast Linux programmers to a different modern tribe, those bureaucrats unwilling to make a move until all the goals, procedures, and desired results for a policy have been mapped in advance. This is a closed knowledge-system. In the history of handcrafts, closed knowledge-systems have tended toward short lifespans. The anthropologist André Leroi-Gourhan contrasts, for instance, the open, evolving, difficult, but long-lasting craft of metal knife-making in preclassical Greece to the craft of wooden knife-making—a more precise, economical, but static system of fabricating knives that was soon abandoned for the problems of metal.∞≥
Linux is most deeply ‘‘Greek’’ in its impersonality. In Linux online workshops, it’s impossible to deduce, for instance, whether ‘‘email@example.com’’ is a man or a woman; what matters is what ‘‘firstname.lastname@example.org’’ contributes to the discussion. Archaic craftsmen experienced a kindred impersonality; the demioergoi were frequently addressed in public by the names of their profession. All craftsmanship, indeed, has something of this impersonal character. That the quality of work is impersonal can make the practice of craftsmanship seem unforgiving; that you might have a neurotic relation to your father won’t excuse the fact that your mortise-and-tenon joint is loose. In one of the Britishbased Linux chat rooms to which I belong, the normal polite feints and indirections of British culture have disappeared. Gone are such locutions as ‘‘I would have thought that . . .’’; in are ‘‘This problem is fuckedup.’’ Looked at another way, this blunt impersonality turns people outward.
The Linux community might have served the mid-twentiethcentury sociologist C. Wright Mills in his effort to define the character of the craftsman. Mills writes: ‘‘The laborer with a sense of craft becomes engaged in the work in and for itself; the satisfactions of working are their own reward; the details of daily labor are connected in the worker’s mind to the end product; the worker can control his or her own actions at work; skill develops within the work process; work is connected to the freedom to experiment; finally, family, community, and politics are measured by the standards of inner satisfaction, coherence, and experiment in craft labor.’’∞∂
If Mills’s description seems impossibly idealistic, rather than reject it we might ask instead why craftsmanship of the Linux sort is so unusual. The question is a modern version of Plato’s ancient worry; the Linux programmers are certainly grappling with fundamental issues like collaboration, the necessary relation of problem solving to problem finding, and the impersonal nature of standards, yet the community seems special if not marginal. Some cluster of social forces must be pushing these fundamental issues to the sidelines.