“The US military is on the slow path to the realization that nation-building — from reconstruction to other forms of traditional COIN dogma that serve to return legitimacy to the government — doesn’t work. Politics and populations in our new global environment fragment faster than they can be assembled into cohesive entities. What does work to slow the spread of temporary autonomous zones and open source insurgencies are open source militias.” John Robb November 19th 2007 (LINK)
I can I say that I’m getting tired of seeing “open source” used in almost as lazy a manner as “terrorist”. A consistent ontology or tautology is important for making sure terms are used as needed. The terms we use can be subtle in the message they give beyond the overt. Software developers and technologists have been manipulated into believing open source software (Linux, Apache, FireFox) should be trusted more than the evil closed source software (Microsoft). It doesn’t matter what facts are used to support either side the emotional answer and the best of either side are used as examples. The reality is the mediocrity of either side. That subtle manipulation of reason and the ascribing of a term like “open source” could be considered a manipulation that creates trust in those who don’t quite understand (most of the public), and is ignored as another buzzword by those who don’t care (most of the military).
“Open Source” gets used with software development and has been a huge buzzword for about thirty-five years. Richard M. Stallman started the movement in about 1970 in his fight against copyright and patents of software. His basic proposition is that “closed source” cannot be changed by the owner of the software and that all software is collaborative and therefore can not be owned, and that nobody should make money off the creation. This suggestion is similar to the tripe of other socialist 60’s radicals saying creation is not worthy of compensation. The author of the book should make no money on the prose between the covers as a similar example. Secondary, and even tertiary benefits in open source have been proven as positives with open development and “all eyes” on the code being security and scalability positives. The actual beneficial nature of “all eyes”and collaboration are easily argued against as more “open source” projects change their license models. The actual statistics regarding the number of people supporting open source software development and auditing open source software suggest there is not nearly the volume of trained developers looking at open source software.
“Open Source” gets used by the intelligence community to describe materials and channels of data and communication that are available to the public, but perspective or other knowledge allows an analyst to ascribe value to that otherwise unimpeded conduit. Anybody may have access to the information but the intelligence community is not changing or customizing that information in any way. Open source in the intelligence community may be “all eyes” but it is not subject to customization. Further the source is not the product as in software development but the provider.
“Open Source” has been applied to the larger idea of community information sharing and manipulation such as Wikipedia. Where the community determines through a variety of methods how content will be created. In all of these examples though there is the idea that the broader community is involved in the process. The broader community being anybody who wants to be involved. Anybody is a big community. It is true that you can restrict a “wiki” to a smaller group, but you begin to take on the concept of using “open source” tools for closed source implementations which is pretty much against the rules of “open source”. You can’t take a “open source” project/process and then close them to scrutiny according to GNU, GPL, Creative Commons licensing standards.
Now we are going to apply “Open source” to warfare. This is stretching a software development concept as a metaphor to the breaking point. Why not use “component based” warfare, or better yet “object oriented” warfare? Rumbaugh, Booch, Yourdon, Jacobsen would be horrified but it might be worth seeing the look on their faces when somebody draws a UML diagram of war. There is no public changing, adapting, or even viewing of the “open source” warfare. Merely changing the roles and attributes of units while adding or subtracting their numbers has little to do with the metaphorical “open source” moniker. Asymmetric warfare and insurgency is going to be public driven as the insurgents are the non-state actors of the public. In other words any insurgency that is not state sponsored is open source (within the tradition of community sharing).
Software development and systems engineering as disciplines are filled with metaphorical representations of real world systems and topics. Metaphors that can withstand scrutiny are valuable. In object-oriented development the common description of the concept is an object “furniture”, with child classes of â€œchairâ€, and chairs like “over stuffed” and “dinner table” chairs are the same but have different attributes. These types of metaphors and ontology’s last because they are expressive. Whereas using “open source” to discuss asymmetric warfare and insurgency likely would be a rhetoricians tautology.
With a good metaphor you should be able to flip it and use it in different venues. In this situation apply “open source” as Mr. Robb has expanded it to the place it came from. In essence “open source” software development is an asymmetric attack on software development. It could be expanded that the attack is for political motivations. Which could imply that there is a moral and or ethical element to “open source” software development. It then follows that â€œopen sourceâ€ software development is likely bad and should be stopped. In systems engineering this rapidly devolving error in logic from one bad premise could be considered a cascading failure.
After having read Mr. Robb’ds article in IEEE Spectrum (LINK). I began thinking about this as an issue in scope and direction. I think we need to go back and instead of applying software development and systems engineering terms to war we should likely be applying the concepts of conflict to software engineering and systems engineering. The broader scope of conflict gives more value to the narrower area of computers than computers give to the world of conflict. Expertise can be transferred to near cognitive elements when they are similar in nature. As metaphor they can be transferred to far cognitive elements. The chess master may not make a great general but the soldier can play a mean game of chess. Here in this situation in an effort to expose new models of technology to the problems of conflict the breadth of the metaphor is not up to the task. Mr. Robb makes a great case in his book for the terms, and I as a systems engineer (software systems) am comfortable with the idea I think that a broader audience is not going to be able to pick up the nuances inherent in this metaphor.