 I want to introduce our next speaker, which is Rishi Verma, is an architect at NASA JPL, the Jet Propulsion Laboratory. He specializes in design of large-scale compute-intensive data systems to support space exploration missions. Rishi leads a program on instituting software process improvements for NASA ground and space software systems through a community run, collaborative, and open-source governance model. Today, he'll talk about the open-source way to develop, iterate, and automate your software lexical standards and the lessons he learns at NASA JPL. Please join me in welcoming Rishi Verma. Well, hello, everybody. Hi, Open Summit. I'm Rishi. And I'd like to start by asking you all a question. Who here does not like being told what to do? I'm peeking out at the audience. And just for the record, I think that's every single hand in the entire audience, including all the boss people, too. So I'm here to talk to you about open-source software standards. You know those things that we get told to follow, but don't really want to? I would like to persuade you that there's a better way. In fact, the open-source way to develop, to iterate collaboratively, democratically, your open-source standards, and to get them disseminated into your institution's projects. At NASA's Jet Propulsion Laboratory, we've been doing exactly that. And we've been trialing this with a set of projects from the institution, which I'd like to talk to you about. But first, before we dive into open-source software standards, what they are, their history, let's start first by giving you all a preview of the types of open source projects and communities at NASA's Jet Propulsion Laboratory. So let's take a look and learn by watching this short video. Hopefully you all enjoyed that preview. And I encourage you all have been the last slides, the list of the URLs to engage with some of those projects. So now that we've talked about just a sample of some of the open-source efforts going on at NASA JPL and NASA in general, let me just talk about how we got there in terms of standards and standard settings. So in 2004, NASA first released an open-source license that was copy left. And that really set the stage for how to transfer intellectual property out to the open-source. Nowadays, we tend to use other popular licenses, but that helps set the stage. In 2009, NASA JPL released a C-language standard, which helped establish some coding standards for the C-language. And there are similar ones for other languages. In 2010, a project called OODT was the first to be adopted by the Apache Software Foundation, which really gave us experience about governance models and how to run projects out in open-source. By 2013, NASA JPL had formalized its release process for taking an internal project and releasing it out to the public and creating open-source community. And lately, I would say in the past few years, the drive at NASA has been to do something called Open Science, which is not just to release the code and create open-source communities, although that's a major part, but also release the data sets and the papers and really try to make a reproducible scientific pipeline. So we've been in the open-source space for a little bit of time, but now what I want to do is to take a slight pivot and talk about the history of software standards to give a little bit of context and talk about why that's important to know for open development. What do these three people have in common? And by the way, I wasn't joking about a small pivot into looking at the history. This is about 1,000 years of history. So this is quite broad, but hang in there with me. So on the far left, we have Alcorazmi, who was somebody who decided and helped create a standard process for taking a series of steps in order to achieve a particular mathematical or computational goal. We now call these algorithms. 1,000 years later, Ada Lovelace created a standard process for how to take a series of instructions, give it to a machine, and have the machine go through those steps, something we now call programming. And in the 20th century, Alan Turing created the standard process for taking any idea of the software and putting it into a universal machine and having that being executed, creating a model for that. So these three people, I argue, would have considered the idea of a standard process and actually software interchangeably, where software is really just the encoding of a standard process. They were really pioneers in establishing software standards, if you think about it, which brings me to my larger point, which is that software is a subset of standards of the standardization process. Software is just the subset of standards that can be encoded to run on a machine. And if you think about it that way, a lot of stuff starts making sense. So let's explore this idea a little bit more. So I believe that to write softwares to implicitly tell the world, we choose to standardize something in a very specific way. So what does that mean? For example, take your favorite web form, which creates a standard process for how we collect information, the types of information we collect from people, or your favorite navigation app, which creates a standard for how people go from point A to point B every day until, of course, everybody takes the same path, and then we all get stuck in a Karmageddon traffic jam. But regardless, with respect to software standards, software is really the encoding of a particular process and way to do things. So that's really what software is, is an encoding process that can be shared with thousands, millions, billions of people to do something in a standard way. So why is that important? So let me go back to this particular diagram, which is given the idea, and if we believe that software is a subset of all standards out there in the universe, and if we know that software is done like we all do here and have experience with, best done in an open source setting, can we extend the sphere of things we treat as software from the pool of things in the standard space to also treat those as code and develop those as software and get those standardized and developed using the open source way? What kinds of standards could we extend this principle to? So some ideas are governance standards, and many of you involved in projects in open source already do some of these. Things like decision-making strategies, automation to manage and effectively coordinate tasks, standards to create and disseminate and communicate roles, automation and schemes to really coordinate behavior in terms of vetting policies, et cetera, or standards related to coding standards, and enforcing those potentially, or documentation, templating generators or checkers, et cetera. Treating really these types of standards as code gives you a new way of looking at this to potentially make it easier for folks to adopt it. Software lifecycle standards, we're all quite familiar with these, cybersecurity scanning, artifact management, dependency tree generation, setting the standard for how open source projects in your own institution should follow these types of policies. So the question here is this, these types of standard categories and potentially more, can we develop these using the open source way? Can we treat them as a software project and collaboratively get together within our institutions with the open source projects that are getting out there and develop and iterate them democratically? At NASA JPL, we're doing exactly that with a small set of projects that we've been trialing with, and I want to encourage you all to set up a similar project to what we've done at NASA JPL called Software Lifecycle Improvement and Modernization, slim for short, in your own institution. So let's dive into it and see what we've been up to. So this is the sort of standard model we've been using for a pipeline for a software standard. We talked to the community, the community of projects at our institution, what do you all need in terms of standard processes? What are you doing differently that you need standardized across different projects and to make your lives easier? We triage those requests, we specify those standards collaboratively, and then we get the community to adopt it and this is actually the key, to adopt it by pushing in many cases those standards out as things like pull requests or things using automation to get those standards actually embedded in open source repositories that are part of our community of projects. So in other words, just to give you a little bit more, this is sort of more details about our process, but you'll recognize this is the open source development model. This could be applied to software or standards. There's a lot going on here, so let's take and walk through a quick example. So one thing that we've been doing is to ask the community. About a year ago, we talked to the community and we were asking, and by the way, the community here is the set of open source projects at NASA JPL. So it could apply similarly to your institution. But we asked them, what's important to you? What are the standards that need to be set as a community? Between your own project and several projects that you might be involved in across the laboratory. We got some community input, polls, discussion boards, et cetera. And one of the things we received, and this will be pretty familiar to a lot of you, which is standards for all my repositories look different. The readme still makes sense. One has a readme that's five pages. One is just a single line. I can't make sense of this. So setting standards for how to set up a repository from scratch and get bootstrapped was one of the standards we looked at. We triaged that request. We put that in with a number of other requests that we got and added a label in our public open source project in Slim and we scheduled it out and decided this is important. We want to do this as a community. So then we got to work. We started writing the standard. We created a pull request, a draft pull request, and then finally another pull request with the standard specification. We had input from folks using GitHub and various features from that environment. We got comments and then finally we made a release with that standard and we put that out there back to the community. And then we didn't stop there. We pushed forth and got the standards actually adopted by not only saying, hey, here's this piece of paper in your closet that's collecting dust and go open that and use it. We didn't just do that. We actually went out there and pushed these standards out. So through automation, because this is retreating as code, we're able to actually push out these templates or specific files to dozens of repositories and through pull requests and get them iterated and fused. So that's really an example of how we've done that and that scales well. In summary, we have this sort of standard process, but I also wanna mention that I think the key model here is not just to develop your standards in the open, but create transparency around that process because one thing we discovered is that people and specific projects, some are far ahead of other projects in terms of maturity. And so some projects not only express need for standard setting, but some are using the best standards out there. And so we want to create sort of a single schedule to say, here's the universe of things we wanna do, the standards we wanna set our institution. Are you working on something interesting? Please post a issue ticket of something you have or pull requests and include that. Or do you need something? Then please post it. So this sort of shared schedule master board, if you will, really puts it all together. So how have we done? Some information about progress. Right now, we're a relatively new project at the lab, but we have about 50 or so people involved. About 35 projects represented. So far in the last year, we've specified about 10 standards for our community of projects. We're currently developing about another 10. And we have a lot backlogged. That's probably pretty common for a lot of open source projects. Regardless, one of the key things I wanna share here, in terms of adoption, right? That's really our success criteria. So we've sent out about over 100 pull requests to software projects in our institution to say, hey, adopt these standards, take a look at this. And for some projects, that might be the first time they've seen them, but then we go through and get information about them. Well, we've seen about half of those actually merged into repositories and being used. So obviously, we wanna grow that number, but the thing is, for a community run project where we're really working with teams to include them in the process, this is something to be proud of. So what are the takeaways here? And what would I like to leave you all with? Well, one is to treat your standards as code and vice versa. I hope I've convinced you of that. The second is to leverage the open source way for your standards to ensure equity and development parity with respect to all people involved. And then finally, to disseminate your software standards just like you do with your code, through pull requests and through the open source way, as that scales really well. Well, that's my last slide. Well, thank you all very much. And speaker contact information is up there as well as a list of some open source projects. I encourage you all to reach out to me if you have interests. Thank you all so much and enjoy your Friday. Thank you so much, Rishi. It's fascinating. Thank you.