 Okay, I'm going to get started because I know we're getting close to lunch now. I'm not going to try and compete with the food here in downtown Portland. So my name is Stefano. My talk is going to be about open source hardware. I want to start off right away by saying that I'm not going to be talking about a lot of stuff that has to do with Intel, but I do work for Intel. So I work for the Intel Open Source Technology Center, and I work contributing to the Yachto project. My talk is actually going to be about some stuff that's sort of been brewing in my head for the past few years. And I worked for a company before Intel over in Lake Oswego, so right around the corner on the other side of the mountain. And we did embedded software and hardware. So we did display modules that went on medical and industrial, medical industrial stuff. And there was a lot of stuff that I learned while I was there that I really started thinking more about open source hardware because we weren't making open source hardware. The hardware we were making was proprietary, but it got me thinking about it and what we can learn from it and how we can take advantage of it. So I'll just start off by just a quick definition of open source hardware because it's, I know most of you probably know what it is, but it can be sort of nebulous when you try and define it. So the definition I'm using is from Oshawa. Oshawa is the open source hardware association. They were founded in 2012, I believe, in 2012. And so the idea behind defining open source software is that you can't patent a scientific fact. You can't put a label on something and say, this is something I'm going to try to sell if it's a scientific fact. So when you try and create open source software and you try to define it, you run into this issue. You can't make an open source chair, four cylinders and a plane make a chair and you're not going to patent that idea. But the idea behind open source software is more the concept behind the intention. So if your intent is to allow somebody else to reproduce this material and to actually go into production with this hardware, then you essentially qualify as open source hardware. Now Oshawa is doing a lot of stuff to make this much more accessible. They're developing a community around this idea, which is really important. And we're going to get back to that idea of community quite a bit. Because I know that we all understand community and open source software world, but open source hardware is just the same when it comes to community. Another thing about this talk, I'm not going to be trying to convince you that you need to open source your hardware because I know that would fall on deaf ears. That's not my point. In fact, my point isn't even to, I don't want you to love open source hardware. I don't even want you to get excited about it. I just want you to be a part of it and to see where the advantage is. And if you already happen to use open source software, I want to give you tools to go back to your leadership and to your boss and to show them why you need to use more open source hardware and more techniques that are used in the open source hardware world. So let's start off by giving you a couple of examples. And I know a couple of these will look familiar. There's one up in the top right corner that I'm sure a few of you have seen before, and there's a couple of people at the conference you could talk to about the BeagleBone. The other one is the Minnowboard that Intel is offering. It's interesting. So I worked with Reach on embedded stuff, and we did all arm stuff. And when I moved to Intel, one of my first things was to grab the Minnowboard, start playing around, and see what it could do. And one of the things that struck me that hadn't really struck me before was how your development model changes and embedded when you go from cross compilation to no cross compilation. It really is a big win. And I'm not going to try and play the game of let's talk about what the benefits of X86 and ARM are. It's not my point. My point is more is here's an open source board being put out by Intel that uses the X86 platform, and it's open source from start to finish. The software is open source, the hardware is open source. The latest version, I believe, is going to be Class B certified. So I know a lot of you will know that's a big win. So here's a piece of software that you can go get the Gerber files for. You can get the schematics for. And it's completely open to do what you will with it. And I'm also not going to get into licensing. I know licensing is a big thing, but I'm not a lawyer. And I can tell you that there are definitely licenses out there that are more permissive than others, much like software. But I'm not going to get into that. So then the last one I want to talk about a little bit is the Olimax. Olimax is the one in the bottom center. And I know a lot of you probably haven't heard of Olimax. In fact, could you raise your hand if you have heard of Olimax? Oh, nice. That's a pretty good crowd. Awesome. Yeah, I always think of Olimax as creating some of the best open source software from a company that you probably haven't heard of yet. So I think it's Svetan Usanov, which I hope I didn't murder his name, is the head of Olimax. And they're in Bulgaria. And he's actually been running that company for 25 years. So he's been doing this for a long time. And one of the reasons it's up there is because I wanted to talk about his process. He gave a talk at a Hackaday conference recently where he described his process as open source from development to production. And that's an interesting concept because, like I said about open source hardware being all about the community, at the end of the day, if you're open source from your development all the way to your production, then the open source community has a say from when you start developing all the way to when you finish it. And if you use what you already know about open source communities, that means that you gain the knowledge that all those people have right from the get-go. So when you're designing your board and you say, oh, I think these are my requirements, well, see what the community has to say about that. Because that's your guess at what your requirements are. But then watch what the community has to say as you move forward and see if there's maybe a requirements you hadn't thought of or something you could have pulled out, some I.O. you could have pulled out that you wouldn't have thought of. So Olimax is a great company. Check them out. There's a few other companies that I'm sure a lot of you have heard about. So I'm not telling you anything new here, but I have to give props to those who've done a great job. There's also, if you go into the big room in the middle, there's 96 boards. They're doing a great job too. So a lot of people are starting to realize that we all implement SPI. We all implement I2C. Like, we can share these things. These aren't the core competencies of our companies. So there's a lot of value to be gained in the open source community. And if anyone ever says, well, open hardware, how do you make a profit doing that? I would tell them to go talk to the folks at SparkFun. I'm sure they'll have something to tell you about how to make a profit using open source hardware. But again, this all comes back to the communities. And I think this is the big question that I want to be able to answer for you, is I know about open source hardware. I've been using open source hardware. How does it help me? Who cares? What do I do with this information? Well, so I've been at Intel now for a year. And one of the things that they say quite a bit at all the company meetings is they want to concentrate on innovation. Innovation is a huge thing. It doesn't matter if you're a giant corporation of 100,000 people or you're a tiny little startup. They'll always talk about innovation. And the key to innovation is creativity. Now, I realize that creativity can be really hard when you're sitting in the center of four beige fabric walls. But regardless of what your desk space looks like or where you work, open source hardware opens the door to ideas that are new. And anytime you can do that, you're feeding creativity. So by ignoring open source hardware, you're going to ignore all that possibility for creativity. And it also gives you the opportunity to try things and fail. And really, by trying things and failing, we learn that way. That's how we all get started. Anyone in here who programs, and I'm sure everyone would raise their hand if I said that, everyone started by failing. You write some code and it doesn't compile. But that's how you learn. And it's the same with hardware. So what I'd like us to do is try to think more like makers. And I know that, especially anywhere from large corporations to even standard businesses, we'll sort of poo-poo the maker movement. And to be like, well, you have to, in production, you have to have things that are available for 10 years. And there's a strict standard that you need to follow to do all this stuff. But that maker mentality, that hacker ideal, that's the thing that breeds creativity. So while, yes, some of this stuff should not be put into production that you see on the maker websites, at the same time, that core idea of how to be creative and change the way you think is what we're missing in business. So one of the things I like to say is hack your proof of concept. So when we sit down and say, all right, I'm gonna start this proof of concept for either a new product or maybe an addition to a product that already exists, what's the first thing you do? Because it shouldn't be document and have meetings and theorize and research. All these are good things. But the first thing you should do is hack something together. Because just like programming, hardware is the same. Once you hack something together, make some mistakes, you're gonna see things that you didn't see before. And I'm gonna, later in this talk, I'm gonna talk about ways that we can do that given the cultures that we work in. So whether it be big corporations or even medium and small sized companies, there's lots of ways you can do this. Another one, open source hardware is free as in freedom, as in speech, that sort of idea. There's tons of knowledge to be gained. I just mentioned research. The amount of research you can do on your own without taking advantage of somebody else's work, forget it. But take somebody else's work, what they've done, that they've open sourced and learn from that and you've just quadrupled the amount of knowledge you have, especially if the hardware is even related to what you're doing. Often we learn because other people show us the way to go and then we try soldering something to that thing and seeing what happens. And even if it blows up and you let the magic smoke out, it's still something that you learned. And the last one I had to use an acronym because I work for Intel, so always be creating. Part of that process is not thinking of the prototype stages ending. Don't think of your proof of concept as being just one thing. Make it be 10 things. And even if the customer didn't want one of those things, try it out and see how it works. So let's talk about a couple of people that I see doing this in the public sphere today. So open source lab is a book by Joshua Pierce. He's a professor at Michigan Tech. If you haven't gotten this book, I highly recommend you get it. Now, why am I talking about a book about research where I'm actually, raise your hand if you're in medical research right now. Okay, so we got one, whoo. So I worked at OHSU, Oregon Health and Science University right up in the hill, so I've done medical research, if you could call it that. But the idea I'm trying to get across here is applicable to all walks of life in the electronics and technology industry. He talks about how to take advantage of digital design sharing and specifically using things like arduinos and rep wraps. Now, and rep wraps are just three printers, if you haven't heard of that. So the idea here being take advantage of whatever's at your disposal to solve the problem that you need to solve. So one of the things I noticed when I was at the university hospital was that a lot of times the tools that I needed were needlessly expensive. So one of the examples I'm gonna use from this book is the Dremel Fuge. Partly because I love the name, because I have a Dremel on my desk. But here's an example of something with a very high perceived value, a centrifuge. A centrifuge must be expensive, right? That's gotta cost a million dollars, right? Maybe a couple hundred thousand. But the idea being that, yes, if you're working in a medical research facility, you might need that tool. But if you're working in a school, you might just want a centrifuge to show the students how that works. But you're not gonna wanna pay $300,000 for one. So the idea that this book brings out very well is sometimes the tools you'll need are right around the corner. You just need to find the right open source avenue to take. And in this case, the Dremel Fuge is awesome because basically all you have to do is 3D print this little piece and then go to Home Depot and buy a paint can. And for the cost of a Dremel, 100 bucks, take the cost of the paint can, you've got yourself a centrifuge. So solving problems in inative ways sometimes means using things that other people would never have thought of. So you have to dig through wherever you can to find these little tricks. So another great book, which some of you might know, is Building Open Source Hardware by Alicia Gibb. She's the executive director of Ashwa, the nonprofit that I mentioned at the beginning, and the CEO of Lunchbox Electronics. And she wrote this book, which is a great read for anyone who's interested in open source hardware. It sort of goes through the history and the design process, but it also touches on derivatives and that's something I wanted to talk about a little bit. I'm gonna preface by saying that in case you were confused, I'm not a lawyer. So please don't take anything I say in this or the remainder of the talk as legal advice, but derivatives are a very interesting topic in hardware just like they are in software, and I don't wanna get into a GPL talk either. So there are lots of permissive licenses out there that will let you take these Gerber files and these schematics and use them in your proprietary hardware. But even if they don't, the things that you can learn from that are still invaluable. So just because you can't copy and paste out of the Gerber doesn't mean you don't wanna look at that. You still wanna look at that and learn all you can and again, talk to your lawyer, because that's really important. She also talks about 3D printing. 3D printing I think is one of those things we forget about. So I work at Intel, but there is a 3D printer in a lab somewhere that I can go use. So if somewhere in my day I find myself going, oh, if I just had this part, don't think about the vendor, don't think about tenure availability. Think about going and making that part right now so you can try that thing. And they talk about this in the book. And they also talk about production manufacturing and stuff I'm not gonna get into here. But I think that's the idea that I wanna get across is that by using all the resources at your disposal, you'll become more creative. Another talk, I actually wanna just borrow from another talk here. This is the logo with the spanner on it is from a video series called Applied Science. Applied Science is by Ben Kroz now. And he gave a talk at the Hackaday conference that I'm gonna use some of the stuff he said because I think it bears repeating and it's extremely applicable here. So the first one is build first, ask questions later. A lot of times, especially when you're in that corporate mentality, you'll get into the habit of saying, well, I need to have four meetings with these four people, then I need to drop this kind of documentation which we may or may not use. Just build something and see how it works. Gather data. I think it was Arthur Conan Doyle who penned the words that you can't make a decision without data. It's useless. So go out there and build something and see what you get. The next is to prototype early and often. So the idea that there's only one prototype, I know from a corporate standpoint, from a manufacturing standpoint, yes, there's probably only gonna be one, maybe two or three prototypes because those are expensive to spend. But we're gonna get to cost a little bit later in how we can fix that problem. But the idea that there's only one prototype is something you need to get away from. There needs to be dozens of prototypes. And again, we're gonna get back to how we do that without spending thousands and thousands of dollars on prototypes. But one of the things I wanna think about too is getting out of that QEMU mindset. So I mean, my last job at Reach, we only cared about whether or not it worked at the board. Does it boot on the board and does it work on the board? And often we forget that. We get into this habit of saying, well, let's just make sure it runs in QEMU. Okay, it's good enough, let's go. That kind of mentality, I think, is necessary in some instances. But in a lot of instances, we're just not taking advantage of the ability that we have to build interesting things and try it out on hardware. So last thing, again, I'm gonna, or not the last, what's second to last? I'm gonna once again reiterate the fact that I'm not a lawyer, because I just put the word patents up there. And I think I could hear Intel's lawyers shattering. So Ben mentioned this in his talk and claims are sort of not what I'm talking about, not the claims of the patent, but rather the specs and the drawings. There's a lot of data that can be drawn out of that. There's a lot of information you can get just by looking at these things. Now, again, please go talk to your lawyers. I'm not a lawyer, but still interesting stuff that you can use. And then finally, purchasing off the shelf items. This gets back to what I was talking about when I was talking about cost. You wanna know at the end of the day what are my customer's requirements? What do I need to be able to do with this item? And you won't know your requirements until you get stuff in the customer's hands. And you should get as much stuff into the customer's hands as possible. So by using eBay or Alibaba or finding on Amazon or going to the dumpster attack, again, the lawyers are angry at me because I just said that. But whatever you gotta do, if you've gotta go find something on Craigslist, find something, glue it together, get it in the customer's hands, see if it's what they want to use. And that sort of gets me to my examples. So I'm gonna be drawing these examples from where I worked at Reach, my last company. And what I'm trying to do with these is give you an idea for the sort of problems that I solved that I saw. Oh, with that open source hardware, I wouldn't have been able to do this. This is really helpful. So the board I've got up there is the UDO. Actually, show of hands. How many people have used or know about UDO? Yeah, not very many. More people should know it. Go home and Google this, all of you. This is really amazing stuff. So these guys are in Italy and they're making this MX6, well, they make lots of stuff, but this MX6 board is the one I was using. It's very close to the board we were doing at Reach. The difference is this board has an Atmel processor, Atmel microcontroller on it. So this has got the MX6 SoC and an Atmel all on the same board and it's sort of made hacker friendly, maker friendly. So normally you would think, all right, what am I supposed to do with this thing? And that's the mindset I want to change. There's a million things you can do with this thing to try out things for your customers. So the example that I'm doing here is multi-touch. Multi-touch is one of those things. So our boards at Reach had capacitive and resistive displays and we used TS-Lib and we didn't do multi-touch. The idea of moving over to multi-touch is not a small endeavor. I mean, unless you're lucky, unless you just plug it all in right and it works and you're like, cool, multi-touch. And you all know that's not gonna happen. So getting that working on our board would have been tough, but there's a community around UDO and a really good one. And taking advantage of that community and their knowledge was invaluable because we had a customer who was coming to us saying, well, we like your product and we want multi-touch. So we wanted to know, okay, first off, is our product right for the customer and is that customer right for us? So in other words, is multi-touch right for us and are we right for the customer? And we answered that using UDO. So we just spun up a quick demo on the UDO. We threw a multi-touch image on there. I think it was just out of Yachto. But we threw an image on there that worked with multi-touch. We showed it to the customer. The customer loved it. But when it came down to the end of the day, the customer wasn't right for us. So we didn't go with that project, but we did like the multi-touch. So we decided, all right, let's put this on the back burner and we can come back to this community later and figure out how to implement multi-touch for our board. So the knowledge that we gained from that transaction was worth so much more than research. It was an actual customer opinion of, yes, I wanna buy this from you. So now we know this is a sellable thing and we know there are people that have got it working on the chip we're using. So it's win-win. The idea that I like to think of when I think of this example is that we're able to make quicker decisions. It would have taken us a while to get multi-touch working on our board and we probably would have been great with it. That would have been awesome. But we were able to do this much, much quicker. So the time savings was worth it. The next one, same board, this time, Android. How many people out here have done both Android and custom embedded Linux on a board? Anybody? Okay, so you guys know that is not a simple switch. You know through experience. Everybody else knows because they think about it in their head and they go, yeah, that doesn't sound like an easy switch. That's not an easy switch. That's, nobody would say to their client, sure, yeah, we run Linux that we built with Yachto and yeah, I'm sure we could do Android too. Like, no, no, no. So this customer wanted Android and again we wanted to know are we right for the customer? Is the customer right for us? So we went back to the Android forums. We found people that were running images, running Android. We got Android on the bar and we started working with the customer. Now this is interesting because my boss at the time hated the idea of Android. He was an old school embedded guy so Android was like the last thing in the world he ever wanted to put on a board. But as soon as you get a customer with enough units suddenly it's an interesting idea. So by being able to do a demo with these clients with Android running on the Udo we were able to see that not only were we not right for the customer as a company, we didn't want to be in the Android space. Now the reason why is because we would have had to have hired a headcount which means we would have had to go out and get the funding from a client to get that headcount to support Android because none of us were good enough with Android to be able to do it. So by using this as an example we learned that we didn't want to add that to our core competency and that took zero meetings, zero dev time. Our hardware people had to do exactly zero hours of work and we knew Android not for us. So I'm not saying don't use Android don't get our impression but we learned something really quickly and didn't have to spend any cycles on it. So when your boss says why should I use open source hardware or why should I let you use open source hardware to do proof of concept tell them well would you rather the hardware guys start spending cycles and they could try stuff out because I'm sure that'll sort of connect the dots for. So the last one, different board, same idea. This is the wand board and I don't know anything about its open source status that you do, you can go online and get the Gerber files and the schematics and all that lovely stuff. I don't know about the wand board. I do know you can get the schematics but I don't know about the rest. But that's okay because the point I'm trying to make here isn't about so much needing the Gerber files or anything like that. The idea here is between how do you debug something complicated without doing a whole lot of work? That just sounds like I'm trying to sell a snake oil now that I said it. But what we did was we mocked up we had a customer who was using our prototype we had already reached the prototype stage we'd spun a board and we were showing it to customers and we ran to an issue with the fi we were using a micro fi. All right, so anybody who's been in the situation where you got your prototype something's going wrong you're about to like break out the checkbook, right? We're gonna need hours of development work hours of hardware work this is gonna be hard. So what we did is we saw that, all right well you've got the wand board out there and the wand board is using the atheros fi and the you do is using the micro fi. So, well a fi is a fi why are they using different fies? So you start digging into those communities into the forums and you'll find other people with the you do are having the same problem. So with exactly zero hours of dev time exactly zero hours of hardware spinning or debugging I don't even know how you debug a fi. Can't imagine it's fun. But without doing any of that debugging we found a possible cause to our errors a possible cause to our bug. We swapped out the fies on our next prototype rev we used the atheros and it worked fine. So using this example this is the perfect example of how community is invaluable. Without those forums on the you do site saying yeah I'm trying this and I'm getting the same thing oh yeah here's the thing I did to fix it I just threw this in the kernel config and now it works fine and you know it works fine and that it's slower and seems buggy but I think it's okay. And we were like okay bye fi hello new fi. So that transition was so much easier because of that community. So not taking advantage of these communities just seems crazy to me. Go out there and try it. So this is sort of the point I'm trying to get across is that there is all of this information all of this knowledge out there and if you don't go out there to the wild with that knowledge you're just missing out. You're just not gonna have something that somebody else has. And if you think that the world acts like it does in the four beige cube walls it doesn't. Outside people will experiment with different things that you didn't think of soldering together. So if you think your problem is really unique and nobody else is doing this thing go check out the forums. Somebody out there is doing that crazy thing you're doing too. So I've talked a whole lot about the good parts of using open source hardware. Let me give you a couple of quick pitfalls that I ran into so that you guys don't make the same mistakes. The first one is confusing the customer. So it's always a great feeling when you get to open source something. So I wrote a program that interacted with our boards at reach and I realized one day this program interacts with our boards and customers all use it. I'm just gonna put this up on GitHub. Why not? Let's make it open source. I mean, right? It sounds like a great idea. I mean, we're all on the same page, right? This is a Linux convention. So I put it up there and I was like, all right, I feel good about myself. I'm like, hey, look, I'm an open source programmer. This is really cool. Took about three days and tech support was sitting next to my desk and saying, hey, so why is this on GitHub? And I said, well, because, right? I mean, nobody cares. This is just code that interacts with our board. Who else is gonna use this? This is cool. And he's like, no, no, no, no. Customers are going to GitHub and downloading the wrong version. So, okay, so open source, good. Not documenting bad. So definitely be careful when you open source stuff. It doesn't matter if it's your hardware or your software. Document, document, document. The community is the invaluable source behind the invaluable part of open source. So if you haven't thought about the fact that you're gonna develop a community, think about it, because it's really necessary. Your customer is gonna hit GitHub and they're gonna hit the branch that has four versions back on it and they're gonna try and put it on the latest board. The next one is losing set at the target. So a lot of times you can get sort of cut up in the maze that is the internet of the maker world. There is tons of information out there and tons of stuff. And you're gonna think, all right, well I'm gonna use this part and this part. I'm gonna develop a community around this idea. Oh, that'll be awesome. And next thing you know, your email is starting to get filled up by makers that have Gmail addresses and your core audience is 1,000 units a month. And this isn't to knock on communities. Like I said, the community is the important part, but be sure that you're ready for that. Be ready to support a community. So if you do wanna do something in the open source realm, develop that community around it because the community will come back to bite you if you're not ready for it. And the last one, I'm gonna reiterate this one more time so that nobody yells at me. As they say then, so I'll take five and go talk to legal. All the stuff I'm saying here is my experiences, just stuff that I've tried and it works really well. But I'm not a lawyer even remotely. My degree is in English and French literature. So if you take legal advice from me, keep that in mind. Okay, so I know lunch is already upon us. So let me just close this up really quick. The idea here is to always think open. All of us use open source software. Why not use open source hardware? I've just demonstrated some great benefits behind it. The idea that you can think like a maker. Use that to innovate. If your customer comes to you and needs a real time clock, don't build a real time clock. They're out there. Just go find one on eBay and glue it to your machine and try it and see if it works. Sometimes J.B. Weld is the best solution. Real time clocks are just a personal example because we did have a client that wanted that and we did kind of J.B. Weld it to our board. So the next one is be part of a community. Really quick, there was Olamex mentioned in their talk, this really great part of the community that sort of came into effect for him. So he does all his open source stuff right from the get-go. And right from the get-go, he was using 3.3 volts to feed his SD card. And he was doing that because that's what it says in the data sheets. And as we all know, the data sheets never lie. So definitely follow them. So he's feeding it with 3.3 volts and somebody in the community comes up and goes, hey, so I see you're doing that thing that we're all doing. Well, we found that actually there's a way to feed that with 3.3 volts and 1.8 volts and you get a lot more speed. And by a lot more, it was four times the speed. So if you think that this community might not have anything to do with you because your piece of hardware is proprietary, go read the forums. There might be some really valuable information in that community. And the final one is to, if there's one thing you take away from this, it's to hack first and gather data second. It just, like I said, JB welds something together and see if it makes any sense because all the meetings in the world can't give you the requirements you need. They'll give you the requirements you think you need. And then you'll go to the client to find out the 30 requirements you didn't have. So just cobble something together. So that's my talk. If you wanna yell at me in public, there's the at symbol thingy that you can use. If you wanna send me an email, there's that thing as well. And I'm happy to take any questions. And there's a microphone somewhere, but I'll just repeat your question. Go ahead. So the question was about the open source FPGA world. I do not. There are people at an FPGA booth over there that might know something. I'm actually studying FPGAs right now at PSU at the college here. So I'm really interested in that subject, but I didn't have time to research that from this. Does anyone here know? True. No, like, but it's all that FPGA though. Okay. There are four. Okay, and they're Lattice. Okay, so just to repeat, it's Lattice FPGAs and who is the person? Clifford Wolff. Clifford Wolff. The name is Wolff Sys. Yossys. Yeah. Okay, Clifford Wolff. That's probably easier to Google. Awesome. Anybody else? How's your chance? See, this or lunch? I know it's a tough decision. All right, everybody go to lunch.