so $700B in defense spending can't match some motivated, talented FLOSS devs? that's rich.
With the exception of:
The motto seems to be: "Open Source is BAD! How are we going the get support?! Let's just buy a product or solution from a vendor" Even though they have people/teams who were hired as developers. I have so many horror stories, it's not even funny.
DoD mindset re: digital acquisitions is changing.
- KR dudes are great and will probably unfuck the AF's tech if they have enough wiggle room and command support against Lockheed and co. Hiring at GS-12s, few weeks approval, quick clearances, other unheard of comp strategies to get good civ talent.
- Army futures command is ..... near retired E9s and O6s in cargo shorts and underarmour polos, hiding out in the Austin Wework
KR stood up by working closely with Pivotal who supplied both the Pivots to pair program with the comparatively inexperienced AF devs as well as the deployment platform.
While the means are debatable, the ends that Units supplying devs to KR had to face we're not. Those Units got back programmers completely reliant on Pivotal Cloud Foundary. You would get devs that had no concept of what happens to their code after they run `cf push` and the Units had to face the reality that their devs were ineffective without PCF which costed 10's of millions to purchase and maintain by a team of Pivotal engineers.
Obviously Pivotal is a company that exists to make profit but smaller units that supplied devs to KR largely felt taken advantage of. And after that you had things like SpaceCamp, LevelUp, Platform1, that are very similar to KR just without the heavy reliance on Pivotal or their products popping up left and right.
Now that it's gone on for so long even leadership in KR is getting pressured to actually produce a product ready app for all the money that's been dumped. They have plenty of MVP's but afaik nothing to big AF's satisfaction.
At least from a lowly enlisted programmers perspective you can live in Boston in civilian clothes for 6 months.
While we do have spring applications running on PCF, we have a significant and growing number of services and applications that are not built on PCF and PCF isn't required to build a production application and be CATO compliant. In fact almost all of the applications and services in my branch are not.
There are also various parties working hard to promote more OSS use in DoD, two examples: GAO, OSSI. Not to mention the DoD is mandated to release at least twenty percent of its own custom software as open source. Like anything gov, it's a slow process.
Also, the requirement to release at least 20 percent of custom-developed code as OSS is not a sole DoD directive.
They are just enforcing the Federal Source Code Policy from: https://sourcecode.cio.gov/OSS/
[1]https://www.candp.marines.mil/Programs/Focus-Area-4-Moderniz...
Not really accurate anymore. Maybe it was true a decade ago but when I worked in the DoD space almost every single project was attempting to use ONLY FOSS where possible and to try and move off of companies proprietary stuff.
Unfortunately most of the projects I've seen ended up failing and Palantir usually sweeps in and gets a contract because the users really like it.
There is a huge want inside of the DoD for FOSS, it's just mortally wounded by others who want systems like Palantir or through simple incompetence.
In my experience, anyway.
I'd love to see some data on FOSS usage across the DoD but that type of audit is likely impossible.
Not in my experience. The problem is not technical talent, it's culture.
That's not to say it's impossible to solve these issues, only that a culture of top-down "get it done" does not tend to mesh well with the rigid discipline needed to make a secure product. Ever had to say "no" to a general?
On any system built in house, there will be management feature requests which force security compromises. For example, "We must archive the data of this comms network - we have a legal requirement to do that!!" or "We need to ability to access user's data for internal/external investigations", etc.
Solving these issues in a secure manner is incredibly hard, and IME it can be incredibly difficult to explain to someone non-technical why "just do X" will harm the security posture. More often than not, a developer (with their salary paid by the boss) will be forced into "just doing X" by someone who does not truly understand how much that compromises the system. Boss will be happy, thinking they "pushed it through" and non-crypto developer will be happy thinking "it has some authentication applied so must be secure" while cryptographer will be largely ignored or misunderstood. (Note: not a cryptographer, but I am an expert in other domains and have worked with enough to see their pain first hand)
Most non-cryptographers on the project start to get confused, typically thinking all of the compromises are OK because they only open doors for the DoD and that is who the product is for, without having the training or knowledge to realize how problematic this thinking can be. IMO - listen to your cryptographer, you hired them for a reason.
I don't think the problem is "top talent". I think the problem is how people think about software, and therefore how they budget for and manage it. And I don't think the problem is unique to government. I've heard about plenty of private sector giant-project boondoggles where enormous sums were wasted in similar fashions. It's just that those don't make the newspapers, but instead get gossiped about by tech people over beers.
Think about it: if you want to implement an echo server that can't be cracked to view previous things it echoed, you could probably do it quite well. Now imagine I bring a billion dollars, and some more requirements, and I hire a few hundred people to work with you on this, and some of them are security consultants, and some are compliance guys who want the echoed text saved for compliance, and some others are privacy experts who want the echo text inspected by DLP software so that you aren't sending PII.
I rate former you more likely to succeed than latter you. In the first problem, it's technical. In the second, it's organizational.
There are not a lot of people who can do crypto well, and they tend to be too weird to make good government or megacorp employees. The NSA will have people capable of doing it, but they undoubtedly have more important things to do than write a chat app.
They could hand a billion dollars to Microsoft or Amazon, who would happily take it, but would that produce a better result? Or any results at all?
Or simply do not want to work for the government or a megacorp.
If the NSA can make it secure against themselves, that's not a bad start.