How to engage with policy makers when you’re a developer (not a lobbyist) 

Why state AI regulations impact open source, and where to submit public comments that actually matter.

State AI regulations aren’t differentiating between developers and deployers, impacting open source contributors who could be held responsible for downstream uses they don’t control. In this episode, Katie Steen-James, Senior US Policy Manager at the Open Source Initiative, joins the We Love Open Source podcast to share how developers can engage with policy makers, why the Federal Register matters, and what the developer versus deployer distinction means for protecting open source.

Katie joined OSI in February as their first full-time US policy manager, tracking issues that affect open source developers at state and federal levels. Her background in open access to research and open science prepared her for navigating policy environments, but open source revealed just how ubiquitous this technology is in everyday life. Most people beyond the open source community don’t realize how much this technology powers what they use daily.

Working with policy makers means meeting people where they are with their open source knowledge. Congressional staff handle many different issues, knowing a little about a lot of things. Agency staff bring deep expertise in specific areas. The challenge and opportunity lie in adapting explanations based on who you’re addressing.

Read more: What version control looks like when AI agents write the code

The current challenge comes from state-level AI regulations. With the federal government showing limited interest in regulation, states are proposing AI rules that don’t differentiate between developers and deployers. This mirrors initial conversations around the Cyber Resilience Act in the European Union. The concern: Regulations could hold open source developers responsible for things happening downstream in AI systems they’re not deploying. Educating policy makers that developers and deployers aren’t always the same entity is critical.

Developers can engage through public comment periods at federal and state levels. The Federal Register, essentially the journal of the US government, posts public comment opportunities where developers can submit expertise. OSI also runs the Open Policy Alliance, a coalition of like-minded nonprofits and code-producing foundations without in-house policy staff. Katie posts relevant information on OSI’s blog and public policy pages, tracking opportunities for developers to participate.

Key takeaways

• State AI regulations impact open source developers: Proposals don’t differentiate between developers and deployers, potentially holding contributors responsible for downstream AI system uses they don’t control or deploy.
• Developers can engage through Federal Register comments: Public comment periods at federal and state levels let developers submit expertise. OSI’s blog and public policy pages track opportunities to participate.
• Asking questions demonstrates how you think: Knowing the right questions to ask is a skill. Questions show your thought process and help navigate unfamiliar territory like policy work.

Katie’s message is practical because policy affects open source whether developers engage or not. Understanding how to participate through public comments and tracking OSI resources makes the difference between regulations that support open source and those that burden it with inappropriate responsibility.

More from We Love Open Source

• 15 open source backup solutions to protect your data
• Open source for the age of agent-native development
• What version control looks like when AI agents write the code
• 6 must-read Linux and open source tutorials
• 5 forces driving DevOps and AI in 2026