Open Government Doesn’t Equal Open Source

Posted by Teresa Carlson 
Vice President of U.S. Federal Government Sales

(Cross-posted from the Microsoft FutureFed blog)

The term “open” has many different connotations across the federal landscape.  According to the president, open government is the promise of transparency, public participation, and bridging the divide between citizens and their government.  When it comes to technology, some are connecting the vision of open government with open source software development, but that connection is false and self-serving. 

Yesterday, Government Computer News reported that government agencies are increasingly embracing open source software, some in an attempt to lower IT costs.  And although many open source applications make sense for specific agency challenges, the idea that open source always equals cost savings is debatable.  In fact, a recent Gartner report states that “through 2013, 50% of mainstream IT projects using open-source software (OSS) will not achieve cost savings over closed-source alternatives.”  The report goes on to say that although organizations can save on license fees through open source, “they are often merely shifting costs from one area to another (for example, commercial operation support to internal employee support).”  

All software, including open source, is comprised of code that may or may not conform to open standards.  Open standards are really the key to achieving open government because, regardless of how software is developed, the final product must be able to integrate and communicate with other applications.  The open source development model produces applications that are no more interoperable (even with other open source applications) than traditional commercial software.

Recent media coverage seems to claim that open source software is also more secure than traditional software. The theory is that more people see and work with open source code, so it has more opportunity for security audits.  The challenge with an open source development process is that the process by its nature is ad hoc and voluntary, making it difficult to determine if the methodology itself reduces vulnerabilities.   There are systematic and rigorous processes that incorporate training, policies, procedures and tools proven to reduce vulnerabilities.  To meet this challenge, for example, our  Security Development Lifecycle approach has been statistically shown to significantly reduce vulnerabilities in products we ship.   Fixing vulnerable software in a piecemeal fashion is a challenging exercise and does not ensure reliable methodology.   

The reality is that governments operate in a mixed source world so interoperability and security should be prioritized across the board.  Microsoft supports a number of open source initiatives designed to meet the specific needs of government customers, from broad programs with vendors like Novell, to projects that integrate with Azure, our cloud operating system.  But let’s make sure that in licensing and business models, government retains its freedom to choose.  Interoperability fosters competition, and competition leads to innovation, enabling government to get the best value for taxpayer dollars.  

About the Author

Microsoft News Center Staff