Standardisation of Open Source Hardware
CC Attribution 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Häuer, Martin
Compared to software, the open source approach is relatively new to most actors in the field of (mechanical) hardware. Plus Open Source Hardware faces some special issues. A yet missing definition of its "source code" is one of them (+ patent law, liability, engineers that do not know how to work with git, costly prototyping…). DIN SPEC 3105 will be/is the first official standard for Open Source Hardware and also the first official standard ever published under a free license (CC-BY-SA 4.0; that was a lot of lobby work ;) ). It defines the technology-specific "source" of Open Source Hardware and aims to build a bridge between research institutes, public authority, industry and the worldwide open source community. In this talk I won't explain why Open Source (Hardware) is great. I assume, you all know that (if not, still feel free to ask me in the Q&A part or after the talk). I'll describe what's the standard for, how it works and why its great _for_ Open Source Hardware.
 Okay, good afternoon everybody. Stabilization of open source hardware. As I described, as I wrote it in my description, I won't tell you about how great open source hardware is, because I assume you all know that. But for those new in the field, open source hardware is not about giving away machines for free, but it's about the question who owns technology. And as hardware or other technology is how we produce our daily production goods or living goods and also the base of circular economy, I assume that's a super important question at least for us. So we start with the term. And the term has been defined by some guys in the US by the open source hardware association that came out with the definition that opens this hardware. This hardware whose design is made publicly available so that anyone can study, modify, distribute, make and sell the design or hardware based on that design. So basically you upload the design files, blueprints and all these calculations and stuff like that, and then anyone can build machines with that. So this is followed by a lot of license terms. So what Osper did is defining what open in open source hardware means. While hardware is rather clear, it remains open what the source actually is. So it is not enough to just share a quick sketch of your machine. Nobody can work with that. So what should actually be shared under an open license so others are enabled to modify, redistribute and whatever your hardware. So it's also a question about the purpose of the source. What are people meant to do with it? And this purpose has been already defined by Osper, open source initiative, and they boil down to these four core points. So people should be able to study, modify, make and distribute the hardware. While we put that in an official standard, which is then the frame for the technical documentation of the hardware because that's what you share in the end. That's also the first official standard for open source anywhere. So in that standard, we also acknowledge that this technical documentation depends on the life cycle phases that you are trying to cover. So not only introducing the hardware to the world, but also to maintain and operate it and to recycle, refurbish and whatever. So you need more documentation. And we also include the point that the technical documentation depends on the technology embedded in the piece of hardware and also that is used to produce the piece of hardware. You will need a different technical documentation for a 3D printed cup of tea without a tea or when you want to share a machine that produces cheese and slices and packages it. So yeah, that's all nice, but why do we actually need a standard for that? Can't people just produce and document open source hardware? So first of all, the standard defines what you should share. And apparently that's a huge issue. There's very few projects out there which are very good documented, at least for mechanical open source hardware. So you're also, despite from enabling people to make use of your invention, you make technical documentation compatible and comparable to each other. So when we have two awesome machines documented well and you can actually make use of both technical documentations, you can combine both to a better machine if you like. And second point, you can actually find it. There's no use if you just publish a lot of open source modules around the web if no one can actually find them. Then you need to reinvent the reel every time again. So the standard defines a common set of metadata so others can actually find your hardware. And as it's an official standard, we can put a trustee and community-based certificate on that. And this is meant to build a bridge between community industry and research institutes. As apparently industry and science needs paper and certificates. And by that process, it doesn't really matter who comes up with the invention first and who uses it in the end. So all can effectively work together. The certification process has also been defined by the standard. Here's how it works. So you start with the documentation release, then you make an application, and then people can peer review your technical documentation just as in science. And when the peer reviews state that this is complete and readable for others in the field, then you will have the certificate, which may look like that. And as the certificate is based on peer reviews, it's updatable and challengeable. So it's not a certificate just for your lifetime. Whenever someone else comes up with a negative peer review and they exceed the positive ones, then it aspires. And this process is moderated by a certification body who can just be anyone who is capable to organize a repository which keeps all these documents open and transparent. So that's how it works in practice. That's the context of the documents, the technical documentation is in the middle. Both standards define how it is made and how it is certified. And there's a third document that I didn't mention yet. There's a guideline that helps you to make this technical documentation in the end. It also helps you in other points like legal issues around open source hardware, patent law issues, and a lot of stuff like that. And on the other side, technical documentation is uploaded somewhere. So people usually upload it on GitHub, Thingiverse, Viki, Fub, whatever they're. Then in the English-speaking area, we have over 80 different platforms. And we developed a search engine that calls these platforms plus Google, plus YouTube, and then you can actually find what's out there. And the aim is to make it filterable by the certificate. So when you search something, you can filter the results for what is actual real open source hardware and what is more DIY stuff. The nice thing about this map, it's all open source, even the standard, which was a lot of lobby work. But you can participate in the standard and give feedback and then doing pull requests and other stuff. And then the National Study-Dissation Institute in Germany needs to look at it and make you that info for the next version of this standard. That was maybe a bit fast, but I wanted to keep it as rough as possible as it's a complex field. And usually, it's better to have a larger Q&A part about that. Feel free to ask me any questions about that, especially the uncomfortable ones are like those. And then we can dig into the details. Thank you. My question is regarding the repository. Is it kind of a product lifecycle management system or is it basically Git where you upload a bunch of, like you have a folder and you upload your CAD files, your calculations, everything, or is it something where you can dynamically pull out the data and say, I have an assembly, I have a bunch of standard parts which are coming from a shared library and you can all mix it up together? This repository is not meant to store the actual documentation, but just all the documents involved in the certification process. How people organize the technical documentation if they refer to other standardized parts is yet their issue. But as they say, that would make a lot more sense if we keep this hardware modular. So if there's a repository of standardized modules and people can look at it and yeah. So there's currently no platform that is capable of like resembling an open source product lifecycle management. I mean, I mean, there is one in progress. Viki Factory is trying to do that. But it's yet a research project. So it's not yet usable. Okay. Thank you. Hello, many thanks for the talk. First of all, it's very interesting that you really got it, that Dean makes something really open source even the specification. So congrats for this, especially. The other question, the other thing I would like to ask is in the open source software, you have tons of different license types. And this is only one license type. So for example, in you have GPL or you have BSD or whatever you think of in open source software, what's the license type when you are talking about open source hardware here? So for open source hardware, there's not so that also be licenses out there yet. There are three major ones, which is XAM, OHL, the most common one and the best maintained, the TAPR license and the solder pad. And they basically split up into with copy left mechanism or without. And that's it yet. So it's a free field. But Oshba is pretty open to that. So they only define the license terms. One can come up with a new license, which is conformative to that. Thanks. Hello. I have a question about this slide here. The certification body, who is this? This can be anyone. So it could be you if you're capable to hold such a repository. I mean, the standard defines how the certification body needs to be organized, what he needs to do. But in the end, yeah, anyone can do that. You just need to state when you give out the certificate who you are, so who issued that certificate and then, yeah, people can trust you or not. And there's also a specification for that? Yeah, we have two documents here. So I didn't mention that particularly. The standard splits up into the definition for the technical documentation and into the definition for the certification procedure. So here it's described how this procedure works and the certification body has clear roles and tasks to ensure that it's working. But again, anyone can just declare he's working in compliance of that standard. And that's actually how certification works in industry, too. You can be an institute, someone is reviewing you and says, okay, you're compliant to that standard. The difference here is that we don't have a power concentration here. So whenever the certification body becomes corrupt, so for example, my organization, I'm open source of college in Germany, wants to found such a certification body. Yet, there's no money involved. So it's unlikely that we have become corrupt in some sense. But when money becomes a thing, there is a risk for that. But as other documentation and the whole process is open, people can just fork us. So when they find out that we accept peer reviews from your friends, for example, that you call a few colleagues and then you say this is open source, and yeah, whatever. So we have some corruption happening there. And then you can just clone the whole thing and open your own certification body. Thanks for the talk. I was wondering about the specifications on how to share your product data, your technical documentation. So for example, how is one supposed to share 3D data? Are there specific file formats? Or yeah, so essentially I think that the open source world is pretty lacking in that regard, for example. And I wonder if there's some direction given there. There is. Basically regarding CAD files, we are not yet ready to only use FreeCAD or OpenSCAD, for example. So these programs are not ready for industrial use. So what we say in the standard is you need to share the original file format. But you also need to make the information available in a way that people can look into this information without any licenses. So you have your CAD file, and maybe people can look into the CAD file. But you should share a drawing as a PDF or whatever, so then people can look into the geometry and tolerances on the other. So the actual information is publicly available. But the CAD model may be only available if you have a solid work license or stuff like that. We give recommendations, but we cannot enforce it yet, because for most companies that's just unrealistic. Yeah, if there's no more questions yet. Yeah, there is. Sorry, what happens if somebody uses the certificate, even though it is not applicable anymore because it's a challenge or something? That's a good question. Yeah, I got this. Ask a lot what's the actual use of the certificate. So we can talk a lot about how well you do this, can be for industry, but there's no one applying that. Who is applying that is science. In science, for research project, it's a problem that you will construct any kind of prototype to test something. And as it's financed in advance, you don't need a business model behind that. You can just build your prototype, but it's usually not documented. So it stays in the laboratory and nobody will ever know about that. And plus, people usually cannot reproduce your test results or all the data that you produce with this prototype or testing environment, because nobody knew, knows how you build the machine. But if there's a standard and if there's a certificate, it's clear what could be documented and could be part of your research project. So people can put this into the application for research project. It becomes part of it. They get money for the documentation and time for that. And so we have all this high-tech research stuff openly documented. And we also win a revenue stream, like money flow for this whole open source hardware field. That was the, that's the first application case. We are also working together with a bunch of media-sized enterprises which are interested in that. They are looking more for a label or something. But they can also apply for public money. And whenever you apply for public money, your results should be publicly available. So certificate again. It all works with paper. And it's a huge authority, as it's been. These three letters make a lot. Thanks for your presentation. I'm Drew from, I'm one of the board members of the Open Source Pro Association. I was told about you from the Libre Solar a few days ago. Over here. Yes. And Matthias is also here. He's also one of the board members. So I think this is really exciting what you're doing. And I'd like to talk more about how, I wasn't familiar with DIN before this, but there's other standards organizations like ANSI and ISO in the US. And I'm thinking maybe this would be applicable to those things as well potentially. Have you looked at other countries, how this process could work there? Yes. There haven't been so open yet for that. The Austrian National Studyization Institute was kind of interested, but they didn't support us so well. And DIN has much more authority in the international sector. So this DIN spec is directly transformable into international standard, but it's under CC by SA. So whoever wants to publish this standard could be ANSI, could be whoever ISO say they need to publish it under CC by SA. So something like ISO is similar to DIN then in terms of a standards body is the ISO is that kind of similar to what DIN does? Yes, it's actually the same building. So inside the DIN building you have the first offices, the National Studyization and if you walk down the corridor there's the international sector. So just pass on the paper. Thank you. Any other questions? Well, what I could do meanwhile is showing you the open hardware observatory which I mentioned. So... Should I ask my question now or? Sure, you can. If not, I ask a question. Already in industry documentation is quite a problem because people are generally too lazy to do it. Do you think that in open source hardware we'll find acceptance in a lot of cases? Depends what you want to do. In the hardware sector support is a huge problem. So a few weeks ago I read an article about the garden robot and that was a relatively small company that wanted to provide ten years support for their products but coming out with a new version of their product every year. So that becomes a huge cost for this company and they couldn't... It could simply not provide such a load of work for the support. But what they did in the end was open sourcing the firmware in some parts of the design so the community can take care of that. So people have the effective ability to maintain their product and also to modify it and ask for help without costing this anything, the company. So some are starting with that. Another example is sort of motors. I don't know if you've heard of them, they're developing an electric car in Munich and they want this car to be fully maintainable by anyone. So they want to also develop an instruction how to maintain this car. They could do that themselves and invest a lot of money in the actual writing of the manual. But they could also just write the first part and let the rest for the community. So the people that repair the car write the manual themselves. By that they get a unique thing out there in the market. There's no car that you can maintain by yourself in all the details, at least in the electric sector and they also get free feedback. So they see that piece that always breaks when they do this and that or it's hard to repair so all these development cycles that cost a lot of money are free then, you're outsourcing things. So I assume that there will be few companies that will open source just everything but a few parts of it, I guess yes. And five years ago that wasn't some kind of impossible thing to pitch to companies to open source your development. But right now I don't know what changed but everyone I'm talking to is like, oh let's make a pilot about that, how can I collaborate with you. So there's a mind shift and I didn't question that yet so deeply as I didn't want these people to change their mind. I'm for Dean because what we're doing is undermining Dean's business model, their core business model and I don't know if all of them understood that but they're super motivated in that. They're actually looking for an open source software project with standardization motivations that they could support. So if there's any out there come to me and I can link you but I'm talking too much. Any more questions? What if not? We could, I could show you all of them. That's this. So that's the web page. You could just type in any kind of technology, any bus word out there, anything you want to do. Take wind turbine and then it shows you what's out there. And then you click on it and then you come to the actual design files. So there's no need to invent anything from scratch. For almost all technologies there's always some dude out there who did it and made at least a video about that. You are, there's my time up yet? Okay. So yeah, thanks for listening.
 Okay, good afternoon everybody.  Stabilization of open source hardware.  As I described, as I wrote it in my description, I won't tell you about how great open source  hardware is, because I assume you all know that.  But for those new in the field, open source hardware is not about giving away machines  for free, but it's about the question who owns technology.  And as hardware or other technology is how we produce our daily production goods or living  goods and also the base of circular economy, I assume that's a super important question  at least for us.  So we start with the term.  And the term has been defined by some guys in the US by the open source hardware association  that came out with the definition that opens this hardware.  This hardware whose design is made publicly available so that anyone can study, modify,  distribute, make and sell the design or hardware based on that design.  So basically you upload the design files, blueprints and all these calculations and stuff  like that, and then anyone can build machines with that.  So this is followed by a lot of license terms.  So what Osper did is defining what open in open source hardware means.  While hardware is rather clear, it remains open what the source actually is.  So it is not enough to just share a quick sketch of your machine.  Nobody can work with that.  So what should actually be shared under an open license so others are enabled to modify,  redistribute and whatever your hardware.  So it's also a question about the purpose of the source.  What are people meant to do with it?  And this purpose has been already defined by Osper, open source initiative, and they  boil down to these four core points.  So people should be able to study, modify, make and distribute the hardware.  While we put that in an official standard, which is then the frame for the technical  documentation of the hardware because that's what you share in the end.  That's also the first official standard for open source anywhere.  So in that standard, we also acknowledge that this technical documentation depends on the  life cycle phases that you are trying to cover.  So not only introducing the hardware to the world, but also to maintain and operate it  and to recycle, refurbish and whatever.  So you need more documentation.  And we also include the point that the technical documentation depends on the technology embedded  in the piece of hardware and also that is used to produce the piece of hardware.  You will need a different technical documentation for a 3D printed cup of tea without a tea  or when you want to share a machine that produces cheese and slices and packages it.  So yeah, that's all nice, but why do we actually need a standard for that?  Can't people just produce and document open source hardware?  So first of all, the standard defines what you should share.  And apparently that's a huge issue.  There's very few projects out there which are very good documented, at least for mechanical  open source hardware.  So you're also, despite from enabling people to make use of your invention, you make technical  documentation compatible and comparable to each other.  So when we have two awesome machines documented well and you can actually make use of both  technical documentations, you can combine both to a better machine if you like.  And second point, you can actually find it.  There's no use if you just publish a lot of open source modules around the web if no one  can actually find them.  Then you need to reinvent the reel every time again.  So the standard defines a common set of metadata so others can actually find your hardware.  And as it's an official standard, we can put a trustee and community-based certificate  on that.  And this is meant to build a bridge between community industry and research institutes.  As apparently industry and science needs paper and certificates.  And by that process, it doesn't really matter who comes up with the invention first and  who uses it in the end.  So all can effectively work together.  The certification process has also been defined by the standard.  Here's how it works.  So you start with the documentation release, then you make an application, and then people  can peer review your technical documentation just as in science.  And when the peer reviews state that this is complete and readable for others in the  field, then you will have the certificate, which may look like that.  And as the certificate is based on peer reviews, it's updatable and challengeable.  So it's not a certificate just for your lifetime.  Whenever someone else comes up with a negative peer review and they exceed the positive ones,  then it aspires.  And this process is moderated by a certification body who can just be anyone who is capable  to organize a repository which keeps all these documents open and transparent.  So that's how it works in practice.  That's the context of the documents, the technical documentation is in the middle.  Both standards define how it is made and how it is certified.  And there's a third document that I didn't mention yet.  There's a guideline that helps you to make this technical documentation in the end.  It also helps you in other points like legal issues around open source hardware, patent  law issues, and a lot of stuff like that.  And on the other side, technical documentation is uploaded somewhere.  So people usually upload it on GitHub, Thingiverse, Viki, Fub, whatever they're.  Then in the English-speaking area, we have over 80 different platforms.  And we developed a search engine that calls these platforms plus Google, plus YouTube,  and then you can actually find what's out there.  And the aim is to make it filterable by the certificate.  So when you search something, you can filter the results for what is actual real open source  hardware and what is more DIY stuff.  The nice thing about this map, it's all open source, even the standard, which was a lot  of lobby work.  But you can participate in the standard and give feedback and then doing pull requests  and other stuff.  And then the National Study-Dissation Institute in Germany needs to look at it and make you  that info for the next version of this standard.  That was maybe a bit fast, but I wanted to keep it as rough as possible as it's a complex  field.  And usually, it's better to have a larger Q&A part about that.  Feel free to ask me any questions about that, especially the uncomfortable ones are like  those.  And then we can dig into the details.  Thank you.  My question is regarding the repository.  Is it kind of a product lifecycle management system or is it basically Git where you upload  a bunch of, like you have a folder and you upload your CAD files, your calculations, everything,  or is it something where you can dynamically pull out the data and say, I have an assembly,  I have a bunch of standard parts which are coming from a shared library and you can all  mix it up together?  This repository is not meant to store the actual documentation, but just all the documents  involved in the certification process.  How people organize the technical documentation if they refer to other standardized parts  is yet their issue.  But as they say, that would make a lot more sense if we keep this hardware modular.  So if there's a repository of standardized modules and people can look at it and yeah.  So there's currently no platform that is capable of like resembling an open source product  lifecycle management.  I mean, I mean, there is one in progress.  Viki Factory is trying to do that.  But it's yet a research project.  So it's not yet usable.  Okay.  Thank you.  Hello, many thanks for the talk.  First of all, it's very interesting that you really got it, that Dean makes something  really open source even the specification.  So congrats for this, especially.  The other question, the other thing I would like to ask is in the open source software,  you have tons of different license types.  And this is only one license type.  So for example, in you have GPL or you have BSD or whatever you think of in open source  software, what's the license type when you are talking about open source hardware here?  So for open source hardware, there's not so that also be licenses out there yet.  There are three major ones, which is XAM, OHL, the most common one and the best maintained,  the TAPR license and the solder pad.  And they basically split up into with copy left mechanism or without.  And that's it yet.  So it's a free field.  But Oshba is pretty open to that.  So they only define the license terms.  One can come up with a new license, which is conformative to that.  Thanks.  Hello.  I have a question about this slide here.  The certification body, who is this?  This can be anyone.  So it could be you if you're capable to hold such a repository.  I mean, the standard defines how the certification body needs to be organized, what he needs  to do.  But in the end, yeah, anyone can do that.  You just need to state when you give out the certificate who you are, so who issued that  certificate and then, yeah, people can trust you or not.  And there's also a specification for that?  Yeah, we have two documents here.  So I didn't mention that particularly.  The standard splits up into the definition for the technical documentation and into the  definition for the certification procedure.  So here it's described how this procedure works and the certification body has clear  roles and tasks to ensure that it's working.  But again, anyone can just declare he's working in compliance of that standard.  And that's actually how certification works in industry, too.  You can be an institute, someone is reviewing you and says, okay, you're compliant to that  standard.  The difference here is that we don't have a power concentration here.  So whenever the certification body becomes corrupt, so for example, my organization,  I'm open source of college in Germany, wants to found such a certification body.  Yet, there's no money involved.  So it's unlikely that we have become corrupt in some sense.  But when money becomes a thing, there is a risk for that.  But as other documentation and the whole process is open, people can just fork us.  So when they find out that we accept peer reviews from your friends, for example, that  you call a few colleagues and then you say this is open source, and yeah, whatever.  So we have some corruption happening there.  And then you can just clone the whole thing and open your own certification body.  Thanks for the talk.  I was wondering about the specifications on how to share your product data, your technical  documentation.  So for example, how is one supposed to share 3D data?  Are there specific file formats?  Or yeah, so essentially I think that the open source world is pretty lacking in that regard,  for example.  And I wonder if there's some direction given there.  There is.  Basically regarding CAD files, we are not yet ready to only use FreeCAD or OpenSCAD,  for example.  So these programs are not ready for industrial use.  So what we say in the standard is you need to share the original file format.  But you also need to make the information available in a way that people can look into  this information without any licenses.  So you have your CAD file, and maybe people can look into the CAD file.  But you should share a drawing as a PDF or whatever, so then people can look into the  geometry and tolerances on the other.  So the actual information is publicly available.  But the CAD model may be only available if you have a solid work license or stuff like  that.  We give recommendations, but we cannot enforce it yet, because for most companies that's  just unrealistic.  Yeah, if there's no more questions yet.  Yeah, there is.  Sorry, what happens if somebody uses the certificate, even though it is not applicable  anymore because it's a challenge or something?  That's a good question.  Yeah, I got this.  Ask a lot what's the actual use of the certificate.  So we can talk a lot about how well you do this, can be for industry, but there's no  one applying that.  Who is applying that is science.  In science, for research project, it's a problem that you will construct any kind of prototype  to test something.  And as it's financed in advance, you don't need a business model behind that.  You can just build your prototype, but it's usually not documented.  So it stays in the laboratory and nobody will ever know about that.  And plus, people usually cannot reproduce your test results or all the data that you  produce with this prototype or testing environment, because nobody knew, knows how you build the  machine.  But if there's a standard and if there's a certificate, it's clear what could be documented  and could be part of your research project.  So people can put this into the application for research project.  It becomes part of it.  They get money for the documentation and time for that.  And so we have all this high-tech research stuff openly documented.  And we also win a revenue stream, like money flow for this whole open source hardware field.  That was the, that's the first application case.  We are also working together with a bunch of media-sized enterprises which are interested  in that.  They are looking more for a label or something.  But they can also apply for public money.  And whenever you apply for public money, your results should be publicly available.  So certificate again.  It all works with paper.  And it's a huge authority, as it's been.  These three letters make a lot.  Thanks for your presentation.  I'm Drew from, I'm one of the board members of the Open Source Pro Association.  I was told about you from the Libre Solar a few days ago.  Over here.  Yes.  And Matthias is also here.  He's also one of the board members.  So I think this is really exciting what you're doing.  And I'd like to talk more about how, I wasn't familiar with DIN before this, but there's  other standards organizations like ANSI and ISO in the US.  And I'm thinking maybe this would be applicable to those things as well potentially.  Have you looked at other countries, how this process could work there?  Yes.  There haven't been so open yet for that.  The Austrian National Studyization Institute was kind of interested, but they didn't support  us so well.  And DIN has much more authority in the international sector.  So this DIN spec is directly transformable into international standard, but it's under  CC by SA.  So whoever wants to publish this standard could be ANSI, could be whoever ISO say they  need to publish it under CC by SA.  So something like ISO is similar to DIN then in terms of a standards body is the ISO is  that kind of similar to what DIN does?  Yes, it's actually the same building.  So inside the DIN building you have the first offices, the National Studyization and if  you walk down the corridor there's the international sector.  So just pass on the paper.  Thank you.  Any other questions?  Well, what I could do meanwhile is showing you the open hardware observatory which I  mentioned.  So...  Should I ask my question now or?  Sure, you can.  If not, I ask a question.  Already in industry documentation is quite a problem because people are generally too  lazy to do it.  Do you think that in open source hardware we'll find acceptance in a lot of cases?  Depends what you want to do.  In the hardware sector support is a huge problem.  So a few weeks ago I read an article about the garden robot and that was a relatively  small company that wanted to provide ten years support for their products but coming out  with a new version of their product every year.  So that becomes a huge cost for this company and they couldn't...  It could simply not provide such a load of work for the support.  But what they did in the end was open sourcing the firmware in some parts of the design  so the community can take care of that.  So people have the effective ability to maintain their product and also to modify it and ask  for help without costing this anything, the company.  So some are starting with that.  Another example is sort of motors.  I don't know if you've heard of them, they're developing an electric car in Munich and they  want this car to be fully maintainable by anyone.  So they want to also develop an instruction how to maintain this car.  They could do that themselves and invest a lot of money in the actual writing of the  manual.  But they could also just write the first part and let the rest for the community.  So the people that repair the car write the manual themselves.  By that they get a unique thing out there in the market.  There's no car that you can maintain by yourself in all the details, at least in the electric  sector and they also get free feedback.  So they see that piece that always breaks when they do this and that or it's hard to  repair so all these development cycles that cost a lot of money are free then, you're  outsourcing things.  So I assume that there will be few companies that will open source just everything but a  few parts of it, I guess yes.  And five years ago that wasn't some kind of impossible thing to pitch to companies to  open source your development.  But right now I don't know what changed but everyone I'm talking to is like, oh let's  make a pilot about that, how can I collaborate with you.  So there's a mind shift and I didn't question that yet so deeply as I didn't want these  people to change their mind.  I'm for Dean because what we're doing is undermining Dean's business model, their core business  model and I don't know if all of them understood that but they're super motivated in that.  They're actually looking for an open source software project with standardization motivations  that they could support.  So if there's any out there come to me and I can link you but I'm talking too much.  Any more questions?  What if not?  We could, I could show you all of them.  That's this.  So that's the web page.  You could just type in any kind of technology, any bus word out there, anything you want  to do.  Take wind turbine and then it shows you what's out there.  And then you click on it and then you come to the actual design files.  So there's no need to invent anything from scratch.  For almost all technologies there's always some dude out there who did it and made at  least a video about that.  You are, there's my time up yet?  Okay.  So yeah, thanks for listening.
36c3-oio-192-eng-Open_Source_Hardware_in_industry_-_meet_DIN_SPEC_3105_hd_0_131.png 36c3-oio-192-eng-Open_Source_Hardware_in_industry_-_meet_DIN_SPEC_3105_hd_132_659.png 36c3-oio-192-eng-Open_Source_Hardware_in_industry_-_meet_DIN_SPEC_3105_hd_660_3899.png 36c3-oio-192-eng-Open_Source_Hardware_in_industry_-_meet_DIN_SPEC_3105_hd_3900_8135.png 36c3-oio-192-eng-Open_Source_Hardware_in_industry_-_meet_DIN_SPEC_3105_hd_8136_8207.png 36c3-oio-192-eng-Open_Source_Hardware_in_industry_-_meet_DIN_SPEC_3105_hd_8208_8291.png 36c3-oio-192-eng-Open_Source_Hardware_in_industry_-_meet_DIN_SPEC_3105_hd_8292_9239.png 36c3-oio-192-eng-Open_Source_Hardware_in_industry_-_meet_DIN_SPEC_3105_hd_9240_10547.png 36c3-oio-192-eng-Open_Source_Hardware_in_industry_-_meet_DIN_SPEC_3105_hd_10548_11963.png 36c3-oio-192-eng-Open_Source_Hardware_in_industry_-_meet_DIN_SPEC_3105_hd_11964_12431.png 36c3-oio-192-eng-Open_Source_Hardware_in_industry_-_meet_DIN_SPEC_3105_hd_12432_13751.png 36c3-oio-192-eng-Open_Source_Hardware_in_industry_-_meet_DIN_SPEC_3105_hd_13752_14807.png 36c3-oio-192-eng-Open_Source_Hardware_in_industry_-_meet_DIN_SPEC_3105_hd_14808_17207.png 36c3-oio-192-eng-Open_Source_Hardware_in_industry_-_meet_DIN_SPEC_3105_hd_17208_18479.png 36c3-oio-192-eng-Open_Source_Hardware_in_industry_-_meet_DIN_SPEC_3105_hd_18480_20579.png 36c3-oio-192-eng-Open_Source_Hardware_in_industry_-_meet_DIN_SPEC_3105_hd_20580_22067.png 36c3-oio-192-eng-Open_Source_Hardware_in_industry_-_meet_DIN_SPEC_3105_hd_22068_22367.png 36c3-oio-192-eng-Open_Source_Hardware_in_industry_-_meet_DIN_SPEC_3105_hd_22368_22427.png 36c3-oio-192-eng-Open_Source_Hardware_in_industry_-_meet_DIN_SPEC_3105_hd_22428_22487.png 36c3-oio-192-eng-Open_Source_Hardware_in_industry_-_meet_DIN_SPEC_3105_hd_22488_22535.png 36c3-oio-192-eng-Open_Source_Hardware_in_industry_-_meet_DIN_SPEC_3105_hd_22536_22583.png 36c3-oio-192-eng-Open_Source_Hardware_in_industry_-_meet_DIN_SPEC_3105_hd_22584_22643.png 36c3-oio-192-eng-Open_Source_Hardware_in_industry_-_meet_DIN_SPEC_3105_hd_22644_23003.png 36c3-oio-192-eng-Open_Source_Hardware_in_industry_-_meet_DIN_SPEC_3105_hd_23004_23351.png 36c3-oio-192-eng-Open_Source_Hardware_in_industry_-_meet_DIN_SPEC_3105_hd_23352_23639.png 36c3-oio-192-eng-Open_Source_Hardware_in_industry_-_meet_DIN_SPEC_3105_hd_23640_23891.png 36c3-oio-192-eng-Open_Source_Hardware_in_industry_-_meet_DIN_SPEC_3105_hd_23892_23939.png 36c3-oio-192-eng-Open_Source_Hardware_in_industry_-_meet_DIN_SPEC_3105_hd_23940_36467.png 36c3-oio-192-eng-Open_Source_Hardware_in_industry_-_meet_DIN_SPEC_3105_hd_36468_36803.png 36c3-oio-192-eng-Open_Source_Hardware_in_industry_-_meet_DIN_SPEC_3105_hd_36804_36851.png 36c3-oio-192-eng-Open_Source_Hardware_in_industry_-_meet_DIN_SPEC_3105_hd_36852_36899.png 36c3-oio-192-eng-Open_Source_Hardware_in_industry_-_meet_DIN_SPEC_3105_hd_36900_37559.png 36c3-oio-192-eng-Open_Source_Hardware_in_industry_-_meet_DIN_SPEC_3105_hd_37560_37727.png 36c3-oio-192-eng-Open_Source_Hardware_in_industry_-_meet_DIN_SPEC_3105_hd_37728_37798.png