<nettime> Interview with Femke Snelting from Open Source Publishing

[Matthew Fuller <cus01mf {AT} gold.ac.uk>]

Open Source Publishing is a recently founded graphic design agency that 
uses only Free Software tools. Closely affiliated with the Brussels based 
digital culture foundation Constant VZW, OSP aims to test the possibilities 
and realities of doing graphic design using an expanding range of Free 
Software tools. On the way, they produce some great designs, test the 
aesthetics and conventions of both software and design practice and run a 
blog at http://ospublish.constantvzw.org/

This interview was carried out by email with Femke Snelting, a member of 
OSP, between March and May 2008.




Matthew Fuller: 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?

Femke Snelting: 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 lay-out, even if 
Processing is open source.

OSP usually works between Gimp (image manipulation), Scribus (page lay-out) 
and Inkscape (vector editing) on Linux distributions and OSX. We are fans 
of FontForge (font editor), and enjoy using all kinds of command-line 
tools, 'psnup', 'ps2pdf' and 'uniq' to name a few.

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 up?

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 '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.

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

FS: The core of OSP is five people (Pierre Huyghebaert, Harrisson, Yi 
Jiang, Nicolas Malevé and me), and between us we mix amongst others 
typography, lay-out, 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.

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?

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.

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 DeJaVu 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.

MF: The cultures around each of the pieces of software are quite distinct. 
People often lump all FLOSS 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?

FS: 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 FLOSS developer communities connect 
with other disciplines (or scenes?) such as design, printing and 
photography.

A great pleasure in working with FLOSS 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 mailinglist 
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 off 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 deScribus 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.

MF: There's a lot of talk about collaboration in FLOSS development, 
something very impressive, but often when one talks to developers of such 
software there is a lot to discus 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 FLOSS?

FS: I can't say we feel completely at home in the FLOSS 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 FLOSS 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 FLOSS 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?"

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?

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 
'before' and 'after' comparison. Or maybe we should call this an 
achievement of Free Software too?

Using FLOSS 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.

MF: You have a major signage project coming up, how does this commission 
map across to the ethics and technologies of FLOSS?

FS: 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.

MF: On this project, and in relation to the seeming omnipresence in FLOSS 
of the idea that this technology is 'universal', how do you see that in 
relation to fonts, and their longer history of standards?

FS: 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 1920's 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.

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?

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... 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 
(it really made me laugh to think of Joseph Muller Brockman as vitalist), 
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 
in the end of the day, we are rather bored by mysterious beauty.

MF: 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?

FS: 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.

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?

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'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.

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 
'solution'. Obviously the readers of the blog only get a formatted version 
of this, as a performed work? What's the thinking here?

FS: '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 FLOSS; 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 it is what it takes to make 
our point.

MF: In terms of the development of FLOSS 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?

FS: 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 
lay-outs 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 NotCourier-sans 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 (tasting, trying, writing, 
cooking), 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.





#  distributed via <nettime>: no commercial use without permission
#  <nettime>  is a moderated mailing list for net criticism,
#  collaborative text filtering and cultural politics of the nets
#  more info: http://mail.kein.org/mailman/listinfo/nettime-l
#  archive: http://www.nettime.org contact: nettime {AT} kein.org