With leadership from the White House, and success stories throughout the government spectrum, clearly open source solutions are gaining ground against proprietary software solutions in the public domain. Government Technology talked to Gunnar Hellekson, Chief Technology Strategist for Red Hat Public Sector, to get his perspective on the open source phenomenon. Hellekson covers the federal, state, local and education markets in the U.S. for Red Hat.

What makes open source solutions viable for government?

Often agencies will first approach open source as a cost-cutting measure -- that's what gets them in the door. I think once they start looking at open source alternatives or using open source systems, they find that they actually have more choice because they're not tied to a specific vendor. Since anyone can maintain or update the code, they can actually choose from many people. There's actually a functioning market around a lot of these software projects. And as a result, not only do they get less lock-in, but they also tend to get more innovation out of the software that they choose. The feature velocity of a lot of this software is a lot better. It tends to interoperate better, so open source and open standards are very closely linked. When you're using a piece of open source software, it's easier to get it working with other kinds of software, both open source and proprietary. And then finally, security. A lot of people see open source as a great way to improve the security of their systems because of the transparency that the open source process gives to the development of the software.

Are there any misconceptions about the security of open source software?

There are two misconceptions about the security of open source software. The first is that when it's open source, anyone can change it or anyone can alter it, like Wikipedia. In fact, open source communities have really robust mechanisms in place to ensure things like peer review before code is entered into the project.

The second aspect of it is the discoverability of flaws. When you have a close source system, only the company that wrote that software can go and find flaws in the software. With an open source project, anyone can come in and audit it and look for flaws, and more often than not, they'll find it and then provide a patch. In fact, the U.S. Department of Homeland Security runs a program to audit major pieces of open source software to ensure their security, acknowledging that a lot of these projects are in use not only by the government, but also by private industry. They regularly run audits on the software, looking for flaws. When they identify those flaws and fix them, everybody gets to benefit from that. That's something that wouldn't necessarily be possible in a close source environment.

What are some of the potential challenges the public sector faces in using open source?

One of the things about open source software that makes it so popular is also one of the things that makes it potentially risky. When organizations bring on open source software purely as a cost cutting measure with the intent of supporting it themselves, it can work out great. They have the talent in house and they have the sophistication to manage that, but often, they'll find themselves unable to keep up with the pace of innovation that's happening in the [open source] communities. They'll find it difficult to keep up with things like security patches, and that's what creates an opportunity for companies like Red Hat. Companies like Red Hat, and there are many, many others, have made a business out of making open source software look and feel like regular enterprise software, taking some of that risk out of it for organizations.

Ten years ago, open source was definitely a novelty, and it was something that organizations were trying to get their heads around. But today, in a lot of cases, open source software is becoming the default rather than the exception. Especially because of things like cloud computing and big data and web applications -- all of these new kinds of avenues were actually built on open source software in the first place.

How should a government entity get started with open source?

There is a kind of maturity model for this. Organizations will start by using open source. They'll take in a project and use it. They'll find it's useful, they'll find it does its job, and they'll find when they integrate it, they want to make a slight change, and then they will start modifying open source. Then they hand it back, so they are learning how to not just use it, but also to contribute back to the project. And then finally, they'll realize they have new ideas that they can release out into the world.

They’ll do it for a bunch of reasons -- moral reasons, since this is taxpayer money, so the taxpayer should be able to benefit from the software that they paid for. They’ll also do it because they want to help. This is what Code for America takes advantage of -- they want to do it because they want to share the burden. If four cities can work together on the same problem, they can solve it. So they go from using it [open source], to contributing back to projects, to starting projects on their own. A lot of cities, especially last year and the year before, released policies for using open source software, which say it is safe to use. There's no sense in being afraid of it just because it's open source. You should treat it with the same kind of scrutiny you give any other kind of software. That's a great start.

Photo: Gunnar Hellekson, Chief Technology Strategist, Red Hat Public Sector

Noelle Knell, Assistant Web Editor Noelle Knell  |  Managing Editor

Government Technology managing editor Noelle Knell has more than 15 years of marketing and communications experience, writing about public projects, transportation, business and technology. A California native, she graduated from the University of California, Davis, with majors in political science and American history. She can be reached via email and on Twitter.