Editor’s Note: This is a guest post from CC Advisor and former New York State CIO, Andrew Hoppin (@ahoppin). We strongly believe that Civic Commons is a community-driven platform, and we not only welcome but encourage dialogue on how to make it most effective as a resource. If you have an opinion on any of these issues — agree or disagree — please contact us to submit a post.

I was thrilled today to see Twitter all abuzz with complaints from Sunlight Labs about why the recently launched Civic Commons Marketplace would deign to list proprietary software applications that currently dominate their government IT niche, such as ArcGIS.  For those of you who don’t know the Geographic Information Systems (GIS) industry, the company behind ArcGIS, ESRI, had a de facto monopoly on Federal government contracts for GIS software for many years, but has recently begun to face new competition from open-source GIS platforms and organizations such as OpenGeo.   I can understand Sunlight Labs’ surprise — after all, Civic Commons has a clear mission to disrupt the status quo of the government IT marketplace and a clear organizational bias towards open data, open standards, and open source platforms / software as the tools of choice to that end.

I was thrilled because I believe the Civic Commons Marketplace will ultimately save US taxpayers billions of dollars in government IT spending while accelerating the propagation of technology-driven civic innovation in the bargain.  I’ve believed this for a while.   Thus, it’s a debate worth having; the Marketplace deserves attention and critique.

In order to realize its potential, from my perspective as a recovering government CIO, I believe that the Civic Commons Marketplace must give equal billing to all software used in government regardless of the software license associated with it; here’s why:

1. As a government IT buyer, I want to know what software my peers are using and how it’s going.  Before the Civic Commons Marketplace came along, if I was to be an “innovative” CIO pushing the envelope I would go to conferences, trade shows, magazines, and myriad blogs and vendor marketing websites and ping my socioprofessional network of people-smarter-than-I-am for information on who was using what software, who was developing what apps, and how it was going.  Then, I would narrow in on a few candidate software solutions and would call references provided to me by the vendors in question; if I remained dissatisfied with the options available to me externally, and had available skills and bandwidth amongst my staff (the exception rather than the rule) I might initiate my own new internal development project to build my own solution.  This evaluation process required a massive investment of time, felt haphazard, and didn’t net out any knowledge that would make this same process easier for my peers when they encountered the same software need in the future.  And I was an “innovative” CIO…  Most government tech buyers simply either purchase products off of government purchasing schedules, which are inherently biased against new and open-source solutions because of the cost and complexity of getting your software or services listed on them, or take what vendors with the largest marketing (and lobbying) budgets are pitching them.  They do so because it’s easier, and it’s lower risk.  ”No one gets fired for buying IBM,” is an old enterprise IT adage, and in government today that applies to Microsoft, Oracle, Salesforce, Accenture, and <insert defense contractor of choice> et al. as well.  All this may sound like ammunition for the argument that Civic Commons needs to shine a light on GeoServer and omit all reference to arcGIS in order to level the playing field, but that misses the point.  Rather, as a government IT buyer, especially if I’m not a C-level appointee with a mandate for change, if I am to seriously consider a newer or more open software solution on the merits, I need a credible not-owned-by-a-vendor-or-industry-trade-association one-stop shop to find out what is being used where by my peers, and how it’s going — a place where I can make apples to apples comparisons of proprietary and open solutions.  That would help level the playing field for open-source software procurement in government.  The Civic Commons Marketplace, while still in beta, is well on its way to becoming that one-stop-shop.  When it gets there, it can save us billions.  If, on the other hand, the Civic Commons Marketplace became a segregated open-source-solutions-only knowledgebase, it would lose credibility with government IT buyers such as myself in my past life, and, I believe, less open-source software would be adopted in government.
2. As my friend Chief Innovation Officer of the State of Maryland Bryan Sivak is fond of saying amongst the Civic Commons digerati, sometimes proprietary solutions are the right solution for government; open-source is not a panacea in and of itself, though I firmly believe that it has structural advantages that will typically outcompete its proprietary alternatives over time, most of the time.  In the case of some software verticals, open-source solutions are not mature enough or well-enough supported to be the right choice for some government buyers. That’s ok.  I want those government buyers in that circumstance to make the right choice for their specific circumstance. This is further complicated by the advent of cloud-hosted solutions, in which the efficiency of purchasing a turnkey hosted service, coupled with corollary issues of portability of data between software applications, can often render the software license question moot, or at least less decisive.  The Civic Commons Marketplace can and should help  that government buyer to select proprietary software in that circumstance.  The problem comes in — and this happens all too often — when a government buyer has insufficient incentive to take appropriate risks, and when there is a lack of parity in terms of the data available to evaluate the relative risks and benefits of a proprietary software solution versus an open-source alternative.   In that circumstance, which was quite ubiquitous prior to the launch of the Civic Commons Marketplace, proprietary solutions will win and be selected most of the time. The advent of a neutral information commons, with information about proprietary and open-source solutions that enabled apples-to-apples comparisons, changes that dynamic.  It will, I believe, will result in open solutions being selected (and developed) far more often in government.

So, I believe that the Civic Commons Marketplace in its current form, open to listings of all software regardless of license, is highly necessary and valuable.   That said, there are at least three more nuanced concerns that I believe are valid, and that should in fact be on the roadmap for the Marketplace to address in the months ahead:

1.  Regarding the concern that a listing in the Marketplace is a tacit endorsement by the Civic Commons organization, I do believe that explicit clarification to the contrary on the website is warranted.  The Marketplace doesn’t play favorites any more than Crunchbase or Yelp.  It’s a wiki, folks.  This is critical because Civic Commons has limited staff and budget, and because their staff, while highly knowledgable about public sector open solutions, would never be able to author nor exert authoritative editorial control over all civic software function verticals.   Still, early revs of the Marketplace included a nuanced ratings functionality.   It may help to add that back in.
2. Regarding Gunnar Hellekson‘s perspective that a comprehensive catalog of all government IT deployments may not be as useful as a more focused catalog of solutions, I believe that such a focused catalog will be most valuable if it is culled from and built upon a foundation of a more comprehensive knowledgebase.  For example, a catalog of open-source Open311 compliant solutions would be valuable to me as a government buyer, but not as valuable as if that catalog were built from a knowledgebase that also allowed me to contrast these open solutions with New York City’s SiebelCRM-based 311 solution, Citivox‘s proprietary but open-standards-compliant SaaS solution, etc.   In other words, the Marketplace 1.0 is intended to be a platform– a mashable knowledgebase upon which a variety of derivative products, such as this notional “focused solutions catalog of open-source government customer service solutions” can readily be built, either as a future rev of the Marketplace itself, or as a separate offering built using its young but increasingly robust API.
3. Gunnar also pointed out to me that ‘entries free of context, like cost and use-case, serve only to promote a product, and don’t help in decision-making.’  I agree with this critique as well, but again, believe that the Marketplace 1.0 is a necessary foundation upon which this metadata can readily be layered over time.  If the Marketplace 1.0 had instead focused on a narrower catalog with more comprehensive metadata and user stories, its impact might be greater in the immediate-term, but I believe would ultimately be more limited.  What if wikipedia had been written as an encyclopedia of only those subject areas where its founders found traditional encyclopedias lacking?  Again, let’s add these important new requirements as feature requests for Marketplace 2.0 — the project ticket tracker is public and open to all.

Full disclosure: I’m on the Board of the parent organization of OpenGeo, have great friends who work at ESRI, and my company helped to build the initial beta version of the Civic Commons Marketplace.