% FS = Femke Snelting 
% LL = Ludvine Loiseau 
% SM = Sarah Magnan 
% AL = Alexandre Leray 
% SV = Stéphanie Vilayphiou 
% ES = Eric Schrijver 
% PH = Pierre Huyghebaert
% PM = Pierre Marchand

% USED FOR NAME INDEXING
% HIDDENKEYWORDS: Vilayphiou, Stéphanie|Loiseau, Ludivine|Huyghebaert, Pierre
% HIDDENKEYWORDS: Schrijver, Eric|Magnan, Sarah|Leray, Alexandre|Marchand, Pierre


% TITLE: Distributed Version Control


% SCALEFONT: 0.8

Date: Thu, **12 Sep 2013** 15:50:25 +0200  
From: FS `<snelting@collectifs.net>`  
To: OSP `<mail@osp.constantvzw.org>`  

% BIGSKIP:
% RESETFONT:
% SCALEFONT: 1.1

Dear OSP,

% BIGSKIP:

For a long time I have wanted to organise a conversation with you about the place and meaning of distributed version control in OSP design work. First of all because after three years of working with Git intensely, it is a good moment to take stock. It seems that many OSP methods, ideas and politics converge around it and a conversation discussing OSP practice linked to this concrete (digital) object could produce an interesting document; some kind of update on what OSP has been up to over the last three years and maybe will be in the future. Second: Our last year in Variable has begun. Under the header _Etat des Lieux_, Constant started gathering reflections and documents to archive this three year working period. One of the things I would like to talk about is the parallels and differences between a physical studio space and a distributed workflow.  And of course I am personally interested in the idea of 'versions' linked to digital collaboration. This connects to old projects and ideas and is sparked again by new ones revived through the Libre Graphics Research Unit and of course Relearn.  
I hope you are also interested in this, and able to make time for it. I would imagine a more or less structured session of around two hours with at least four of you participating, and I will prepare questions (and cake).

% BIGSKIP:

Speak soon!

% BIGSKIP:
    
x F

% VFILL:
% NEWPAGE:
% RESETFONT:



% NOWSPEAKING: FS
% ---------------
How do you usually explain Git to design students?


% NOWSPEAKING: AL
% ---------------
Before using Git, I would work on a document. Let's say a layout, and to keep a trace  of the different versions of the layout, I would append _01, _02 to the files. That's in a way already versioning. What Git does, is that it makes that process somehow transparent in the sense that, it takes care of it for you. Or better, you have to make it take care for you. So instead of having all files visible in your working directory, you put them in a database, so you can go back to them later on. And then you have some commands to manipulate this history. To show, to comment, to revert to specific versions. 


% NOWSPEAKING: LL
% ---------------
More than versioning your own files, it is a tool to synchronize your work with others. It allows you to work on the same projects together, to drive parallel projects.


% NOWSPEAKING: ES
% ---------------
It really is a tool to make collaboration easier. It allows you to see differences. When somebody proposes you a new version of a file, it highlights what has changed. Of course this mainly works on the level of programming code.


% NOWSPEAKING: FS
% ---------------
Did you have any experience with Git before working with OSP? 


% NOWSPEAKING: AL
% ---------------
Well, not long before I joined OSP, we had a little introduction to Mercurial, another versioning software, at school in 2009. Shortly after I switched to Git. I was working with someone else who was working with Git, and it was so much better.


% NOWSPEAKING: SV
% ---------------
Alex was interested in using Git to make Brainch[^]{A distributed text editing platform based on Django and Git http://code.dyne.org/brainch}. We wanted to make a web application to fork texts that are not code. That was our first use of Git.


% NOWSPEAKING: ES
% ---------------
I met OSP through Git in a way. An intern taught me the program and he said: _Eric once you'll get it, you'll get so excited!_. We were in the cafeteria of the art school. I thought it was really special, like someone was letting me in on a  secret and we we're the only ones in the art school who knew about it. He thought me how to `push` and `pull`. I saw quickly how Git really is modeled on how culture works. And so I felt it was a really interesting, promising system. And then I talked about it at the Libre Graphics Meeting in 2010, and so I met OSP. 


% NOWSPEAKING: PM
% ---------------
I started to work on collaborative, graphic design related stuff when I was developing a font manager. I've been connected to two versioning systems and mainly used SVN. Git came well after, it was really connected to web culture, compared to Subversion, which is more software related. 


% NOWSPEAKING: FS
% ---------------
What does it mean that Git is referred to as 'distributed versioning'?


% NOWSPEAKING: AL
% ---------------
The first command you learn in Git, is the `clone` command. It means that you make a copy of a project that is somehow autonomous. Contrary to Subversion you don't have this server-client architecture. Every repository is in itself a potential server and client. Meaning you can keep track of your changes offline.


% NOWSPEAKING: FS
% ---------------
At some point, you decided to use 'distributed versioning' rather than a centralized system such as Subversion. I remember there was quite some discussion...


% NOWSPEAKING: LL
% ---------------
I was not hard to convince. I had no experience with other versioning systems. I was just excited by the experience that others had with this new tool. In fact there was this discussion, but I don't remember exactly the arguments between SVN or Git. For what I remember Git was easier. 


% NOWSPEAKING: PM
% ---------------
The discussion was not really on the nature of this tool. It was just: _who would keep Git running for OSP?_ Because the problem is not the system in itself, it's the hosting platform. We didn't find any hosted platform which fitted our taste. The question was: do we set up our own server, and who is going to take care of at. At this time Alex, Steph and Ivan were quite excited about working with Git. And I was excited to use Subversion instead, but I didn't have to time to take care of setting it up and everything. 


% NOWSPEAKING: FS
% ---------------
You decided not to use a hosted platform such as Gitorious or GitHub?


% NOWSPEAKING: SV
% ---------------
I guess we already had our own server and were hosting our own projects. But Pierre you used online platforms to share code?


% NOWSPEAKING: PM
% ---------------
When I started developing my own projects it was kind of the end of SourceForge.[^]{SourceForge is a web based source code repository. It was the first platform to offer this service for free to Open Source projects.} I was looking for a tool more in the Free Software tradition. There was gna, and even though the platform was crashing all the time, I felt it was in line with this purpose.


% NOWSPEAKING: AL
% ---------------
If I remember correctly, when we decided between Git and Subversion, Pierre, you were also not really for it because of the personality of its main developer, Linus Torvalds. I believe it was the community aspect of Git that bothered you.


% NOWSPEAKING: PM
% ---------------
Well Git has been written to help Linus Torvalds receive patches for the Linux kernel; it is not aimed at collaborative writing. It was more about making it convenient for Linus. And I didn't see a point in making my practice convenient for Linus.
I was already using Subversion for a while and it was really working great at providing an environment to work together with a lot of people and check out different versions. Anything you expect from a versioning system was there, all elements for collaborative work were there. I didn't see the point to change for something that didn't feel as comfortable with, culturally.
This question of checking out different directories of repositories was really important to me. At this time (Git has evolved a lot) it was not possible to do that. There were other technical aspects I was quite keen of. I didn't see why to go for Git which was not offering the same amount of good stuff. 


% NOWSPEAKING: ES
% ---------------
But then there is this aspect of distribution, and  that's not in Subversion. If some day somebody decides to want a complete copy of an OSP project, including all it's history, they would need to ask us or do something complicated to give it to them.


% NOWSPEAKING: PM
% ---------------
I was not really interested in this 'spreading the whole repository'. I was more concerned about working together on a specific project. 


% NOWSPEAKING: FS
% ---------------
It feels like your habit of keeping things online has shifted. From making an effort afterwards to something that happens naturally, as an integral part of your practice.


% NOWSPEAKING: LL
% ---------------
It happened progressively. There is this idea that the Git repository is linked to the website, which came after. The logic is to keep it all together and linked, online and alive. 


% NOWSPEAKING: ES
% ---------------
That's not really true ... it was the dream we had: once we have Git, we share our files while working on them. We don't need to have this effort afterwards of cleaning up the sources and it will be shareable. But it is not true. If we do not put an effort to make it shareable it remains completely opaque. It requires still an investment of time. I think it takes about 10% of time of the project, to make it readable from the outside afterwards.


% NOWSPEAKING: SV
% ---------------
Now, with the connection to our public website, you're more conscious that all the files we use are directly published. Before we had a Git web application that allowed someone to just browse repositories, but it was not visual, so it was hard to get into it.
The Cosic project is a good example. Every time I want to show the project to someone, I feel lost. There are so many files and you really don't know which ones to open.


% NOWSPEAKING: FS
% ---------------
Maybe, Eric, you can talk about 'Visual Culture'?


% NOWSPEAKING: ES
% ---------------
Basically 'Visual Culture' is born out of this dream I talked about just now. That turns out not to be true, but shapes our practice and helps us think about licensing and structuring and all those interesting questions.
I was browsing through this Git interface that Stéphanie described, and thought it was a missed opportunity, because here is this graphic design studio, who publishes all their works, while they are working. Which has all kind of consequences but if you can't see it, if you don't know anything about computer programming, you have no clue on what's going on. And also, because it's completely textual. And for example a .sla file, if you don't know about Open Source, if you don't know about Scribus it could as well be salad.
It is clear that Git was made for text. It was the idea to show all the information that is already there in a visual form. But an image is an image, and type is a typeface, and it changes in a visual way. I thought it made sense for us to do. We didn't have anyone writing posts on our blog. But we had all this activity in the Git repository.


% NOWSPEAKING: PH
% ---------------
It started to give some schematic view on our practice, and renders the current activity visible, very exciting.
But it is also very frustrating because we have lots of ideas and very little time to implement them.
So the 'Visual Culture' project is terribly late on the ball comparing to our imagination.

Take by example the foundry. Or the future potential of the 'Iceberg' folders. Or our blog that is sometimes cruelly missing.
We have ways to fill all these functions with 'Visual Culture' but still no time to do it!


% NOWSPEAKING: FS
% ---------------
In a way you follow established protocols on how Open Source code is usually published. There should be a license, a README file ... But OSP also decided to add a special folder, which you called 'Iceberg'. This is a trick to make your repository more visual? 


% NOWSPEAKING: ES
% ---------------
Yeah, because even if something is straightforward to visualise, it helps if you can make a small render of it. But most of the files are a accumulation of files, like a webpage. The idea is that in the 'Iceberg' folder, we can put a screenshot, or other images ...


% NOWSPEAKING: SV
% ---------------
We wanted the files that are visible, to be not only the last files added. We wanted to be able to show the process. We didn't want it to be a portfolio and just show the final output. But we wanted to show errors and try-outs.
I think it's not only related to Git, but also to visual layout. When you want to share software, we say _release early, release often_, which is really nice. But it's not enough to just release, because you need to make it accessible to other people to understand what they are reading. It's like commenting your code, making it ... I don't want to say 'clean' ... legible, using variable names that people can understand. Because, sometimes when we code just for ourselves I use French variables so that I'm sure that it's not word-protected by the programming language. But then it is not accessible to many people. So stuff like that.


% NOWSPEAKING: FS
% ---------------
You have decided to use a tool that's deeply embedded in the world of F/LOSS. So I've always seen your choice for Git both as a pragmatic choice as well as a fan choice? 


% NOWSPEAKING: ES
% ---------------
Like as fans of the world of Open Source? 


% NOWSPEAKING: FS
% ---------------
Yes. By using this tool you align yourself, as designers, with people that develop software.


% NOWSPEAKING: AL
% ---------------
I'm not sure, I join Pierre on his feelings towards Linus Torvalds, even though I have less anger at him. But let's say he is not someone I especially like in his way of thinking.
What I like very much about Git is the distributed aspect. With it you can collaborate without being aligned together. While I think Linus Torvalds idea is very liberal and in a way a bit sad, this idea that you can collaborate without being aligned, without going through this permission system, is interesting. With Scribus for example, I never collaborated on it, it's such a pain to got through the process. It's good and bad. I like the idea of a community which is making a decision together, at the same time it is so hard to enter this community that you just don't want to and give up. 


% NOWSPEAKING: FS
% ---------------
How does it feel, as a group of designer-developers, to adopt workflows, ways of working, and also a vocabulary that comes from software development?


% NOWSPEAKING: ES
% ---------------
On the one hand it's maybe a fan act. We like this movement of F/LOSS development which is not always given the importance it has in the cultural world. It's like saying _hey I find you culturally relevant and important_. But there's another side to it. It's not just a distant appropriation, it's also the fact that software development is such a pervasive force. It's so much shaping the world, that I feel I also want to take part in defining what are these procedures, what are these ways of sharing, what are these ways of doing things. Because I also feel that if I ask someone from another field as a cultural actor, and take and appropriate these mechanisms and ways of doing, I will be able to influence what they are. So there is the fan act, and there's also the act of trying to be aware of all the logic contained in these actions.


% NOWSPEAKING: LL
% ---------------
And from another side, in the world of graphic design it is also a way to affirm that we are different. And that we're really engaged in doing this and not only about designing nice pictures. That we really develop our own tools.


% NOWSPEAKING: ES
% ---------------
It is a way to say: hey, we're not a kind of politically engaged designers with a different political goal each next half month, and than we do a project about it. It really impacts our ecosystem, we're serious about it.


% NOWSPEAKING: SV
% ---------------
It's true that, before we started to use Git, people asked: _So you're called Open Source Publishing, but where are your sources?_ For some projects you could download a .zip file but it was always a lot of trouble, because you needed to do it afterwards, while you were already doing other projects.


% NOWSPEAKING: PM
% ---------------
Collaboration started to become a prominent part of the work; working together on a project. Rather than, _oh you do that and when you are finished you send the file over and I will continue_. It's really about working together on a project.
%
% N!OWSPEAKING: PM
% ---------------
Even if you work together in the same space, if you don't have a system to share files, it's a pain in the ass. 


% NOWSPEAKING: FS
% ---------------
After using it for a few years, would you say there are parts of in Git where you do not feel at home? 


% NOWSPEAKING: AL
% ---------------
In Git, and in versioning systems in general, there is that feeling that the latest version is the best. There is an idea of linearity, even though you can have branches, you still have an idea of linearity in the process.


% NOWSPEAKING: SV
% ---------------
Yes, that's true. We did this workshop _Please computer let me design_, the first time was in a French school, in French, and the second time for a more European audience, in English. We made a branch, but then you have the default branch - the English one - you only see that one, while they are actually on the same level.


% NOWSPEAKING: FS
% ---------------
So the convention is to always show the main branch, the 'master'? 


% NOWSPEAKING: ES
% ---------------
In a way there is no real requirement in Git to have a branch called 'master'. You can have a branch called 'English' and a branch called 'French'. But it's true that all the visualization software we know (GitHub or Gitorious are ways to visualize the content of a Git repository), you'll need to specify which is the branch that is shown by default. And by default, if you don't define it, it is 'master'.


% NOWSPEAKING: AL
% ---------------
For certain types of things such as code and text it works really well, for others, like you're making a visual design, it's still very hard to compare differences. If I make a poster for example I still make several files instead of branches, so I can see them together at once, without having to check-out another branch.
%
% N!OWSPEAKING: AL
% ---------------
Even in websites, if I want to make a layout, I'll simply make a copy of the HTML and CSS, because I want to be able to test out and compare them. It might be possible with branches, it's just to complicated. Maybe the tools to visualize it are not there... But it's still easier to make copies and pick the one you like. 


% NOWSPEAKING: SV
% ---------------
It's quite heavy to go back to another version. Also working collaboratively is actually quite heavy. 
For example in workshops, or the 'Balsamine' project ... we were working together on the same files at the same time, and if you want to share your file with Git you'll have to first `add` your file, then `commit` and `pull` and `push`, which is four commands. And every time you commit you have to write a message. So it is quite long. So while we were working on the .css for 'Visual Culture', we tried it in Etherpad, and one of us was copying the whole text file and committing. 


% NOWSPEAKING: FS
% ---------------
So you centralized in the end.


% NOWSPEAKING: PM
% ---------------
It's more about third-party visual software. Let's say Etherpad for example, it's a versioning system in itself. You could hook into Git through Etherpad and each letter you type could be a commit. And it would make nonsense messages but at the same time it would speed up the process to work together. We can imagine the same thing with Git (or any other collaborative working system) integrated into Inkscape. You draw and every time you save... At some point Subversion was also a WebDav server, it means that for any application it was possible to plug things together. Each time you would save you file it would make a commit on the server. It worked pretty well to bring new people into this system because it was just exactly the same as the OpenOffice, it was an open WebDav client. So it was possible to say to OpenOffice that you, where you save is a disk. It was just like saving and it was committing. 


% NOWSPEAKING: ES
% ---------------
I really agree. From the experience of working on a typeface together in Git with students, it was really painful. That's because you are trying to do something that generates source code, a type design program generates source code. You're not writing it by hand, and if you then have two versions of the type design program, it already starts to create conflicts that are quite hard. It's interesting to bring to models together. Git is just an architecture on how to start your version, so things could hook into it.

For example with Etherpad, I've looked into this API the other day, and working together with Git, I'm not sure if having every Etherpad revision directly mapped to a Git revision would makes sense if you work on a project ... but at the same time you could have every saved revision mapped to a Git revision. 
It's clear Git is made for asynchronous collaboration process. So there is Linus in his office, there are patches coming in from different people. He has the time also to figure out which patch needs to go where. This doesn't really work for the Etherpad-style-direct-collaboration. For me it's cool to think about how you could make these things work together. Now I'm working on this collaborative font editor which does that in some sort of database. How would that work? It would not work if every revision would be in the Git. I was thinking you could save, or sort of `commit`, and that would put it in a Git repository, this you can `pull` and `push`. But if you want to have four people working together and they start `pull`ing, that doesn't work on Git.


% NOWSPEAKING: SV
% ---------------
I never really tried Sparkleshare, that could maybe work? Sparkleshare is making a `commit` message every time you save a document. In a way it works more like Dropbox. Every time you save it's synchronized with the server directly. 


% NOWSPEAKING: FS
% ---------------
So you need to find a balance between the very conscious commits you make with Git and the fluidness of Etherpad,
where the granularity is much finer. Sparkleshare would be in between?


% NOWSPEAKING: SV
% ---------------
I think it would be interesting to have this kind of Sparkleshare behaviour, but only when you want to work synchronously. 


% NOWSPEAKING: FS
% ---------------
So you could switch in and out of different modes? 


% NOWSPEAKING: SV
% ---------------
Usually Sparkleshare is used for people who don't want to get to much involved in Git and its commands. So it is really transparent: I send my files, it's synchronized. I think it was really made for this kind of Dropbox behaviour. I think it would make sense only when you want to have your hands on the process. To have this available only when you decide, _OK I go synchronous_. Like you say, if you have a commit for every letter it doesn't make sense. 


% NOWSPEAKING: PM
% ---------------
It makes sense. A lot of things related to versions in software development is meant to track bugs, to track programming choices.


% NOWSPEAKING: SV
% ---------------
I don't know for you ... but the way I interact with our Git repository since we started to work with it ... I almost never went into the history of a project. It's just, it really never happened to go back into this history, to check out an old version.


% NOWSPEAKING: AL
% ---------------
I do!


% NOWSPEAKING: PM
% ---------------
Some neat feature of Git is the dissect command. To find where it broke. 


% NOWSPEAKING: AL
% ---------------
You can top from an old revision that you know that works and then track down, like `checkout`, track down the bug. 


% NOWSPEAKING: FS
% ---------------
Can you give a concrete example, where that would be useful, I mean, not in code. 


% NOWSPEAKING: AL
% ---------------
Not code, okay. That I don't know. 


% NOWSPEAKING: SV
% ---------------
In a design, like visual design, I think it never happens. It happens on websites, on tools. Because there is a bug, so you need to come back to see where it broke. But for a visual design I'm not sure. 


% NOWSPEAKING: LL
% ---------------
It's true, also because as you said before, with .svg files or .sla files we often have several duplicates. I sometimes checkout those. But it's true it's often related to merge problems. Or something, you don't know what to do, so you'll just check-out, to go back to an earlier version.


% NOWSPEAKING: PM
% ---------------
It would be interesting for me to really look at our use of Git and map some kind of tool on top of a versioning system. Because it's not even versioning, it is also a collaborative workflow, and to see what we mean. Just to use maybe some feature of Git or whatever to provide the services we need and really see what we exactly work with. And, this kind of thing where we want to see many versions at the same time, to compare seems important. Well it's the kind of thing that could take advantage of a versioning system, to build. 


% NOWSPEAKING: FS
% ---------------
It is of course a bit strange that if you want to see different versions next to each other you have to go back in time. It's a kind of paradox, no? 


% NOWSPEAKING: SV
% ---------------
But then you can't see them at the same time 


% NOWSPEAKING: FS
% ---------------
Exactly, no.


% NOWSPEAKING: SV
% ---------------
Because there is no way to visualize your trip back in history. 


% NOWSPEAKING: ES
% ---------------
Well I think, something you could all have some interesting discussion about, is the question of exchange. Because now we are talking about the individual. We've talked how it's easier to contribute to Git based projects but to be accepted into an existing repository someone needs to say okay, I want it, which is like SVN. What is easier, is to publish you're whole Git repository online, with the only difference from the the first version, is that you added your change, but it means that in proposing a change you are already making a new cultural artifact. You're already putting a new something there. I find this to be a really fascinating phenomena because it has all kinds of interesting consequences.
Of course we can look at it the way of, it's the cold and the liberal way of doing things. Because the individual is at the center of this, because you are on your own. It's your thing in the first place, and then you can see if it maybe becomes someone else's thing too. So that has all kinds of coldness about it and it leads to many abandoned projects and maybe it leads to a decrease of social activity around specific projects.
But there's also an interesting part of it, where it actually resembles quite well how culture works in the first place. Because culture deals with a lot redundancy, in the sense that we can deal with many kinds of very similar things. We can have Akzidenz Grotesk, Helvetica and the Akkurat all at the same time, and they have some kind of weird cultural lineage thing going on in between them.


% NOWSPEAKING: FS
% ---------------
Are there any `pull` requests for OSP? 


% NOWSPEAKING: SV
% ---------------
We did have one.


% NOWSPEAKING: FS
% ---------------
Eric is right to ask about collaboration with others, not only how to work internally in a group.


% NOWSPEAKING: SV
% ---------------
That's why GitHub is really useful. Because it has the architecture to exchange changes. Because we have our own server it's quite private, it's really hard to allow anyone to contribute to fonts for example. So we had e-mails: _Hey here's a new version of the font, I did some glyphs, but also changed the shape of the A_. There we have two different things, new glyphs is one thing, we could say we take any new glyph. But changing the A, how do you deal with this? There's a technical problem, well not technical...


% NOWSPEAKING: FS
% ---------------
An architectural problem? 


% NOWSPEAKING: SV
% ---------------
Yeah, we won't add everyone's SSH-key to the server because it will be endless to maintain. But at the same time, how do you accept changes? And then, who decides what changes will be accepted?


% NOWSPEAKING: LL
% ---------------
For the foundry we decided to have a maintainer for each font project. 


% NOWSPEAKING: PM
% ---------------
It's the kind of thing we didn't do well. We have this kind of administrative way of managing the server. Well it's a lot of small elements that all together make it difficult. Let's say at some point we start to think _maybe we need to manage our repositories, something a bit more sophisticated then Gitolite_. So we could install something like Gitorious. We didn't do it but we could imagine to rebuild a kind of ecosystem where people have their own repositories and do anything we can imagine on this kind of hosting service.
%
% N!OWSPEAKING: PM
% ---------------
Gitorious is a Free Software so you can deploy it on your own server. But it is not trivial to do. 


% NOWSPEAKING: FS
% ---------------
Can you explain the difference between Gitorious and GitHub?


% NOWSPEAKING: AL
% ---------------
Gitorious is first a free version, it's not a free version of Git but GitHub. One is free and one is not. 


% NOWSPEAKING: FS
% ---------------
Meaning you can not install GitHub on your own server.


% NOWSPEAKING: PM
% ---------------
Git is a storage back-end, and Gitorious or GitHub are a kind of web application to interact with the repository and to manage them. And GitHub is a program and a company deploying these programs to offer both a commercial service and a free-of-charge service. They have a lot of success with the free service Git in a sense. And they make a lot of money at providing the same service, exactly the same, just it means that you can have private space on the server. It's quite convenient, because the tools are really good to manage repositories.
And Gitorious I don't exactly know what is their business model, they made all their source code to run the platform Free Software. It means they offer a bit less fancy features. 


% NOWSPEAKING: FS
% ---------------
A bit less shiny? 


% NOWSPEAKING: PM
% ---------------
Yeah, because they have less success and so less money to dedicate to development of the platform. But still it's some kind of easy to grasp web interface management, repositories manager. Which is quite cool. We could do that, to install this kind of interface, to allow more people to have their repositories on the OSP-server. But here comes the difficult thing: we would need a bit more resources to run the server to host a lot of repositories. Still this moment we have problems sometimes with the server because it's not like a large server. Nobody at OSP is really a sysadmin, and has time to install and setup everything nicely etcetc. And we also would have to work on the gitorious web application to make it a bit more in line with our visual universe. Because now it's really some kind of thing we cannot associate with really. 


% NOWSPEAKING: FS
% ---------------
Do you think 'Visual Culture' can leverage some of the success of GitHub? People seem to understand and like working this way.


% NOWSPEAKING: PM
% ---------------
Well, it depends. We also meet a lot of people who come to GitHub and say, I don't understand, I don't understand anything of this!
%
% N!OWSPEAKING: PM
% ---------------
Because of it's huge success GitHub can put some extra effort in visualization, and they started to run some small projects. So they can do more than 'Visual Culture' can do. 


% NOWSPEAKING: FS
% ---------------
And is this code available? 


% NOWSPEAKING: AL
% ---------------
Some of their projects are Open Source.


% NOWSPEAKING: PM
% ---------------
Some of their projects are free. Even if we have some things going on in 'Visual Culture', we don't have enough manpower to finalize this project. The GitHub interface is really specific, really oriented, they manage to do things like show fonts, show pictures, but I don't think they can display .pdf. 'Visual Culture' is really a good direction, but it can become obsolete by the fact that we don't have enough resource to work on it. GitHub starts to cover a lot of needs, but always in their way of doing things, so it's a problem. 


% NOWSPEAKING: AL
% ---------------
I'm very surprised ... the quality of Git is that it isn't centralized, and nowadays everything is becoming centralized in GitHub. I'm also wondering whether ... I don't think we should start to host other repositories, or maybe we should, I don't know.


% NOWSPEAKING: PM
% ---------------
Yeah, I think we should 


% NOWSPEAKING: FS
% ---------------
You do or you don't want to become a hosting platform? 


% NOWSPEAKING: AL
% ---------------
No. What I think is nice about GitHub is of course the social aspect around sharing code. That they provide comments. Which is an extra layer on top of Git. I'm having fantasies about another group like OSP who would use Git and have their own server, instead of having this big centralized system. But still have ways to interact with each other. But I don't know how.


% NOWSPEAKING: FS
% ---------------
It would be interesting if it's distributed without being disconnected. 


% NOWSPEAKING: PM
% ---------------
If it was really easy to setup Git, or a versioning server, that would be fantastic. But I can remember, as a software developer, when I started to look for somewhere to host my code it was no question to setup my own server. Because of not having time, no time to maintain, no time to deploy etcetc. At some point we need hosting-platforms for ourselves. We have almost enough to run our own platform. But think of all the people who can't afford it. 


% NOWSPEAKING: FS
% ---------------
But in a way you are already hosting other people's projects. Because there are quite a few repositories for workshops that actually not belong to you. 


% NOWSPEAKING: PM
% ---------------
Yeah, but we moved some of them to GitHub just to get rid of the pain of maintaining these repositories. 


% NOWSPEAKING: LL
% ---------------
We wanted the students to be independent. To really have them manage their own projects. 


% NOWSPEAKING: PM
% ---------------
GitHub is easier to manage then our own repository which is still based on a lot of files. 


% NOWSPEAKING: SV
% ---------------
For me, if we ever make this hosting platform, it should be something else then our own website.
Because, like you say, it's kind of centralized in the way we use it now. It's all on the Constant server. 


% NOWSPEAKING: PM
% ---------------
Not anymore? 


% NOWSPEAKING: SV
% ---------------
No, the Git repositories are still on the Constant server. 


% NOWSPEAKING: PM
% ---------------
Ah, the Git is still. But they are synced with the OSP server. 
%
% N!OWSPEAKING: PM
% ---------------
But still, I can imagine it would be really nice to have many instances of 'Visual Culture' for groups of people running their own repositories. 


% NOWSPEAKING: FS
% ---------------
It feels a bit like early days of blogging.


% NOWSPEAKING: PM
% ---------------
It would be really, really nice for us to allow other people to use our services. I was also thinking of this, because of this branching stuff. For two reasons, first to make it easier for people to take advantage of our repository. Just like branching our repository would be one click, just like in Gitorious or GitHub. So I have an account and I like this project and I want to change something, I just click on it. You're branched into your own account and you can start to work with it. That's it, and it would be really convenient for people who would like to work with our font files etc. 
%
% N!OWSPEAKING: PM
% ---------------
And once we have all these things running on our server we can think of a lot of ideas to promote our own dynamic over versioning systems. But now we're really a bit stuck because we don't have the tools we would like to have. With the repositories, it's something really rigid. 


% NOWSPEAKING: FS
% ---------------
It is interesting to see the limits of what actually can happen. But it is still better than the usual (In)design practices?


% NOWSPEAKING: LL
% ---------------
We would like to test GitMX. We don't know much about it, but we would like to use it for the pictures in high-resolution, .pdfs. We thought about it when we were in Seoul, because we were putting pictures on a gallery, and we were like _ah, this gallery_. We were wondering, perhaps if GitMX works well, perhaps it can be separated into different types of content. And then we can branch them into websites. And perhaps pictures of the finalized work. In the end we have the 'Iceberg' with a lot of 'in-progress'-pictures, but we don't have any portfolio or book. Again because we don't care much about this, but at the end we feel we miss it a bit. 


% NOWSPEAKING: FS
% ---------------
A narration ...


% NOWSPEAKING: LL
% ---------------
... to have something to present. Each time we prepare a presentation, we need to start again to find back the tools and files, and to choose what we want to send for the exhibition.


% NOWSPEAKING: PM
% ---------------
It's really important because at some point, working with Git, I can remember telling people ...


% NOWSPEAKING: AL
% ---------------
_Don't `push` images!_


% NOWSPEAKING: FS
% ---------------
I remember.


% NOWSPEAKING: PM
% ---------------
The repository is there to share the resources. And that's really where it shines. And don't try to put all your active files in it. At some point we miss this space to share those files. 


% NOWSPEAKING: FS
% ---------------
But an image can be a recipe. And code can be an artifact. For me the difference is not so obvious.


% NOWSPEAKING: PH
% ---------------
It is not always so clear. Sometimes the cut-off point is decided by the weight of the file, so if it is too heavy, we avoid Git. Another is: if it is easy to compile, leave it out of Git. Sometimes the logic is reversed. If we need it to be online even if not a source, but simply we need to share it, we put it on the Git. Some commits are also errors. The distinction is quite organic until now, in my experience. The closer the practice gets to code, the more clean the versioning process is.


% NOWSPEAKING: FS
% ---------------
There is also a kind of performative part of the repository. Where a commit counts as a proof of something ...


% NOWSPEAKING: SV
% ---------------
When I presented the OSP's website, we had some remarks like, _ah it's good we can see what everybody has done, who has worked_. 


% NOWSPEAKING: PH
% ---------------
But strangely so far there were not many reactions from partners or clients regarding the fact that all the projects could be followed at any stage. Even budget wise... Mostly, I think, because they do not really understand how it works.


% NOWSPEAKING: SV
% ---------------
And sometimes it's true, it came to my mind, should we really show our website to clients? Because they can check whether we are working hard, or this week we didn't do shit... And it's, I think it's really based on trust and the type of collaboration you want with your client. Actually collaboration and not a hierarchical relationship. So I think in the end it's something that we have to work on. On building a healthy relationship, that you show the process but it's not about control. The meritocracy of commits is well known, I think, in platforms like GitHub. I don't think in OSP this is really considered at all actually.


% NOWSPEAKING: PH
% ---------------
It supports some self-time tracking that is nuanced and enriched by e-mail, calendar events, writing in Etherpads. It gives a feeling of where is the activity without following it too closely. A feeling rather than surveillance or meritocracy.


% NOWSPEAKING: SV
% ---------------
I know that Eric ... because he doesn't really keep track of his working hours. He made a script to look into his `commit` messages to know when he worked on a project. Which is not always truthful. Because sometimes you make a commit on some files that you made last week, but forgot to `commit`. And a commit is a text message at a certain time. So it doesn't tell you how much time you spent on the file. 


% NOWSPEAKING: FS
% ---------------
Although in the way you decided to visualize the commits, there is a sense of duration between the last and the commit before.
So you have a sense of how much time passed in between. 
%
% N!OWSPEAKING: FS
% ---------------
Are there ways you sometimes trick the system,  to make things visible that might otherwise go missing? 


% NOWSPEAKING: AL
% ---------------
In the messages sometimes, we talk about things we tried and didn't work. But it's quite rare. 


% NOWSPEAKING: LL
% ---------------
I kind of regret that I don't write so much on the commits. At the beginning when we decided to publish the messages on the homepage we talked about this theater dialogue and I was really excited. But in the end I see that I don't write as much as I would like. 


% NOWSPEAKING: PM
% ---------------
I think it's really a question of the third-party programs we use. Our `commit` messages are like a dialogue on the website. But when you write a `commit` message you're not at all in this interface. So you don't answer to something. If we would have the same kind of interface we have on the website, you would realize you can answer to the previous `commit` message. You have this sort of narrative thread and it would work. We are in the middle, we have this feeling of a dialogue on one side, but because when you work, you're not on the website to check the history. It's just basically, it would be about to make things really in line with what we want to achieve.


% NOWSPEAKING: AL
% ---------------
I `commit` just when I need to share the files with someone else. So I wait until the last moment. 


% NOWSPEAKING: SV
% ---------------
To `push` you mean? 


% NOWSPEAKING: AL
% ---------------
No,  to `commit`. And then I've lost track of what I've done and then I just write... 


% NOWSPEAKING: FS
% ---------------
But it would be interesting, to look at the different speeds of collaboration. They might need each another type of `commit` message.


% NOWSPEAKING: SV
% ---------------
But it's true, I must admit that when I start working on a project I don't read the last messages. And so, then you lose this dialogue as you said. Because sometimes I say, _Ludi is going to work on it_. So I say, _OK Ludi it's your turn now_, but the thing is, if she says that to me I would not know because I don't read the `commit` messages. 


% NOWSPEAKING: PM
% ---------------
I suppose that is something really missing from the Git client. When you `pull`, you update your working copy to synchronize with the server it just says files change, how many changes there were. But doesn't give you the story.


% NOWSPEAKING: SV
% ---------------
That's what missing when you `pull`. It should instead of just showing which files have changed, show all the logs from the last time you `pull`ed. 


% NOWSPEAKING: PM
% ---------------
Your earlier point, about recipes versus artifacts. I have something to add that I forgot.
%
% N!OWSPEAKING: PM
% ---------------
I would reverse the question, what the versioning system considers to be a recipe is good, is a recipe. I mean, in this context 'a recipe' is something that works well within the versioning system. Such as the description of your process to get somewhere. And I can imagine it's something, I would say the Git community is trying to achieve that fact. Make it something that you can share easily. 


% NOWSPEAKING: SV
% ---------------
But we had a bit of this discussion with Alex for a reader we made. It is going to be published, so we have the website with all the texts, and the texts are all under a free license. But the publisher doesn't want us to put the .pdfs online. I'm quite okay with that, because for me it's a condition that we put the sources online. But if you really want the .pdf then you can `clone` the repository and make them yourself in Scribus.
%
% N!OWSPEAKING: SV
% ---------------
It's just an example of not putting the .pdf, but you have everything you need to make the .pdf yourself. For me it's quite interesting to say our sources are there. You can buy the book but if you want the .pdf you have to make a small effort to generate it and then you can distribute it freely. But I find it quite interesting to, of course the easiest way would be the .pdf but in this case we can't. Because the publisher doesn't want us to. 


% NOWSPEAKING: FS
% ---------------
But that distinction somehow undervalues the fact that layout for example is not just an executed recipe, no? I mean, so there is this kind of grey area in design that is... maybe not the final result, but also not a sort of executable code.


% NOWSPEAKING: AL
% ---------------
We see it with 'Visual Culture', for instance, because Git doesn't make it easy to work with binaries. And the point of 'Visual Culture' is to make .jpegs visible and all the kind of graphical files we work with. So it's like we don't know how to decide whether we should put for instance .pdfs in the Git repository online. Because on the one hand it makes it less manageable with Git to work with. But on the other hand we want to make things visible on the website. 


% NOWSPEAKING: SV
% ---------------
But it's also storage-space. If you want to `clone` it, if you want people to `clone` it also you don't want a 8 gigabyte repository.
%
% N!OWSPEAKING: SV
% ---------------
For me it's OK to make a low-resolution .pdf, even if Git doesn't handle them so well. Not the .pdf that is sent to the printer, because it's too big, and that you can produce by cloning the repository. Making a low-res file for people to look at.


% NOWSPEAKING: PM
% ---------------
I don't know because it's not really what OSP is for, but you can imagine, like Dropbox has been made to easily share large files, or even files in general. We can imagine that another company will set up something, especially graphic designers or the graphic industry. The way GitHub did something for the development industry. They will come up with solutions for this very problem.


% NOWSPEAKING: SV
% ---------------
I just want to say that I think because we're not a developer group, at the start the `commit` messages were a space where you would throw all your anger, frustration. And we first published a Git log in the Balsamine program, because we saw that. 
%
% N!OWSPEAKING: SV
% ---------------
This was the first program we designed with ConTeXt. So we were manipulating code for layout. The `commit` messages were all really funny, because Pierre and Ludi come from a non-coding world and it was really inspiring and we decided to put it in the publication. Then we kind of looked, Ludi says two kind of bad things about the client, but it was okay. Now I think we are more aware that it's public, we kind of pay attention not to say stuff we don't mean to...


% NOWSPEAKING: FS
% ---------------
It's not such an exciting space anymore as in the first half year?


% NOWSPEAKING: AL
% ---------------
It often very formal and not very, exciting, I think. But sometimes I put quite some effort to just make clear what I'm trying to share.


% NOWSPEAKING: SV
% ---------------
And there are also commits that you make for yourself. Because sometimes, even if you work on a project alone, you still do a Git project to keep track, to have a history to come back to. Then you write to yourself. I think it's also something else. I've never tried it.


% NOWSPEAKING: FS
% ---------------
It's a lot to ask in a way, to write about what you are doing while you are doing it.


% NOWSPEAKING: LL
% ---------------
I think we should pay more attention to the first commit of a project, and the last. Because it's really important to start the story and to end it. I speak about this 'end' because I feel overflowed by all these not-ended projects, I'm quite tired of it. I would like us to find a way to archive projects which are not alive any more. To find a good way to do it. Because the list of folders is still growing, and in a way it is okay but a lot of projects are not active. 


% NOWSPEAKING: SV
% ---------------
But it's hard to know when is the last commit. With the Balsamine project it's quite clear, because it's season per season. But still, we never know when it is the last one. The last one could be solved by the 'Iceberg', to make the last snapshots and say okay now we make the screenshots of the latest version. And then you close it... 
%
% N!OWSPEAKING: SV
% ---------------
We wanted that the last one was _Hey, we sent the .pdfs to the printer_. But actually we had to send it back another time because there was a mistake. And then the log didn't fit on the page anymore.