Nava Strata: Open Source Government Technology
We’re joined by Ed Mullen, Technical Solutions Director and Lauren Ciferri Director of Product, over at Nava PBC. We’ll have a conversation about open source government technology, using Nava’s Strata project as a key example. The chat will dive into importance of open source in the space, maintaining projects like this one, and how one can get involved.
Resources and shoutouts:
Music Credit: Tumbleweeds by Monkey Warhol
Top Keywords
- strata 0.028
- nava 0.013
- open source 0.013
- open 0.013
- source 0.012
- government 0.012
- vendor 0.009
- agencies 0.006
- vendor lock 0.006
- lock 0.006
- well 0.005
- delivery 0.005
Transcript
Hello. I'm Ryan Cook, and this is Civic Tech Chat, a show that looks at the way technology, politics, and policy impacts the world around us. The tools we use, the way services are delivered, and how we talk about and set policy all shape our society. We'll gather around and have a chat about these things together and more. This will be a sort of special episode that we're about to hop into. I'm, grateful for the fact that Nava PBC has partnered with us to do a sponsored episode. So I'm excited both for the partnership and for the very interesting conversation we'll have ahead. Ed, LP, thank you both for joining us here on Civic Tech Chat. Could you each introduce yourself and tell us a bit about what you do?
Absolutely. I'm Ed Mullen, technical solutions director at Nava. I support Nava's solution development practice, helping to shape solutions that meet customers' needs in response to specific new business opportunities as well as helping to shape future facing solutions that Nava's building. I've been with Nava for about six years, initially leading design on a large project for CMS, and then shifting to business development in the last few years. Recently, I've been focused on Nava's response to HR one, including our open source community engagement reporting tool for Medicaid, as well as, SNAP payment error rate reduction solutions. And I've also been working with the Strata team, which we'll be talking a lot about today. I've been in the civic tech space for about fifteen years. I was the original designer of healthcare.gov way back in 2010. And then again, I worked on it in 2012 and '13. Later, I joined 18F as a strategist, working closely with state and federal agencies on a variety of issues.
And I'm Lauren Saveri, but I go by LP. And in my role as director of product, I support a 70 plus person product organization delivering digital services for both state and federal programs. Since I started at Nava almost nine years ago, I've led product teams on high impact projects, including the implementation of a new veterans appeals legislation and the launch of Massachusetts paid family and medical leave program. Before joining Nava, I worked in multiple roles related to public health and health care. I was a product manager for a health care software and consulting company and medical scribe in a, in the emergency department of a hospital.
For each of you, what would you say is your personal why? The thing that drives you to get out of bed each morning and do what you do.
I I guess I see all the people in this country as a community, and our governments are the way that we, as communities, have tried to organize ourselves to meet our collective needs. But government is really an imperfect machine that needs a lot of attention and care to keep it working right. So to me, if I can use my labor to help make this big complicated machine more responsive to the needs of people in these communities, well, that then that's how I wanna spend my time.
I believe in the power and necessity of the government to provide basic human services to people, and I love that this job connects me to those programs. I mentioned my favorite project with Nava was implementing a paid family medical leave program, and I saw how people policy and technology enabled that program to work well and have a direct and important impact on people's lives, caring for their families. And in my role now, I love leading and supporting our teams working on those similarly impactful services.
We're here to today to talk a bit about open source work Nava has been involved in recently. Let's start at a base level with that. When we use the term open source, what are we referring to?
Yeah. Thank you for this question. We know that open source can conjure different ideas, some positive, and some maybe even unsettling. Open source software is built in public so anyone can use it, learn from it, improve it, and share it based on the belief that collaboration and transparency lead to better outcomes. Open source is less about free stuff and more about the following four values. Sharing, that knowledge gets better when people share it. Collaboration, that many minds together usually produce better results than one company alone. And transparency, that you can see how things work instead of just trusting or paying for a black box. And freedom, you're not locked in to one vendor or company. When we refer to open source within the realm of civic tech, we are applying this approach to building technology for government programs, including benefit applications and data tools. Tools that affect many people should be open to inspection, and trust go grows when systems aren't hidden.
As we think about how you described open source, why is it important to promote such a thing in public technology use cases in particular?
Yeah. I think it's important to promote it in public technology. It's really important for accelerating delivery and fostering ecosystem wide improvement. By adopting open source, agencies can save significant time by leveraging established best practices, to avoid redundant work and errors. The approach really encourages vendor agnosticism too. In closed or proprietary systems, vendors often create and maintain government dependence on themselves because the systems they provide are hidden. They're poorly understood. They're sometimes even intentionally obfuscated. Open source can prevent this kind of lock in by granting agencies full control over the code, their data, and their long term road maps and ecosystems. Ultimately, open source empowers the government to drive down system costs, enhance speed and quality of outcomes, and maintain the flexibility needed to succeed in their missions. I think, overall, if we want to accelerate the delivery community in the civic tech space, open source is a really important part of that.
I think what I hear in both of your answers is that, in open source, people may well be paid to either produce or to or paid to use such technologies. But the freedom aspect is the important part, the free sharing of tools and techniques and also kind of the openness of being able to inspect those, which it sounds like, in a government context are both things that you really want. People want transparent government and, also one where, you know, a common good is able to be accomplished. Am I following along with what you're both trying to get at with kind of your perspectives on open source?
Yeah. Absolutely. That's right. These systems are, there are a lot of common solutions, common problems across government, and the solutions can be, common as well. And so by opening up these systems, either, be the government themselves opening up the the work that their contractors are doing and and doing the project in the open is a great way to start to build that transparency or adopting solutions or open source projects that have already been built for similar use cases. Again, gets the team jump started and operating, at an advantage rather than starting from scratch over and over.
As we go from concept to something more specific, project Nava has announced recently in the open source space is called Strata. What is it, and why did Nava seek to build and publish it?
Strata is our gold standard target architecture and suite of open source tools that gives government agencies what they need to run a modern service, deliver quickly, and achieve their program outcomes. It emphasizes modularity and reusability and provides an open alternative to black box vendor lock in. We built it over time. Strata turns over ten years of Nava's government delivery experience into reusable tools that can be deployed immediately. It contains production ready patterns for secure, compliant government services across three offerings. One, infrastructure templates for production ready cloud environments spanning both AWS and Azure cloud providers, application templates to quickly build user facing and back end applications, and a software development kit to build human centered digital services like placement applications, business processes, and eligibility engines. Compared with commercial off the shelf or software as a service or custom development, Strata offers vendor neutrality and full data and code ownership while keeping upfront and long term cost advantages. As a company, we sought to build and publish these best in class tools because we believe that technology built for the government must be resilient, transparent, easy to maintain, and cost effective, That vendor implementations across similar programs shouldn't hamstring government programs or unnecessarily cost them and taxpayers more. And we wanna help agencies save time, avoid exorbitant costs, and build modern and resilient services that truly support the public's needs.
I imagine other organizations and government spaces might be seeing Nava doing this, and they might be wondering what what signal this sentence about Nava's positioning of open source in its organizational strategy as it goes forward. How would you describe that?
As it stands, Strata is the only solution on the market that's open source, has been used at scale, and is aligned with the government's long term interests. By positioning Strata as a means to break free from entrenched and inflexible legacy vendors, we're prioritizing empowering agencies and nurturing long term resilience over proprietary vendor lock in. As LP touched on, we want to drive down the cost of systems and make it easier for government to succeed. And we think that an open architecture that is vendor agnostic, modular, extensible, open and adaptable is the right way to do it. Overall, we're pushing for open source adoption as an organization as well as breaking old vendor patterns that no longer serve the American public. This strategy aligns with our, public benefit mission. We are a public benefit corporation. We are working to empower agencies, accelerate, and raise the bar for the entire delivery community, and seek higher level ecosystem change at the same time. Because, you know, if anyone, including us, can contribute to improve government outcomes at higher speed and quality, well, then that's good for all of us.
Each of you has described this or used this term vendor lock in as a thing that, government should seek to avoid and as a benefit for using open source. What do we mean by the term vendor lock in for folks that, maybe haven't been out procuring software in recent days?
To me, vendor lock in is when a government, or an agency needs to accept that they're gonna keep working with a vendor even though that vendor is not serving them well because it's too hard to change, they don't understand the system, they don't have full access to their data, all these other kinds of methods of sort of entrapping agencies into a pattern of dependency where the switching costs are just too high to move away from them. And that really reduces the op the the optionality that agencies have because even though they know that the vend that they're not being well served, they can't get away from working with that vendor, and that's lock in.
What impact are y'all hoping Strata's going open source will have on the rest of the public interest space? Are you hoping that other companies out there will publish their own open source tools as well?
Absolutely. Yeah. We hope that making Strata open will empower government agencies with more choices beyond relying on their incumbent vendors' proprietary software for costly iteration after iteration. We also hope it will invite the government and civic tech community to share feedback and continuously improve the platform for a broader benefit. To answer the second part of your question, another resounding yes, of course. Why aren't other companies publishing their own open source tools as well? It seems like best practice to open source your work when you can, because these are projects that government has paid for. Of course, you need to move in alignment with your client's perspective, but companies are charging one government agency after the other for the same patterns and systems. This could be much more efficient. So we do hope Strata will have ripple effects in the public interest space and ultimately place more autonomy in the hands of government agencies working closely with vendors and partners.
Have folks already started to make use of Strata as a foundation? What are folks using it to do out there?
Yes. They are. An example of this would be simplergrants.gov, which is the US Department of Health and Human Services open source web portal that allows grant seekers to search for and apply for about $300,000,000,000 a year in federal grants. Starting in July 2023, the core contributor team selected or elected to use Strata's infrastructure and next. Js templates. This accelerated delivery and raised the overall code quality through a shared well architected code base proven on other high impact projects. The built in patterns, documentation, and architecture decision records not only streamlined onboarding for new engineers, but it also met the client's goal of demonstrating how to transparently, develop an open source government application. The team was so impressed with the results that they shared the Strata templates with other members of the grant seeking software community. And then in September 2025, Nava was chosen to lead an adjacent, project related to to that project called grants management based off of our prior work. In practice, Strata saved an estimated 12 of of developer time over the course of the two years standing up simpler grants.gov. And in general, it saved agencies thousands of hours when standing up modern government services.
I'd like to shift a little and talk about licensing, which is, I know, a very, very excited thing it gets folks, hearts beating. I noticed that Strata uses Apache two .o as its license, which is an interesting choice. It's a flavor of open source license that allows folks to use, modify, and distribute the software covers in a fairly permissive permissive fashion. Can you talk about how Nava came to choose this license and why it finds this choice important?
Absolutely. We chose the Apache two dot o license because of many of the reasons you mentioned. It's permissive for broad adoption, permits incorporating the code into proprietary or closed source products as long as license and notice requirements are met. We know that government technology ecosystems are really complex, so we wanted to be ready to plug Strata offerings into existing government technology stacks that have a variety of systems and services and to be able to meet government programs on their modernization journey. It also provides strong patent protection for users and encourages enterprise trust through clear legal terms and supports digital sovereignty by keeping control with the agency. We really believe in keeping ownership of data and and systems in the hands of the government programs themselves, so this license helped us achieve that.
The last line you said really resonates with me. It sounds like, you know, that ownership is important maybe in part because it allows government projects to remain sustainable. And if I connect this back to the lock in answer y'all talked about before, programs can continue without this needed kind of rental thing with it with a particular organization in order for the government service to run. Am I kinda kinda tracking the pattern there?
Definitely. Yeah. I mean, there are very good reasons to for government programs to, work with people outside the government to get more done and to, include best practices. But at the end of the day, who's gonna be there to keep running these programs? Government staff.
Very true. And as we're on the topic of projects being sustainable, one of the advantages to open source projects is the community building that can happen around the thing that you're building as folks end up finding it either cool or useful or just something they wanna contribute to. Is that something y'all are seeing or hoping to see with Strata as that kind of community building around it?
Yeah. We've seen some community contributions so far, but we'd love to see some more. Novice experience and expertise contribute to the existing Strata reusable components and flows, but imagine how much more useful they could be with more input and more examples. I know that there's much more we can do and more that we need to do to increase those contributions. We wanna make it easy for anyone to adopt, implement, and build upon. So building out the user experience of our open source community is something I'm excited to work on this year.
Managing an open source project, particularly as a business organization, can come with its own challenges. How is Nava going about managing the added thing of competing concerns, vying for its focus as it seeks to try to keep this open source project healthy?
Mhmm. Yeah. It it can be tricky. With Strata, we're, you know, we're committed to supporting this platform long term. We wanna grow it and make it more feature risk, rich, and robust, and flexible. But we're primarily a company that's focused on directly supporting, our government agency clients who, you know, have hired us for specific projects. And we always keep our focus on that delivery. For Strata to work for our company and for delivery teams to adopt it either internally or externally, it needs to make it easier for those teams to deliver effectively. And the way that we do that is by making sure that the Strata team is talking and listening to delivery teams constantly. What we're trying to do is fold in the lessons learned from delivery teams, from work done in the field into prebuilt smart default positions so that the next team doesn't need to do all that primary discovery work like conducting the research and synthesis, building the prototypes, doing the testing, build the production systems, etcetera for really common, really repeated pieces. You know, we love that human centered process. But after we've done it a, a few times, we've tested with users, we we we we tend to know how to say, collect household income data in a way that works best for users that aligns broadly with the kind of programs that require that data. So through an agile process, through conversations with delivery teams, through reviewing research that's already been conducted, we can prioritize feature sets that will be needed again in the future and build them. So then the next time, a delivery team can rapidly deploy that proven approach, test it, and adjust from that point forward as needed to meet the specific needs of their project, and then move on to the next thing. But it requires that motion of that dialogue.
I think I hear a couple of things in that answer. One is that, I hear a focus on reusability, not just, like, with the technology, but, like, knowledge and process, kind of things that are packaged up so that not just it's not just good for one team, it's good for many, which I imagine is important in an organization like yours. And then the other I'm hearing is that, it seems like some of the focus is trying to make it so the tool and its health is tied to the value in the partnership. So it's not like, hey. I have to set up a separate activity that requires some investment to keep the tool healthy. It's like part of our work together is to use this and keep it healthy as part of the maintenance, like the upstream part is part of our work. Am I following you there? Is that is that kind of a focus as you see?
Yeah. That's right. We wanna help we wanna help go further. You know? So, yes, there is definitely we wanna keep those things aligned so that so that we each time, we each each at bat, when we get up to bat, we're able to start off and start building from the positions that we've done before with other clients. But, yeah, keeping those things aligned, making sure it's it that Strata, makes it easier for Nava and others to effectively deliver against, you know, government missions is really critical.
What advantages do you see approaching services delivery using a templated approach, like with Strata, as we've been talking about, where it's a bit of an in between gradient between something that's fully custom, against something that's, like, fully a software as a service offering. It's somewhere between.
Yeah. Well, you know, smart defaults let us focus on and get faster at solving the unique needs, in in a in a client implementation. We wanna help Strata, adopters go farther with the resources they have. And it's kind of like the moving walkways at an airport. You hop on, get farther faster with less effort. So by using a templated approach like Strata, they can skip past many of the repetitive early startup type activities and jump ahead to working on features and functionality that is central to achieving the mission. We want to remove as much of the basics that make it slower to deliver outcomes for users. You know, The US web design system is a great example here too. We don't need to spend time designing basic user interface elements like buttons, form fields, etcetera. USWDS already did that. They made sure that the patterns were accessible and mobile responsive. So something like USWDS has really gained a lot of traction because it really clearly has a value and it's easy to adopt. So they can skip ahead and focus on, you know, what does not what not what does the UI need to look like at every minute detail, but what does it need to do? And so we're trying to do the same thing with Strata, but at a deeper infrastructure and application level.
It sounds a bit like because the setup is opinionated in a way, it it kind of makes some choices for you early that that you could spend your wheels on. You know, early architecture decision records can need a lot of time at the beginning of a project. And, even, like, web design system stuff, like you mentioned with The US web design system. Those choices on, you know, how should the button be? What's the design language? Like, what experience we're trying to do? This also can burn a lot of time, energy, and, like, decision energy, which much like people, I think organizations have a limited amount over a period of time. Would it be right to say that that's one of the the primary goals of a tool like this is not to spend the energy there, but on, like, your program and how it interacts with the tool.
Yeah. That's exactly right. And, you know, it ties back to what you said earlier. It, you know, it is codifying lessons learned from the field. You know, it's we are Nava is a human centered, company at its core. So the things that we are, codifying into Strata are things that we have worked on, tested, evaluated, and have found them to be, good practices for this kind of work. So they're not neutral positions. You know, they are really building off of those lessons learned, codifying them in a way, and then create putting those in place so that the first thing teams can really get started on is adapting them to to to to function for the specific mission of that contract or that project.
I see that the project covers templates for three different tech stack options. There's one, starting with Next. Js, which I think the earlier example was one that used that one. There's another option, Ruby on Rails, and one with Flask, which is a Python ecosystem. Why did y'all choose those specific ones as technology tooling choices?
Great question. These tooling choices for the Strata application templates offering were based on what we've evaluated and implemented on current and past projects and represents many years of successfully delivering with our government clients. They represent a combination of factors such as what's industry standard, tried and tested by many development teams across the tech industry. Also, what's well supported, including a robust ecosystem of open source libraries and some and that are used on high scale, high availability, and secure systems. Another factor is that large pools of industry talent, and it, these tools are attractive to top industry talent to work on these types of tools and systems. And existing technology preferences for some of the government agencies that we work with. If the government is already working with a particular stack, let's meet let's meet them where they are. And this is just on the application level. We also have the Strata infrastructure template offerings, and we have support for both AWS and Azure so we can leverage best practices while fitting into our government partners' cloud provider context, for instance.
As we kinda keep on this, like, how Strata structured conversation, what tooling and patterns are you hoping to champion and promote by the way Strata was designed and ultimately built?
At the highest level, we're trying to promote open architectures, that help government agencies address that challenge we were talking about with vendor lock in. And as I said, a lot of contractors try to build entrenchment through obfuscation. They wanna make it hard to understand the systems, modify them, and hard to move away from them as the contractor. So Strata, in contrast, is completely open. So clients, competitors, collaborators, everyone can see how things work. Now if an agency chooses to use Strata, they aren't required to make their systems open too. They can, you know, take Strata, use it themselves, and keep it all closed. But we think it's advantageous if they do make it open, as well. That way, as they evolve their systems, they can nurture a developer developer community that understands their system architectures that makes it easier to switch contractors if they're unhappy with their current one. It also keeps everyone on their toes knowing that the source code is public. They need to make sure that the code remains high quality. So championing that openness is a big one. Also, we want to be as we wanna be agnostic to cloud providers as much as possible, minimizing lock in there and maximizing flexibility and portability for agencies. And then there really are a whole host of patterns and templated, components that have been proven in real world solutions. These can almost, be seen as grab and go. Say you want to use AI to review incoming documents to head off errors that before they happen? Well, great. We're currently working on adding this functionality to Strata right now, so stay tuned for that. So there's that general, reuse of proven, components and patterns as well.
Something that resonates for to with me from this answer is, again, kinda talking about that vendor lock in bit as well as the mention of, obfuscation as a strategy. Something that, in my day job life, I've had the fun of talking with both as a procurer as well as a builder at different times is the kind of risk management element of open tools versus closed tools and tools that kinda require a certain amount of long term lock in in order for them to be useful. Do either of you have a a take, for someone that might be out there trying to have that conversation with the organization about how an open tool might put them in a better long term position with their kind of risk profile with a project?
You know, every system has risk. The question is where the risk lies. With proprietary soft software, there's a lot of risk concentrated in a single vendor. You know, you can't see the code. You're dependent on their timelines. And you may have limited leverage if priorities change or costs rise. Open source distributes the risk differently. The code is visible, multiple organizations can evaluate it. Security issues can be identified and fixed in the open, and then agencies can retain more control over how and when changes are applied. That doesn't mean that open source is automatically safer, but it does mean that the risk profile is different and often more governable, especially for organizations that already have strong operational controls.
For folks out there that have listened so far and are finding themselves interested in this work. Maybe they wanna try it out. Maybe they wanna figure out how to contribute, to the project. How can they go about getting started with Strata?
Absolutely. I love this question. So what to do next? Well, visit our Strata page on novice website to learn more about our offerings and about how to get started. Please visit our Strata GitHub repo to explore and find ways to contribute. And, of course, you can reach out to myself or Ed with any questions. We'll have Ryan include our emails as well as those links I mentioned to these pages in the show notes. Thanks for asking.
LP, thank you both for joining us here on Civic Tech Chat. I have no doubt that the insights we unearth today together will, help folks out in their work and maybe just be an interesting note to their day.
It's great to be here. Thank you. Yeah. Thank you, Ryan. Thanks for having us. We've enjoyed it.
Visit us on the web at civictech.chat, or subscribe to us for content updates wherever it is you download your podcasts.