The DoD is prioritizing open source software
ritwikgupta.me
ritwikgupta.me
Anecdata, but most DoD program managers (CIV, CTR, or MIL) I know who work on software programs are generally driven by a need to solve the problems that they face. They gladly embrace open source solutions when they're made available easily.
AT the bare minimum, even doing it yourself, it costs more money to create a company and apply for 501C3 status than the paltry sums of money most projects receive in donations.
> (1) Government employees may contribute to existing OSS projects (including being the primary maintainer) as part of their official duties, so long as they consult with their supervisor first to ensure a common-sense approach for contributions that preserve Operations Security (OPSEC) and further the Government's interests.
NB there's no such thing as an "Open Source community", just individuals and orgs with different goals: some want to show off, some want additional maintainers if at all possible, some want to give away their complement, some want to establish an alternative to a competitor's product, some want to promote a language or format, some want xGPL for political reasons, yet others don't care at all
What is that based on? Have you worked at DoD? Is there research supporting it?
DoD acquisition depends much more on civilians, not uniformed officers, and then they must be part of the President's budget and, ultimately, Congress. Officers play a minor role.
I work at a Navy research center that's 3000+ employee strong and feeds all of DoD (we're a working capital fund, meaning we take customers to fund ourselves). In four years here, I've worked projects sponsored by Air Force, DHS/CBP, Navy, Marines, and two three letter agencies. There was no general involved in any of them, and I don't know any projects by coworkers that involved acquisition of technology. As for my projects, all except one still still in R&D have transitioned into production systems. All involve OSS to some degree. One was a design for a COTS multi source information fusion system meant to be deployed in the cloud and has all the open source tech there you'd expect, NiFi, Kafka, Spark, etc. My current project is a combination of us (correlation) and two contractors (separately IT and predictive models). Again, it's all the OSS and tech you'd expect to find in a real time analytics/tipping system and CI/CD pipeline/orchestration.
I bring up my experience not to say you're wrong but to show there are other avenues it comes in. There are lots of research labs, and researchers aren't about buying software from contractors.
In these DoD research environments (I've worked in them before), researchers typically aren't about building software, either. It's expensive, even if you hire the teams. Not always, but unless your research is technology driven, it tends to be about cutting corners on software and delivering research quality MVPs (semi-working prototypes) while all focus is on the research. You can forget overhead of best practice infrastructure for development/engineering, that's wasted overhead in some of those group's eyes. The more theoretical it is, the easier it is to get away with, the more applied, the less easy it is to handwave away reality.
If you're at a heavily funded technology focused org like NRL (which the description sounds a lot like--neat stuff comes out of NRL), then this can be the case. There are, however, a lot of DoD funded research labs that are dumpster fires in terms of the software--NRL is almost the golden child compared to most of them. Again, in some such labs, a project may only have sufficient budget for 0.05 to 0.1 FTEs worth of software engineers. In such cases, 0.4 FTEs of software engineers can be considered a significant investment for a project, which is beyond laughable.
I'm not sure what the typical cost for an FTE are in industry, but I believe they are lower than 3-4x base salary.
There are often large gaps between the mission requirements and the technical capabilities of open sources software, and research labs lack the expertise and budget to address those gaps in practice. Of course, the usual system integrators can't build this software either but they will charge the taxpayer a lot of money to fail at it.
License fees are a rounding error compared to the cost of personnel.
A commercial vendor works to please large customers, such as the military. If the big customer needs a feature supported long term (remember that military systems commonly last decades), the vendor makes it happen. If the big customer needs a specific enhancement or fix, that is a priority for the vendor, and if it's needed ASAP, that can happen too.
FOSS communities are a bit more independent-minded (which I generally like) and some developers won't want to help the military for ideological reasons. Communication with FOSS communities is much different than communication with commercial vendors, and much less efficient.
I think DoD needs access to paid, professional developers who can provide those services for FOSS. That could be someone like Red Hat, it could be outside consultants, it could be internal developers, they could hire members of the FOSS community. Also, DoD will need to fork projects when the community is uninterested in a DoD priority.
And there's another major problem: Imagine bombs are falling, people are dying, national security priorities are being lost - and the military needs a fix or enhancement now. Submit a bug to bugzilla and wait? Email the dev list? IRC? They need someone to call, who can answer the phone and get things done.
I think there are still one or two steps/precedents needed from this memo to a real pipeline of FOSS projects getting DoD funding, but these projects would be foundational things like video transports protocols, container orchestration tools, etc. (to name a few).
In addition, if there is a mission-critical fix which needs to be made to a project, this memo authorizes + encourages DoD personnel to contribute to FOSS projects!
> Employee participation in OSS projects used by DoD is often in the Government's interest, and is typically a legitimate use of government resources when the Government uses the software in question, either directly, as a component of a larger government system, or as a component of underlying government infrastructure.
> (1) Government employees may contribute to existing OSS projects (including being the primary maintainer) as part of their official duties, so long as they consult with their supervisor first to ensure a common-sense approach for contributions that preserve Operations Security (OPSEC) and further the Government's interests.
Yes, but that is rarely a means to get anything done urgently.
Of course. You have to do
sudo ./war.sh -f --command STOP
systemctl war.service stop
or
systemctl stop war.service
That much is a given, and it was already true today. Even if DoD would do nothing more than contract for outsiders to build its software, the people writing the contracts need to have access to government staff who understand software (i.e. actual developers).
> And there's another major problem: Imagine bombs are falling, people are dying, national security priorities are being lost - and the military needs a fix or enhancement now. Submit a bug to bugzilla and wait? Email the dev list? IRC? They need someone to call, who can answer the phone and get things done.
I regret to inform you that the military is already used to this taking months and years. The Navy was unable to field a COVID tracking software tool in time for it to matter when the aircraft carrier USS Theodore Roosevelt got sidelined by COVID, the needed tool ended up being fielded by Defense Digital Service who operate under different authorities.
But even if we pretend the wider military could do need this, that's the internal developers you already mentioned (like DDS), or developers already on contract to provide urgent support. But that's separate from FOSS vs. proprietary. If anything, the farther we get into an "everything-as-a-Service" model, the less likely it will be that a company whose product is not open source would be able to meet those kind of urgent timeframes, because making changes willy-nilly to their -aaS product may risk their FedRAMP certification and DISA P-ATO.
> If you have a large project that is getting significant usage, incorporate a 501(c)(3) organization which will officially manage the project. Funding for the effort will live in this 501(c)(3)
Not too long ago, the IRS was clamping down pretty hard on the creation of new 501(c)(3)s, especially ones that were functioning (as they saw it) as the equivalent of businesses:
https://www.techdirt.com/articles/20140701/11470827745/irs-r...
This issue doesn't get much coverage today, but as far as I'm aware, this is still the status quo, with 501(c)(3) applications being subjected to additional scrutiny and denied regularly.
And it is also probably setting up obstacles for getting money from the DOD, if they aren't expecting to bill a fiscal sponsor as an intermediary.
We have a Github, but in a lot of ways it feels kind of like an archive. Does anyone have feedback on how it can be made more useful? We have all the authority to be good OSS community members.
Maybe if we were to prioritize like general purpose libraries instead of just our super domain specific projects?
It is needs to be repeatedly brought (but gently).
Forward links to success stories, provide counter arguments to FUD (but again, gently!)
I say gently because it's easy to create enemies by making people look bad, and that's a no-no, you have to gradually wear down the old consensus and build a new one.
Add a description to every repository.
Make sure every repository has an informative README. There are a ton of templates and generators out there, most are pretty good (if you find or create one that is especially useful for your agency, consider promoting it internally).
Now comes the 'next level' stuff.
If a project would be useful in an academic context, perhaps include a blurb on attributing a citation for it.
There are a lot of folks out there looking for projects that will accept their contributions so they can build up some cred. Populate projects' issues with stuff you can tag as a good-first-issue, and your projects will start showing up in various aggregators (be judicious about selecting projects to do this for, you don't want issues and PRs languishing without being incorporated for lack of maintainer interest or time, that just looks worse).
For projects that really are just being thrown over the transom, mark them clearly as such and invite friendly forks.
Try to imagine who might find a particular project useful. Write that up as an example and incorporate it into the README or other documentation (eg. I imagine that anything related to stormwater runoff may be useful to civic planning departments, or perhaps environmental advocacy groups). Blog/tweet about the use case (your agency's comms team may be helpful here).
I hope these suggestions help.
Every time a major org claims to be open to OSS it rapidly reverts to old tools and ecosystems. The new CIO can claim all he wants, it's not going to happen. DoD is run by entrenched civil servants. I've seen it happen time and time again in MDA, Army, and Navy work.