What's the thinking here

This interview about the practice of OSP was carried out by e-mail between March and May 2008. Matthew Fuller writes about software culture and has a contagious interest in technologies that exceed easy fit solutions. At the time, he was David Gee reader in Digital Media at the Centre for Cultural Studies, Goldsmiths College, University of London, and had just edited Software Studies, A Lexicon, and written Media Ecologies: Materialist Energies in Art and Technoculture and Behind the Blip: Essays on the Culture of Software.

OSP is a graphic design agency working solely with Open Source software. This surely places you currently as a world first, but what exactly does it mean in practice? Let’s start with what software you use?

There are other groups publishing with Free Software, but design collectives are surprisingly rare. So much publishing is going on around Open Source and Open Content … someone must have had the same idea? In discussions about digital tools you begin to find designers expressing concern over the fact that their work might all look the same because they use exactly the same Adobe suite and as a way to differentiate yourself, Free Software could soon become more popular. I think the success of Processing is related to that, though I doubt such a composed project will ever make anyone seriously consider Scribus for page layout, even if Processing is Open Source.

OSP usually works between GIMP, ¹ Scribus ² and Inkscape ³ on Linux distributions and OSX. We are fans of FontForge, ⁴ and enjoy using all kinds of commandline tools, psnup, ps2pdf and uniq to name a few.

How does the use of this software change the way you work, do you see some possibilities for new ways of doing graphic design opening up?

For many reasons, software has become much more present in our work; at any moment in the workflow it makes itself heard. As a result we feel a bit less sure of ourselves, and we have certainly become slower. We decided to make the whole process into some kind of design/life experiment and that is one way to keep figuring out how to convert a file, or yet another discussion with a printer about which ‘standard’ to use, interesting for ourselves. Performing our practice is as much part of the project as the actual books, posters, flyers etc. we produce.

One way a shift of tools can open up new ways of doing graphic design, is because it makes you immediately aware of the ‘resistance’ of digital material. At the point we can’t make things work, we start to consider formats, standards and other limitations as ingredients for creative work. We are quite excited for example about exploring dynamic design for print in SVG, a by-product of our battle with converting files from Scalable Vector Format into Portable Document Format.

Free Software allows you to engage on many levels with the technologies and processes around graphic design. When you work through it’s various interfaces, stringing tools together, circumventing bugs and/or gaps in your own knowledge, you understand there is more to be done than contributing code in C++. It is an invitation to question assumptions of utility, standards and usability. This is exactly the stuff design is made of.

Following this, what kind of team have you built up, and what new competencies have you had to develop?

The core of OSP is five people ⁵, and between us we mix amongst others typography, layout, cartography, webdesign, software development, drawing, programming, open content licensing and teaching. Around it is a larger group of designers, a mathematician, a computer scientists and several Free Software coders that we regularly exchange ideas with.

It feels we often do more unlearning than learning; a necessary and interesting skill to develop is dealing with incompetence – what can it be else than a loss of control? In the mean time we expand our vocabulary so we can fuel conversations (imaginary and real life) with people behind GIMP, Inkscape, Scribus etc.; we learn how to navigate our computers using commandline interfaces as well as KDE, GNOME and others; we find out about file formats and how they sometimes can and often cannot speak to each other; how to write manuals and interact with mailing lists. The real challenge is to invent situations that subvert strict divisions of labour while leaving space for the kind of knowledge that comes with practice and experience.

Open fonts seem to be the beginnings of a big success, how does it fit into the working practices of typographers or the material with which they work?

Type design is an extraordinary area where Free Software and design naturally meet. I guess this area of work is what kernel coding is for a Linux developer: only a few people actually make fonts but many people use them all the time. Software companies have been inconsistent in developing proprietary tools for editing fonts, which has made the work of typographers painfully difficult at times. This is why George Williams decided to develop FontForge, and release it under a BSD license: even if he stops being interested, others can take over. FontForge has gathered a small group of fans who through this tool, stay into contact with a more generous approach to software, characters and typefaces.

The actual material of a typeface has since long migrated from poisonous lead into sets of ultra light vector drawings, held together in complicated kerning systems. When you take this software-like aspect as a startingpoint, many ways to collaborate (between programmers and typographers; between people speaking different languages) open up, as long as you let go of the uptight licensing policies that apply to most commercial fonts. I guess the image of the solitary master passing on the secret trade to his devoted pupils does not sit very well with the invitation to anyone to run, copy, distribute, study, change and improve. How open fonts could turn the patriarchal guild system inside out that has been carefully preserved in the closed world of type design, is obviously of interest as well.

Very concretely, computer-users really need larger character sets that allow for communication between let’s say Greek, Russian, Slovak and French. These kinds of vast projects are so much easier to develop and maintain in a Free Software way; the DéJàVu font project shows that it is possible to work with many people spread over different countries modifying the same set of files with the help of versioning systems like CVS.

But what it all comes down to probably… Donald Knuth is the only person I have seen both Free Software developers and designers wear on their T-shirts.

The cultures around each of the pieces of software are quite distinct. People often lump all F/LOSS development into one kind of category, whereas even in the larger GNU/Linux distros there is quite a degree of variation, but with the smaller more specialised projects this is perhaps even more the case. How would you characterise the scenes around each of these applications?

The kinds of applications we use form a category in themselves. They are indeed small projects so ‘scene’ fits them better than ‘culture’. Graphics tools differ from archetypal Unix/Linux code and language based projects in that Graphical User Interfaces obviously matter and because they are used in a specialised context outside its own developers circle. This is interesting because it makes F/LOSS developer communities connect with other disciplines (or scenes?) such as design, printing and photography.

A great pleasure in working with F/LOSS is to experience how software can be done in many ways; each of the applications we work with is alive and particular. I’ll just portray Scribus and Inkscape here because from the differences between these two I think you can imagine what else is out there.

The Scribus team is rooted in the printing and pre-press world and naturally their first concern is to create an application that produces reliable output. Any problem you might run in to at a print shop will be responded to immediately, even late night if necessary. Members of the Scribus team are a few years older than average developers and this can be perceived through the correct and friendly atmosphere on their mailing list and IRC channel, and their long term loyalty to this complex project. Following its more industrial perspective, the imagined design workflow built in to the tool is linear. To us it feels almost pre-digital: tasks and responsibilities between editors, typesetters and designers are clearly defined and lined up. In this view on design, creative decisions are made outside the application, and the canvas is only necessary for emergency corrections. Unfortunately for us, who live of testing and trying, Scribus’ GUI is a relatively underdeveloped area of a project that otherwise has matured quickly.

Inkscape is a fork of a fork of a small tool initially designed to edit vector files in SVG format. It stayed close to its initial starting point and is in a way a much more straightforward project than Scribus. Main developer Bryce Harrington describes Inkscape as a relatively unstructured coming and going of high energy collective work much work is done through a larger group of people submitting small patches and it’s developers community is not very tightly knit. Centered around a legible XML format primarily designed for the web, Inkscape users quickly understand the potential of scripting images and you can find a vibrant plug in culture even if the Inkscape code is less clean to work with than you might expect. Related to this interest in networked visuals, is the involvement of Inkscape developers in the Open Clip Art project and ccHost, a repository system wich allows you to upload images, sounds and other files directly from your application. It is also no surprise that Inkscape implemented a proper print dialogue only very late, and still has no way to handle CMYK output.

There’s a lot of talk about collaboration in F/LOSS development, something very impressive, but often when one talks to developers of such software there is a lot to discuss about the rather less open ways in which power struggles over the meaning or leadership of software projects are carried out by, for instance, hiding code in development, or by only allowing very narrowly technical approaches to development to be discussed. This is only one tendency, but one which tends to remain publicly under-discussed. How much of this kind of friction have you encountered by acting as a visible part of a new user community for F/LOSS?

I can’t say we feel completely at home in the F/LOSS world, but we have not encountered any extraordinary forms of friction yet. We have been allowed the space to try our own strategies at overcoming the user-developer divide: people granted interviews, accepted us when we invited ourselves to speak at conferences and listened to our stories. But it still feels a bit awkward, and I sometimes wonder whether we ever will be able to do enough. Does constructive critique count as a contribution, even when it is not delivered in the form of a bug report? Can we please get rid of the term ‘end-user’?

Most discussions around software are kept strictly technical, even when there are many non-technical issues at stake. We are F/LOSS enthusiasts because it potentially pulls the applications we use into some form of public space where they can be examined, re-done and taken apart if necessary; we are curious about how they are made because of what they (can) make you do. When we asked Andreas Vox, a main Scribus developer whether he saw a relation between the tool he contributed code to, and the things that were produced by it, he answered: Preferences for work tools and political preference are really orthogonal. This is understandable from a project-management point of view, but it makes you wonder where else such a debate should take place.

The fact that compared to proprietary software projects, only a very small number of women is involved in F/LOSS makes apparent how openness and freedom are not simple terms to put in practice. When asked whether gender matters, the habitual answer is that opportunities are equal and from that point a constructive discussion is difficult. There are no easy solutions, but the lack of diversity needs to be put on the roadmap somehow, or as a friend asked: Where do I file a meta-bug?

Visually, or in terms of the aesthetic qualities of the designs you have developed would you say you have managed to achieve anything unavailable through the output of the Adobe empire?

The members of OSP would never have come up with the idea to combine their aesthetics and skills using Adobe, so that makes it difficult to do a ‘before’ and ‘after’ comparison. Or maybe we should call this an achievement of Free Software too?

Using F/LOSS has made us reconsider the way we work and sometimes this is visible in the design we produce, more often in the commissions we take on or the projects we invest in. Generative work has become part of our creative suite and this certainly looks different than a per-page treatment; also deliberate traces of the production process (including printing and pre-press) add another layer to what we make.

Of all smaller and larger discoveries, the Spiro toolkit that Free Software activist, Ghostscript maintainer, typophile and Quaker Raph Levien develops, must be the most wonderful. We had taken Bézier curves for granted, and never imagined how the way it is mathematically defined would matter that much. Instead of working with fixed anchor points and starting from straight lines that you first need to bend, Spiro is spiral-based and vectors suddenly have a sensational flow and weight. From Pierre Bézier writing his specification as an engineer for the Renault car factory to Levien’s Spiro, digital drawing has changed radically.

You have a major signage project coming up, how does this commission map across to the ethics and technologies of F/LOSS?

We are right in the middle of it. At this moment ‘The Pavilion of Provisionary Happiness’ celebrating the 50th anniversary of the Belgian World Exhibition, is being constructed out of 30.000 beer crates right under the Brussels’ Atomium. That’s a major project done the Belgian way.

We have developed a signage system, or actually a typeface, which is defined through the strange material and construction work going on on site. We use holes in the facade that are in fact handles of beer crates as connector points to create a modular font that is somewhere between Pixacao graffiti and Cuneiform script. It is actually a play on our long fascination with engineered typefaces such as DIN 1451; mixing universal application with specific materials, styles and uses – this all links back to our interest in Free Software.

Besides producing the signage, OSP will co-edit and distribute a modest publication documenting the whole process; it makes legible how this temporary yellow cathedral came about. And the font will of course be released in the public domain.

It is not an easy project but I don’t know how much of it has to do with our software politics; our commissioners do not really care and also we have kept the production process quite simple on purpose. But by opening our sources, we can use the platform we are given in a more productive way; it makes us less dependent because the work will have another life long after the deadline has passed.

On this project, and in relation to the seeming omnipresence in F/LOSS of the idea that this technology is ‘universal’, how do you see that in relation to fonts, and their longer history of standards?

That is indeed a long story, but I’ll give it a try. First of all, I think the idea of universal technology appears to be quite omnipresent everywhere; the mix-up between ubiquitousness and ‘universality’ is quickly made. In Free Software this idea gains force only when it gets (con)fused with freedom and openness and when conditions for access are kept out of the discussion.

We are interested in early typographic standardization projects because their minimalist modularity brings out the tension between generic systems and specific designs. Ludwig Goller, a Siemens engineer wo headed the Committee for German Industry Standards in the 1920s stated that For the typefaces of the future neither tools nor fashion will be decisive. His committee supervised the development of DIN 1451, a standard font that should connect economy of use with legibility, and enhance global communication in service of the German industry. I think it is no surprise that a similar phrasing can be found in W3C documents; the idea to unify the people of the world through a common language re-surfaces and has the same tendency to negate materiality and specificity in favour of seamless translation between media and markets.

Type historian Ellen Lupton brought up the possibility of designing typographic systems that are accessible but not finite nor operating within a fixed set of parameters. Although I don’t know what she means by using the term ‘open universal’, I think this is why we are attracted to Free Software: it has the potential to open up both the design of parameters as well as their application. Which leads to your next question.

You mentioned the use of generative design just now. How far do you go into this? Within the generative design field there seem to be a couple of tendencies, one that is very pragmatic, simply about exploring a space of possible designs through parametric definition in order to find, select and breed from and tweak a good result that would not be necessarily imaginable otherwise, the other being more about the inefible nature of the generative process itself, something vitalist. These tendencies of not of course exclusive, but how are they inflected or challenged in your use of generative techniques?

I feel a bit on thin ice here because we only start to explore the area and we are certainly not deep into algorithmic design. But on a more mundane level… in the move from print to design for the web, ‘grids’ have been replaced by ‘templates’ that interact with content and context through filters. Designers have always been busy with designing systems and formats, ⁶ but stepped in to manipulate singular results if necessary.

I referred to ‘generative design’ as the space opening up when you play with rules and their affordances. The liveliness and specificity of the work results from various parameters interfering with each other, including the ones we can get our hands on. By making our own manipulations explicit, we sometimes manage to make other parameters at play visible too. Because at the end of the day, we are rather bored by mysterious beauty.

One of the techniques OSP uses to get people involved with the process and the technologies is the ‘Print Party’, can you say what that is?

'Print Parties' are irregular public performances we organise when we feel the need to report on what we discovered and where we’ve been; as anti-heroes of our own adventures we open up our practice in a way that seems infectious. We make a point of presenting a new experiment, of producing something printed and also something edible on site each time; this mix of ingredients seems to work best. 'Print Parties' are how we keep contact with our fellow designers who are interested in our journey but have sometimes difficulty following us into the exotic territory of BoF, Version Control and GPL3.

You state in a few texts that OSP is interested in glitches as a productive force in software, how do you explain this to a printer trying to get a file to convert to the kind of thing they expect?

Not! Printing has become cheap through digitization and is streamlined to the extreme. Often there is literally no space built in to even have a second look at a differently formatted file, so to state that glitches are productive is easier said than done. Still, those hickups make processes tangible, especially at moments you don’t want them to interfere.

For a book we are designing at the moment, we might partially work by hand on positive film (a step now also skipped in file-to-plate systems). It makes us literally sit with pre-press professionals for a day and hopefully we can learn better where to intervene and how to involve them into the process. To take the productive force of glitches beyond predictable aesthetics, means most of all a shift of rhythm – to effect other levels than the production process itself. We gradually learn how our ideas about slow cooking design can survive the instant need to meet deadlines. The terminology is a bit painful but to replace ‘deadline’ by ‘milestone’, and ‘estimate’ by ‘roadmap’ is already a beginning.

One of the things that is notable about OSP is that the problems that you encounter are also described, appearing on your blog. This is something unusual for a company attempting to produce the impression of an efficient ‘solution’. Obviously the readers of the blog only get a formatted version of this, as a performed work? What’s the thinking here?

‘Efficient solutions’ is probably the last thing we try to impress with, though it is important for us to be grounded in practice and to produce for real under conventional conditions. The blog is a public record of our everyday life with F/LOSS; we make an effort to narrate through what we stumble upon because it helps us articulate how we use software, what it does to us and what we want from it; people that want to work with us, are somehow interested in these questions too. Our audience is also not just prospective clients, but includes developers and colleagues. An unformatted account, even if that was possible, would not be very interesting in that respect; we turn software into fairytales if that is what it takes to make our point.

In terms of the development of F/LOSS approaches in areas outside software, one of the key points of differentiation has been between ‘recipes’ and ‘food’, bits and atoms, genotype and phenotype. That is that software moves the kinds of rivalry associated with the ownership and rights to use and enjoy a physical object into another domain, that of speed and quality of information, which network distribution tends to mitigate against. This is also the same for other kinds of data, such as music, texts and so on. (This migration of rivalry is often glossed over in the description of ‘goods’ being ‘non-rivalrous’.) Graphic Design however is an interesting middle ground in a certain way in that it both generates files of many different kinds, and, often but not always, provides the ‘recipes’ for physical objects, the actual ‘voedingstof’, such as signage systems, posters, books, labels and so on. Following this, do you circulate your files in any particular way, or by other means attempt to blur the boundary between the recipe and the food?

We have just finished the design of a font (NotCourier-sans), a derivative of Nimbus Mono, which is in turn a GPL’ed copy of the well known Courier typeface that IBM introduced in 1955. Writing a proper licence for it, opened up many questions about the nature of ‘source code’ in design, and not only from a legalist perspective. While this is actually relatively simple to define for a font (the source is the object), it is much less clear what it means for a signage system or a printed book.

One way we deal with this, is by publishing final results side by side with ingredients and recipes. The raw files themselves seem pretty useless once the festival is over and the book printed, so we write manuals, stories, histories. We also experiment with using versioning systems, but the softwares available are only half interesting to us. Designed to support code development, changes in text files can be tracked up to the minutest detail but unless you are ready to track binary code, images and document layouts function as black boxes. I think this is something we need to work on because we need better tools to handle multiple file formats collaboratively, and some form of auto-documentation to support the more narrative work.

On the other hand, manuals and licences are surprisingly rich formats if you want to record how an object came into life; we often weave these kinds of texts back into the design itself. In the case of NotCourierSans we will package the font with a pdf booklet on the history of the typeface – mixing design geneology with suggestions for use.

I think the blurring of boundaries happens through practice. Just like recipes are linked in many ways to food, ⁷ design practice connects objects to conditions. OSP is most of all interested in the back-and-forth between those two states of design; rendering their interdepence visible and testing out ways of working with it rather than against it. Hopefully both the food and the recipe will change in the process.