There is a lot of internal resistance to open sourcing code. Lots of people believe that their code is their secret sauce - and why would you have highly paid consultants create code just so the next department can take it?
There's also security concerns to take into account - which I know someone will say is a good thing, because of transparency and so forth. But just realize that it's not a trivial amount of work to clean up a code-base and display it to the public all of the time.
And if the policy were open-source by default, the unspoken policy for project managers would be "automatically submitting a request to be closed source"
It's not perfect, but I know that 20% is a lot, and I think anyone who's worked in the sector would agree.
Those reasons, which surely place some non-negligible burden on the teams involved, do not seem to be so overwhelming as to ultimately dictate that 80% of projects are not made open source.
I'm definitely aware of the difficulties involved in open sourcing significant amounts of your work. The bigger burden is less, in my opinion, about cleaning up your code base. If you're committing potential security vulnerabilities into your code that are then tracked by your version control system – and you're a Federal agency – that's already a problem that's just going to be exacerbated by making it public; making that code private doesn't make the problem disappear.
The real meaty problems that all open source projects share is people: people like me who come in and overwhelm the project with support requests. I just opened four issues tonight just for this website, in the span of several minutes. (Sorry team!) If you already have poor project management practices in place, or your team is too small, this can quickly overload you.
Of course, with a vibrant community around your project, even the social and management problems could become trivial with time. Look at especially great examples like Hoodie. Given the number of technical people who have left cushy, high-paying jobs to serve in 18F, USDS, and the other alphabet agencies of late, I have to imagine the rallying cry to support truly useful code by compassionate people will be significant enough to justify the upfront expense here.
Not only is 20% not perfect, I don't think it's enough. I want 100%, and I think it's a fair request as a taxpayer, even if there is some burden. This country has fought two world wars and gone to the moon. We can always do better.
Assuming that's true, private companies contracted by the government may not be under that same requirement (think military specs and designs). The output as a whole may be public domain (I know what an F22 is, and the parts to build one, but the specs to those parts are proprietary) but the operations, and binaries,(specs and requirements to build the individual pieces) to produce that output may remain private.
There's also security concerns to take into account - which I know someone will say is a good thing, because of transparency and so forth. But just realize that it's not a trivial amount of work to clean up a code-base and display it to the public all of the time.
And if the policy were open-source by default, the unspoken policy for project managers would be "automatically submitting a request to be closed source"
It's not perfect, but I know that 20% is a lot, and I think anyone who's worked in the sector would agree.