 Hi everyone, I'm Gorn Haff, Technology Advocate at Red Hat, where I work in emerging technology areas. And as part of that, I do a lot of work with Red Hat Research. And the topic of my talk today is I'm going to take you through, serve some of our thinking around setting up Red Hat Research, some of the things we're doing at Red Hat Research, some of the things that we've learned in setting up the program the way we have. But first, I'd like to spend a few minutes to talk about the nature of invention in the first place. Now when we ask how does invention happen, probably one of the logical first places we end up is, well, there's an inventor, of course, and on the right hand side here we have the first marine chronometer, which was important for determining the longitude of ships that see you need precise time on a rocking sailboat, which made traditional clocks not work very well. And Leonardo da Vinci, famous artist, famous inventor, and we could go down a whole list of things, probably most of you at some point in high school or whenever, probably had to memorize a whole list of inventors of various technologies. Now there's a couple of things wrong with this mindset. The first is that certainly people do invent things, I know won't take that credit away, but they're almost always based on pre-existing work of various kinds. The other thing we find is that when people are listed as inventors and you really dig into the stories, usually those stories are a lot more complicated. There were various people doing different things at about the same time, taking different approaches, but really the need to have an inventor is so ingrained that you almost always come up with an inventor for the thing and that's what makes it into the school books. Now particularly as products technologies got more complicated, we start to see more invention at really the company or a team within the company level. So if you look at something like the Ford Model T for example, Henry Ford gets a lot of the credit, probably rightly so, however obviously there were teams of engineers at Ford Motor Company who made the assembly line happen, made the Model T happen. It wasn't one individual who did this, however there was really kind of an other mode of invention. I think I alluded to this a little bit when I was talking about how individuals invent things based on prior work and that has been well recognized for a long time. If you look at for example how viticulture happened in Southeast Asia and Europe, there are patterns of spread of technologies over time and this seems to be a natural process. There was no board of viticulture spreading this knowledge. This knowledge just kind of happened and this has been well known for a long time but wasn't actually studied until relatively recently and in 1983 a researcher, professor at University of British Columbia, R.C. Allen studied this idea of collective invention, this idea of informal knowledge sharing and specifically he looked at the 19th century steelmaking industry in the UK and what he observed was that a lot of knowledge seemed to be being informally shared between companies and by individuals moving from one company to another. Now companies at that time generally didn't have corporate research departments. Most of these inventors at these companies with few exceptions aren't very well known but he found that things like chimneys get incrementally higher or there were incremental changes that seemed to be coming from some sort of knowledge diffusion and he actually studied this quantitatively and the other thing he found was there were patterns here. You had companies that seemed to be out ahead of making changes and then you had other companies that just kind of followed what those first companies have and what has happened in more recent years is that you can look at a couple of different things and this is where Burkai gang into how we're thinking about the Red Hat Research Program is research obviously happens in academia. A lot of this is actually a relatively recent process. A lot of the academic research we think of was really kind of a product around the World War II era. There was research in universities earlier, particularly starting in maybe the later 19th century, but sort of the modern research university is probably less than a hundred years old and these are some institutions in the Boston and Cambridge area, institution in Brno obviously and what we can kind of say about this academic type of research is you do have a lot of collaboration in academia, but it's often in silos IP licensing may be a consideration actually some of the big research universities make quite a bit of money off of licensing their IP. One thing we can also say about academia is it can be rather academic. It can be not terribly rooted in real world use cases and practices and this is a concern that played into getting Red Hat Research started, but we also see this in some of the big research universities where there's been some deliberate efforts to do more collaboration across different specialties. In academia they use a lot of open source but actually working in open source working in upstream communities may not be familiar and what academia tends to produce is sort of the almost stereotypical publish or perish. They do fundamental research and they publish papers based on that and that's very important for both PhD students, for example, getting their thesis and for professors to get tenure. Another phenomenon that we've seen over kind of the same period, maybe a little, starting a little earlier, is the idea of the corporate laboratory. Edison's lab is sort of famous for this Bell Labs is a very familiar example, but a number of large companies have had fairly well-known corporate laboratories. DuPont and the chemical area talk right as IBM corporate lab up in Yorktown Heights in New York. Interestingly enough, IBM, when they started out their initial corporate lab, it was actually located at Columbia University in New York so IBM was actually a fairly early on example of an academic and corporate collaboration in terms of research. What can we say about corporate labs? Well, they were mostly limited to dominant firms. Typically companies that had some sort of monopoly either kind of legally in the case of Bell Labs are de facto in terms of companies like IBM and DuPont in the chemical area because basically their financial situation allowed them to put money into labs that weren't necessarily going to have short-term benefits to the company. There didn't tend to be a lot of collaboration outside the labs. They were famously a lot of collaboration within the labs but not necessarily between companies. They are generally looking to make money in the long-term. They've tended to be in companies have gone back and forth a bit about this over the years sometime but they're tending to be wanting to have results that have some immediate benefit or at least if not immediate relatively near-term benefit. In fact, a trend that we've seen over the years in corporate labs has often been that they they will sort of go off in more academic territory and particularly if profits go down a bit they'll kind of get sucked back into the product development space. The research can end up looking a lot more like development. The output here is patents, fairly famously in the case of IBM and working artifacts of various kinds, something practical. Again there may be collaboration papers and so forth. If you look at somebody like Microsoft Research for example or Google but that's not really the primary thing they're trying to accomplish. We bring this to open source and this is sort of the ultimate knowledge diffusion and the IP concerns are mostly handled by things like licenses, maybe trademarks. Most of the bigger successful products out there, projects out there are very collaborative. Open source has tended to work better in software than in other areas. There are some other things like hardware for instance in RISC-5 ISA but it's been harder outside the software space and again like Allen's knowledge diffusion they tend to lean towards the incremental and the output is obviously code. Again we're trying to broaden that out to things like operational knowledge and so forth. And one of the nice things about open source is what Jim Zemlin of the Liggs Foundation calls these virtual open source cycles. So you have projects that lead to products, products hopefully make money and if they do that can feed back into the projects and pay developers for example. So we set out at Red Hat to think about how can we organize deliberate invention that pulls in some of that virtual virtuous cycle that I described and really have a model of a research organization that brings in that open source that can combine some of the academic type of invention and some of the corporate type of invention. And that's sort of where we ended up at Red Hat Research. So start out Red Hat Collaboratory at Boston University in Boston obviously started 2018. It was a joint project by Red Hat and BU and the goal would basically do advanced research in emerging technologies in areas of joint interest. So in the case of you know Red Hat it's been mostly things in the loosely defined software infrastructure space and we've had these collaborative teams of BU faculty, PhD students predominantly, although not exclusively in Red Hat engineers, and we support fellowships, internship programs for the students, organized joint talks and workshops. We've also been expanding this to other universities including in Bernau. However we've been very deliberate about this and I'll talk about some of the lessons as we go on here to not try to boil the oceans here but to really focus where we can have a real effect and a real difference. And from Red Hat's perspective this is run out of the office of the CTO. So the mentioned were predominantly in Westford Boston and Massachusetts, Bernau in the Czech Republic and Tel Aviv in Israel. There are some other projects going on so it's not exclusively by again we've tried to keep this focused in a manageable number of areas. We publish quarterly magazine, we have internships, we do mentoring with students closely, we have some Red Hat engineers who teach classes and we have Red Hat research days events which we'll hopefully go back to in person one of these days obviously haven't been in a while. So what kind of projects do we do in terms of kind of scale? Some of you looking at this may be familiar with some of the three horizons planning model and to me this looks a little bit like that. That you have large-scale projects, smaller-scale projects and speculative projects and you know essentially this corresponds to the amount of funding and the amount of Red Hat effort that go into these. So you know there are projects that are very well established. We know there's something there basically but we want to do more with those projects so something like Chef for example is probably a good example here. It's very visible, there's a number of people involved both from academic background and from Red Hat and often these are built up from something that has already been proven may even be a product based on it and we just want to make some changes, improvements, speculative projects you know like hey this is an interesting idea don't know if there's anything there or not but it's worth putting a little bit effort, putting a little bit of money into this and you'll see if there's something there that's worth spending a bit more effort on and then small-scale projects are kind of in between those two. One of the kind of the general ground rules here is this is all open source and publicly available so this is we're not interested in working on closed source in this context. There's a bunch of related work predominantly coming out of our our Boston Cambridge based efforts. They're sort of this complex interlocking of different organizations out there they're doing various things in terms of providing research work into large-scale cloud operate first is one very currently active project we're looking for ways to kind of bring open source approaches into an operational context rather than just software development looking at telemetry as part of that and again a number of these other projects that are a combination of Red Hat funded, Partner funded, Massachusetts government funded, University funded so there's a lot of related things that are kind of going on in this space. So you know we've had a lot of success here we have quite a few Boston University professors who are involved in this specifically again in the Boston Cambridge area we have a very large number of OpenShift compute platform licenses that have been donated to mass open cloud there's a ton of SEF storage which is being increased continuously and you know we've funded a lot of public research over the last five years and we've influenced other you know other research that's going on as well. Some of the areas we're working on I mentioned SEF, Unicernals is an interesting area basically Linux based Unicernals and there's an article about that in a recent Red Hat research quarterly issue FPGA tooling and there's also some work going on with risk five in conjunction with FPGAs AI ops a lot of self-tuning there's been some other work in the AI area as well in terms of preserving privacy and data sets so differential privacy homomorphic encryption 5G project specifically with northeastern in that area and looking at various types of software verification. What we learned well just giving money isn't enough the the sort of people component here the internships the mentorship are important I mean you need money at the end of the day but this isn't just a case of writing a check and I think related to that there really has to be this joint commitment Red Hat or industry more broadly needs to work with academia can't just go off in its own thing and do it and again these are all kind of part and parcel the same thing the senior engineering time has definitely been a bottleneck here and again can't just write a check you you know you need to supply the the senior people to do the mentorship and the work there does need to be local involvement again that's you know why we're not doing this every place do need some focus as I say we've been focusing in areas that are primarily of interest to Red Hat and I think we did we've over time we've sort of discovered the project management and so forth associated with this is something that really needs to be thought about deliberately you can't just do this all ad hoc so what's next feel free to reach out to me with any questions feel free to subscribe to Red Hat Research Quarterly there's a digital version available HTML on Red Hat Research website and we also have a very nice print magazine and we're going to continue to have Red Hat Research Days events we've been doing these virtually as shorter sort of self-contained pieces because nobody really wants to be in video all day but hopefully we will get back to person one of these days so with that thank you and I can take some questions