They largely circumvent a lot of the process with help from policy makers at the highest levels.
Even then, I'm pretty sure they don't offer hosting/authorizing deployments from party sources. So they essentially have a monopoly on the ability to use OSS freely for bulding government websites.
> Even then, I'm pretty sure they don't offer hosting/authorizing deployments from party sources. So they essentially have a monopoly on the ability to use OSS freely for bulding government websites.
That's not quite the case. Many agencies use a ton of OSS to build websites and other services.
https://github.com/cfpb/source-code-policy https://github.com/uscensusbureau/open-source-policy https://github.com/18F/open-source-policy
The policy links above refer to those teams releasing their own code as open source, but you will find huge amounts of outside open source code being used there, and in many other agencies.
The Department of Defense is famous for (in 2003!) making sure their department knew that open source software was A-okay to use, and people refer to their amazing FAQ all the time:
http://dodcio.defense.gov/OpenSourceSoftwareFAQ.aspx
(I'm an 18F employee.)
According to https://www.govcode.org/repos, there are about 1,300 U.S. government repos on GitHub that do not belong to 18F.
If you're generally interested in how we do ATOs, https://pages.18f.gov/before-you-ship/ato/ is a nice internal guide for our devs.
(I work at 18F)
Establishing an ATO for end user systems, specifically hardware/software that is intended to connect to the military tactical networks comes with a very high barrier of entry.
Being an OCCFLD made up of media specialists (ie photographers, videographers, illustrators, reproduction specialists); they have requirements for hardware/software that fall outside the generalized platform/support provided by G-6.
Overwhelmingly, they prefer Apple/OSX but building Apple-based systems that support the wide range of security scanning, observation, and auditing requirements simply isn't possible. AFAIK, nobody has established a baseline for Darwin and the cost/risk to do so within the schedule of the systems lifecycle is too high. As a result, Windows is only option.
The systems I supported directly included laptops running a custom configuration (ie Adobe, etc) as well as tactical deployable media production studios that provide print, media, large format, networking, and archival capabilities in the field. At one point we added VLC (ie due to it's superior playback format support) but had to nix it after discovering that it had a CAT I CVE.
Things may be different outside the DOD but for the USMC specifically, MITSC are the 'gatekeepers' for the Marine Corps when it comes to establishing an ATO baseline and meeting the requirements for ATC (Authority to Connect) to the MCEN-N (ie unclassified tactical network). Frequent scans, remote access, and auditing aren't recommendations so much as an absolute baseline requirement. Don't get me wrong, they do their job very well.
When it comes to fielding COTS systems, lifecycle sustainment is a huge problem. Depending on Windows based systems and Dell Enterprise networking hardware makes the problem much worse. Unfortunately, that's what everything is standardized on and systems that can't be bought with a long-term support contract are no-go. Diverging from the standard is a recipe for failure.
I didn't deal with the ATO process directly. Instead, I provided field support, user feedback, and maintenance of the systems.
I established a distribution channels and did my best to provide periodic updates to all the systems within my AOR to meet the requirements of the ATO/ATC. I even spent months trying to hack the bureaucracy -- with little success -- to get the systems connected and operating at their full capacity.
Throughout that process I discovered numerous missing prerequisites buried among a morass of policy and documentation. I'm no stranger to reading dull/dry specifications but the literature surrounding ATOs and their application is a minefield. One misstep can lead to the loss of certification so it's wise to be cautious.
I tried to raise the issue with my superiors but as the saying goes, 'shit flows downhill'. It's not really their fault, they don't know what they don't know. I've learned not to take it personally, life of a contractor in the field is one where you'll inevitably (and hopefully infrequently) accept fault for failures beyond your control.
What really bothers me is that the Marines have to go forward with limited/degrading technical capabilities and little/no support. No amount of effort, willpower, or policy will solve significant technical problems that require technical solutions.
-----
Just to be clear, the following isn't specific to COMCAM. If anything the leadership I had the privilege to work with made an exceptional effort to always do things the right way, despite some of the ridiculous barriers we had to face. This is based on a wider perspective gained from working with many organizations across many military installations.
The DOD doesn't suffer from technical debt so much as technical poverty. Any benefit I had from being good with technology going in became a weakness. The military is a black hole of communication and information sharing. Don't get me wrong, it was an amazing opportunity to 'level up' my people skills but seriously...
I often see people complain about rampant waste and the lack of transparency in government and the DOD specifically. I can honestly say from first hand experience, it doesn't come from lazy or malicious behavior. When limited time/resources restrict decision making to a gray area between doing things the 'right way' and accomplishing the mission, it's the duty and responsibility of our service members to choose the latter. Waste and opaque behavior is a symptom of systematic failure (ex lack of knowledge, communication, unnecessary bureaucratic barriers, etc) at a much grander scale.
I probably have a unique perspective. I went in with no prior military background and a strong technical background. The former makes it very difficult to accept 'broken' as norm, the latter provides a unique perspective of what can be done to fix it.
-----
I'm a huge proponent for OSS, having contributed and/or authored many projects. From what I've seen, breaking new ground and introducing OSS to the DOD on a larger scale is currently beyond reach.
There are pockets of exceptionally talented/capable individuals with the technical background required to make it possible. Except, they represent an extreme minority and are already over-taxed with supporting the existing systems. I'll spare you a the diatribe on why the alternatives consistently come up short.
I have read all of the literature 18F has to offer (except a few blog posts). 18F sets a very good example for others to follow. Unfortunately, the platform is limited to internal use and the organization's capabilities are limited to serving the latest 'hot button' issues within the DC political spectrum.
Much like SV represents an extreme monoculture fueled by exceptional technical ability and a flood of VC funding. DC represents its own extreme monoculture fueled by the concentration of power/influence and a flood of taxpayer funding.
Beyond the bubble the state of things is much messier, broken, and in need of help.