powdermonkey

Government get your Sh** Together

Commenting on the ‘new’ government digital service and TechFAR. 

Great article here:  New US Digital Service Looks to Avoid IT Catastrophes 

Discussion by Gunner: US Digital Service is Born

Steve Kelman, FCW:  The REAL regulatory challenge of agile development

 This simply isn't bold enough. This effort simply try’s to fix whats broken instead of looking more deeply at why its broken and how to ‘reformat’ the way IT services are built and most importantly used by the government and citizens.

The Service and TechFAR is akin to what the military seems to plan for: planning and building systems to fix yesterdays battles instead of really and deeply thunking for the future. 

UK: the UK gov digital service worked because its much, much smaller than our government (think California), two the UK gov is setup very differently than our government bureaucracy. The UK digital service reports directly to the PM and as I understand it, really could walk into any UK Agency (save MoD) and demand changes + take over projects. Also in a Parliamentary system, what the PM says goes, no discussing with Parliament, arguing over budgets, etc. a number of projects get killed pretty fast when there is a gov changeover. 

The US has neither. 

GSA is a pretty widely ignored Agency (for a number of historical reasons), maybe this time it will be different, I’m sure they can help web pages load faster. But the Digital service is going to report a few levels down from POTUS and the head of GSA, both of which have many other things on their plate. 

Also US Agencies have two masters they play pretty well off each other, Congress and the Pres.  Scale: the gov is friggin huge. Also some government systems have very unique and multiple functions for only one customer (the Gov + citizens).  Fixing FAA and SSA isn’t a few agile sprints over pizza and Dew.

 Instead of fixing past problems, we need deeper thinking about HOW and WHY the government should provide services. 

Examples: 

- The government no longer runs motor pools, it outsources the entire job to companies with specific service levels and agreements (SLA).

- Failed example: SABRE (the airline reservation company) came to DoD and pitched the idea that they would take care of all military travel for something like $60 a ticket. Some govvies pitched they could do it cheaper, they tried and build a disaster of a service ++ Defense Travel continues to eat funds way above and beyond. And continues to frustrate and strand military travelers overseas. 

 There are many more, but the basic take away is this: the government must not recreate services the private sector does cheaper, better and faster unless its part of its' core mission. 

• Bombs, check - part of core military mission. 
• HR? (outside of the military and CIA), the government should license or buy as a service HR capabilities. 
• Websites? I’m having a tough time with this. If the government could come up with a list of requirements and define a serious set of SLAs, they are any number of companies who would gladly offer website as a service, with the government managing the input.
• IRS systems: parts of it could defiantly be outsourced, especially all of fraud monitoring. 

One last point: 

YAR - yet another review, I don’t see how another YAR by the Digital Service is going to add to government agility and flexibility. Make no mistake, the gov is setup with a number of very expensive and time consuming YARs already, each which must be planned for and dumbed down to senior management. 

TechFAR inculcates YAR + yet another ref doc to read, that  won’t apply to any Agency that doesn’t adopt it. 

Many of these suggestions sound good for a few projects, but crumple and slow down system creation when scaled to 1000s of project in an $80 billion portfolio. 

Some question to ask as the Gov builds systems: 

1. Is the thing your Agency needs to develop a core competency? 

2. if not, define how to buy it as a fixed price service offering w/ a tight SLA

3. if yes, first start developing small + draft off of any existing efforts (open source software, or other state, local, international gov’s) ++ be open to the outside

Errata: 

• stop fixing current problems with past thinking 
• stop telling industry how to suck the egg (i.e., stop dictating to industry what methods to use to develop technologies, CMMI was great for adding bodies - thanks for the revenue, is Agile really the endpoint of development methods? Lets not hard code something (again) into how the gov does procurement)
• automate eixsting jobs, rethink how the work gets done (IRS a body shop)
• automate existing process and rethink if you need them at all 
• Start to collapse Agencies and processes. Does every Dept and Agency really need a CIO and associated staff? 
• What things could Agencies outsource to each other (like paychecks that Dept of Ag does for smaller Agencies)

 

Cost Overruns in Large Systems (HHS take note)

From my Masters Thesis, wonder how much planning went into Healthcare.gov... so if NASA who has the brains about how to build build systems has a tough time getting it right, HHS has no hope. There were also time over runs as well. 

... design decisions made early in the life cycle can have a large impact later when the technology is in operation.  An example of this in the graph by Werner M. Gruhl (Cost and Analysis Branch, NASA) presented at a INCOSE (International Council of System Engineering) System Engineering Seminar in 1998.

In the Figure 1-1, Phase A & B Costs are the costs associated with early stage conceptual planning and design of a technology. One early stage decision in the life cycle of a technology is how much money to allocate to the early stages of development and design. The chart shows that (for systems at NASA) if less than ten percent of the total cost is allocated to these early stages there can be an expectation of cost overruns. Making the decision to allocate more money to these earlier stages allows for the use of more resources to make sure the technology being developed closely matches what was envisioned.

 

 

Military Systems + Process = Technical Debt

I was just reading through the literature on Technical Debt (see Ward's Technical Debt). I like these definitions of Technical debt (from Construx) : 

The first kind of technical debt is the kind that is incurred unintentionally. For example, a design approach just turns out to be error-prone or a junior programmer just writes bad code. This technical debt is the non-strategic result of doing a poor job. In some cases, this kind of debt can be incurred unknowingly, for example, your company might acquire a company that has accumulated significant technical debt that you don't identify until after the acquisition. Sometimes, ironically, this debt can be created when a team stumbles in its efforts to rewrite a debt-laden platform and inadvertently creates more debt. We'll call this general category of debt Type I.

The second kind of technical debt is the kind that is incurred intentionally. This commonly occurs when an organization makes a conscious decision to optimize for the present rather than for the future. "If we don't get this release done on time, there won't be a next release" is a common refrain—and often a compelling one. This leads to decisions like, "We don't have time to reconcile these two databases, so we'll write some glue code that keeps them synchronized for now and reconcile them after we ship." Or "We have some code written by a contractor that doesn't follow our coding standards; we'll clean that up later." Or "We didn't have time to write all the unit tests for the code we wrote the last 2 months of the project. We'll right those tests after the release." (We'll call this Type II.)

to quote Martin Fowler (Fowler TechDebt) "The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments." Leading to the Red Queen effect: running to stay in place or falling slowly behind. 

But there is a third cause of technical debt, process debt.

Process debt occurs when an organization is so process laden that they are unable to develop or deploy a software system that has any hope of being current or of meeting current needs. Many larger Defense systems fit this mold: the shear mind-numbing process of how to create these systems from design to RFP to contract award virtually ensues that the system when and if its completed is Legacy. 

the fix to military acqusitions will be painful, not quite sure when the healing will start 

If we don’t want to be like the Iranians and get Stuxnetted, take these 4 steps

Thanks to Tom Ricks for allowing me to post on his blog a short piece:

If we don’t want to be like the Iranians and get Stuxnetted, take these 4 steps

It's Wednesday, and that means another story about the looming threat of cyberattack, how vulnerable the United States and its infrastructure is, how bad the Chinese are, how to retaliate, etc. But what seems to be left out of the discussion is what can practically be done about it (beyond scolding bad people). 

The first thing that should be done is to shrink surface area for attack. What does this mean? Right now the U.S. government and industry runs a pretty homogenous set of operating systems and applications that have shown to be a big part of the problem; specifically, Microsoft and Adobe are two companies whose wares have become amazing attack vectors. Why? For a few reasons: 1) if you want to create a virus/exploit weapon you tailor one for largest adoption, 2) attack large morphing code bases that give rise to known-unknown software vulnerabilities, and 3) updates don't always filter out in time once new vulnerabilities are detected and patched.

A great example is how Stuxnet is reported to have entered the Iranian nuclear program: 

The main (and initial) infection vector is the transmission of the Stuxnet malware via USB devices: if an infected USB device is inserted into a clean PC and later accessed with the Windows Explorer, then the infection of that PC is triggered. This is due to either a malicious ‘Autorun.inf' file present on the USB device (for the oldest variants of Stuxnet) or to the usage of the ‘LNK' Windows vulnerability (MS10-046,CERT-IST/AV-2010.313 advisory) for the variants found in June 2010.

The Iranians were probably running older versions of Microsoft operating system software that wasn't updated (and was probably pirated to boot). Further, the Iranians were a victim of Microsoft's business model of stitching together source code to lock-in users and conversely lock-out other software, which allowed the virus carte blanche access to anything. 

So what should we, the government, or private companies for that matter, do? First thing, we've got to get our own house in order to limit our vulnerabilities (or "know thyself," to paraphrase Sun Tzu).

• First, get rid of software for which we have to continually make excuses. Just as the U.S. military doesn't promote smugglers (Han Solo) and farm boys (Luke Skywalker) to general, stop deploying software that requires additional fixes and comes stitched together. Microsoft and Adobe might be less expensive software, but if it leaves a backdoor open, is it really "cheaper"?

• Second, only install operating systems and applications where the source code is available for widespread public inspection. Keeping source code secret increases its widespread vulnerability to exploitation when a defect is detected.

• Third, increase heterogeneity of operating systems and applications to create gaps so that a virus/exploit can't transverse between different systems.

• Fourth, fund research into more secure operating systems and make the fruits of that investment public: A rising tide lifts all (security) boats. A small investment in maturing source code can have a large impact. 

 

 

 

my WSJ OpEd: Arthur Herman & John Scott: Send in the Tech Reinforcements

first WSJ oped: 

By ARTHUR HERMAN 
AND JOHN SCOTT

Today's Pentagon is losing its most important battle, the one for its own future. The Defense Department's latest evaluation report on the F-35 Joint Strike Fighter reveals how badly that fight is going, and why.

There have been many stories about the F-35 Lightning II's problems and delays, and its looming total price tag of $1 trillion, up from prior estimates of $331 billion and $177 billion before that. Still, the DOD's Jan. 14 report zeroes in on the key issue: software and information technology.

All five software "blocks"—systems to take the plane from testing to full production—that Lockheed Martin is contracted to develop for the Lightning II are behind schedule and over budget. The testing of software for producing F-35s won't get done until 2017. Any new glitches that are found will likely delay deployment even longer.

The fault, however, doesn't lie with Lockheed Martin, or even with the F-35.

The problem is how the Pentagon goes about acquiring the IT and software that modern weapons systems need. If this problem doesn't get fixed, any hope of building a 21st-century American military will be doomed.

The complexity of the software that the F-35 fighter needs is staggering, almost incomprehensible. It runs to almost 10 million lines of software source code. The man in charge of the F-35 program, Maj. Gen. Chris Bogdan, has been quoted as saying about thesoftware, "it scares the heck out of me"—because he knows in the world of high tech, complexity is the enemy of effectiveness.

Reuters/Lockheed Martin

The U.S. Marine Corps version of Lockheed Martin's F-35 Joint Strike Fighter, F-35B test aircraft BF-2 flies with external weapons.

Yet that's the dilemma the Pentagon faces every day when it comes to IT and software.

For example, the Air Force's Oracle -based Expeditionary Combat Support System was supposed to be ready in October 2013. Having spent $1 billion already, it needed another $1 billion just to get to one-quarter functionality by 2020. ECCS was supposed to automate the Air Force's management of parts and equipment. This inherent complexity of the acquisitions process effectively killed ECCS and led to the rampant cost overruns that also killed the Navy's DDG1000 destroyer late last year.

The Pentagon acquires IT and software-based systems the way it buys aircraft carriers—as if they were physical items to be forged or welded or mass-produced. The standard procurement cycle is geared around multiyear milestones and intensive evaluation reviews that can take months or years.

The modern software development cycle, by contrast, moves in weeks, days and even hours—because software is a malleable digital item whose only limits are the human imagination.

In addition, the Pentagon relies on a bureaucratic review process that demands contractors anticipate and resolve problems in advance. Every software engineer, however, knows that's not possible or even desirable.

Modern software constantly evolves. Engineers know that repeated test cycles in small portions at a time work best. Designers can learn from mistakes and glitches embedded in initial and early versions, and they can learn as well from early users of these versions.

More important, designers can take advantage of technologies that are unknown today but emerge later on. Learning by trial and error doesn't work so well for aircraft carriers or Abrams tanks, but it is crucial for the development of effective software.

The DOD's current acquisition strategy hasn't caught up or caught on. By treating software as if it were a product instead of a process, our military services are shutting themselves off from the kind of cost-efficient innovation that rules in the commercial software and IT industries. Amazon, for example, can make over 30 changes a week to its portal, from adding simple code changes to new complex features, without a major glitch. Our service personnel know this only too well, when they see how their children's videogames work better and have more sophisticated apps than the electronic gear they have to use in the field—and at a fraction of the cost.

The Pentagon has tried to go around the problem by buying off-the-shelf software for some systems. But that only postpones the inevitable frustration when it comes time to design software that can integrate those commercial products into warfighting systems. This is what happened when the Air Force tried to create the Expeditionary Combat Support System, which ended up as a $2 billion boondoggle.

Instead, the Pentagon needs a modern software and IT acquisition process that's as flexible, agile and open-ended as software itself—one that's geared for Moore's Law (computing power doubles every 18 months) and Butter's Law (network capacity costs get halved every nine months) instead of Murphy's Law.

Until we do, expect more messes like the F-35 and DDG 1000—which we ultimately can't afford and our fighting men and women ultimately won't survive.

Mr. Herman is the author of "Freedom's Forge: How American Business Produced Victory in World War Two" (Random House, 2012). Mr. Scott is a senior system engineer for Radiant Blue Technologies and co-wrote "Open Technology Development: Lessons Learned and Best Practices for Military Software" (Department of Defense, 2011).

A version of this article appeared Feb. 12, 2013, on page A15 in some U.S. editions of The Wall Street Journal, with the headline: Send in the Tech Reinforcements.

 

Issa IT reform bill now w/ Open Source Sec 405.

very interesting langauge in the new IT Reform Bill, on open source software:

Sept 6, 2012, HR ___ Disscusion Draft 

SEC. 405. PROMOTION OF GOVERNMENT-WIDE SUPPORT FOR THE USE AND

DEVELOPMENT OF OPEN SOURCE SOFTWARE.

(a) PURPOSE.—The purpose of this section is to promote the use and

collaborative development of open source software within the Federal government.

(b) STANDARDS AND GUIDELINES.—Section 11302(d) of title 40, United

States Code, is amended by adding at the end the following: “The standards and

guidelines shall include those necessary to enable effective adoption of open

source software.”

(c) GUIDANCE.—Not later than 180 days after the date of the enactment of

this Act, the Director, in consultation with the Chief Information Officers Council,

shall issue guidance for the use and collaborative development of open source

software within the Federal government.

(d) MATTERS COVERED.—In issuing guidance under subsection (c), the

Director shall include, at a minimum, the following:

(1) Guidance to clarify that the preference for commercial items in

section 3307 of title 41, United States Code, includes all open source

software that meets the definition of commercial item in section 103 of

title 40, United State Code, including all such software that is used for

non-Government purposes and is licensed to the public.

(2) Guidance regarding the conduct of market research to ensure

the inclusion of open source software.

(3) Guidance to establish a program to educate the acquisition

workforce by providing information to identify and counter

misconceptions about open source software and to keep such

information updated.

(4) Guidance to define Government-wide standards for security,

redistribution, indemnity, and copyright in the acquisition, use, release,

and collaborative development of open source software.

(5) Guidance for the establishment of a Government approval

process to qualify open source software for widespread Government

use, addressing issues such as security and redistribution rights.

(6) Guidance to establish standard service level agreements for

maintenance and support for open source software products widely

adopted by the Government, as well as the development of

Government-wide agreements that contain standard and widely

applicable contract provisions for ongoing maintenance and

development of open source software.

(7) Guidance on the role and use of the Federal Commodity

Information Technology Acquisition Center, established pursuant to

section 11501 of title 40, United States Code (as added by section 302),

for acquisition of open source software.

(e) REPORT TO CONGRESS.—Not later than 2 years after the issuance of the

guidance required by subsection (b), the Comptroller General of the United States

shall submit to the relevant congressional committees a report containing—

(1) an assessment of the effectiveness of the guidance;

(2) an identification of barriers to widespread use by the Federal

Government of open source software; and

(3) such legislative recommendations as the Comptroller General

considers appropriate to further the purposes of this section.

 

It's only your tax dollars

This is a little something I've posted to the Whitehouse.gov site, if you agree please sign up and sign the petition, it is your tax dollars. 

Maximize the public benefit of federal technology by sharing government-developed software under an open source license

Top Three Reasons to Mandate Open Sourcing of Custom Federal Software:

Openness: Open Sourcing ensures basic fairness and transparency by making software and related artifacts available to the citizens who provided funding, consistent with the President’s 2009 declaration that “Information maintained by the Federal Government is a national asset.”

Economic Multiplier: Making Provides an economic stimulus by serving as the raw material that supports a competitive software development and services industry.

Supports the Federal “Shared First” Agenda: Maximizes value to the government by significantly increasing reuse and collaborative development between federal agencies and the private sector, consistent with the current Office of Management and Budget (OMB) “Shared First” initiative.

Link Here: Maximize the public benefit of federal technology by sharing government-developed software under an open source license.

 

Someone Doesn't like Accumulo

Someone doesn't like Accumulo. And by the looks of it they are very well versed in the language of open source software (OSS).

Back ground: Accumulo was recently released as OSS to the Apache foundation and has to do with securoty features using a cloud architecture. What was interesting is that NSA funded, created and released it to build a community around these features that they wanted. 

Let the guessing begin on who put this in...

Department of Defense use of National Security Agency
cloud computing database and intelligence community
cloud computing infrastructure and services (sec. 929)
The committee recommends a provision that would prohibit the
use of the National Security Agency’s (NSA) Accumulo cloud computing database by other Department of Defense (DOD) components after September 30, 2013, unless the Chief Information Officer certifies that there are no viable commercial open source databases that have the security features of Accumulo, or that
Accumulo itself has become a successful open source database
project. The provision also would require that Department of Defense and intelligence community officials coordinate fully on the
use by DOD components of cloud computing infrastructure and
services offered by the intelligence community for purposes other
than intelligence analysis to ensure consistency with the DOD information technology efficiencies initiative, data center and server
consolidation plans, and cybersecurity plans and policies.
The committee applauds NSA’s decision to adopt open source architectures and software for most of its cloud computing development. However, the committee disagrees with NSA’s decision to develop its own cloud computing database—called Accumulo—rather
than adapt an open source version of the Google BigTable product.
The committee understands that NSA decided to build a government solution several years ago because the open source systems
lacked security features that NSA considers essential. In hindsight,
the committee believes it would have been smarter for NSA to have
worked with industry and the open source community to add NSA’s
security features to the open source database systems. Indeed, the
committee believes that NSA should pursue that course now.
The downside of using a government-unique database is that,
compared to open source products, there will be far fewer developers contributing to technology advances, and all of the applications, analytic tools, and functionality that the open source community and commercial industry are developing for cloud computing
will not be compatible or interoperable with the NSA database, depriving the government of valuable innovation. The committee believes it is very likely that the rapidly expanding and innovating
cloud computing industry will pass NSA by in a hurry, with lagging performance and higher costs. The consequences would not be
confined to NSA, since the Army intelligence community has already adopted the NSA cloud architecture, and NSA is strongly
urging the entire Department of Defense to do likewise. One of
NSA’s arguments is that the security features of Accumulo are essential for the cybersecurity of DOD as a whole.
NSA is making an effort to heal its divergence from the open
source community by proposing Accumulo as an open source project
under the Apache Foundation as a competitor to existing Apache
Foundation open source databases like HBase and Cassandra,
which are widely used and supported in industry.
The committee believes it is important to ensure that there are
options available if Accumulo does not in fact become a viable and
widely supported open source project. The committee is aware of
commercial interest in the cell-level data tagging security features
that NSA built into Accumulo. These features should be as useful
to industry clients who need to protect and control access to the
data resident in cloud facilities as they are to the intelligence community and DOD.
If Accumulo is successful, or if the commercial open source community produces nothing comparable to Accumulo’s security features, this provision would permit Accumulo to be used in DOD
outside of NSA. But if Accumulo is not an open source success, and
if industry follows NSA’s security lead, the Department should use
a commercial product. This provision would give NSA almost 2
years since it made the Accumulo open source proposal to Apache
to succeed. The deadline in this provision is also sufficiently distant
to enable DOD components and industry to plan accordingly.
Under the direction of the Director of National Intelligence, the
Central Intelligence Agency (CIA) and NSA are planning to provide
cloud infrastructure and software ‘‘as a service’’ to all of the intelligence community. As noted, NSA is offering a government implementation of open source standards. CIA is offering a competitively
awarded commercial solution. These cloud services would cover all
manner of computing needs and capabilities, not just intelligence
analysis. This provision is also intended to ensure that DOD components’ use of these cloud services is consistent with DOD information technology policies and plans. The committee notes that the
software services that the CIA may offer to DOD customers could
include analytic databases like HBase and Cassandra, and other
commercial open source products, potentially providing an alternative to Accumulo.

Transparency & Failure in .Gov/.Mil IT

Recently at the Gov 2.0 summit Fed CIO Viveck Kundra talked about stopping/killing some very expensive .gov IT programs, video here:

Gov 2.0 Summit 2010: Aneesh Chopra and Vivek Kundra, "Closing the Technology Gap"

But I was left wondering what were the programs and more over why killed? Oftentimes federal (and military) IT programs will be killed or left to die, without a postmortem or documeting lessons learned. Sometimes an intrepid reporter will try to one, but that usually just scratches the surface. GAO or internal Government offices will sometimes do them if asked to by Congress, but GAO reports are usually only for the largest of the large failing programs. .Gov internal reports are usually not published or done, much less published.

Its always struck me as weird that the government doesn't push more of a lessons learned culture like the one ingrained in the military (but sadly not in the military IT field). We do this for plane crashes, but there doesn't seem to be a systematic process for documenting IT failure?

(if there is please post)

I'm hoping that Viveck and Team can come up with some sort of simplified lessons learned document, this would do a few things:

1. Put government / contractors on notice that failure will be documented, like Gunnar says "The gov doesn't look good Naked" but it might be in better shape if it was

2. Learn, Learn, Learn: doomed to repeat mistakes if we don't learn

3. Gather requirements for potential changes in process, law, promotion schedules, etc. IF need be

A lessons learned doc should include: original cost of program (estimate and contractor proposed), original period of performance, winning contractor team, dollars spent, government intellectual property developed, reasons for cancellation, etc. I'd put a floor on the study and get a small team 2-3 weeks to prepare a doc, maybe only document failure under $ xx millions?

Or maybe this would be better as a wiki somewhere?

thoughts? unworkable? makes folks too uncomfortable?

Mil-OSS working group 2 wrap-up

(first published on www.opensource.com) Mil-OSS working group 2 wrap-up

Openness in the military is coming of-age, as was evident to the attendees at the 2nd Military Open Source Software (Mil-OSS) working group held August 3-5 in Arlington, Virginia. This grassroots gathering of practitioners in the art/science of creating military capabilities was unique in its inclusive atmosphere of government civilians, military uniformed (and retired) personnel, government contractors, and university academics. All gathered with one goal: how to more rapidly create and deploy military capabilities utilizing open source software for the U.S. Soldier, Sailor, Airman, and Marine.

What was interesting was a shift from the attitude at last years meeting of: "We can use open source software in the military?" to this years vibe of "How can we use, modify, sustain, and create more open source software around the military?" In the last year, since the update of DoD Open Source policy (see the 2009 DoD Open Source Memo), there has been an important shift in understanding that the benefits of being open vastly outweigh the hassles and foibles of closed and gated source code development--especially when the U.S. taxpayer is picking up the tab. Roadblock issues were brought up, such as:

- What are the best practices for how to run unclassified code communities for a classified client?

- How do we create, fund, and sustain development of open source?

- How do we generate more ideas on how to fix and deal with the government's acquisition system?

The military-focused OSS projects in attendance ran the gamut, from the long-established computer-aided design project BRL-CAD, to cyber (Suricata), modeling and simulation (Delta3D), geospatial (OMAR & OSSIM), and new projects such as EurekaStreams and the to-be-released Analysis of Competing Hypotheses. Presenters and the three tracks were almost too numerous; see MIL-OSS 2 Agenda for details.

The kickoff keynote was Lt. General Elder (retired), who reviewed cyber issues facing the military (video). Subsequent military keynotes discussed internal military community collaboration (Lt. Col. Allen of MilSuite), an update on the need to simplify information technologies acquisitions and deployment processes in the military (Maj. Neushul - Update on Keeping it Stupid Stupid), and a review of the current state of OSS in the DoD (Dan Risacher - DoD OSS Review).

Defensive Homeland security, OSS, and cyber issues were reviewed by Doug Maughan of DHS (Homeland Open Security Technologies) and contrasted by HD Moore of Rapid7/Metasploit who went over Open Source Cyber Weaponry.

Most presentations can be found on Slideshare at Mil-OSS WG2 Meeting. Selected presenters can be found on Vimeo.

A great addition at lunch were the many Ignite sessions, such as Gunnar Hellekson's "Fighting Forks [in DoD]" and Maj. Neushul's talk about the need for a functioning Combat Relevant Position Location Information (CRPLI) capability for the Marines.

An unexpected shout-out for WG2 came from Wired's Dangerroom (Noah Shachtman) who interviewed presenter Mathew Burton on his soon-to-be-released open source project: Analysis of Competing Hypotheses, which is "a system for organizing information that would help analysts think about complex problems more objectively, even when confronted with mountains of evidence." He called it Analysis of Competing Hypotheses, or ACH.

The ball seems to be rolling on releasing or converting military or intelligence source code as pure open source software.

By the third day, it was time for something unplanned: Barcamp, which basically split into two groups: projects and process. Project discussions included CRPLI and the Ozone Widget Framework (being used by the DoD Storefront project). The process track was mainly focused on issues around how to use, develop, and sustain OSS projects tied to the military.

A challenge was issued at the barcamp lunch in response to the need for a canonical set of briefing charts detailing the value of open source software for the military, from security to basic definitions to legal issues. All-in-all, about 100 briefing charts were created and will soon be made available to the community to use/modify/tweak as needed.

Future of Mil-OSS

The future of software in the military was a much discussed and argued topic, but one key issue agreed upon by all was the continued need for community building and collaboration. There was consensus for a Mil-OSS large annual gathering coupled with regional grassroots meetings and/or barcamps. There are rumors of proposed camps in Boston, New Orleans, Charleston, and San Diego. Join the Mil-OSS Google Group to track their progress.

A few reference links for the uninitiated:

• Website: www.mil-oss.org
• Mil-OSS WG2 presentations - http://www.slideshare.net/event/miloss-2/slideshows
• Mil-OSS WG2 videos - http://vimeo.com/channels/miloss
• Mil-OSS WG mailing list
• Mil-OSS LinkedIn group
• twitter hashtag: #miloss

Thanks to our amazing sponsors. We really couldn't have put on a great show without you!

And a big thanks to Georgia Tech Research Institute, especially  Josh Davis and Claire Gould, for doing the truly thankless back (breaking) office work of coordinating everything!