Civic technology

2010 Wish: A Non-Profit to Help Government Entities Share Code

We want to share

We write a lot of code in the New York State Senate Office of the CIO. It’s all released under dual BSD and GPLv3 open-source license, and we post most of it here on GitHub (and some on  We fervently hope that our peers in government– whether in other legislative bodies, at other levels of government (e.g.: city, county, federal), or other branches of government (e.g.: NY State Agencies in the Executive Branch)– will find and make use of this code.

For example, our website, into which 1000s of hours of developer work have been invested to customize the Drupal CMS platform for our legislative body, should ideally be able to meet the quite analogous website needs of the ~98 other State-level legislative bodies in the USA, not to mention the 1000s of City Councils in the USA.  I’d like it to be easy for an IT Director for any legislative body in the US to quickly and easily get capabilities analogous to without needing to reinvent our wheel.

But It’s Hard…

However, most of the time for most of our applications to date, the promise of delivering more utility more efficiently by sharing the costs of developing and maintaining application code between peer public sector entities– better leveraging investments of precious tax dollars in public sector IT– is merely a good idea.

We try to go the extra mile to document our code well, posting it on GitHub, making our peers aware of it through speaking engagements, participation in unconferences, and use of the social Internets, and by liberating the data at least through our extensive support for open data standards and APIs.  We field calls about approach and policy and precedent frequently from our peers.  However, there is no question that it remains a heavy lift for a peer institution to actually take our application code and efficiently drop it into their own use case, because our code is necessarily customized to our specific nuanced needs in the Senate.  Like most government entities these days, we’re understaffed relative to the workload we have.  We don’t have the resources to easily contribute the custom Drupal modules we’ve written to and commit to becoming the maintainers of these modules.  Nor do we have time to refactor our code into a more generic “Legislative CMS product” for our peers to more easily find and make use of.

Another example– this time one in which another government entity could help us here at the NY Senate: friends of mine at NASA recently built an online application (in their own free time) that leverages NASA’s publicly accessible LDAP server data (which is a subset of the internally accessible data from the same LDAP server), and then allow NASA employees to “claim” their profile on this public website, and add additional metadata like your Gravatar, your skills and interests, etc.  Here in the NY Senate we’ve been researching enterprise social networking & collaboration applications that could help our internal staff to discover and leverage specific interests and skills of their colleagues.   The application written for NASA, which is open-source and posted on GitHub, could help meet this need for us, but at the moment we’d have to rip out and replace code in order for us to be able to use it; it would take the NASA crew some significant additional work to refactor the code to turn it into more of a product in which we could merely edit a config file to deploy it for NY Senate…

In both our NY Senate example and the NASA example, if the refactoring work on code were done, and some level of ongoing maintenance and support of the code were available, more value would have been returned from tax dollars invested in our respective work, and we would also in turn be able to leverage off of the additional refinement of our code done by our peers in government to further benefit our institution.  In other words, we could share the workload of software development and maintenance with our peers in government.

In the case of some business applications, vendors do offer productized SaaS solutions that meet the needs of a customer vertical like “legislative body.”  But these solutions are rarely open-source, and are often either prohibitively expensive, or are not really built to suit the nuanced needs of a niche customer group, because such a niche may not be a large enough potential business market to warrant development of a highly nuanced product.  Therefore, I think that the public sector needs to innovate in terms of self-support of technical collaboration.

I can envision a thematically-focused technically competent organization like the Sunlight Foundation doing the heavy lifting on a specific application that might be of specific interest to them, like our Open Legislation application.   Others of our peers, like the NYS Department of Labor, have taken explicit steps to increase technical collaboration with other Labor organizations in the public sector by creating online hubs like sets a strong precedent at the Federal level, and I’ve heard rumors of a to be launched in the future.

Open standards help.  Unconferences and virtual peer communities of practice help.  Open APIs help.  Open software licenses help.  Code repositories help.  Cloud computing infrastructure in which a machine image can be cloned with a few clicks helps.  Developing applications within a service-oriented architecture (SOA) helps. The promise of online government app stores and feature servers help.

However, all of these approaches today are being implemented piecemeal if at all, and, when they are, often within a narrow niche where a motivated group of peers seeks help in solving a single problem they’re focused on at a single time.

A Solution?…

I believe that citizens and governments alike would be well-served by an international non-profit entity (or perhaps a consortium of non-profit and for-profit entities committed to open-source?) charged with putting all these techniques together in a way that any public sector institution can easily contribute to and extract value from software development by their peers.  Unlike some existing efforts, this organization would NOT be limited to moving the ball forward in a single thematic arena like “transparency” (e.g.: Sunlight Foundation) nor to a single geographic purview (e.g.: US Federal Government or New York State Government), nor be focused within a specific government service sector (e.g.: Labor, Motor Vehicles, Tax), nor that is focused on a particular technology stack (e.g.: Drupal for Government).  Rather, such a non-profit technology organization or consortium would:

  1. Map the the virtual space of government IT applications (ranging from procurement and contract management, to payroll and other business applications, to citizen identity management, to CMS to CRM to more niche applications like news clippings services and legislative research tools);
  2. Find open-source licensed code that is being developed within the public sector to address these application needs and that could deliver value for a wide range of public sector entities;
  3. Do the hands-on work to generalize the code so that it is broadly useful and productized as much as practical;
  4. Publicize the availability of the new open-source products within the government (as customer) and public sector IT consulting services communities;
  5. Provide support and maintenance of the code for its public sector consumers and contributors;
  6. Maintain roadmaps for, and convene multi-institution developer communities around, specific major areas of opportunity for ongoing collaborative software innovation.
  7. Play a role in the planning and build-out of government clouds, app stores, and feature servers.

Such an entity, once fully realized and effective over a period of years, I believe could yield hundreds of millions of dollars of tax dollar savings worldwide on public sector software development and licensing annually.  It could also significantly expand the size of the public sector market addressable by small and medium-sized IT consulting firms by moving dollars spent from software licensing to customization and support, and by allowing small engineering teams from separate companies and institutions to more easily collaborate to achieve large scale engineering capacity when required.

In other words, such an effort might well  reduce government IT costs, increase the capacity for government entities to collaborate with one another through technology, increase competition in the private sector for government IT contracts, and increase the likelihood that smaller businesses can provide services higher in the food chain of government IT contracts.

Organizations that I hope will look at taking on part or all of this opportunity include Code for America, the Open Planning Project, the World Bank, ExpertLabs, and perhaps the Ford Foundation’s Effective Government Program.

colab, nasa, reinventing government, second life

How Online Organizing in ’04 and ’08 Can Improve our Federal Government in ’09

Recently I was asked to reflect on how the lessons of online organizing by those of us who worked in the 2004 Presidential campaign have impacted not only the 2008 Presidential campaign (in which Dean ’04 and Clark ’04 veterans teamed up to create Blue State Digital, the technology backbone of Obama’s online operation), but also the Federal Government, over the past four years.

Many 2004 veterans have been working in the realm of making government more open in order to enable watchdog oversight of it. I have been working more in the realm of trying to make government more efficient and effective through technologies and organizing techniques that promote openness. I’m personally mostly focused on the cultural and policy side of things– trying to get people inside NASA used to being more open and sharing by default rather than only when explicitly forced to. There is also a great deal of work being done by reformers in the CIO’s offices and elsewhere on the communications technology side of NASA’s operations. They’re working on open APIs, open-source licenses, etc. I’ve told a bit of this story, in the context of NASA, in several presentations over the past year. Here below I’ve attempted to break down the problems, implications and solutions I see in a more structured format, again using examples we have encountered at NASA.

Note that none of these observations below are specific to NASA… They apply to any large government bureaucracy, and we are working with our change agent peers in other Agencies as well. We simply have the luxury/curse at NASA of a high-profile brand and significant public interest and goodwill to use as a lever for this change.



  • no internal searchable database of people, projects, skills and technology assets


  • internal inefficiency and redundancy; internal competition for resources and a culture of sequestering information because having information that no one else has is perceived as having power


  • reforming human resources policy to permit and encourage more open communication (internally and externally) and bottom-up innovation, and reforming management structure to create a more flat more networked organization
  • foster cultural change, including renovating NASA’s physical plant to create inspiring workspaces that foster openness and collaboration
  • creation and implementation of systems to capture knowledge and make it searchable



  • slides for any Powerpoint presentation to be given to a public conference are supposed to be submitted for review well in advance to make sure that no sensitive information is included in them, rendering it onerous to speak openly or to include recently updated information
  • policies for NASA employees to spend their own time working on other projects, communicating through social media about their ideas and work, etc. are restrictive and at best fuzzy, and the burden of proof rests on the employee to prove WHY they should be able to communicate with the public, rather than the burden of proof resting on the Agency to prove why not
  • reaches millions but is all processed edited moderated content; very difficult to mash this content up and re-share it, and no opportunity for user-generated content either from the public or from a broader array of NASA employees than just authorized Web Content Managers.


  • less public interest and awareness and inspiration and educational benefit than otherwise possible, because content consumption is passive
  • NASA unable to benefit from the innovation and work cycle leverage that could result from leveraging the goodwill, technical skills, time and creativity of members of the general public, and entrepreneurial private sector
  • NASA has difficulty attracting and retaining talent that is used to working in a more open environment in the private sector


  • agency-wide deployment of the Web 2.0 communication tools, communications policies, and processes used by the world’s leading private technology enterprise
  • build communities and create formal processes to leverage the time and skill of these communities for practical benefit to NASA
  • highlight and build on the few examples of successful crowdsourcing at NASA
  • create sustainable professional relationships between NASA and non-NASA personnel that shift NASA’s internal culture through co-working and open-space format events
  • shifting the budget and skillset of NASA Strategic Communications staff to focus on encouraging, training and supporting non-StratCom staff in their public communications role, including hiring staff with corporate blogging and online organizing skills
  • set communications policy that mandates open publication of all internal Agency communications such as meeting minutes, absent demonstrable and internally verified need to maintain confidentiality; shift the burden of proof from the need to show that information is “safe” to publish, to the need to show the information “is not safe” to publish.



  • NASA hires contractors to write code and doesn’t mandate that is be open-source and often doesn’t even acquire the rights to modify, repurpose, or release that code
  • IP created within NASA is unknown and unsearchable internally, let alone externally, and it is extremely labor intensive and relationship-dependent for internal business development staff to collect data, identify IP licensing opportunities, and execute those licenses
  • petabytes of data collected by NASA that is legally in the public domain is extremely difficult to find, search, interpret, and share, due to slow data processing and archiving and limited APIs


  • the inability to get more eyes on code eliminates an opportunity to reduce the likelihood of failures such as the Mars Climate Orbiter explosion
  • NASA pays more $ for code to be written by contractors than it would have to if it leveraged existing open-source projects (including its own)
  • NASA returns less value to the taxpayers because IP assets aren’t easily licensed or contributed to the public domain where they could yield ancillary benefit to society