Hi, I am from Berlin and making research about open source hardware and would like to organize the following workshop for the OSCEDays in Berlin. Don’t hesitate to comment on this proposition. I’m still working on it.
Jérémy
There is a precise definition of what open source means. Also the term open source hardware has been coined quite precisely. But interestingly, not every project claiming to be open source fits in these defintions. Having a closer look to current practices, there acually seems to be a certain discrepancy between theory and practice, intention and reality.
So what makes that a product can be qualified as open source? If the concept of openness is no binary concept but more like a continuum between “completely open” and “completely closed”, where is the limit between open and closed ? If I develop a product and intend to publish the CAD files but didn’t find the time to do it, do I have the right to call my product open source? Can be the opennes defined upon the quantity of information that is shared or more upon the quantity of people actively working on it, forking it or replicating it?
Objectives of the workshop: * reflect on the concept of open source and on best practices of open source hardware * working on the definition of an openess index for product (development projects) * raise awareness on the meaning of open source The challenge will take place in Berlin.
Hi Sharon,
If you look at the best practices of open source hardware published by the open source hardware association, there are basically three things to share to make your hardware open source: original CAD files, BoM and instructions, all in editable formats. Not all projects claiming to be open source are sharing these files. Some share only one of them, some none of them, and only a few share all these documents. My hypothesis is that this behaviour says something about the intentions of the projects and their state of development.
For example, about the intention of projects:
if you merely wish to broadcast your innovation, then you may share the CAD files of your hardware, a BoM and HowTo instructions in a non editable format (e.g. STL for CAD files)
if you not only want to broadcast your innovation but also want to collaborate with the community, then you may share all those files in editable format.
But there are other things we can learn about these projects by observing these sharing behaviour. And that’s actually what I would like to discuss in this workshop.
The idea would be to address the following questions:
What is the minimal requirement for a project being called open source?
How can the openness of a project be assessed on a scale?
What are the intentions behind going open source?
What are the needs in terms of process support of the makers/communities?
The underlying idea is that the concept of “open source” is more complex than what we may think, I will tell you why during the workshop
Here is the time plan I suggest:
10:30 – 11:00 Teaser. I will give some background information about some concepts, who I am and why I am doing this workshop.
11:00 – 12:30 Hard work. For those who would like to come on board: we will develop together a questionnaire addressing questions like the above, which we will then ask to other participants/exhibitors of the OSCEDays.
12:30 – 16:00 Walk around. Workshop participants walk around at their pace and ask questions to other participants/exhibitors of the OSCEDays.
16:00 – 17:00 Wrap up. We meet again for a short wrap-up to gather and discuss the results
Expected outcomes are:
we get a better understanding of the not-that-simple topic of open source
we know what are the minimal requirements for being open source and we can evaluate the openness of a project on a scale
we had a nice time talking to interesting people !
If you are interested or if you have any question, please don’t hesitate to comment or to contact me!
thanks!