powdermonkey

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!

Military Open Source Software conf starts this week in DC, really great line-up of speakers AND a barcamp Thursday. It will be fun!

http://www.mil-oss.org/

SoftWar(e)

My new oped in Defense News!

http://www.defensenews.com/story.php?i=4677662&c=FEA&s=COM

Losing the SoftWar(e)

The victors in battles are those who create, modify and deploy ideas faster and more nimbly than opponents. Regrettably, limiting the U.S. military's access to ideas risks failure. For years, the U.S. military has been losing an asymmetric battle that involves not improvised explosive devices, bullets or al-Qaida, but instead swarms of defense industry contractors seizing control of taxpayer-funded ideas because government policy and regulations were engineered to buy iron and steel, not to deploy a software-based military. Much like the battles in Iraq and Afghanistan, the rapid and continual evolution of technology demands that the military accelerate just as rapidly, and the only way is to manage the ideas it has funded. A common theme since 9/11 is that the U.S. government lacks imagination. We have not misplaced our imagination; we are simply unable to deploy new ideas as effectively or as quickly as we could. This loss of agility stands in stark contrast to private industry, foreign governments and nonstate actors, who are adopting and deploying software technologies once exclusively in the military domain. For instance, China deploys advanced electronic warfare technologies, Iran builds unmanned aircraft, al-Qaida evolves explosive devices, and private companies like FedEx and eTrade create complex, redundant and failsafe command-and-control systems. Software is the fabric that enables planning, weapons and logistics systems to function. It might be the only infinitely renewable military resource. New software builds on the raw material of previous software, evolving capabilities. Software is pervasive, from ground sensors to satellites; it is the final expression of a military idea transformed into human readable source code and deployed to a battlefield. WASTED BILLIONS The Department of Defense spends tens of billions of dollars annually creating software that is rarely reused and difficult to adapt to new threats. Instead, much of this software is allowed to become the property of defense companies, resulting in DoD repeatedly funding the same solutions or, worse, repaying to use previously created software. The lack of a coherent set of policies and regulations for the DoD's intellectual property has eroded the U.S. military competitive advantage, leading to compromised missions and lost lives. Improvised explosive device countermeasure systems can't be upgraded rapidly without replacing entire systems; personnel position systems can't update in real time; billions are wasted on software radios that don't interoperate. The byzantine rules governing the military's intellectual property portfolio use an antiquated rights structure where the contractor always retains copyright, and therefore effective monopoly, control over taxpayer-funded software ideas. By contrast, commercial industry ruthlessly exercises control over its own software ideas. The U.S. government has legislated a belief that the defense industry will do right by the military. However, the defense industry will, understandably, do what is best for its shareholders: maximize profit. Monopolies via copyright ultimately increase costs and decrease adaptability and agility in military software. Examples include the General Atomics Predator and the recently canceled Future Combat Systems, where only one company can control these platforms and manipulate the software. Imagine if only the manufacturer of a rifle were allowed to clean, fix, modify or upgrade that rifle. This is where the military finds itself: one contractor with a monopoly on the knowledge of a military software system. A first step would be to require all taxpayer-funded software ideas to be licensed with an open source software copyright. An open source license would define the rights, roles and responsibilities for the military and defense industry and simplify how military software ideas can be shared. To keep the U.S. military ahead of its adversaries, the DoD and defense industry must end this dysfunctional partnership of nonsharing. Defining a modern software intellectual property regime would broaden the defense industrial base by enabling industry access to defense knowledge, thereby increasing competition and eventually lowering costs. Over time, DoD would evolve common software architectures and industrywide baselines to increase the adaptability, agility and - most important - capacity to meet new dynamic threats. As Defense Secretary Robert Gates said at the Eisenhower Library, "The gusher has been turned off and will stay off for a good period of time." The Department of Defense must develop a rights regime that explicitly deals with taxpayer-funded software ideas to increase returns on software investments. The software idea chain is a future weapon; we can either plan for it now or be on the receiving end of it later. --- John Scott is a term-member at the Council on Foreign Relations. He co-wrote the U.S. Defense Department's "Open Technology Development Roadmap," which promotes adoption of open-source methodologies within the military.

@ Politics of Open Source Conference

Politics of Open Source Conference

http://politicsofopensource.jitp.net/program

"Women in Free/Open Source Software Development" - Hanna Wallach

Women in software: 28% in closed source vs. 2% in open source

number came out of FLOSSPOLS, EU Study,

Qual/Quan study (online survey 1,541 participants) 

Results: active (but unconscious) exclusion: "jokes" about women, women used as nontechnical 'typical' user - i.e. Aunt Tilly used as strawman 

Beard distinguishes you as a 'hacker' 

Typical tasks:

Men: Technical tasks (code writing, testing, bug reports, etc.)

Women: Social tasks (documentation, org events, translation, etc.)

Grassroots projects:

Debian GNU/Linux, 4 out of 900 Debian developers are women, 8 in the entire history of Debian.

DEPARTMENT OF DEFENSE NEW GUIDANCE ON OPEN SOURCE SOFTWARE

As a Marine friend says "Agility is the Capability" - open source software and methods is the enabler of this.

The DoD CIO office (or ASD-NII) just has posted new open source software guidance for the whole Department of Defense! Only took about 18 months to get through, so worth it. Hopefully this puts the FUD to bed.

Definitively open source software can be used inside the US Dept. of Defense. This is great news and shows that DoD is heading in the right direction to change how information intensive technology acquisitions programs can move toward a more dynamic OODA loop like model.

The entire policy is here: October 16 2009, Open Source Software Guidance Memo, text as follow:

To effectively achieve its missions, the Department of Defense must develop and
update its software-based capabilities faster than ever, to anticipate new threats and
respond to continuously changing requirements. The use of Open Source Software
(OSS) can provide advantages in this regard.

Doc Download 2009OSS

Sakai Foundation Open Source Software

Good to see the Sakai Foundaiton open source software is making inroads into the US Naval Postgraduate Schoo:, Via Kulai:

The Kuali Foundation is an open source software development effort focused on student information management systems.

Its about time: Open Source for America Campaign launch !

All I can say is it's about time, today we've launched the Open Source for America Campaign. The press release says it all:

The mission of Open Source for America is to serve as a centralized advocate and to encourage broader U.S. Federal Government support of and participation in free and open source software. Specifically, Open Source for America will: help effect change in policies and practices to allow the federal government to better utilize these technologies; help coordinate these communities to collaborate with the federal government on technology requirements; and raise awareness and create understanding among federal government leaders about the values and implications of open source software.

Great group of individuals and companies involved see:

About Open Source for America Open Source for America is a coalition of industry leaders, non-government groups and academic/research institutions organized to serve as a centralized advocate, to encourage broader U.S. Federal Government support of and participation in free and open source software. Membership in Open Source for America is open to any individual or entity signing the campaign's mission pledge.

Learn more and sign up to join ! at http://www.opensourceforamerica.org We are also planning on having various working groups focusing on health, energy, education, defense and cyber issues.

You can also on Twitter at http://twitter.com/OpenSourceGov

Real-time embedded open source software OpenCPI website Launched!

Our OSS website is launch for OpenCPI, Sign up!

The Component Portability Infrastructure (CPI) is a real-time embedded (RTE) middleware solution that simplifies programming of heterogeneous processing applications requiring a mix of field-programmable gate arrays (FPGA), general-purpose processors (GPP), digital signal processors (DSP), and high-speed switch fabrics. The “mix” can be over a lifecycle (technology insertion) as well as within a single implementation (to meet SWAP constraints). CPI improves code portability, interoperability, and performance in FPGA and DSP-based environments by providing well-defined waveform component APIs (application programming interfaces) with a set of infrastructure blocks that act as a hardware abstraction layer (HAL). CPI is also appropriate for the incorporation of GPU and multicore technologies. CPI is uniquely positioned to meet the goals of S3 since in some sense component-based systems are computer-science’s answer to dealing with “knowledge capture” and lock-up of intellectual property (IP). CPI is classified at a technology readiness level 6, and is in programs that will establish it for level 7.

Built on the U.S. Government’s Software Communications Architecture (SCA) standard, CPI extends component-based architectures into FPGAs and DSPs to decrease development costs and time to market with code portability, reuse, and ease of integration. All interfaces are openly published and non-proprietary, using an appropriate mix of industry and government specifications.

To overcome the challenges of code portability in FPGA environments in particular, CPI provides a pre-validated set of building blocks to interface the FPGA waveform applications with high-performance switch fabrics, onboard memory, system command and control, and wideband I/O. CPI’s non-proprietary interfaces act as an abstraction layer to increase the portability of FPGA applications. A verification suite is also included to facilitate debugging and reduce development time.

At the highest level, the CPI vision allows users to outsource the technology transition management job to others. Using the CPI interfaces, developers can protect their application development investment by cost-effectively moving their applications to new generations of systems using the latest technologies. CPI is essentially a kit of necessary pieces to create an application platform for component-based applications based on the SCA model extended to a heterogeneous mix of computing, interconnect and I/O resources. When CPI is adapted to, and installed on a platform, we say that the platform is now “waveform-ready”. While the SCA defines the operating environment and APIs for C++ software applications components running in a CORBA and POSIX-compliant environment, CPI extends the SCA environment, according to the Proposal 289 to SCA (FPGA/DSP extension by Mercury funded by program office) to DSP and FPGA technologies. Analyses for suitability for GPU and Multicore technologies have shown promise.

Meeting, May 21 in DC: Open Source, Virtualization & Cloud Computing

Great even to be held in DC, May 21 and its free. Pretty amazing lineup of speakers we've managed to get and its at no cost:

Federal IT on a Budget Forum

Join government IT professionals and industry thought leaders for this FREE full-day event to get smart about implementing Cloud Computing, Open Source, and Virtualization in your agency or organization.

Co-Chairs:
• Pete Tseronis, Deputy Associate CIO, Department of Energy
• Tim Young, Senior Manager, Federal Government Services Group, Deloitte Consulting LLP and Former Deputy Administrator, Office of E-Government and Information Technology, Office of Management and Budget
Morning Keynote:
• Jim Whitehurst, President and CEO, Red Hat ˜ Answering the Call for Transparency in Government: The Open Source Opportunity
Co-located AFFIRM May Luncheon and CIO/CFO Panel:
The New IT Economics:
• Herb Strauss, Chief Strategy and Marketing Officer, Robbins-Gioia [Moderator]
• Robert Carey, CIO, Department of the Navy
• Casey Coleman, CIO, General Services Administration
• Chris Kemp, CIO, National Aeronautics and Space Administration Ames Research Center
• Radha Sekar, Assistant Deputy Under Secretary for Financial Management for the Under Secretary of Defense Comptroller USD(C)

Register now at www.meritalk.com/2009-federal-it-forum.php