Interesting. I don't see the point, though.

The issue with the US government and software is not a lack of talent (within the country, or even within the government itself). But a poor structuring and assigning of responsibilities and a severely risk-averse culture, paired with the overreaction of a risk-accepting culture occasionally showing up and fucking it all.

There is, or will be, sufficient talent in the US to maintain and develop government software systems. Flat out, people keep going into CS and software engineering degree programs. Programming itself is ludicrously accessible compared to nearly any other technical discipline because the cost of entry is about $200 and time.

The problems that actually need to be resolved:

1. Government employees (contrary to popular opinion) are grossly underpaid for their expertise. This leads many of the best to leave and go to private industry and/or government contractors. Those who remain are truly civic minded, or zombies. Moving away from GS helps here (pay for time in grade), but the alternatives are also severely abused. NSPS paid people for changing positions, so there was a ton of job hopping before it was canceled. Expertise wasn't really cultivated, only the same stupid culture of bouncing between jobs you find in parts of private industry. AcqDemo is somewhat better, but in implementation lost all its potential value. Still better than GS, but only barely.

2. In-house development shops are typically made to compete for contracts in the same way as private companies. This creates some interesting conflicts within the organizations. And a ton of the in-house software development efforts are spent on maintenance, not developing new systems. So a different kind of expertise shows up, but not the expertise needed when truly novel projects start up.

3. The people in charge of the IT and software development efforts are usually inexperienced with IT and software development. They're either straight out of college EEs (CS people are at a disadvantage in many government shops) or career civil servant bureaucrats. The latter rely on those same inexperienced EEs. This leads to an incredibly advantage for contractors to push program offices around because they can come off as reliable experts, until you've been burned a few times. But hit a couple milestones and the civil servant in charge is already promoted out of that position and a new one is left holding the bag when shit hits the fan.

4. Risk averse IT severely restricts development environments even when software is made in-house. This leads to incredible slowdowns and often automation is impossible due to having to develop and test on multiple test/dev network enclaves that are separated even from each other. An example is the typical CCB (configuration control board) process which is a monthly (at best) meeting where, mostly, managers decide what new things can be installed on the network. You want an updated version of VS or GCC? Gotta wait a month. You want to use a common library? Gotta wait a month. And that's on top of the delays imposed by security scans (a manual process, that could be automated if it's necessary).

5. Risk accepting IT goes too far the other way as a reactionary response to the risk averse culture that held them back. Their fuck ups lead to the people in (4) being able to justify their positions and cement their culture.

You have to improve the approach to IT, the staffing of the acquisition offices to have competent individuals in the appropriate fields, not just successful (from a promotion perspective) bureaucrats, and probably increase pay across the board for technical people.