Developing a Lean, Agile Procurement Guide

At Code for America, we’re encouraged to release work product often – what the techy entrepreneur crowd terms an iterative, lean, agile development process. The net result forces you to embrace mistakes, rather than be in denial about them. In this way, work product is available, even if it is in an imperfect state, to begin leveraging community around the project.

In following this philosophy with the Legal Procurement Guide, I’d like to share with you the “Minimal Viable Findings” or MVF as I will call it. Starting in late June, I began reaching out and scheduling, then conducting, and then distilling and documenting phonecalls with about 9 people. All the while, I was continuing to read and digest more resources on the topic, and fold them into our MVF living guide.

What I’m finding is that above all, while government technology decision makers have at least heard of open source software, and understand some of the benefits that flow from the business model, they are still uncertain how easily the OSS business model can fit into their typical procurement workflow, which assumes the software to be procured has a license fee, and that the proprietary vendor assumes some level of liability for the product.

I found that other scholars have discovered this to be a major issue also, and their proposed solution is to reframe the discussion assuming that “Pre-Existing OSS is Commercial Off The Shelf (COTS).” If a description of how to fit OSS into a current COTS procurement framework will help overcome your biggest hurdle, then Dave Wheeler has a guide for you: “Open Source Software (OSS) in U.S. Government Acquisitions.”

Other interesting observations from my research include the following:

• For known solutions, government staff need to know there is a vendor that will support the customization or maintenance of the software.
• Government organizations want to know, and are willing to reuse the best practices/contractual language/procurement practices that a government organization that they perceive to be similar to them uses.
• Open source is a broad term and needs to be clarified on vendor contracts as to what part of the application is considered part of the “code” to be open sourced. With content management systems, configuration data should also be considered part of the code.
• While overall there is understanding that FOSS can be a cost-saving or otherwise beneficial solution for government software needs, the specific reasons why this is so are not well understood. The main concern always comes back to what benefits the agency gains from keeping the developments to the FOSS code freely available to the public when the agency has invested all of the money in the developments.

One of the most salient, albeit tangential issues I’m learning though, is that it’s straight up difficult to reach a broad range of people in government to collect their insights. Not only is it a lot of work to research interviewees and attempt to cast the net wide, but its also a lot of work just to find time with government staff. While I’m grateful to the brave few who endeavored through a phone call with me, sometimes as long as an hour, there’s a lot of people I would still like to talk to, but have not been able to for one reason or another. But, this further illustrates the need to have open, accessible processes – so that what knowledge is missing, can in time be contributed by the right people when they have the time and awareness to engage.

All of the government folks I’ve spoken with though, whether or not they could interview with me personally, are deeply committed to saving their organization money, and being as resourceful as possible to provide citizens with more for less. It seems like outreach and community management may be the bigger, meta issue. That is, how do you reach out to a time crunched crowd, get them the concise information and best practices they need to be innovative in the most efficient manner possible, get feedback from them as to how things worked out, and get them to come back periodically to see what the latest strategies are?

That’s what we’ll learn on each iteration. And so it begins. Like the community of developers that form around open source repositories, we seek a community of interested government staff to continually contribute their latest observations or findings from their own work, regarding what works for the reuse of technology.

If you have an insight you would like to share, we’d love to hear from you! Please comment here or join our growing team of Wiki volunteers to edit and add your own insights regarding OSS procurement in government.

(Photo credit: katielips Flickr photo stream)

Original post