[thisismyaccoun7]

Acquisition is not the only way DoD operates.

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.

[Frost1x]

>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.

[amcoastal]

Out of all the comments in this thread, this one has been the most like my experience.

[quadruplebond]

If dod research labs are like NNSA research labs part of why 0.4 FTEs can be considered significant investment is because overheads are quite high. My experience is that for every dollar a FTE makes their project is paying an additional 2-3 dollars in overhead. That means your $130K/yr FTE is using 50% of your $1M/yr budget.

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.

[jandrewrogers]

I think the best future model for DoD software is to bring much more of the systems integration and product development in-house, mostly using open source, which will produce a higher quality and less expensive result for the DoD. Critical differentiated software technologies will be outsourced to boutique software companies that can offer software capabilities that are qualitatively superior to anything available in open source but can't be developed on DoD software engineering wages and/or budgets.

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.