Dear (potential) collaborator,

Here is a brief document we have prepared that we hope, helps to establish our future working relationship together. In this way we hope to develop a better mutual understanding of each other and get around any false assumptions, and introduce you to OSP's practice and preferred ways of working. We kept it as short as possible, but we are happy to discuss points with you in detail.

Who is OSP?

OSP (Open Source Publishing) is a Brussels-based collective who work with free/libre open source software (F/LOSS) to make graphic design. We have been doing this since Janurary 20, 2006. Our members are multilingual, and we use English as a common language.

Which tools do we use? And why?

We prefer to use F/LOSS, and suggest alternatives to proprietary software, such as those within Adobe's Creative Cloud. F/LOSS is based on four freedoms: freedom to study the code, to run it as you wish (for any purpose), to redistribute it, and to distribute copies of your own modified versions. This also means:

• Having a close relationship to our tools, knowing them intimately
• Encouraging a ecology of shared work and ideas
• Refusing the notion that ideas come from nowhere and things are created out of nothing
• Acknowledging that culture is the shared practice of making meaning
• Being able to imagine and realise the tools we use as interconnected pipelines
• Being able to offer those tools back to others so they may also work with them

What is our process?

• We meet with you to gain an understanding of what needs to be done and which team of OSPs can work on it
• We never work alone, always between 2-4 OSP members work on a project together, but not the whole collective
• We spend time doing technical and visual research. Because we are working with F/LOSS, we need to research and experiment with different methods and tools until we find something that works
• We spend time to develop one strong idea, which we are convinced by
• Each collaboration is different, we don't work with a streamlined, seamless method
• Instead, a "seamful" way of working is preferred. This means a way of working in which tensions are present. This is not always comfortable, but it is often in discomfort that things become interesting
• We find it important to stay with the frictions and include our collaborators in conversations around them
• Because it reflects or shapes how we function, design is permeable with other practices. While discussing the creation of custom-made meaningfull structures (both for print and web and everything in between) it may interogate your own ways of doing. For example: the way we categorize content, where the focus is put visualy, what type of interaction do we want to trigger, is not a solved science. We believe there is value in seeing an opportunity to re-think our practices through design projects.
• We should agree to be ready to re-discuss our expectations on a project and keep an open mind to alternative ways of doing. That includes being willing to participate in conversations exercices to figure out together what make sense in the context of the project, instead of projecting ready-made workflow as "neutral" or "simple".

How should we meet?

• Meaningfull processess require a deeper engagment in the collaboration from both side. we think about project as dialogue, as such it makes sense that you introduce your preferred mode of dialogue and own sensibilities and constraints, we'll create spaces for you to discuss about that with us.
• It is important to clearly state wether a meeting is space for going deep in the subject of the project, or more about feedbacks on concrete elements (e.g size of logo, fonts, colours etc) and timeline or practical organisation.
• We should agree at the beginning of the project of a clear timeline and meetings. Those can (probably will) be postponed, it should be made clear when to reschedule
• We would like to know who will be involved in these meetings before beginning. Please don't add any 3rd party collaborators to the loop during the process unless it is explicitly agreed between us.

If the project involves a website

Website are ever-changing objects, it often doesn't reach a state when it will stop changing: you will continue editing content, and often you'll do it while it is being constructed. Coming up with an empty-but-finished website is contradictory with creating a structure that reflects what you are doing. Making a website will create back and forth between trying out to implement content, even as an exercice, and furthering the development on our side, then discuss it back together. Such process also gives you agency over the project as early as possible.

• We would like to have direct contact with the person puting content on the website. It is important for us to discuss the editorial practice of that person, and make sure that the developed system fits their needs and practices. They may have to learn on the way - while not always necessary, we believe basic knowledge of things such as markdown templating language and understanding the deployement your website are powerfull tools for you.
• We don't add the content ourselves, but use placeholders to test the website design a structure for you to try.
• Websites require hosting and domain names. OSP doesn't pay for hosting and domain name purchase, this is something that needs to be arranged with a web hosting service. Servers services are not neutral, when we can we suggest going for a local one with which we more agree on their ideology. We can make some suggestions to help.

If the project involves an identity & print publications

An identity can not always be reduced to a collection of assets. It can also be expressed to printing materiality, styles of writing, choosing the (online) places in which it is expressed, or even custom made image filters.

• if there is any content that must be included (e.g. partner logos and images), these need to be provided as soon as possible
• all assets and their formats should be clearly listed
• for publications we prefer to use tools that don't require us to wait for the content: the collaborator will be autonomous and add the text themselves, unless it is explicitly agreed between us.
• We would like to have direct contact with the person adding the content so that we are aware of when this happens

How should we communicate?

• Through email only, sent to the OSP subgroup working on the project and CC the OSP general email miam@osp.kitchen.
• Any communication through social media and instant messaging will not be considered, unless explicitly agreed upon.
• Work hours are : Monday - Friday, 10am - 6pm

What to do about publishing work?

• We want to make our work available for other people to study, copy, modify, redistribute. We want to make it accessible and publish it on our git repository.
• OSP and any collaborators should be credited when our work is shared, (or) according to what the choosen license states.
• Licenses are a very complex thing to discuss, but we think it is valuable to consider publishing the work under non-copyright licences such as CC4R

What if things outside of the budget come up?

Because of the experimental nature of our work, things may go into unexpected direction for both parties. If something new is added to the process outside of the agreed budget and process, it should be understood that this requires an extra invoice, and should be accepted by the collaborator (i.e. you) before working on it. However we are ready to see how to adapt a budget together if desired.

How should we deal with payment?

• Part of the money get by the OSPs on a project is used to pay our fixed costs, such as rent
• In order to avoid precarity, 30% of the total amount should be paid before the start of the project
• The remaining 70% is paid after completion of work, depending of the scale of the project. This 70% can be spread out within the timeline, as agreed on between us
• For quick projects, we ask for 50% of the budget within a month after the start of the project.

How do we end?

We'd be happy to dedicate a reflection moment at the end of the project to give each other constructive feedback on the collaboration

If you are interested in learning more about the philosophies OSP comes from, here is the previous long-form collaboration agreement

If one of the above is a problem for you for some reason, let's discuss it, there is probably a solution.

This document was written at the OSP retreat of June 2024, including Gijs de Heij, Ludi Loiseau, Doriane Timmermans, Simon Browne, Vinciane Daheron, Clara Pasteau. It is under CC4R license.

Feedback - Find some space to understand their own constraints and limitation to know from the beginning, we'll take in consideration - explain e.g why it's important for them to add content themselves, for them to have agency on the tools they are using

http://pads.osp.kitchen/p/retreat-2024

https://ecotones.caveat.be/osp.html