I attended the first GOSCON 2009 (Government Open Source CONference) in DC last week and learned a lot about the government’s use of open source software (OSS). There were two major announcements at the conference,
first by the DoD and the second
by the White House.
The keynote with DoD CIO David Wennergren was the most anticipated event for most at this conference as his talk was about the newly released DoD guidance document that clarifies the use of open source software at the agency (and is also considered a template for all the rest.)
To quickly sum it up for anyone who missed his talk, he reiterated current federal law, which states Government agencies HAVE to look at commercial items [when building out new capabilities] and that open source is considered commercial software also. So a tip to all of us in OSS land, when dealing with the government agencies, if the agency you are working with already knows how to budget and procure commercial software today, then the procedures are the very same for agency projects that want to use open source software.” It’s that simple! then he went into specific examples in the DoD.
A lot of newspaper articles were written about how this will revolutionize the software landscape in Government, but I would argue that the revolution is already underway as most progressive government agencies are already using open source software. Though I would also say that this document will make OSS use more common place now as many in the room seemed to struggle with licensing and procurement in the past (based on the questions being asked at the conference it was just as much about OSS and the services for the project.) This memo clarifies a lot of misunderstandings within DoD (and the government) on how and when open source software can be implemented. This evens the playing field because it says open source solutions should be allowed to compete when the department is implementing a major system.
Did we really need a memo that reiterates what most enterprises have already discovered: open source saves money, is scalable, secure, and easy to adapt? Not for the early government adopters like the White House. The other big presentation at GOSCON was about the Whitehouse.gov switching its site to use open source software PHP and Drupal. For many of you who have been following my blog articles, back in February I had an article about “The most Tech Savvy use of OSS in Government” and that distinction went to BarackObama.com and the folks at Blue State Digital who took their ideas and implemented them in open source PHP to change the state of politics and campaigning forever,
read more here. A little over 9months later, the president’s office does it again, and revamps one of the most important government sites,
Whitehouse.gov and again proves why the most Tech Savvy president’s office uses open source PHP to make fast, flexible and frugal government a reality.
After months of planning the White House has ditched the proprietary content management system that had been in place by prior administrations in favor of the latest version of the open-source content management system based on PHP.
As first reported by the AP The Obama new media team, with a few months of executive branch service under their belts, decided they needed a better development environment for the White House web presence.
After Obama’s new media team entered office and started tweaking the old WhiteHouse.gov, they decided they needed a more flexible development environment for the White House web presence. They wanted to be able to more quickly, easily, and gracefully build out their vision of interactive government. General Dynamics Information Technology (GDIT), the Virginia-based government contractor who had executed the Bush-era White House CMS contract, was tasked by the Obama Administration with finding a more flexible alternative. The ideal new platform would be one where dynamic features like question-and-answer forums, live video streaming, and collaborative tools could work more fluidly together with the site's infrastructure. The solution, says the White House, turned out to be a PHP based content management system. That's something of a victory for Drupal and PHP (not to mention open-source) community.
Is this the first move to a more open and transparent government even in code? As government developers start to embrace OSS programming and other open systems like open - forges, frameworks, languages and applications etc? I think the White House's move to open-source software signals a move towards this idea that collaborative programming can also inspire (or at least support) more open government systems.
As PHP programmers we all have seen how code openness (transparency) has made a huge impact to our own systems. When some other group/programmer wants to add or improve something to a shared OSS system, they can with open systems or they can just fork your work as a starting point. When we PHP programmers need a new system and there was already an open source project that can help get us started quickly, we just went to sourceforge.org and downloaded the PHP application to get started (just like the Whitehouse.gov site team did.) If we needed to implement something truly innovative and revolutionary, we could still use PHP to build it, even hire consultants to do it for us, and yet still we are free to build more into our system at a later date since the code is open to change (just like BarakObama.com online social politics and networking did.)
David Wheeler from DoD made a real good analogy to one attendee who was having a hard time with the concept of open code in government, he said it this plainly after several prior attempts - by comparing OSS project to buying a car for government use, "Do you want your new government car to have a hood that is welded shut because that's what proprietary software is like, or would you rather have a car that lets you open the hood, and lets you pick whatever shop or mechanic you need to improve it, not just today but into the future, and that's what open source using open languages are like" Yup that's what PHP will offer government applications, it will allow them to build IT projects with a hood that can be opened by any programmer (of course with the right approval and security - there is after all a key needed to open that hood, just like the car.)
What I think that these examples start to show us is that transparency in open code can offer transparency and agility when government polices change over time, and that’s real exciting and a huge step forward for Government. Fewer projects will be started from scratch, and more reuse and evolution of ideas will undoubtedly become the norm with more OSS proliferating government. OSS use also allows the government to reuse ideas and code that has already been proven in commercial settings. If you look at all the opportunities for different government agencies to not only reuse much of OSS code that’s out on the web, but also share more unique and US government focused projects on its own internal forges. (Forge.mil is another agency example of the forward thinking DoD open source initiatives) Many of the large enterprises that I work with have this very same type of open source policy for internal business as well as leveraging the OSS forges and applications. I’m sure this will inspire other governmental agencies (and contractors) to think about how best to leverage and share OSS code to make fast, flexible and frugal government a reality in the US. So let me know how you’re using PHP in government today and making fast, flexible and frugal government possible.
Other articles:
How many times have you heard that an application problem is not reproducible? Yea, I know, if you're a veteran like me, way too many times and sleepless nights I bet. But non-reproducible errors are common for developers. Its just impossible most times to have development setup exactly like production when the problem was happening. There are different loads between Dev and Prod, servers and environments are typically different between them, and especially database differences, and lack of good forensic information about the problem make it hard to exactly duplicate the situation that was happening to our customers on the website. So the problems fester, we learn to live with the kinks, even put ugly band-aid solutions because its all we could find. I recall talking to a developer once at Zendcon and he told me that they created a cron scrip that would restart the apache server every night to clear up a random problem that they kept having, that was the only fix he could find. And the amount of time and effort expended by developers and the staff to troubleshoot these issues start to take a toll on the project time lines. We did a survey here at Zend and interviewed 1500 developers and found that the majority spent over 30% or more of their time with maintenance and troubleshooting production issues. Non-reproducible problems don't have to be a drain on our resources anymore, we can still find them fast (and fix them) by using new diagnostics capabilities recently released in Zend Server 5.0
Posts
