Ethical Questions over Apps.gov

It’s been no secret since the Obama administration took office, that a key technological interest for the administrations tech policy would involve Cloud-based, Software as a Service (SaaS) initiatives. To that end, contractors and providers have been jockeying to provide cloud service to the federal government.

One of these contractors, notable for their size and breadth within the government I.T. contracting ecosystem, is Computer Sciences Corporation [CSC], who has partnered with Microsoft [MSFT] to provide a specialized product offering for the government.

Interestingly this week, the federal government jumped on the the “app store” movement, made sexy by Apple [AAPL] and expounded on by BlackBerry manufacturer Research in Motion [RIMM] and Palm [PALM] and now Google [GOOG] with their Android phones.

Incidentally, I’m including stock symbols for a reason. Follow the money and see where it goes. Thats your homework for the day, kids.

Screen shot 2009-09-17 at 1.52.02 PMThe new government offering, Apps.gov is a new “app store” for the federal government. Unlike other app store offerings that are geared toward mobile computing, this app store, an initiative of the GSA seeks to be a clearing house for cloud/SaaS services for the federal government. I’d be lying if I told you I thought this wouldn’t work in driving adoption by other federal agencies of these services.

The App store is divided into four sections: Business Apps, Cloud IT Services, Productivity Apps and Social Media Apps. Most of the applications found in Apps.gov are for-pay services and they are only available for purchase with a government purchasing card. These pay-services include a variety of products from Force.com, creator of the highly popular (if onerously annoying) Salesforce, and a variety of Google Apps products (all paid).

Interestingly, there are free products as well, and this is where I have ethics questions. Many of the products that are free, mostly in the Social Media section, are tools that are used everyday in social media, blogging, and web culture. Many of these apps we take for granted and talk about everyday. Applications like Slideshare and DISQUS have been used on this blog absolutely free of charge.

However, in the government, there always needs to be a tradeoff. You do something, you get something. Even Freedom of Information Act provisions make getting information a freely available right, but it doesn’t make it free. Most requests must be paid for.

Even when working with Lijit, I spent weeks and months trying to get one of the campaigns to adopt the product, but we couldn’t get it done as a free product without it being considered a campaign contribution. Granted, campaigns are not government, but you see where I’m going with this.

Daniel Ha, the CEO of DISQUS commented that they work with a variety of government agencies but that the GSA requires agreements to keep things official and on the up and up. This does not surprise me. It seems to be necessary. Ha did indicate that he was not aware of Apps.gov though, which seems to indicate that the app store was simply populated with providers who the GSA has a record of. It seems to me there’s some kind of missing piece here and I can’t put my finger on what it is.

When browsing around Apps.gov, it is not immediately known how providers get listed in the store. This is where my ethics questions come up. Companies listed in the store gain an implicit endorsement by the government, and probably immediate adoption in other agencies struggling to identify which services should be allowed and which services should not. This is not a transparent process of product selection or offering that I would have hoped for, though on the surface, it is certainly a good step in the right direction.

The major missing piece here is a transparent statement that informs the public on how apps are selected, if there is money changing hands (pay per play), how companies can get their own apps listed, etc.

This is the same problem Apple [AAPL] has had with the iTunes App store and arbitrary selection. It is such a problem that the Federal Trade Commission is looking into it. It also sets up a possibilty of an FTC investigation of the GSA for anti-competitive practice, though I’m not entirely sure if that is logistically or legally possible.

My point is that GSA is doing the right thing here, mostly. They just need to tweak and get rid of any shadow of wrongdoing or ethics questions.

The BASIC Cloud Framework API

Last night, I spent the evening with a bunch of PHP developers in DC. This informal gathering in the DC-PHP community is a regular occurrence known as the DC PHP Beverage Subgroup – Virginia Chapter. There is also a DC-chapter that meets once a month as well. These two informal gatherings are for the sole purpose of getting together, enjoying some food and cold beverages and generally just talking about anything and everything. It complements the official DC PHP meeting which is generally a technical presentation directly related to PHP.

So last night, we were yukking it up about how PHP has re-invoked the GOTOoperator, a programming mechanism that, we thought, died with the BASIC programming language of yore. Coding in BASIC was very procedural and not very rich in its abilities.

1
2
10 PRINT "Hello World!"
20 GOTO 10

One of our number suggested that PHP, since they regressed so badly with the GOTO operator inclusion, should also adopt line numbers in code as well. :) This conversation devolved into all the clich√© buzzwords of our time and eventually, it was suggested that what we really need is a “BASIC Cloud Framework API”.

Putting aside BASIC, which is not really practical or desirable, the concept of a Cloud-based Framework API, whatever it actually is, is not all that undesirable. If you think about it, we already have a Cloud-based API for APIs (yes, I realize this is very meta) with the super-cool Gnip which we covered last year when they launched. Social services channel their data through Gnip and Gnip provides a single API layer for data access. And it’s built in the cloud.

Similarly, up until a few years ago, Javascript was painful to write because developers had to write code for all the browsers and all their nuances. That was before Javascript libraries — or APIs, if you will — like Prototype or jQuery came along providing the developer with a single layer of javascript programming that would work seamlessly on all browsers.
1206677_75532165
The concept of single layer APIs is not a new one. Why can’t we have an API for cloud-services as well?

Think about this. Right now, anyone wanting to build an application has three options. They can build out a server cluster or farm that physically scales and, by proxy, ends up costing a lot as physical hardware costs a lot. A second option would involve a virtual cluster made up of virtual machines. You still need hardware, but each server souped up with up to 32G of RAM can theoretically host tons of virtual machines all acting as a physical server. An entirely virtual solution is hosting applications in “the cloud”.

Cloud computing is not without it’s challenges. I’ve challenged the reliance on it in the past, and I still do. However, with cloud services like Amazon’s EC2, S3 or Google’s App Engine, it becomes entirely possible to not only store data in the cloud, but also run and maintain entire services in the cloud.

The problem is, each of them require different things. Amazon has a suite of developer tools that are needed to build against their cloud offerings. Google App Engine only supports Python, Ruby or Java.

There should be a way to abstract this development to a single layer — or API, if you will — to take advantage of this.

Laugh it up, chuckles. A cloud-based framework API is not all that ridiculous of a concept. The world once thought the earth was flat as well.