Let's start with a short Q&A that might surprise you!
Q1: You write a nifty program and share it with someone on the Internet. Is it possible for the government to show up at your door and charge you with the felony of sharing classified information?
A1: Nope! Thankfully, this won't happen!
Q2: You write a nifty program and share it with someone on the Internet. Is it possible for the government to show up at your door and charge you with the felony of creating and exporting a munition?
A2: Yup! It most certainly is.
In many countries, certain types of technologies are classified as "munitions", and the export of those technologies to foreign nationals is tightly controlled. In the United States, these export controls are known as International Traffic in Arms Regulations (ITAR), administered by the US Department of State, and Export Administration Regulation (EAR), run by the US Department of Commerce.
In reality, most software developers will never have to deal with export control. If running afoul of export law was extremely prevalent, general awareness would be much more widespread. But, there are certain fields of engineering and computer science where is it a significant issue. Certainly anyone working in infosec and cybersecurity should have it on their radar - especially given current events. The cryptography community, for example, has been dealing with this for decades.
One of the more famous cases is Bruce Schneier's textbook "Applied Cryptography". In the mid-90s, US courts ruled that the textbook, which contains the printed source code to known cryptographic algorithms, could be exported, but that a floppy disk containing the exact same source code was a munition under export law and could not be shared with non-US persons. That particular cryptography case was litigated by Phil Karn and the EFF and finally resolved in January of 2000, but the fundamental problem still exists. If you create something and distribute it, without realizing it's regulated by export control, it's up to the subjective opinion of a judge to determine whether or not you are a felon - and there are clear examples of the courts making nonsensical decisions in that regard.
Export control is particularly problematic for open-source efforts, which fundamentally rely on the sharing of information to be successful, because things you create in total isolation can be regulated by export law. This is acutely different from other types of information regulation, like data classified for national security. If, for example, you write a new software library with personal resources and in your own time, it is not magically classified information. If you post the library online or share it with friends, you can't be put in prison for leaking classified data. It is entirely possible for you to create something regulated by ITAR or EAR, though, even unintentionally. If your creation falls into one of the restricted areas, it is a felony for you to make that information available to a foreign national - this includes e-mailing it to your friend who isn't a US citizen or green card holder, or posting it online (e.g., Github). And, unfortunately, determining whether or not a technology is a "munition" is not always easy. For example, systems that perform "energy detection on RF signals" can be regulated by ITAR - but that's exactly what your car stereo does when you "seek" between stations.
Most open source projects, thankfully, are at no risk of being encumbered by ITAR or EAR. But, for those that are, export regulation poses a serious challenge. As the open-source movement continues to grow into new markets and technologies (e.g., open-source cubesats), more projects will begin to encounter this hurdle.
To help mitigate this issue, Bruce Perens, co-founder of the Open Source Initiative (among other things), founded the Open Research Institute with Michelle Thompson (you can find her on page ~5 of your ARRL Handbook) . I am pleased to join them as the third founding board member.
To be clear, ORI cannot retro-actively make ITAR / EAR information suddenly not regulated, and its goal is in no way to facilitate the sharing of such information (and that would be illegal). Rather, by being a member of ORI and enforcing its rules, the goal is to prevent a project from ever becoming export-regulated to begin with.
Another goal of ORI is to facilitate open R&D and reproducible science, and provide a home for open-source projects that might not be a natural fit in other organizations (e.g., FSF, SPI, Apache Foundation). The open-source movement is more than just software and hardware; things like open standards have been a crucial part of our largest technological advancements (e.g., the Internet), and I believe open source has an important role to play in the future of reproducible science.
We're still working on getting content up on ORI's website, but if you're interested or have any questions, don't hesitate to get in touch!
 Bruce Perens first announced ORI on his blog, which you can read here: Open Source vs. Munitions Export Restrictions – Announcing Open Research Institute, Inc..