Recently I posted a basic statement by Major James Neushul, USMC Communication Officer and Information Management Officer. Below is his full statement – available nowhere else online – I’ve highlighted some key points. It’s a bit of a long read, I know, but it’s worth it.
Military software – by and large – sucks.
- Most military professionals don’t know or care about software, and do not distinguish software from systems.
- Military Industrial Complex (MIC) corporations cannot and do not compete in the real economy.
- MIC corporations are protected behind “Systems Engineering” requirements that are layered with policies enforced by military professionals who don’t understand them.
- “Systems Engineering,” “System of Systems,” “Configuration Management,” “Systems Integration,” and “Security Accreditation” are MIC supported concepts that are used to preserve system-centric MIC profit motives and cannot be associated with verifiable success models.
- MIC corporations persist socialist style mediocrity behind a facade of legalistic capitalism.
- DOD system architectures are completely divorced from DOD operational architectures to the detriment of Warfighting effectiveness.
- Net-Centric Warfare Doctrine is an excellent effort that has never been realized, despite widespread claims of success.
- Net-Centric Warfare objectives will not be achieved until exclusive use of open standards and public domain Open Source software are mandated and enforced in the DOD.
- The DOD owns all of the software it has paid for, but demonstrates ownership of none of the software it has paid for.
- The vast majority of U.S. Military software development is duplicative.
- Code re-use is unheard of due to the complete lack of policy, neglect of existing network resources, and abrogation of responsibility by DOD leadership.
- All products of DOD software development belong to the people of the United States and must be made available to them.
- Through the ignorance of their military overseers MIC corporations take de-facto ownership of the DOD software that they develop, and in doing so they steal from the people of the United States. By allowing this, military professionals and DOD officials violate the public trust.
- Failure to require that ALL products of software development activities in the DOD be made completely available to ALL DOD entities, organizations and developers using existing software repository tools is reprehensible.
Major premise: Failure to make ALL products of software development activities available to the general public using existing software repositories except in cases where CLEAR and PROVABLE security concerns exist is wasteful, unnecessary and abusive of public trust.
Minor Premise: With current object oriented procedures that effectively allow the separation of presentation and data, software that CLEARLY and PROVABLY demonstrates or reveals controlled or secret information is so poorly designed as to represent a WORST practice – and should be prohibited in the strongest terms and eliminated.
Conclusion: All DOD software development products should be in the public domain as open source.
- Web Services and Service Oriented Architectures rely intrinsically on common, collaborative, open source technologies that derive relevance from widespread use and from the “Many Eyes” principle.
- NCW objectives will not be achieved until “Off-The-Shelf” products are replaced with “Off-the-Net” products.
- The requisite skills to achieve “Off-The-Net” capabilities do not exist in MIC corporations and are actively resisted in order to preserve traditional system-centric profit models. Service Oriented Architectures require service oriented profit models that existing non-competitive MIC corporations cannot be expected to achieve.
- Adherence to traditional development practices will result in continued failure to achieve NCW objectives.
- The “Many Eyes” principle is a cornerstone security factor that cannot be matched by any closed source processes, and without which truly reliable software cannot be developed.
- Explicit mandate of open source software that leverages a community of worldwide proportions is imperative for true security and reliability.
- Explicit mandate in the DOD of open source software that leverages public domain collaboration, re-use, and development will create a revolution in military affairs (RMA), and will represent an appropriate and effective expenditure of public funds in a way that will improve national defense, promote general public security, and support critical public infrastructure.
- Arguments that posit security or legal concerns to oppose the use and support of public domain open source software are vapid, uninformed, irresponsible and support MIC profit motives that are not in the best interests of the public or of the Warfighter.
- Version control has been solved in the public domain. It has not been solved in the DOD and represents billions of dollars of waste.
- Emulation of the public domain in the DOD is not sufficient.
- The use of Microsoft Software represents blatant violation of NCW principles, waste of public funds, ignorance of real security principles, and reprehensible complacency.
- Use of Microsoft software in the DOD caused friction and inertia that retards progress and is a clear detriment to Warfighting effectiveness.
NCW capabilities will not be realized until there is congressional or executive level mandate of open standard, open source, public domain software in the DOD and all government agencies.
As Neushul quotes in the header on the original document – “You cannot solve your problems using the same thinking that caused them.” – Einstein
What do you think? Is Neushul off his rocker or the only sane person related to Military Software? Hope you enjoyed this refreshing bit of fresh thought on the subject!
Colin
Zeeg hits on a good point here – yes it's good to minimize the amount of resources spent developing something – but the federal government is so massive that you could have people getting paid to work on similar projects and nobody would know.
For a software development platform, you need the same tools – version control, etc etc. The government hasn't solved these problems and it's not only costing us big $ as a nation, it's not a good practice.
Fully Open Source DoD software has pros and cons. The biggest con is that any other state would have much easier access to our software, and would be able to toy with it at their leisure. For our allies, this is all well and good. For those that are NOT our allies, that's unacceptable.
Expand the development process, but running with the Many Eyes concept has to be tempered with the reality that we might not want certain eyes involved.
I'd agree with you except for one thing — allowing everyone access to the software doesn't mean it's a security risk; giving everyone access to the data that the software is processing is where the security risk lies. You could quite literally roll this software out to the entire world, release no data (the developers would have to implement their own test data). When the military then goes to implement it in a live environment, they only need to sanity check the code to make sure there are no intrinsic bugs left over from the rest of the world who'd been working on it, and then once cleared, load their data.
The whole article raised a flag in my mind — he talks about the "Many Eyes" concept and open source. In my own opinion (meaning I could be wrong to some of you, I could be right — but it's my opinion) releasing the development to open source would be of wonderous benefit. It'd be the epitomy of "Many Eyes"; the joy of open sourced software is that so many people get their hands on it it spawns multitudes of other ideas/concepts/designs/etc. Imagine if you took some of the creative genius that exists out there in the open source market and applied it to the work they're doing behind closed doors — the results would be endless, both good and bad.
Is upgrading the wheel the same as re-inventing it though? Because we've upgraded wheels already in the miltary — the same basic premise is the same, it's round, it rolls on surfaces that are relatively flat. As I mentioned to C. Magee above, re-inventing the wheel isn't neccessary — we just need to upgrade selectively.
I may be deviating from the intended path here, but I have felt this way for a long time and I have never laid eyes on military grade software myself. It would seem from my civilian experience that the most secure and efficient systems are those upon which the least developer limitations have been placed and the most user customization is possible. Also,larger populations seem to attract larger "predators" (for lack of a better term) . It has been my thought, then, that military software should by and large be developed and used by the military so that the population of active computers is incredibly small and the code can be directly modified by the institutions using it without compromising national security. I realize that this sounds a lot like re-inventing the wheel, but if you want a wheel that can't be shot out by your enemies, then you *are* going to have to reinvent the wheel.
Once again proving that things with too much gov't interference generally operate innefficiently. Laissez faire s'il vous plaît! (sucky french…oh well)
Very true stuff, Pete. Very true. And don't worry about the poor french – I can't tell it's bad anyways.
Take care, thanks for stopping by.
Think past secure / sensitive / militaristic technology to everyday stuff – procurement, supply chain management, project management, inventory management, resource management. Think of all the programs they have to do menial tasks that everyone could benefit from.
Doesn't the public – who pays for this stuff with tax dollars – have the right to see the stuff that isn't sensitive?
After all, sensitive stuff will never be released to the public domain – but think of the other 85% of the government software out there (made up that percentage to make my point)?
This pre-supposes that US DoD software is worth using and that they can't already get better software on the net. I have worked with some small, poor foreign militaries that are using state of the art encryption and open source tools that eclipse what US DoD can do. Beyond that – source code is only the ingredients. With proper version control – the source won't be compromised. Security through obscurity is the hallmark of closed software, as if because it isn't publicly releasable our enemies can't get access to it. Invalid assumption. We have to assume that all source code is available to our enemies. Better to acknowledge that up front and move on.
Being on the fielding end I can contend that you are misguided – probably by your Military industrial Complex employer. You can use Google to find out the legal DOD policy toward Open Source software, to include specific admonition to consider it. You can also find out all you need to know about waveforms, combat ID information, EPLRS (portions of which are in fact open source now), and if you are a software developer you will also find out that the DOD is well behind the general public in capabilities and knowledge. I've seen it done wrong from a desk chair, as well as from Al Anbar.
Most Marines I know are not good computer programmers. However, most computer programmers I know are not good computer programmers, either. Regarding math skills, look at the bios of Marines O-3 and up, and you will likely find a technical bachelor's degree, a Masters degree, and a fair amount of specialized training. These men and women are smart–you underestimate them at your peril. (And by peril, I mean getting a bayonet plunged into your chest.)
Yep – so I feel it's more beneficial to have a discussion about open source applied to the federal government than the DoD. It's just that Major Neushul has experience in the DoD and can identify what he sees there.
I'd love to talk to some software developers in other areas and get their take on this. I'd also love to get a one-on-one interview with Major Neushul and post it here.
Yes, it comes with the territory. No worries though – everyone's allowed to hold their own opinion.
You make another good point, Zeeg. Let me put this quote out there… from another source:
"In reality, Open Source projects are tested and accredited the same way as closed source solutions. The biggest difference is that if questions as to the security of stability of the software come up during accreditation, there is the ability to inspect the source code as part of the process."
The thing is Colin, you're close to right on the 85%. Most of the software development done by the military -isn't- security sensitive. The things that are security sensitive aren't being laid out to people on a regular basis — military personnel get bits and pieces over time
Marines can not use computers. They do math with rocks and sticks. This blog is a hoax.
It is true that Marines would rather hit you with the computer to kill you, but if clicking does it better, they'll do that too.
ITAR makes open source military software impossible and illegal, and i disagree, being on the development end we are very close to fulfilling the NCWD, the main problem is it takes years and years to develop this stuff, so needs typically outpace development (same problem occurs in airplane industry). Open source would mean having to reveal details of waveforms, combat ID informaton, EPLRS data etc, it would be a disaster if any of this information or its inner workings were revealed on any level to our enemyies. Its great to sit in a desk chair all day and talk about how its being done wrong, but with all due respect, you dont know your ass from a hole in the ground.
As a former military contractor, I can say that this movement towards OSS for the DOD is long, long overdue. Reading the Major's "manifesto" here is nothing short of exhilarating for someone who has been thinking & saying most of these exact things for years (albeit much less eloquently); reading this is exhilarating because here's someone who not only has the connections and the credibility to make things happen, but who clearly *gets it*.
Morrissimo – thanks for dropping by and giving the Manifesto a read, and taking time to comment on it. I'll have more content coming with the Major as time goes on (working on an interview now), so continue to check back and see what's going on. People working together can change things – we don't always have to accept the status quo.
Morrismo – Semper Fi. Your sentiments are ubiquitous across the workforce. Many many DOD contractors are intensely frustrated by the "make it wrong deliberately and get paid to fix it" racket that they are often forced to perpetuate. The military leadership simply doesn't know enough to properly supervise, which is why some higher intervention is required. Anyone who reads the DOD Federal Acquisition Regulation (DFAR) can see that the rules protect the DOD very well. DOD can do anything it wants with the code, to include open sourcing it. Contractors tend to have too much influence on their military overseers. OSS would definitively change the game.
Major Neushul is spot on. The U.S. Marine Corps and the DoD as a whole has very intelligent methods by which we protect our data. For those that read this blog, I suggest you do some googling on Suite A and Suite B algorithms, comsec, and transec. Given that a large portion of our "data" flows across email, running on microsoft exchange (another huge error of our ways (security, 50 MB inbox etc.)) (Hey look i double nested a comment), you have to suppose that in that particular medium for transmitting data, our enemies are running exchange as well, likely 2007 and not 2003 (HA!), but this aside. The speak of open source code obviously will have very minor limitations to opening it up to some kid in his mom's basement with a Star Trek fetish that watches "Wargames" twice a week. We are going to establish a GForge site that is PKI enabled, and will keep the vast number of monkey code warriors out of our code. This being said, a great deal of our code should be opened to the general public. The use of JBOSS for example as an ESB is no huge secret. The development of a SOA stack to present user defined operational pictures for Blue Force Tracking, Logistics, Force protection, and Fires for example is no big secret and the development of the tools, portlets, widgets, etc, are no big secret. We will be doing this and are developing to Web 2.0 and Web 2.0+ standards right now. We have development efforts underway to leverage the open source community right now. We will succeed because Marines like Major Neushul and myself are going to lead the charge! Currently, some of our most secret data exchange mechanisms are using W3C standards, and open source code. But ha ha, you can't see them nor will you ever. The beauty of the development is within the eyes of the beholder and we see great things in our military future for Open Source software development. Some of it you all may see, some of it you may not. Some of it will be Open Source in a public domain, some of it in a government only domain. Currently I can name 10 organizations in DoD working on SOA and exposing data. Do you think they talk? Hell no!!! Do you think we are wasting tax payer money on this crap, Hell Yes!!! Do you think we don't recognize it and aren't trying to change it? Think again.
The Agility, is the Capability!!!
Semper Fi,
"GForge site that is PKI enabled" – WHO? WHEN? HOW? I've been talking about this for years. How can I help make this happen?
michael.t.howard1@us.army.mil
Contact Mike Howard at SPAWAR Charleston, he will be the one instantiating this idea that came of last weeks meetings.
I don't really get the point of posts like this… Why bash the Marines?
They make monkey sounds when they click and fling poop on the monitor.
Great perspective there Neutron – I think you're right – we have to assume they have access to the source code and go from there.
Enjoyed your posts – thanks for dropping by.
Unfortunately this is one of the many side effects of getting Fark'd. You'll get a large influx of new users/commentors, some with good feedback, some with bad feedback, and some who just like to bash on everything.
However, back to the relevant point at hand:
TheEnder talked above about how Open Source means we'd be revealing sensitive concepts (waveforms, combat ID information) to everyone — not the case. A lot of what is developed on a military level can be open sourced and not have any impact on the sensitive things — the flaw is human error, not the policy of Open Source. If someone in the DOD lacks the neccessary brain cells to realize "hey, if we release SpecificPieceOfSoftwareV1.0 to the public, then they'll know all of our top secret combat formations!" that isn't part of the Open Source problem. Again, as I mentioned above — the base model of the code can be released to the public with the sensitivities stripped out and it would still be of benefit.
It is very important to distinguish the data from the software. Security flaws arise in software and it's better to address these sooner than later. Releasing this stuff to whoever wants it would just prove to make the software better in the long run and identify security leaks. The majority of this software is stuff that would not be a security risk if open source procedures were adopted.
Even within the Military there needs to be more open-ness. How do you know what someone else in another division is working on if there's no central code repository? There are different degrees of open-ness that could be adopted at different levels for different projects.
Sorry — my last comment was cut short due to an issue trying to post.
Reposting full message below:
The thing is Colin, you're close to right on the 85%. Most of the software development done by the military -isn't- security sensitive. The things that are security sensitive aren't being laid out to people on a regular basis — military personnel get bits and pieces over time; what they need to know.
So that 85% (I'd wager it's likely close to 75%) are things the public domain could benefit from, if not directly than indirectly. Imagine releasing an entire software development platform that the miltiary's had locked away for years; a whole new language/menthodology/etc — they only need to release the base model, no secure data, no secure code, just a base model. That base model could revolutionize the way program development, systems analysis and design/implementation are handled — and what would it cost? Nothing.
That's right, the mil could drop the thing online (I'm thinking in a manner similiar to SourceForge) and let the public take what they wanted from it without ever risking security.
There's a whole world of technology, both hard and soft, that the military keeps locked up from the public – but they're doing themselves and the rest of the world a major disservice by not releasing it.
Wow.
How did you get a hold of this otherwise unavailable information?
Bad idea. Releasing military software to the public would give our enemies our software capabilities, and would also expose our software vulnerabilities.
Generally speaking, open source only makes sense to your competitors. They LOVE it!
A buddy of mine where I work works with Major Neushul – and he showed a group of us at work interested in Open Source the Major's document. We talked about it for a bit and decided to post it a few places to gauge the response.
Thanks for dropping by!