 Hello, and welcome. My name is Alejandro Del Castillo, and today I'm going to be talking to you guys about how to keep up with open source innovation. So a little bit about myself. I work for NI, have been working there for a while. And I will say that my involvement with open source goes back about 10 years. And since then, I have picked projects at NI that use open source or let me experiment with different technologies. These are some of the projects that I've been working on. And O-Package, it's a project that I maintain. There was a session on it in the morning if you want to go back and listen to it if it's of interest to you. I'm also leading the open source guild at NI. And that's going to be the main topic of my presentation today. So I'm first going to cover a little bit about how has been the involvement of NI with open source. Then I'm going to spell out the problem that we found when we started using open source more, which is how can you keep up. Then I'm going to be talking about the open source guild. And at the end, there's going to be some time to answer questions. So please put your questions on the chat window. And there will be time at the end while I'll go over the questions and share some of my thoughts. So before we start, I want to say that I don't claim that I have feared this out. This is a super hard problem. Also, I think at NI, for example, we have some groups that are very well versed on open source use and others that not so much. So an organization like the open source guild have helped us a lot to cross-pollinate, to make sure that we radiate some of the knowledge that the groups that are good at using open source have acquired over the years. I will say that at NI, the guild has improved our collective open source IQ. So I want to share my findings during this process. And we'd love to hear how you guys have tackled similar problems. Here's my email address. Please feel free to contact me directly or over Slack during the conference. So if I had to pick one project that was super important to the way we use open source at NI, I will go back 10 years and pick this one. So back in 2010, we wanted to modernize the family of controllers that we sell. So at NI, we sell controllers like the one you see on the picture you see on the screen. These controllers have a CPU. And then you can put cartridges for the different type of IO that you need. They used to run a proprietary OS. But back in 2010, we decided to modernize the platform and run Linux with the preempt RT patch. And then we spin up a whole group in charge of creating an OE Yocto-based distribution that will be running in these controllers. So my involvement started here with open source. I was part of the original team. And I will say that we moved to Linux back then, and we haven't looked back ever since. This was a great decision. It gave us a huge lift. But it was not all free. Basically, if you're going to adopt a project like Linux with the preempt RT to be very core to your platform, you need to invest. You need to engage the community. So we did. We joined the Linux Foundation on 2015. And we also were founding members of the RT Linux Collaborative Project, which is a Linux Foundation project in charge of making sure that the preempt RT patch makes it into the mainline. During this process, we ended up maintaining a couple of different sub-projects. So I became the maintainer of our package because we use the package manager for OE very extensively. And there was an opening, so I stepped up. And Julia Cartwright was a stable RT maintainer for a couple of years. Below are some numbers of some of the contributions that we have made for OE and the Linux kernel. And I'm showing that just to convey that if you are going to adopt a project to be so core to your platform, you need to engage. And you need to engage to make sure that it is going to work for your use case. So back then, that's kind of like the lesson that we learned. So fast forward in a few years, this was another project that I think was seminal to how we use open source. So we had these controllers. And now we were tasked with creating a platform that will make sure that there were running specific versions of software, make sure that they were healthy, make sure that we were getting blogs out of them and present those in a UX friendly way. So we're tempted to go ahead and do what we know and just build our own thing. However, building on the knowledge that we acquire during the Linux RT project, we decided to not do that. We determined that there was a trend of heavy investment already for system configuration management for data centers. So there was a lot of investment on the cloud to be able to manage all these VMs. And we decided to use one of those solutions, specifically Solstack, and adapt it to our use case. So it was not a perfect match. We required to run on Windows. And there was no master Windows support. So we had to add that. It was missing some modules. And also, it was very memory hungry. So we decided to invest on the project and make it work for our use case. So we engage, again, quite heavily. We did the Windows master port, as well as a bunch of other features. We developed pretty strong developer to developer communication with Solstack, which has been great. And we then ended up in a few working groups. So if I have to summarize the learning from this experience, is that it pays off to adopt a higher level open source projects, even if they don't do 100% of what you need, even if they do 80%. You are going to be better off if you invest on that extra 20%. It's tempting to say, well, the project doesn't work exactly for what I need. I'm going to scrap it. I'm going to do the whole thing myself. But actually, I will argue that if it does about 80% of what you need, you should consider just working with the project to extend it to the extra 20%. And a nice side effect of these two projects is that the developers that work on them became evangelists of open source when they move on to other projects. So we started to build some core number of developers that were very well-versed on open source. So with all this knowledge, now we're going to leverage more. And the question is, how do you find the next project that is going to fit what you do very well and is going to give you a big lift? And this graph I borrowed from my colleague, Michael Phillips. What he's showing is on the x-axis, it's a timeline. And on the y-axis, he's showing a software stack from the bottom to the top. So for example, Linux came up to live in 1991. And it's an OS category Apache was about 96. What the line tries to convey is that open source is commoditizing software starting from the bottom of the stack and it's going up. So for example, in 2005, you would consider buying a compiler unless you have very niche needs. You would just use GCC. Same thing in 2010. You probably won't consider buying a proprietary web server or building your own. You will just use a very well-established, strong web servers like Apache or Nginx. And that's kind of what we did with Salt in 2014 when we started the project. Maybe it was not completely clear that the ecosystem has already coalesced in the system configuration management space around a couple of options. But it was fairly clear. So it was tempting to build our own thing, but we decided to just go ahead and use one of the solutions that already had a strong community around them. And by the way, that graph ended in 2015, but this has just accelerated. And I will say that the higher you go up the stack, it's probably going to translate into higher leverage. But also, it means that you're going to have to spend time adapting that project and making sure that it's going to work for your use case. And that's not trivial at all. Especially now that we are talking about whole platforms that are being a open source and foundations and communities built around them. So as an example, we were recently looking at Kubeflow. And the stack of Kubeflow is gigantic. It builds on top of Kubernetes, and then it has serverless via Knative, which then serves models that you could build in TensorFlow, PyTorch, et cetera. And then there's a database where you're storing all this. So it's a very complex stack. And if you adopted it instead of building your own, you're going to get a very big leverage. But it's not going to be that straightforward. And by the way, in top of all this, Kubeflow also has the whole Jupyter stack to train your models. So just to give you an idea of how gigantic the ecosystem is, in 2018, GitHub created this blog post where they were saying they reached a milestone of 100 million public repository. Last week, I went ahead and did a query, and then that number was already 270 million, which is mind blowing. That's a gigantic number. So with an ecosystem that big, how can you keep up? The ecosystems are moving really, really quickly. It's hard to identify the disruptive technologies that can make a big impact in your organization. And then sometimes a problem has different implementations. And then how do you pick the one that is going to end up winning? So this is a very hard problem. So one way to try to filter the gigantic ecosystem is to look at growth rate. So if you do that, you could see a graph like this where if you are looking at Kubernetes package managers, you see that helm is there. And that gives you some confidence that that project is getting energy. So you might say, OK, I'm going to take a deeper look there because there's energy in that project. Another metric that you could use is contributions. So again, looking at this graph, you could say, well, yeah, like Kubernetes and TensorFlow, those are clearly two projects that are seeing a lot of movement. So if you're looking to a container orchestrator or a machine learning framework, those will be high on the list of price to look at. So another prism that you can use, and this is actually one that we've been using quite a lot, is to look at foundations. So I see foundations as being the custodians of open source. They already filter projects based on metrics. So if a project is in incubation state, that means that it's just starting up. The products that have gone out of incubation can give you some confidence that they are actively maintained and they have a decent community around them. OK, so this painting is from Rembrandt. It's called the Syndex of the Drapers Guild. So basically, the Syndex of the Drapers Guild were elected people from the guild that will look at the different clods than the weavers from the Weavers Guild will bring them and then they will look at the quality and only the ones that have a certain level of quality will be approved for the rest of the guild to buy. So in a way, I think that kind of matches the mission statement of the open source guild. We try to look out there to all the different clods and do some filtering that then we can radiate to the rest of the organization. So the mechanics of the guild are this. At the very beginning, each member will look at different projects using all the different filters that I mentioned and they bring all the products of interest to an initial meeting, a pool of projects that look relevant and we try to apply some filters like foundations, contributions, et cetera, et cetera. But also trying to see if the product could be relevant to what we do. Then we have a discussion on each project and here we try to use filters like disruption potential. Like if this project, a game changer and then also try to filter it on relevance to what we do. Another filter is internal awareness. Like if a project is very well known within an eye, then there's no point for us to look at it again. So we filter and then we get this smaller pool of projects that deserve a deeper look. What we do next is that one guild member spends between a few days and a week taking a deeper look at the project. We usually try to have demos around them and focus on how can this project be applied at an eye. Then there is a presentation where we have the guild members but we also have stakeholders that we think could be interested in the project. The presentations just usually take one hour and then they are followed by a half an hour internal discussion of how can this be applied to an eye. Then as a group we decide if this is relevant or not. If it's not relevant then we just stop there. If it is relevant it moves to a next stage. In the next stage we try to engage other venues. So for example recently we have a presentation on graph databases and there are some projects that use graphs internally but they don't use databases. So we ended up engaging tech leads on those particular products and representing what the guild found. So they can then run with the technology if it's appropriate. We have some other presentations like on columnar databases which are more broad. So then what will happen is that they may go to different venues like our internal tech exchange called NI-Tech. There are other venues where we usually redirect presentations like VP Technology Exchange. So the structure we meet only once a month for those presentations that I just mentioned. Each presentation has an owner. So the guild member should present on the topic or should found someone that will present on the topic. And we will keep a schedule of about one year ahead. A backlog but we revisit that backlog to make sure that it's still relevant. And I will say that on the guild we have a healthy mix of long-time contributors to open source and less experienced developers that are eager to learn more. So we cross-pollinate that way. I'd like to mention that the guild is not an open source office. It's a more organic initiative, a more bottom-up. So we don't dictate a policy on open source or give-hope presence or any of that. But it's a venue for open source exploration and I see it as an agent of change to radiate best practices and how to engage with communities and leverage open source in general. Challenges, keeping the backlog relevant, that's a challenge. I think we're doing okay, but you need to constantly revisit it because the business needs change and you have to be responsive to that. Keeping the members engaged. Right now that's not a problem for us but that's something that is on my mind. Getting time commitment for the research, that's also a challenge. You need to either have managers that understand the value and then they give the developer the time to go do the research or do it on 10% time, et cetera. I also think that we could be more strict about how we evaluate projects. So having an evaluation framework is something that I would like to have at some point. Some of the material that I presented here, it's in a case study by the to-do group. Here's the URL if you wanna check it out. The to-do group is an open Linux Foundation sub-project where open source program officers used to exchange best practices. And that's what I have for today. I'm gonna go ahead and answer some of your questions. So there's a comment here that says, okay, buying a compiler, Windows in a niche case and Visual Studio still be there but even then they give a lot of it away for free likely because GCC, Clang are there as alternatives. Okay, so I think Brandon's point is that the push for towards open source in something like compilers have forced companies like Microsoft to develop different business models. For example, Visual Studio still pick out there but then they generated VS Code as a ramp up to Visual Studio. And that's probably because GCC, Clang and others have came into the ecosystem. So yeah, Brandon, I agree. Okay, I have another question here. Any open source projects you suggest for getting started, that's a hard one because if I answer, I'm gonna answer with all my biases. I think the Linux foundation have a list of projects that are good for getting started. But if you ping me after the session I would love to point you to some of the ones that I like or can point you to some resources that you can browse on your own. I think we're, okay, we have time for one more. What challenges you want to highlight doing open source at primarily a hardware company like NI? So that's a very good question. I think at NI being a company that big the groups that are closer to hardware they find it more challenging to engage in, you know, higher up the stack open source projects. They're very likely gonna be using a build systems, compiler, et cetera, but where the ecosystem is exploding is more in app software, I will thank. So at NI, I think it depends on your group and how much exposure you're gonna get to open source. I think it's changing quickly, but I do think that app software has it easier because sometimes like that's the only option. You're using open source software because even if you didn't want to, like that's your only option. Okay, so I would like to thank everyone. Please ping me on the Slack if you wanna chat more. I'd love to talk about this and we can continue the conversation there.