(1) About Open Source Workflows
Many people think of open source as publishing building plans, after you have made them – for others to study and use. But in fact this is not really the story, at least not in most cases. Especially not in the world of software where ‘Open Source’ was coined.
Instead you should think about it like this: working on open source is like a regular project where you work alone or in a team, with one little difference, you do it in the open.
When you work with a team on a project in a company, a university or in a hobby project, you share information and resources needed to get the work done with your team. This might be data sets, design files, software code, protocols, lists, decisions made etc. You make the information accessible to your collaborators, in an editable format – so they can use, update or adapt it. And get the work done.
In open source you do basically the same thing, just in public, all the time. The conversation in the project and all its files and resources are publicly visible and accessible. It is not about making it public afterwards. You don’t write an email and publish it later, you post the email in a public mailing list.
(2) OSCEdays and OSCE association
This is how we work at the OSCEdays and OSCEdays association. We don’t use email, we use our forum. The forum is our project management tool. There we do our work, transparently, available to be followed by everyone in the community. Meetings, project data, resources, protocols, design files, discussions … it is all there in public (with the exception of personal and partner data).
And if you scroll through the forum you see city categories. They are available for local communities that want to use a similar style of open workflow to organize their local events and activities. Some organizers did this last year, like Berlin, Barcelona, London, Vienna and Mouans-Sartoux.
The same method applies to challenges as well. If you post a challenge in the forum, don’t think about it as broadcasting. Think about it as structuring your task for you and your team allowing and enabling you to work on it – organizing a work environment. This is what will make the information really useful.
(3) Advantages of the Open Source Collaboration Workflow
Here are some of the advantages or effects of this way to work (for us in the OSCEdays):
- Empty inboxes: We prevent a lot of emailing! The OSCEdays happens (almost) entirely outside of our email-inboxes. We go to the forum, when there is time to do OSCEdays work and don’t get it mixed up with other projects or stuff.
- Better onboarding of new collaborators: If new people come on board, we don’t have to explain things every time. Because everything is already publicly documented – we can just give them links or they find them by themselves, and can learn how the work is done and what are the tasks to do. Onboarding new people is much easier! We can be more inclusive. Plus the information is also there for people who never actually would ask for it, but still might find unexpected ways to become part of everything because the information is there.
- Easier to work with at a later date: being in the open might encourage you to be clear and tidy from the start, especially if you want allow also others to make sense of everything. Also Future You will benefit from that.
- Balanced power structures: ‘Knowledge is power’. Often in a project the person with the most knowledge about it has some kind of power. This person is too important! When everything is publicly available, everyone can catch up and this position of power is less important. The project is more stable, it has fewer points of failure, people are easier to replace, and the project is more trustworthy and less hierarchical.
For me, the OSCEdays workflow is a great experience! In the beginning, learning how the forum works was a small hurdle, because the technology we use (discourse) is very powerful. But it is worth it to push yourself through it. I am sure that our open source workflow makes us much more efficient. The OSCEdays is a complex project and with the limited resources we have, it would not have been possible to come this far with a closed workflow.
In recent decades we have seen open source proving itself in most cases as the superior development model for software!
That’s it for a general introduction. If you dive more into it there are new questions and possibilities which emerge from working in public; for example about the tools to use or licensing practises. We will post about these issues in the future, but if you can’t wait, here is a little text about ‘Documentation in Open Source’ from our Open Source themed calendar which will introduce you to the idea of “forking”.
No, that is not Open Source!
Some people will say what I just described is NOT Open Source. And of course! If you start to play football on an ice field instead of grass it will no longer be football. You will need new rules and others will stop to make sense. New things are interesting to achieve. People might start to wear different clothes and so on. You will end up a whole different game .. But in its core it will remain the same, that you somehow started to play football on an ice field instead of grass.