The Government Open Source Conference, masterfully curated by Deb Bryant and the good people at the Oregon State University Open Source Lab, is one of my favorite open source events. Every year, they manage to pull together quality speakers from innovative agencies and projects in a warm, collaborative, and exciting environment.
Before the earthquake unpleasantness later in the day, I was able to was able to catch the "Cutting Costs" session. Alex Howard of O'Reilly ("The hardest working man in Gov 2.0") moderated a panel discussion between
Dr. David Wheeler of the Institute for Defense Analysis, Tiffany Smith Licciardi from the State Department's Office of eDiplomacy, and Greg Elin, the Chief Data Officer for the FCC.
Frankly, I was expecting to hear a lot of the arguments I've heard before. Let's face it: cutting costs with open source is very well-trod territory. This panel, though, surprised me. The level of sophistication and the quality of the advice this panel produced was remarkable. They weren't beating the same tired clichés about security and licensing. Instead, we heard about the ways open source software and even the open source process were informing agency strategies, and got some very practical advice on where open source can be used, and how it can serve a larger mission.
The Scholar
Wheeler is famous in government open source circles for his ability to dispel open source myths. He's not a contracting officer, and he's not a lawyer, but he's one of the few open source advocates who can claim that he's not only read but *understood* the Federal Acquisition Regulations, the Defense Department's supplements to the FAR, and the government's regulations for handling intellectual property. When it comes to open source and the federal government, he's the expert's expert.
It's also a pleasure to see him speak. He's enthusiastic, plain-spoken, and his arguments are insightful and air-tight. Early in his presentation, for example, he reminded us that we rarely buy software. In most cases, we've only purchased the right to use the software. Getting procurement officers to think in terms of licensing and "rights to use" draws out the similarities between proprietary and open source software for the procurement folks.
His focus on this panel was Total Cost of Ownership, a method of analysis that anyone in IT is familiar with. He reminded us that TCO is very context-dependent, and it's easy to miss or ignore all the variables involved in a TCO analysis:
- Hardware Costs: is the new software going to require new hardware?
- Direct Software Costs: how much will it cost to acquire the software licenses? What about ongoing maintenance costs?
- Indirect Software Costs: do you have the staff you need to support the software? Do you need to hire new talent, or train the folks you have? All software has downtime; can you afford the kind of downtime you expect?
He also encouraged us to think about costs over a longer term. Too often, government procurements are worried only about the current budget cycle. In software procurements, this can be deadly. Future costs are almost always higher than the first-year costs. The mismatch between software lifecycles and hardware lifecycles can play havoc with a TCO analysis. Perhaps most important, if you aren't accounting for switching costs, you're missing a huge cost driver: how expensive will it be to exit the solution in question?
With all of this in mind, he believes that open source has broad advantages: the acquisition costs are generally lower, increased competition keeps upgrade and maintenance costs low, and there is far less overhead managing open source license compliance that proprietary licenses. At the same time, Wheeler warns, installation, staff, and training costs may be higher for more complex open source deployments. He helpfully provided an entire page of TCO studies on open source software, which you'll be able to find at http://goscon.org/ once the presentations have been posted.
Finally, he reiterated the most important fact about open source in government: that in government procurements, it is "commercial software". That is, it's the same as software that you pay for. It has to follow the same rules, the same procedures, and it's actually illegal to ignore it.
The Advocate
Greg Elin has been working on openness and transparency issues ever since his stint at the Sunlight Foundation. As Chief Data Officer of the FCC, he's had a tremendous opportunity to affect change from inside a notoriously opaque organization. Under his leadership, the FCC launched a new Drupal-based FCC.gov, and released the open source National Broadband Map.
As you might expect, he learned some lessons.
While agreeing with Wheeler, he also emphasized the complexity of procurements from the government's perspective. It's not sufficient to blithely recommend the "right tool for the right job" when faced with "the labyrinthian licensing landscape" that confronts a government project. Between cloud services, the Creative Commons, proprietary, open source, and firm fixed price contracts, the diversity of licenses make it difficult to calculate TCO. ROI is also difficult: how do you calculate the value of Twitter, which is free?
Elin identified three areas in which open source enhances the bottom line. First, commoditized computing and network services like Apache, sendmail, Nagios, and openssh can provide quality software for critical infrastructure at a very low cost. Open source is also helpful in cloud computing, where user demand is elastic but user support is low. His experience is that at some point, the scale of a system demands open source use to reduce the overhead of licensing and licensing management costs. Finally, green-field deployments where a project can compound cost savings through expertise development. That's a fancy way of saying "open source is good for getting other people to help you." NASA's Nebula project, through the OpenStack project, is a good example of this, as is FCC's own National Broadband Map.
Elin also reminded us that licensing is rarely the most expensive aspect of an IT project. Often, it's staff and training. If you have a lot of engineers who work very "close" to the Internet, you're more likely to use open source, because the support costs go down. If you're not engineering-oriented, or not close to the Internet, those costs will go up.
The Diplomat
Tiffany Smith Licciardi has spent her time at the Office of eDiplomacy dragging the State Department into the 21st century. Licciardi's challenge is a geographically distributed user base and a critical need for close collaboration.
In the past, technology has been unceremoniously forced into the historically conservative organization with questionable results. Instead, Licciardi and her team resolved to work with tools that are focused on the user's needs. More often than not, these are social, communication tools that permit staff to connect with one another more easily. With "almost no budget," they were naturally drawn to open source tools and ways to use the open source process to develop them over time.
Communities@State is an internal multiple-author blog platform based on WordPress that provides a forum for professional dialog between staff and their counterparts in other countries. There are now dozens of active communities connecting staff that would otherwise have no venue to meet or collaborate.
Diplopedia, started in 2006, is a Wikipedia-style collaborative editing platform based on MediaWiki. They seeded the site with 20 articles, and invited a handful of trusted contributors. The site then blossomed, and has since grown to 14,400 articles with 43,000 page views every week.
Corridor is a professional social networking platform, very much like Facebook, based on Drupal. Staff can use the platform to connect with each other, collaborate, and ask questions of each other. Crucially, Corridor was an experiment: if it hadn't worked, it would have been just fine. That meant keeping the project low-risk and low-budget, which was perfect for open source. IBM's Center for the Business of Government has a written a case study on the success of the platform.
Open source also finds its way into other eDiplomacy programs, like the regular Tech@State meetings that encourage public-private collaboration. Through the Virtual Student Foreign Service, State Department interns can help embassies overseas with tasks like translation at very low cost. After the disaster in Haiti, a Tufts student was able to work with Ushahidi to improve communication among the public and the emergency responders.
Licciardi emphasized an important aspect of open source deployments that's often overlooked: the ability to respond quickly to user needs. For each of the platforms she described, eDiplomacy is constantly tweaking and improving in response to user's feedback. This process is considerably easier because eDiplomacy has control over the source code.
Climbing the Mountain
During the question and answer portion of the panel, a member of the audience asked how open source can respond to RFPs that seem "wired" for a proprietary solution. The panel was unanimous: if you're engaged after the RFP has been written, you've already lost. Working with the government means a real collaboration. Wheeler reminded the audience that in many cases, the RFPs aren't wired deliberately. It's far more likely that the procurement officials are simply unaware of the open source alternatives and inadvertently create requirements that preclude their use. He recommended responding to the Requests for Information (RFIs) that preceed most RFPs. This way, the officials can be exposed to the open source alternatives.
Elin added that open source advocates can attend the regular "Industry Days" that procurement officials sponsor to answer questions from potential bidders. These are excellent forums that let industry learn more about the thinking behind new programs.
Elin also mildly scolded the open source community for giving up too easily. Too often, he says, open source developers and vendors retreat when confronted with the (admittedly intimidating) government procurement process. Instead, he says, projects need to learn the process and how they can work within it to affect change. "We need folks who can climb the other side of the mountain and meet us at the top," he said.
What I saw in this panel was a real change in the government attitude towards open source: it's not new, it's not revolutionary. It's just an extremely effective tool that agencies are learning how to put to its best and highest use. With staff like Wheeler, Elin, and Licciardi, it's easy to imagine quite a few open source advocates at the top of Elin's mountain.
Comments are closed.