> No, OSS is developed by a wide variety of software developers, and the average developer is quite experienced. A Boston Consulting Group study found that the average age of OSS developers was 30 years old, the majority had training in information technology and/or computer science, and on average had 11.8 years of computer programming experience.
If true, that’s an amazing statistic.
For many things (or in an alternate universe), you would hope the opposite had been the default, and commercial proprietary software had to justify why it should be adopted.
What the senior leadership is trying to do here is create that alternate universe you want to see. Force anyone using or creating proprietary software to justify why they're doing that.
Time to go tool shopping again! Rinse and repeat for many decades.
When you purchase commercial proprietary software (especially, I think, on the DoD scale) you purchase commercial support and put liability and responsibility on some other entity. If you use open-source software, you only just get the code without any guarantees.
As much as I love using open-source dependencies as a developer, I completely understand why a company or a government agency prefer the proprietary path.
> The following organizations examine licenses; licenses should pass at least the first two industry review processes, and preferably all of them, else they have a greatly heightened risk of not being an open source software license
The first two are OSI and FSF.
Some other questions also allude to not including more restrictive "source available" licenses, presumably including commons clause, as open source.
[0] https://en.wikipedia.org/wiki/Force_XXI_Battle_Command_Briga...
While this and more recent documents [2] indicate that Open Source software is encouraged in the Army, the reality is that software selected first has to be on the site local "Approved Products List" or APL, or the wider Army APL. If it is not then an approval request form must be submitted, requiring services running, ports opened, and so on. The approval process can be weeks or even months.
[1] https://www.nonprofitpro.com/post/understand-the-difference-...
[2] https://dodcio.defense.gov/portals/0/documents/library/softw...
Sometimes the point of contact on the DoD or the program office side is a vacant position that never gets filled, and the person up the chain from them refuses to sign off.
The key is to find, institutionally, a heavy hitter doing something similar to what you're trying to do, and join forces. This is a lot harder than it sounds. The whole industry is stovepiped to a degree that's hard to express to outsiders. I've gone years before meeting peers in the same sort of spec areas I deal with, for example. Alone, with these weird arcane documents and disappearing vendors made of lies and ghosts, you start to feel a bit like a crazy person.
I can report that perseverance pays off sometimes though. As of this month my program is approved to use Rust along side C++ on our contract. We will be submitting an approval authorization to get Rust on the APL, but can use it before then since we are CRN and have contractual approval.
Also, while the section 'What are synonyms for open source software?' later clarifies what is meant by Free Software, the FSF would likely avoid calling OSS and Free Software synonyms, even if by implication:
https://www.gnu.org/philosophy/open-source-misses-the-point....
General: So, Major, how did you prepare those fine graphics of the war plans?
Major: Gimp sir.
General: 'Gimp' you say?