> Q: Isn’t OSS developed primarily by inexperienced students?
> 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.
I'm not sure what part of these statistics you're commenting on in particular. If you're amazed at how much experience the average open source developer has, it's worth pointing out that there's a lot of open source software development that is directly sponsored by enterprise-scale companies that use the software itself. E.g. companies that both use, and contribute to the Linux kernel such as Google, and Facebook. Another good example is Netflix and FreeBSD. Also relevant are processor manufacturers who contribute code relevant to their IP to GCC. It's really awesome seeing companies be good stewards of OSS.
The only problem I have with this document (which is quite good), is that it basically is a reflection of the mentality that we have to answer all these questions because commercial proprietary software is the "normal" path and we need all these justifications / answers for OSS.
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.
It's meant to combat that kind of mentality in the minds of the acquisitions specialists directly responsible for contracts. To be clear, it is absolutely the official position of the DoD CIO right now that you should be using off-the-shelf solutions everywhere possible and open-sourcing your own work unless you have a damn good reason not to, usually meaning hiding a classified capability. Otherwise, you need to answer for why you are not. Open source is very much intended to be the default for all new DoD software projects, but we need some way of overcoming the inertia of all the program-level responsible parties who still have the mindset that they need to hide everything and all software should be totally custom for their own narrow purpose.
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.
Don't forget that with Open Source, all the blame lies with the implementer. One of the huge draws for paid solutions is that when the system gets borked - as it almost inevitably does - institutional blame can be routed on to the tools vendor, instead of a business process that, if you looked at it even medium-hard, shows itself to be a mobius strip of idiocy, incapable of existing in any meaningful sense.
Time to go tool shopping again! Rinse and repeat for many decades.
> commercial proprietary software is the "normal" path and we need all these justifications / answers for OSS
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.
> Public Law 115-232 defines OSS defines OSS as “software for which the human-readable source code is available for use, study, re-use, modification, enhancement, and re-distribution by the users of such software
> 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.
I'm led to believe that the DoD is Red Hat's largest customer. This is based on my own experience seeing and using various systems in the US Army (most notably FBCB2 [0]), plus a quick web search which turned up a few articles that agree with me without giving any actual data or source.
Dr. Albert Einstein has a famous quote: “In theory, theory and practice are the same. In practice, they are not.” [1]
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.
Years. This has taken years for me in some cases. The further down the totem pole you are, in terms of technology, the longer it takes.
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 agree, it does take years sometimes. I've been working on getting Rust approved on my contract for two years. Also, an institutional heavy hitter is key like you said. Often, you cab find someone to work with in special ops, who can get waivers to use cutting edge technology for their missions.
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.
Indeed this seems like a fairly accurate account so far.
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:
> 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.