Users can search anything from bombs to toilet paper and filter government spending by location, timeline, agency, extent competed, recipient, product/service code, NAICS and fiscal year.

USAspending.gov first launched December 2007 as part of the Federal Funding Accountability and Transparency Act (FFATA) of 2006 that required the Office of Management and Budget to ‘establish a single searchable website, accessible to the public at no cost’ on all federal government spending.

From USAspending.gov What’s New in 2.0?:

1. Compare spending across agencies – understand types of agency spending understand types of agency spending
2. View agency spending dashboards – see how and where agencies are spending money and who the recipients are
3. Explore spending trends with interactive charts – use interactive motion charts to see how spending trends have changed from year to year
4. See spending where you live – use interactive maps to see dollars being spent in your state
5. Quickly find what you are looking for – use interactive search features to customize your search across multiple dimensions
6. Filter, analyze and share – share your feeds, exports and results with friends via social book-marking and RSS feeds
7. Analyze contract and award transactions – review all transactions for a single contract or award in one simple list
8. Download bulk data – download all spending data for offline analysis
9. Get spending updates every day – access new spending data on a daily basis
10. Expect more transparency – look for more spending data in the future as 2.0 is engineered to support full FFATA compliance

(via Wordle)

However, most of the content within the Open Government Plans (at least the ones that I’ve had time to review) are largely aspirational. Each of them reviews the tenets of the OGD, and commit to transparency, collaboration, and participation, but lack the substance and details that will achieve each of these goals. Buzzwords dominate promises to “explore” or “experiment” towards reaching a goal. Agencies are working to plan openness, hoping to explore ideas with the public, and ready to become more transparent – but we’re not seeing the follow-through that we had hoped for in terms of actionable plans or lists of useful data sets the agency will be releasing to the public. Still, one part of each plan tended to be more fleshed out than the rest of the plan: the flagship initiative.

The OGD required agencies to describe at least one new initiative that they would begin implementing soon, and some agencies have already started their efforts towards these flagships. Because of the immediacy of the initiatives, they provide a glimpse of how each agency sees openness within their mission and how they plan to get there. Some are very substantial, providing the timelines and planning necessary to ensure that the project is ready to get underway – or in some cases, are already launched (link).

Flagship initiatives are probably the best indicator of how an agency is approaching the mandates of the Open Government Directive. They are intended to be the most concrete and specific part of the Plans – and typically, they are the only specific and developed plan for new steps towards openness. This is the road that will take agencies from idea to goal.

Some of the flagships are quite impressive, like the DOJ’s FOIA Dashboard, which will centralize and present data about FOIA, while others seem aspirational rather than ready to implement. For example, the Treasury Department hopes to become mostly paperless [link] but doesn’t provide an executable plan or indications of how they hope to achieve that goal. The four paragraphs on their open government flagship barely manage to explain the scope of the project.

Many flagship initiatives follow the general dashboard model: making data about government spending more accessible to the public using web tools and graphical presentation. OSTP (link) will be launching an R&D dashboard, and DOJ (link) has proposed centralizing FOIA data from 92 agencies as a dashboard. Centralizing this data into a dashboard allows easy comparisons between agencies and from year to year. Similarly, the Department of Energy (link) will be releasing energy information for the public in a wiki-style format, alongside educational initiatives.

Others propose opening processes that have not been open to the public, especially in technological ways. The NASA initiative (link) to collaborate with the public in developing their software, as part of an Open Source Software Development Program, will address a problem that’s widely addressed in the geek-oriented side of the open government community – it’s inordinately difficult to try to help out in technology oriented ways. Similarly, OSTP will be starting a “Geeks for Wonks” program to connect technology students and agencies with projects. Creating these avenues for skilled engagement – rather than simply asking for ideas – has the potential to engage those hoping to help who have thus far been shut out.

The most notable success? Agencies are starting to build career champions for transparency and for the use of technology within agencies. Technology can enable the transparency, participation, and collaboration that will make government more effective.

Each of these initiatives has the potential to change the way that agencies do business. That is the intention of the OGD – to change the way that the government interacts with citizens, how agencies collaborate internally, and how much information is available to the public. Clearly, this culture change has been embraced in many agencies, but not everyone has had the time to develop substantive plans. The most promising ones are well developed and are going to make information available, streamline performance, or engage citizens. I have every hope that even the most ambitious of flagships can become a reality, as agencies move forward with their Open Government Plans. I hope that next time around, the plans will have more substance – more concrete, achievable initiatives to go with the grand plans full of buzzwords.

Cowan-Sharp shares what inspired them and how they did it.

Why did you create OpenGov Tracker?

In its own way, the public consultation process happening on IdeaScale right now is a historic activity, but so few people know about it. We thought that a single access point would give a sense of the participation on all the different sites, a window into the discussions happening, build some excitement, and inspire people to participate. We also thought maybe a bit of healthy competition would emerge between the different agencies, spurring additional participation. Finally, we wanted to call out and celebrate the ideas of those people who have made valuable contributions, so we promoted the most popular ideas across all agencies.

What’s the development story behind it?

When we realized the IdeaScale site had an API, we grabbed the ideas for the NASA site and started playing around. Seeing that each idea object included counts of comments, votes and lots of other information, we realized it would be easy to pull out those basic stats, calculate a few additional ones and aggregate them for all the agencies. So, we started building. The way the sites are set up, you have to register separately for an API key for each of the agencies, which wasn’t so bad– but of course then it turned out that although each agency has the same set of nominal categories, each is represented by a different category ID in the backend. This makes sense when you realize that IdeaScale is used to supporting multiple, completely stove-piped clients. But that was a fun hour or so of tediously building an index to match up the category names with each agency’s numeric category IDs.

As the number of ideas started going up, we realized that our numbers looked wrong. Upon closer inspection it turned out that the API was truncating result sets at 50. We were worried that as soon as any agency had a category that went above 50 ideas, the site would basically be useless. But IdeaScale was really helpful, and lifted the limit for us. We really appreciate that.

Of course a few agencies chose their own route instead of IdeaScale, so we haven’t included them. I’m of two minds on this. I think it’s great if agencies have their own vision for things and do something different and unique to them, since it shows they’re interested. At the same time, as a developer, it really helps us promote your stuff when there’s a common interface for accessing it. It would be neat to see us collectively put some thought into common interfaces, where feasible, for data objects on government sites and projects.

I always fail to appreciate how time consuming presentation is. Pulling out the data was much easier and faster than tweaking the layout and style. But it’s important you do that well, or obviously no one will stay on the site long enough to look at those numbers. Thankfully, Robbie’s pretty good at that part!

The site is built in using Python with Tornado as the web framework. We’re in the process of adding in MongoDB as a backend data store. It took about two evenings and two full days before we deployed it.

What features do you plan on adding in the future?

Right now the site focuses a lot on numbers. We’re working on a few additions that will bring out more of the actual content to highlight the diversity of contributions. I love looking over the tags and the titles, and appreciating how different the ideas are, how different the focus of each agency is, and how each one has its own microcosm of terminology, challenges and touchy issues. It’s actually really educational to scan the lists of ideas and learn what’s happening in the different agencies.

When we first released the site, it was just what we call a “tinyhack,” a quick and dirty project to get something useful up and running. We weren’t even saving the data. But a lot of people have asked for the ability to look at contributions over time, so now we’re growing up the code a little bit, adding a proper data store on the backend. That will also enable us to easily display trend lines, pull out more content, etc.

But there’s only another 25 days to go, so we need to optimize value provided and time to deployment. That said, we’ll make sure the data continues to be available after the consultation process is over so more fun stuff can be done by those who want to.

These resources can be rapidly self-provisioned online with no service provider interaction. The service is fully managed by the provider, freeing users from the finer details of system maintenance.

Services are sold on-demand and provisioned on a pay-per-use or metered-use basis, similar to a utility. Services are also elastic, meaning they will automatically scale to meet fluctuations in demand so a user can have as much or as little of a service as they want at any given time.

Cloud services typically fall into three broad categories:

Software as a Service (SaaS)

Software services can include anything from Web-based email to specialized inventory control and database processing software. The user interacts with the software product through a front-end portal and because the service provider hosts both the application and the data, the end user is free to use the service from anywhere.

Platform as a Service (PaaS)

Platform as a Service provides a set of software and product development tools hosted on the service provider’s infrastructure. Developers can create custom software applications on the provider’s platform over the Internet. Service providers may use APIs, website portals or gateway software installed on the user’s computer to enable interoperability with other systems. (*note: There are currently no standards for interoperability or data portability in the cloud)

Infrastructure as a Service (IaaS)

Sometimes referred to as utility computing, Infrastructure as a Service provides virtual server instances with unique IP addresses and blocks of on-demand storage. Users can start, stop, access and configure their virtual servers and storage via the provider’s application program interface (API). Users pay for only as much capacity as is needed, and the cloud provides more capacity automatically as soon as it is required.

Advantages of cloud computing for the federal government

Cloud computing offers a cost-effective and service-oriented approach for sharing computing resources across the government. Being able to access a powerful pool of common infrastructure, applications, information, and solutions greatly improves communication and collaboration across government in addition to providing incredible cost savings. The overall objective is to create a more agile federal enterprise, where services can be provisioned and reused on demand to meet changing business needs.

How cloud computing enables government transparency

Cloud computing is an excellent tool for fast, easy, secure and economical data sharing. By using a hybrid cloud environment, a government agency can easily port data sets into a secure computing environment and that data can be safely accessed by outside parties via open data APIs or commercial cloud services such as Amazon EC2 or Goggle App Engine.

Government clouds underway

• NASA’s Nebula Cloud Computing Platform
• DISA’s Rapid Access Computing Environment (RACE)

More on cloud computing

• National Institute of Standards and Technology (NIST) definition of cloud computing
• Wikipedia: Cloud computing
• NIST: Cloud computing
• Apps.gov: A collection of Cloud services available to Government Agencies
• Vivek Kundra’s apps.gov announcement: Streaming at 1:00: In the Cloud

Federal cloud bodies

• Cloud Computing Advisory Council
• Cloud Computing Executive Steering Committee

Videos

The Benefits of Government Cloud Computing

Technology, Innovation and Government

Vivek Kundra introduces apps.gov

Aneesh Chopra, Federal CTO discusses Cloud Computing

Linda Cureton, NASA CIO discusses Cloud Computing

Popular private-sector clouds

• Amazon Elastic Compute Cloud (Amazon EC2)
• Google App Engine
• Rackspace
• Salesforce
• Microsoft Windows Azure

Although I am a believer in free markets and the benefits of competition, industry has a responsibility to work together on the foundational layers to build security, quality and reliability from the ground up to advance the professionalism of the field. In essence, the information technology industry must emulate other engineering disciplines, or technological disasters and cybersecurity holes will worsen.

Daconta is uneasy with the number of platforms and methods available to software developers, and sees ever-more options and disruptions in the near future; IPv6 and 64-bit computing seem to trouble him particularly. We’re already balkanized and disorganized, how can we possibly expect to produce reliable and useful software with all this messy innovation happening?

The answer, of course, is control. Lots of it. Specifically, three proposals:

• Licenses for software developers
• A new, reliable, layered software platform developed by the NSF and DARPA
• Treat software like engineering, not art.

Gracious. I barely know where to start. Let’s try to imagine the software development world in five years, with these proposals in place.

Software development is now a licensed activity. Like an architect or a mechanical engineer, you have to pass an exam and perhaps post a bond to practice the discipline. There’s probably a professional association, like the America Bar Association or the American Medical Association, to administer the credentials.

This licensing regime is actually a pretty good idea, because all software has to be developed according to some very specific methods, with plenty of testing and documentation to back it up. So rather than letting any fool with a compiler write software, they’ll have to spend a year or two learning the right way to write code. The process is cumbersome, but every piece of software that gets compiled is perfect. At least, as perfect as we know how.

The licensing and formal methods are only possible, of course, because we have a government-directed platform that we must build on. Anyone who wants to run software in the government must do so on this stack.

It sounds as though Daconta would like a broad mandate for NASA-style code development. You can probably see where I’m going with this. Another way to tell the story might be:

There is now a government-owned platform that every government program is mandated to use, from clouds to mobile phones. Any software built on that platform must submit to rigorous, independent testing before it is deployed. Imagine ISO 9000 and Common Criteria having a baby with teeth. Anyone writing software must be licensed to do so in the United States. As a result, the pool of available programming talent is decimated. The costs of developing software for government rise, naturally.

The pool is further diminshed because developers who want to work with the latest hardware or software no longer work for agencies or contractors — they’ve wandered back to the private sector, where they can enjoy the fruits of the free market. The government software platform quickly begins to show its age, since the only developers on the platform are those that are paid to use it. Platforms that people truly want to use are in the open market, innovating at their leisure, out of the reach of government agencies.

As the government is no longer able to consume most commercially available software, it is now back in the business of writing software itself. More accurately, it is back in the business of hiring system integrators to write that software on its behalf. It’s the 1970s all over again. Budgets explode, and innovation grinds to a halt. It’s all the agencies can do just to tread water. System integrators, of course, are delighted. They’re now commanding outrageous salaries for the few programmers trained and willing to work on this mandated government platform.

Let’s hope there’s a better way.

This doesn’t diminish the problem that Daconta is hinting at, of course. Software reliability is certainly something to worry about. But there is no single solution or set of policy prescriptions that will solve the problem. I don’t think that imposing additional controls on the development of software makes sense, certainly not for all cases. There are already robust certification regimes and methods for software that does very important work: fly an airplane, control a nuclear reactor, and so forth. We don’t need that kind of scrutiny on my game console or desktop.

It’s important to note that these robust certifications only evaluate the software itself, not the people who make it. This is what’s great about software: we can examine the final product before it’s distributed. I don’t really mind if my software is written by a clever 7 year old. If it’s doing the job it’s supposed to, that’s fine with me.

This focus on ends, rather than the means, is something you can’t do with a building or an airplane. With software, we can change our minds with far fewer consequences. We can thoroughly test and scrutinize before it’s in a customer’s hands. When we do find a flaw, it’s easier to patch software than it is a 777 or a skyscraper. We should take advantage of that fact, not try to make software rigid and inflexible just because we know how to manage rigid and inflexible things. Because software has these unique properties, we have the freedom to bring more or less scrutiny to bear, depending on the circumstances. Which is what we’re doing already, through programs like the federally-funded Software Engineering Institute at Carnegie Mellon.

So where Daconta sees mayhem and chaos, I see creativity and innovation. There are many opportunities to improve the reliability of our software, but none of them have to do with the process by which we arrive at a particular piece of code. Projects like David Wheeler’s OpenProofs, for example, can provide the tools we need to be mathematically sure software is doing what we intended. The Linux Test Project does this for Linux, and it was inspired in no small part by governments’ Common Criteria mandates.

This is, in fact, how the process should work. The government should set the requirements for reliability and assurance, and allow the private sector to innovate its way toward those requirements. If we only create software that we can understand perfectly, we lose the ability to be creative, to innovate, and to take advantage of the collective intelligence and cleverness of millions of software developers. We will never eliminate risk in software, but we can manage that risk, not through more stringent controls, but by encouraging as many smart people as possible to address the problem.

GovFreshTV talked with NASA Nebula CIO Chris C. Kemp about Nebula’s role in cloud computing.

What is openNASA and why did you create it?

OpenNASA is a collaboratively written public blog by NASA employees with open comments. The authors blog on their own time and therefore do not represent NASA. The motivation for opening up this unique voice from NASA and allowing dialog to occur is something that was lacking within the internal NASA community (to communicate between ourselves) and between the public and NASA. While, again, the perspectives of the authors are theirs and not NASA’s, it does give non-NASA people a different insight and perspective into some of the activities, thinking, and desires of individuals within NASA. Over the years, we have added additional functionality to the community such as ideation, voting, sharing files, and feeds from other NASA social media communications.

We created openNASA in the beginning of social media adoption within large organizations and while NASA was still watching the trend and weary of this communication methodology, our goal was to help NASA become more transparent, authentic and direct with its communication to the public. While there are many interest groups in the space community, there wasn’t a culture which was overly positive and humble with exploring challenges and opportunities; we wanted a different dialog. We wanted this communication to be a “conversation” rather than a one way directed message. From the beginning, openNASA has been an “experiment” because we were not sure if the NASA culture was really ready for this shift in communication. But, it was clear that the public was ready for more engagement with it’s space program, so we took the initiative to bridge that gap. Our intention is to help create a participatory space agency – one that actively engaged people from all backgrounds and perspectives.

What culture issues did you face in executing this?

OpenNASA has been quite well received since its launch. It’s interesting to note that most of the challenges we have faced have been within the space community. For those in the space community who are still testing out social media, openNASA can seem a risky proposition. We also have others, who have been involved in the space community for quite some time, pushing for the very same openness, transparency and authenticity in government that we hope for. To them, openNASA can be seen as competition and threatening to niches they have carved out for themselves. Yet, these cases are very rare and, overall, we have enjoyed overwhelming support from the space community and the openNASA audience.

For the authors, the question of when to blog, how to make it clear posts are not written in any kind of official capacity, and how to walk the line of transparency without sharing inappropriate information or causing strife has at times been a delicate one. Sometimes colleagues might be uncomfortable with the ideas being discussed or questions raised. There are times when being a leader in the transparency realm makes one a target inside their own organization, more because people aren’t sure what to do with it than because they really have bad intentions.

However, these are all important questions for the transparency movement to be addressing, so it’s important to participate in initiatives where the kinks get to be worked out.

What has NASA learned and changed because of it?

We don’t think that it is fair to directly link something that NASA has learned and changed from the activities of openNASA. That being said, it is conceivable that openNASA has served as an example of exploring new methodologies for engagement and to highlight the utility of more of a dialog with the public, rather than a traditional one-to-many communications approach. NASA should be greatly commended for allowing its employees to self-regulate themselves with their personal tweets and blogs. NASA itself has surely adopted blogging and tweeting and has done so with cautious aggressiveness. As a result, the last couple years has added to the transparency and personality of NASA and helping to create a more human-side of the space program.

What would you recommend to other agencies thinking about starting an ‘open agency’ collaboration blog?

1. Be targeted – in our experience, one of the reasons openNASA has been successful is because we aren’t just talking about space in general. There are lots of great sites out there that do that. Ours has a focus on operational and personnel aspects that NASA employees are uniquely qualified to participate in. We think this makes NASA more real and tangible, and also gives NASA’s employees (us!) a place to have a say, share ideas, challenge on another, and get new inputs.

2. Start simple – this is probably true of everything in life, but start with a simple site, a few authors who are committed to posting, and let it evolve from there. Give the collective voice of the site a chance to evolve, and then invite new authors.

3. Make it easy for people to participate – The idea is about participation. Make sure it is easy for people to comment without too much work. Also encourage and support authors with differing viewpoints. Constraining authors too much will result in a homogeneous community that lacks the spirit and energy of constructive disagreement and brainstorming.

4. Have a rough posting schedule for authors, and have someone who’s role it is to gently enforce it by nudging and communicating to the authors themselves. Consistently posting new content creates a virtuous cycle of conversation.

5. Defend and protect the culture you create – Write terms and conditions on your blog reflecting the type of culture you want to create. Heated discussions are great, but disrespect, name-calling and personal attacks are something we have had to draw a line at, and we feel our community is stronger because we stood up for those values. The culture created in the beginning of a community ends up creating its norms and becomes its personality when thriving. Be prepared for Government Trolls, and know how to defend the terms and conditions you set out. These people are tax payers, and they may have personal relationships with high-level people in your agency, so be prepared to be direct but firm.

What other agencies are doing the same?

Ideas for Seattle

On behalf of Mayor-Elect Mike McGinn, welcome to Ideas for Seattle. The strength of our city comes from our talented citizens. We need your input during this transition so that we can work together to make Seattle a better place for all of us.

Santa Cruz City Budget

This is your city. Though these challenges are shared with a nation and indeed the world, we need to come up with our own solutions. How would you like to see the city handle these trying times?

Ideas for Austin

What are your ideas to prepare our city for the 21st century economy?

openNASA

Welcome to the official openNASA feedback and ideas forum. Do you have an idea? Do you recognize a good idea when you see one? We want to hear from you!

Department of Veterans Affairs Website

St Louis County Crime Incident Map

Welcome to the official feedback forum for the St Louis County Crime Incident Map. Do you have an idea to improve our site? Do you recognize a good idea when you see one? We want to hear from you!

Emma Antunes, project leader for NASA’s internal social network, Spacebook, discusses innovation, collaboration, social media, user engagement, team work, knowledge management, and her expectations for Spacebook.