Open Source Lessons For Feds

White House and agency IT leaders discuss how open source can empower government IT project teams, at FOSE conference in Washington, D.C.
5 Online Tools Uncle Sam Wants You To Use
5 Online Tools Uncle Sam Wants You To Use
(Click image for larger view and slideshow.)

Government executives may have doubts about using open source software, but they could learn a few management lessons from those who live and work in the open source development community, a group of federal IT leaders said this week.

"It's not about code, but the process of making a product [that distinguishes open source software development from the traditional waterfall approach]," said Matthew Burton, former acting CIO at the Consumer Financial Protection Bureau. "You can do open source practices without having to share code."

Burton, along with CFPB senior designer Victor Zapanta, White House aide Erie Meyer, and GitHub government evangelist Ben Balter, spoke at this week's FOSE government technology conference in Washington, providing insiders' views on how open source workflow practices could empower teams of all sizes, even in stodgy federal agencies.

[There's a religious war between the defenders of open-source and commercial product supporters. Learn why: Open-Source Vs. Commercial Software Is A False Dilemma.]

As one of the executives who took part in the launch the Consumer Financial Protection Bureau, Burton offered three lessons that even dedicated commercial-off-the-shelf (COTS) users could take away from open source development practices and apply on the job:

1. Get your products in the hands of actual users -- releasing improvements early and often.
"The open source environment tends to focus on everything that happens after the launch, whereas most enterprises focus on everything ahead of the launch," Burton said. Instead of waiting for a product owner or manager to approve and release large batches of updates, he advised, get feedback from users right away on a specific feature or enhancement. The interaction identifies problems sooner and speeds decision making.

2. Use more products at a lower cost.
In enterprises there's a tendency to think one product will solve all the problems, but that leads to massive projects that can consume all of your project funds without your knowing if the product will ultimately work. Burton pointed out. Better to spread the money into smaller projects -- and consider open source software that can usually be customized less expensively than mammoth software installations.

3. Build for other developers in addition to actual users.
"If you're an open source coder, your hope is that others will improve your product. In an enterprise, working with proprietary software, there's not the same incentive," Burton said. But as leaders turn over and new developers arrive, providing thoughtful documentation can help preserve the value and legacy of your work.

Ben Balter, a recent White House Presidential Innovation Fellow and leading voice for open government data and open source software, argued that open source practices bring about a level of collaboration and speeds decision making in ways that elude traditional projects that rely on sequential decisions.

"Traditional waterfall software development leads to low visibility and management by email," Balter said. "The always-available, asynchronous, and lock-free nature of open source projects offers a useful model for working in tight-budget environments." Workflow constraints, he added, can teach us a lot about working in a more collaborative world.

"What do you do when your agency is just hell-bent on using COTS software?" an Interior Department employee in the audience asked the panelists. He expressed the frustration he and his team experienced after providing a cost/benefit analysis that showed how in-house, open source development was the better business decision over a COTS integration.

"Forget the cost/benefit analysis, and the memo storm, and the decision matrix. Just make something!" answered Erie Meyer, a senior advisor to US CTO Todd Park. "The only way to move these conversations forward is to build what you're talking about. It's not that people disagree with you," she suggested, "They just don't know what you're talking about."

Meyer pointed to a new resource that could help federal open source advocates: a website called GovCode that indexes government open source projects and offers links to open source software code and the developers working on them. The projects are all hosted on GitHub. One example is the White House iOS mobile app code that fetches, caches, and displays articles, photos, and live and on-demand video from multiple sources.

If there's one other reason for considering open source practices in the government workplace, added Zapanta, who advised the Clinton and Obama campaigns and is a founding member of CFPB's technology and innovation team, it's the signal it sends to prospective employees coming out of top engineering and technology schools.

"If you're at Berkley or Carnegie Mellon and you drop the fact that you work on SharePoint or, their eyes glaze over," he said. "We want people working on projects in government. Drop [open source application] names like Ruby on Rails and Python, and you'll get their interest."

Could the growing movement toward open source hardware rewrite the rules for computer and networking hardware the way Linux, Apache, and Android have for software? Also in the Open Source Hardware issue of InformationWeek: Mark Hurd explains his "once-in-a-career opportunity" at Oracle.