 Hello. My name is Mark Himmelstein. I am the Chief Technology Officer for RISC-5 International, and I'm here today to talk about a new model for open-source contributors in an open-source project. So we're going to give you some basics. So you have some contacts for the rest of the slides, and then talk about open-source hardware versus open-source software, what a hardware runway and life cycle looks like, ISA design versus product design, what that looks like, how big is this thing we're talking about that we're facing, what we're doing to handle the challenge and to change that model and what we still need help with. So first, it's important to know what RISC-5 is. So I'm going to be talking about things in the context of RISC-5 and hardware contributors for open-source and RISC-5. So RISC-5 is a relatively new computer chip. It just had its 10th anniversary. It was born in Berkeley. It is meant to last 50 years. How did we do that? That really means that it's flexible, going all the way from embedded to HPC. How did they do that? Well, they broke things down into extensions. The base instruction set, addition, subtraction, multiply, divide, all that stuff was laid down. And then we allowed people to add extra extensions to do more complexity, like cryptographic instructions or vector instructions or bit manipulation instructions. And we have continued to grow the organization and grow the extensions that go on to this product. We also allow members to go ahead and create their own extensions for proprietary added value. But the base instruction set, unlike any other chip of this magnitude, is free. Also, it is becoming one of the largest open-source projects around. And you'll see that shortly. But it's a different thing. We're not, for the most part, writing code. We are writing code, but that goes upstream to existing projects. But mostly what we work on is the architecture. So a little bit about me and how I fit in and what my relationship is to the open-source world and to chips. So I was an early employee at MIPS. So I got to work on instruction sets. I was a software guy. So I worked in compilers and operating systems and bootloaders and things like that. And then later on in my career, I ran Solaris. So I ran a group of 2,500 people putting out Solaris. Everything from hardware to chips to Java to the operating system, libraries, et cetera. And so I had to coordinate that whole group and only 500 reported to me. So it's very much like running a community, except we all had kind of one big boss, right? And then I was a founder at a massively parallel, massively parallel flash-based computer clients for big data. And sold that off to EMC in 2015. So I've had systems experience. I've had software experience. I've had ISA experience. And I've also had the experience of herding cats and bringing people together. So that has worked very well. And then in the open-source world, I worked with the open-source community, got PKI in from Solaris early on, NFSE4 as just a list of some of the things that we worked on. So the first thing we'll talk about is the history of how open hardware showed up. And we kind of all know about Linux and there was GNU before that, and then Minux and then Linux. And we all kind of follow that history and understand that it evolved, but hardware, open hardware in particular evolved differently. So if we take a look at the different architectures that showed up, and this isn't all them, but this is a set of them that showed up in the open-source world, they all started as private closed-source architectures. IBM Power, SunSpark, MIPS, they all sort of began in the 80s. And then when you hit the 2000s and Linux started being popular, everybody said, oh, we better like go ahead and jump on this bandwagon. IBM already had a lot of success with Linux. So it went ahead and created this thing called power.org. It's still lived inside of IBM, but it was a consortium of people to go ahead and work on it. Spark did the same thing, it's kind of inside of Sun and now Oracle, but it made things as available as Java, for example. And then over time, things moved forward. Risk five started again in really around 2010 and around the same time a little bit later, open power became an open-source separate org. It's now lives on our Linux foundation. And then risk five moved into an organization, originally called risk five foundation, now called risk five international. And then MIPS of late turned into open-source as well. And that's kind of just the most recent of these things. So what does this mean? Well, they all started as proprietary and all those companies, well, the companies that build systems still build proprietary systems based on that technology. And while the ISA is certainly available for the public to use, a bunch of the stuff around the system that's needed to make that system work is still fairly proprietary. And so you have to, if you're a user of open power, you have to take it and figure out what your buses are gonna be, what your cash is are gonna be and so on and so forth and make all that decision process and make that successful. The other thing to note is the companies that donated these things, they donated them kind of whole cloth. They already existed. And they donated them to the open-source community. Once they donated them, they still had to stay involved in order for the community to flourish and they're still involved till this day. Risk five, on the other hand, is the first chip of this magnitude that was born in open-source and grew in open-source. And that's important. You'll see it plays a major role in how we think about things and how we wanna think about things. So let's look at the Linux contributor model a little bit and this fits into the whole story and how things are different in software and hardware. So in 1993, there were 100 developers on Linux. In 2014, it was reported that 80% of the active contributors were paid volunteers as opposed to people doing things in their spare time. They again, started being called contributors. Very similar things in the amounts of people being paid for things like Hadoop and Apache and Eclipse and then in 2017, it was reported that there was 15,000 developers and 1,400 companies contributing to Linux. But they'll also tell you that there are really only about 30 people who contributed to the bulk of the core of Linux. Obviously, every time you do a port and do something special, I mean, those folks are working on separate things but the core of Linux is around 30. So why did Linux become successful? I mean, one of the reasons obviously is price and I didn't mention that here but it's obviously something that's very important but it's starting an open source and I think that there's some value in that and in particular, there's pride of ownership and I don't think there's any way to quantify the impact of pride of ownership. People felt like it was theirs. They made it, it was their thing. It's their house, they're proud of this thing. And so I don't think anyone can underestimate that and risk five shares that. Also careers flourished, technology flourished. So it was basically a bed for both innovation and advancement. So there's a whole bunch of lessons learned that have been given and there's a 2017 Linux Kernel Development Report and I'll let you read through most of them yourself but we have some similarities. So just like their shorter release cycles and risk five, we tried very hard to break things down, divide and conquer, have smaller pieces that can go out more quickly and we're still kind of making that happen but we've learned that lesson and we're working very hard to do that. The other thing is that the importance of tools. So risk five, the hardware is useless without software and I would say it's a tip of an iceberg. The chip and the ISA, they're kind of that thing you see outside the water but the big thing that's underneath, that's everything else from formal models to architectural tests to boot loaders and hypervisors and operating systems and compilers and debuggers and optimizers and profilers and runtimes and applications, right? So there's this huge, huge ecosystem which makes it all work and they all have to work. And then the other thing is, it says here no internal boundaries, we have to work harder I think that software sometimes around making sure that everybody's talking to each other. So for example, if you're going ahead and developing bit manipulation instructions, you wanna make sure you aren't subject to any security issues. So you better be talking to the security people and the security people aren't necessarily gonna be in the same meeting, same thing's true with cash management operations and so on and so forth. So there's a whole bunch of things and you're gonna see a bunch of things that we have to do in order to get something ratified. Those are a subset of the list of things that the developers of the extensions have to consider in order to be successful. But the thing that's in black is the most important thing and it's the thing we talked about on the previous page paid volunteers, the increased importance of corporate participation. So the path forward, same prior to ownership we talked about that, same opportunities we talked about that. So one of the challenges, the open source hardware world has to nurture the open source software world's contributor model. It is not its nature because of the way it grew up in proprietary chips. There's still the possibility for corporate control and dominance because we still see these big entities driving a lot of the support and nourishment of these previously donated architectures. And then we also have an issue around speed of development where you're doing something in a community that moves a little slower than other times. And so you have to work very hard. If you don't have a very strong contributor model then things will go slower because people are working on other things for their companies. And then finally, if people are unpaid volunteers they're using their private time, their family time and it's really important to understand they're doing day jobs too. So they're gonna get burned out and we don't want that to happen. So let's move on to the next part. How big of a thing are we talking about? So let's talk about a couple of different kind of vectors here. So what does it take to get an extension ratified? So if you decide you're gonna do bit many manipulation instructions or crypto instructions what do you have to go through to do it? Because that informs how much work you have to do and that informs what kind of contributors you need. The number of groups involved the number of people involved and then some stats on the repositories. So we have an extension life cycle not gonna go through all the details here but there's these milestones you see in sort of the clear boxes and they're pretty understandable. The kickoff is when you kick off the project the stable is when the spec is kind of frozen but you're finishing it off getting it ready for public review. We have as part of our charter 45 public day of public review and then you have to do a bunch of things to get ready to get this thing ratified or approved and then there's some things that may be leftover that you have to deal with in order to get it complete. Each of these and again I'm not gonna go through all these points and just putting this up at more as an eye chart. Each of these milestones have deliverables both before the milestone can occur and right after the milestone occurs and in each one of them is really critical in order to make sure that this is useful for our members and eventually there are end customers. One of the things we will introduce here is the idea of the definition of done. A bunch of you have defined it as named it other things in your companies. These are the set of tasks you need to do to consider yourself done. This is the criteria and we'll talk about that a little bit because again it informs what kind of resources we need when we need them and kind of how much work. So this is the definition of done checklist. So for each of the milestones we saw on the slide two slides ago, we have a stable, freeze, a couple of optional checkpoints and then the vote ready and then complete and then all the members have contributed all these rows which contain as you can see things in the ecosystem. I mean, look the spec is there. There's no question about it. The spec is there. But most of the stuff is ecosystem that we talked about is that bigger part of the iceberg. And it's all the way again from the bottom formal models all the way to the top and making sure that applications perform well. And anybody going through with an extension has to comply with this checklist and tell us when they're gonna get things done and if they want to do things differently than the defaults that are in here they have to ask for exceptions. But that puts a lot of pressure on the amount of work that needs to be done. So we have a bunch of groups. We have a technical steering committee and I'm gonna show you the org chart in a second but just to give you by the numbers there's chairs groups. So the technical steering committee think of that as more strategic. The chairs is kind of the day-to-day operations of all the technical groups underneath it. There's five standing committees which are kind of umbrella organizations that again guide those groups and help them with strategy and help them interact with the chairs and the technical steering committee. And then we have subcommittees that are kind of a nested concept that either can behave like standing committees or like cast groups that you're gonna see and they either can make specs or they can spawn other groups. And then the big thing is we have 24 cast groups. We have some that have retired that are graduated that finished their jobs. We have some that are kind of on their way to being specified. But these are the guys so we have 24 groups specifying extensions and you're gonna see the names of them here shortly. And then we have special interest groups that just worry about sort of more discussions and then they can either become a task group or spawn a task group or do whatever but it's things like functional safety is in there and they affect a lot of things everything from performance to RAS to optimizations and so on and so forth embedded. And then there's dotted lines where we go ahead and we note the interactions between groups. Remember I told you it's kind of harder in our world to make sure the left hand is talking to the right hand and this is our attempt to make sure that this all works correctly. So here's a beautifully big chart with all of our zillion groups but you can see the hierarchy, the board of directors the technical steering committee, the chairs and then these kind of horizontal bars are our standing committees these umbrella organizations and underneath them could either be task groups or subcommittees and underneath them more subcommittees or task groups but this is a big deal. I mean, there's a lot of groups here and there's a lot of work going on and you'll find also just like most organizations there are a lot of people on multiple of these groups but we still have to work to make sure there's adequate representation across technologies and across disciplines. So just some stats. These are some of the specifications that are out there. The original two specifications are the unprivileged spec which are think of your standard arithmetic, you know, atomic, you included compressed in there but these are, you know, addition, subtraction, multiply, divide, so on and so forth. Integer, floating point, double, quad, so on and so forth. So 237 pages, 120 members, privilege, 133 pages, 206 members, that's for the operating system stuff. So everything from the control status registers for, you know, to say where each of the unproved instructions are and how they work to state with things with respect to, for example, virtual memory. It's a very, these two are very big by themselves but, you know, the other groups sometimes they go ahead and work on their specs before they reintegrate them back into the big thing. So Vector, for example, is sitting on 87 pages. Hack Decimal is sitting at 568 pages but a lot of it's data, right? So there's a lot of examples and data and information there. Bitmanipulation 92, there's a lot of instructions there and you can see the members and you can see the lines of code which for us is pros and graphs. So how does this relate when you compare it to Linux? So Linux by all counts is somewhere around 25 million lines of code. And we just saw it's probably now 17, 18,000 contributors and we have a total of about 1800 contributors with, you know, you can just see here there's, you know, maybe 30, 40, 50,000 lines of pros but the pros is dense, right? It's not like you have comments and you have spaces and there's one little operation per line like you do in code. This is dense, you have to read it and understand it. And so, you know, think of this as kind of a 10X kind of thing. So if it's 50,000 lines of code, you know, you know, 10 would be, you know, 500,000 but maybe it's really more like 100 in which case it would be 5 million. And so the same thing's true with the developers. So it's a different kind of work. It's very dense work. And all the work you see on this page is all done by architects. So we're gonna talk a little bit about the life cycle of hardware versus software, okay? And just wanna show you about, you know, sequentiality and stuff like that. We talked to a number of industries and asked them what the runway, how long does it take? From the minute you think about doing a product that will include a new chip of some sort to the point where that product gets an end user sands not the chip and end user sands but the product. So for cars, three to five years, disks, year and a half, server, five years, graphics card, two years and then the world has changed. 30 years ago, it would cost you $100 million and a hundred people taking two to three years just to create the chip. Last year in China, the Chinese Academy of Sciences for undergrads created a RISC-5 based chip, a real chip in four months for $12,000. So we know we can make the chips more quickly but we still can't push the rest of the schedule for the runway any more quickly. So the chip will feed into the rest of the process. It will not make the rest of the process faster for the other parts of the product that need to come together. So there's a quote here, UNIX philosophy, we wanna be able to do things that happen within weeks, right? And don't forget to throw away the clumsy parts. We get to do that in software. And people are, they work on something, they develop it for, let's say, for the Linux operating system, it gets to a point where it's stable, you do integration and field tests and it's a fairly straightforward thing. Most of the operating systems that they go, get put out from Linux, they depend on existing pre-existing systems and chips. They don't work on new ones and they don't allow new ones to come in too close to the end. If you have a new one, then you have to do it after the fact in some kind of patch or something like that. Or in the next release. So this is the way software works. It's kind of one big thing and it's set up to meet this design philosophy, but hardware is different. When you're dealing with a new instruction set and you're dealing with new chips or versions of instructions, that's because we know all the ones out there, the arms and the intel, they have new versions that add new instructions and so on. If you're working on that, you have to do all that work in order to get those chips in the hands, the designs, the instruction sets in the hands of chip designers. And then the chips have to be done in order to get into products. What product developer, if you're developing a server or you're developing a consumer device, when will you ever depend on a chip that's not done? You're not gonna make your dates. We know that people really want to depend on what's already there. So even if we shorten the time it takes to produce a chip, you're not gonna shorten the rest of it. And because of that, it's really different than software. Software is like kind of depends on what's out there. It's one big kind of path and in hardware, it really is staged and you'll see in the next section, we'll talk about the resources needed to do it overlap. So this is a lot of words here, but basically it's a continuation of what we discussed before that because of the life cycles, there's competition for resources and in particular competition for the architect resources. So what's the life cycle of an architect? In our world, again, there's the ISA design, there's the chip design, there's the product design and eventually it gets out to customers. The architects are heavily needed in the beginning to make the ISA. They're needed to, you know, those same ISA architects are needed to make the chip and then they have to work with the system developers to make sure that chip fits well into a system. And then over time, once that's gone to a certain point, the architects are needed a little less, but they're needed throughout the whole time and they're heavily needed at the beginning of the cycle. And as you can see, they're doing multiple jobs because not only they're designing the ISA, but they're designing the chip and they're also helping design the systems or helping integrate into the systems. The problem with that is, you know, when you're dealing with a community that's building a lot of extensions, while these architects are doing this for their companies, you know, maybe they can spend some time on the ISA design for RISC-5 International, but the minute they go off to work on the chip design and the product design, they don't have time to go work on the next set of ISA designs. And those same architects are needed that did addition, subtraction, and multiplication. They're the same ones who are needed to do vector instructions. And because they're busy doing other stuff, often there's conflicts for their resources. And this is one of the things that provides challenges for open source hardware development. You know, it doesn't make a difference. You take a look again at Linux. They say there's like 30 developers that have made most of the changes and contributions for the kernel. The same thing's true for this and most companies. They maybe have one or two people who are architects at the level that can design an ISA and architects at the level that can bring that ISA into a chip design and make it happen. And that really puts a lot of pressure on that resource. So we also run into Mythical Man month stuff. So I was having discussion about one of the extensions and one of the main architects, in fact, the chair, said he's volunteering. He's on paid. So, you know, his company wants him to do it, but he has a day job and it doesn't allow him to work on anything that's five-hour national. He does it all in his own time. So I said, okay, let's try to bring somebody in. And it was very clear very quickly that Mythical Man month came in. There's no way you can add people in it later stages and be effective. It's just not gonna work. And so you have to really have it happen from the beginning and you have to change the mindset of companies that are used to know the source software model, but not used to know the source hardware model to start moving in that direction. Okay, so how are we going attempting to go ahead and approach this problem? And how are we changing things in order to make it easier at least to address some of these issues? So let's go back to this extension model, extension lifecycle model that we showed you before. So, you know, when you're going ahead and creating your ISA and moving things forward, even within this, you need different types of skill sets. So again, you need architects more at the beginning and less at the end. They probably have to be pretty full-time until the end of the 40 to 50 day public review, otherwise things would go more slowly or, you know, we need more of their time and then after that it goes down. But then there's a whole bunch of things that we saw in that definition of done list where that work can be done by developers and doesn't need architects. And you're gonna see that's where we're gonna try to go ahead and split this up so that there isn't as much pressure on the architects. They have a bunch of people to help them offload them for those kind of tasks and hopefully make the whole process work, you know, better, faster and sort of, you know, less invasive into people's lives. And then also doc writers are needed and they're like architects, right? We need real doc writers. I mean, look, the guys who are architects, they can write and they can draw nice pictures but they really need help in organizing things, doing indices, making pictures look nice, you know, so on and so forth. And so we really need experience. So it's kind of like bookends, architect on one side, documentation person on the other side, but everything in the middle can be done by developers. And that's what we tried to break out and do something different. So in particular, you know, again, going back to the kind of definition of done thing here, all these things in the middle are conducive to the developer and we're introducing this concept of a group contributor model. And what a group contributor model is, is that we're working with some institutes that have some combination of professionals and students who are interested and willing to go ahead and do the work, for example, to make sure the architecture tests are done for bit manipulation instructions. So that the bit manipulation architects don't have to write those. The bit manipulation architects still have to kind of write the test back. They have to say, here are the parameters, here are the corner cases, here maybe some of the dataset parameters, but they can offload a bunch of that work to developers. And rather than like individual developers trying to be recruited, we again are working with some of these institutes I'll talk about in a couple of minutes that help us go off and do this in bulk, okay? And so hopefully, again, the challenge ends up being getting the architects time and the documentation folks time, but the rest of it, hopefully we offload that. So what are the models? So the one we are all know about is this volunteer model. And at some point it got called volunteer and paid volunteer. And in certain worlds, it was called the contributor model. And it doesn't matter if you talk about Linux again or Hadoop or Apache or Eclipse, there are contributors. And it's a club and you aren't allowed to contribute to you've proven your worth. And a lot of people want to be contributors and the companies and some of them have worked for me, the companies that hire these people, they do it for a couple of reasons. One is there's prestige in having a Linux developer in your company. You make press releases and so on and so forth. Secondly, you have somebody with inside knowledge when you run into problems or you're doing design and having that person on staff really makes a very big difference. If they did it purely as volunteers, again, the challenge is burnout, right? How do you go ahead and do your day job and do all your product stuff and go ahead and do this volunteer work for the community and go ahead and have a life. And look, we all live in challenging times. We all know we need to have lives. So these two kind of bookends on the side are kind of known quantities, volunteer model and the contributor model when the contributor model again is the paid volunteer model. And it's pretty understandable how they work. The group contributor is what I just started talking about where we get a specific area that somebody can or some group that is a subgroup of some institute can go ahead and become an expert in. They provide some professional oversight, tech lead, manager lead and we, risk five international provide an architect for oversight and they work together to figure out what the criteria for acceptance is and help slog through problems and review things and so on and so forth. So again, the way we've done this is we've divided and conquered. We've partitioned the problem. The things that have to be done with by architects we're having done by architects. We're trying to remove the rest of the stuff being done by architects to be done by developers. And one of the big benefits of that is when you go back and think about, hey, 30 developers really contribute to the current home, right? If those developers are off bothering with porting LS or fixing bugs in LS they're gonna be not very useful and they won't have time to do stuff. That's the equivalent thing here. There's no reason why the architects ought to be writing architectural tests. We can have them guide developers to go off and do that. So some examples, China Academy of Sciences, Rios, and I always forget what this stands for but risk five internationals, something. And it's a joint cooperation, Shakti, which has just made a lot of news. They just put out, I think they're not their first risk five chip and it's very exciting. Everybody's excited about that. And sci five, which contains some of the folks who are at Berkeley who helped start this project and they're working with a group called Shandy also in Asia. And so we're expanding this. So we have some folks in Europe and we're working on trying to get some universities involved there. So we hope to expand this and have half a dozen or more institutes that we can engage and get them to adopt some of these pieces and adopt the highway kind of thing, adopt one of these pieces and help our architects complete their tasks so things can be ratified. So what are they gonna do? So some group can take responsibility for architecture tests. They'll do it over a set of things. So they may do it across bit manipulation. They may do it across vector. They may do it for other things. And so they become a bit of an expert in writing architectural tests and they also become a bit of an expert in the ISA because they have to know the ISA, the instruction set architecture in order to write those tests. So somebody asked me today, are they getting paid? No, they're not getting paid. What they get, I mean, obviously they get whatever they get as being part of the Institute. They don't get paid by risk five international. What they get from us is the opportunity to work on leading edge stuff, learn a bunch of stuff and work with incredibly bright brilliant people who helped create risk five and make it what it is today. So this is kind of heading into my final slide and call to action. I mean, I think we've done what we can to analyze the problem. We've done what we can to divide the problem and to go ahead and try to optimize the resources that are most precious. But we still have some issues we need to work on and we still are different than software. And this whole talk was about forging a new model. This is really talking about moving the open source hardware developers in the community, the contributors to be more like open source software. So here's the call to action. One is we need more paid hardware contributors. These architects are still the most precious resource. So even if we get developers soft load them, we still need more of them. But once we have, we need more of their time for. And we know because we've done the analysis we've shown you that's really difficult for companies because A, they don't have enough architects who nobody has enough architects. And B, it's the same people who have to do the design of the ISA and the chip and product at some level. And they're different artifacts, they're different things. The ISA is different from the chip and the chip is different from the product. Whereas in the software world, it's one set of bits. It's one set of source lines, it's Linux, right? And when you produce it, you typically produce it on a chip that's already existing. So you're not waiting, you don't have that dependency and you can go ahead and have those same people contribute and still feel like they're working on something for your company. That's not the case for architects for ISAs. And then the last thing is we have to evolve the group contributor model. And if you guys know of groups that wanna participate that'd be great. If you have any ideas on how to do this, we're not proud. We take as much help as we can get. But in the end, this is an exciting project. We're doing amazing things. And I think that it's gonna change how the world looks at doing open source hardware projects everywhere. So again, I'm Mark Epelstein. Thank you very much. And I think we will head off to the Q&A section.