Switch branches/tags
Nothing to show
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
477 lines (418 sloc) 27.2 KB
<h1> What's the thinking here</h1>
<blockquote>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 &#8217;solution&#8217;. Obviously the readers
of the blog only get a formatted version of this, as a performed work?
What&#8217;s the thinking here?&quot;</blockquote>
<p>This interview about the practice of OSP was carried out by e-mail
<strong>between March and May 2008</strong>. 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 <em>Software Studies, A Lexicon</em>,
and written <em>Media Ecologies: Materialist Energies in Art and
and <em>Behind the Blip: Essays on the Culture of Software</em>.
<p class="mf">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&#8217;s start with what
software you use?</p>
<p class="fs">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 &#8230; 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.</p>
<p>OSP usually works between GIMP, <sup><a href="#b026324c">1</a></sup>
Scribus <sup><a href="#26ab0db9">2</a></sup> and Inkscape <sup><a
href="#6d7fce9f">3</a></sup> on Linux distributions and OSX. We are fans
of FontForge, <sup><a href="#48a24b70">4</a></sup> and enjoy using all
kinds of commandline tools, <tt>psnup</tt>, <tt>ps2pdf</tt> and
<tt>uniq</tt> to name a few.</p>
<p class="mf">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
<p class="fs">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
&#8216;standard&#8217; to use, interesting for ourselves. Performing our
practice is as much part of the project as the actual books, posters,
flyers etc. we produce.</p>
<p>One way a shift of tools can open up new ways of doing graphic design,
is because it makes you immediately aware of the &#8216;resistance&#8217;
of digital material. At the point we can&#8217;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
<p>Free Software allows you to engage on many levels with the technologies
and processes around graphic design. When you work through it&#8217;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
<p class="mf">Following this, what kind of team have you built up, and
what new competencies have you had to develop?</p>
<p class="fs">The core of OSP is five people <sup><a
href="#1dcca233">5</a></sup>, 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.</p>
<p>It feels we often do more unlearning than learning; a necessary and
interesting skill to develop is dealing with incompetence &#8211; 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.</p>
<p class="mf">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?</p>
<p class="fs">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.</p>
<p>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.</p>
<p>Very concretely, computer-users really need larger character sets that
allow for communication between let&#8217;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&#233;J&#224;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.</p>
<p>But what it all comes down to probably&#8230; Donald Knuth is the only
person I have seen both Free Software developers and designers wear on
their T-shirts.</p>
<p class="mf">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?</p>
<p class="fs">The kinds of applications we use form a category in
themselves. They are indeed small projects so &#8216;scene&#8217; fits
them better than &#8216;culture&#8217;. 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.</p>
<p>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&#8217;ll just portray Scribus and Inkscape here because
from the differences between these two I think you can imagine what else
is out there.</p>
<p>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&#8217; GUI is a relatively underdeveloped area of a
project that otherwise has matured quickly.</p>
<p>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 <em>a relatively
unstructured coming and going of high energy collective work</em> much
work is done through a larger group of people submitting small patches and
it&#8217;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.</p>
<p class="mf">There&#8217;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?</p>
<p class="fs">I can&#8217;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 &#8216;end-user&#8217;?</p>
<p>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: <em>Preferences for work
tools and political preference are really orthogonal</em>. This is
understandable from a project-management point of view, but it makes you
wonder where else such a debate should take place.</p>
<p>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: <em>Where do I file a meta-bug?</em></p>
<p class="mf">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?</p>
<p class="fs">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 &#8216;before&#8217; and &#8216;after&#8217; comparison.
Or maybe we should call this an achievement of Free Software too?</p>
<p>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.</p>
<p>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&#233;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&#233;zier writing his specification as an engineer for the
Renault car factory to Levien&#8217;s Spiro, digital drawing has changed
<p class="mf">You have a major signage project coming up, how does this
commission map across to the ethics and technologies of F/LOSS?</p>
<p class="fs">We are right in the middle of it. At this moment &#8216;The
Pavilion of Provisionary Happiness&#8217; celebrating the 50th anniversary
of the Belgian World Exhibition, is being constructed out of 30.000 beer
crates right under the Brussels&#8217; Atomium. That&#8217;s a major
project done the Belgian way.</p>
<p>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 &#8211; this all
links back to our interest in Free Software.</p>
<p>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.</p>
<p>It is not an easy project but I don&#8217;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.</p>
<p class="mf">On this project, and in relation to the seeming omnipresence
in F/LOSS of the idea that this technology is &#8216;universal&#8217;, how
do you see that in relation to fonts, and their longer history of
<p class="fs">That is indeed a long story, but I&#8217;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
&#8216;universality&#8217; 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.</p>
<p>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 <em>For
the typefaces of the future neither tools nor fashion will be
decisive</em>. 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
<p>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&#8217;t know what she
means by using the term &#8216;open universal&#8217;, 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.</p>
<p class="mf">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?</p>
<p class="fs">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&#8230; in the move from print to design for
the web, &#8216;grids&#8217; have been replaced by &#8216;templates&#8217;
that interact with content and context through filters. Designers have
always been busy with designing systems and formats, <sup><a
href="#9ae0ea9e">6</a></sup> but stepped in to manipulate singular results
if necessary.</p>
<p>I referred to &#8216;generative design&#8217; 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.</p>
<p class="mf">One of the techniques OSP uses to get people involved with
the process and the technologies is the &#8216;Print Party&#8217;, can you
say what that is?</p>
<p class="fs">'Print Parties' are irregular public performances we
organise when we feel the need to report on what we discovered and where
we&#8217;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.</p>
<p class="mf">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?</p>
<p class="fs">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&#8217;t want them
to interfere.</p>
<p>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 &#8211; 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
&#8216;deadline&#8217; by &#8216;milestone&#8217;, and
&#8216;estimate&#8217; by &#8216;roadmap&#8217; is already a beginning.</p>
<p class="mf">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 &#8216;solution&#8217;. Obviously the readers
of the blog only get a formatted version of this, as a performed work?
What&#8217;s the thinking here?</p>
<p class="fs">&#8216;Efficient solutions&#8217; 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.</p>
<p class="mf">In terms of the development of F/LOSS approaches in areas
outside software, one of the key points of differentiation has been
between &#8216;recipes&#8217; and &#8216;food&#8217;, 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
&#8216;goods&#8217; being &#8216;non-rivalrous&#8217;.) 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 &#8216;recipes&#8217; for physical objects, the actual
&#8216;voedingstof&#8217;, 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?</p>
<p class="fs">We have just finished the design of a font
(NotCourier-sans), a derivative of Nimbus Mono, which is in turn a
GPL&#8217;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 &#8216;source code&#8217; 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.</p>
<p>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.</p>
<p>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
&#8211; mixing design geneology with suggestions for use.</p>
<p>I think the blurring of boundaries happens through practice. Just like
recipes are linked in many ways to food, <sup><a
href="#84bc3da1">7</a></sup> 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.</p>
<li id="b026324c"> image manipulation </li>
<li id="26ab0db9"> page layout </li>
<li id="6d7fce9f"> vector editing </li>
<li id="48a24b70"> font editor </li>
<li id="1dcca233"> Pierre Huyghebaert, Harrisson, Yi Jiang, Nicolas
Mal&#233;ve and me </li>
<li id="9ae0ea9e"> it really made me laugh to think of Joseph M&#252;ller
Brockman as vitalist </li>
<li id="84bc3da1"> tasting, trying, writing, cooking </li>