CivicOpen: New Name, Old Idea
BY David Eaves | Monday, February 11 2013
The other day Zac Townsend published a piece, "Introducing the idea of an open-source suite for municipal governments," laying out the case for why cities should collaboratively create open source software that can be shared among them.
I think it is a great idea. And I'm thrilled to hear that more people are excited about exploring this model, and think any such discussion would be helped with having some broader context, and more importantly, because any series of posts on this subject that fails to look at previous efforts is, well, doomed to repeat the failures of the past.
I wrote several blog posts making the case for it in 2009. (Rather than CivicOpen, I called it Muniforge.) These post, I'm told, helped influence the creation of CivicCommons, a failed effort to do something similar. (I sat on its advisory board.)
Back when publish my posts I thought I was introducing the idea of shared software development in the civic space. Not not after l learned of Kuali — a simliar effort that was occurring the university sector — and was so enamoured with it I wrote a piece about how we should clone its governance structure and create a simliar organization for the civic space (something that the Kuali leadership told me they would be happy to facilitate). I also tried tried to expose anyone I could to Kuali. I had Kuali representative speak at the first Code for America Summit and have talked about it from time to time while helping teach the Code for America Fellows at the beginning of each CfA year. I also introduced them to anyone I would meet in municipal IT and helped spur conference calls between them and people in San Francisco, Boston and other cities so they could understand the model better.
But even in 2009 I was not introducing the idea of shared municipal open source projects. While discovering that Kuali existed was great (and perhaps I can be forgiven for my oversight, as they are in the educational and not municipal space) I completely failed to locate the Association des développeurs et utilisateurs de logiciels libres pour les administrations et les collectivités territoriales (ADULLACT) a French project created seven(!) years prior to my piece that does exactly what I described in my Muniforge posts and what Zac describes in his post. (The English translation of ADULLACT's name is the Association of Developers and Users of Free Software for Governments and Local Authorities; there is no English Wikipedia page that I could see, but a good French version is here.) I know little about why ADULLACT has survived, but their continued existence suggests that they are doing something right - ideas and processes that should inform any post about what a good structure for CivicOpen or another initiative might want to draw upon.
Of course, in addition to these, there are several other groups that have tried – some with little, others with greater, success – to talk about or create open source projects that span cities. Indeed, last year, Berkeley Unviersity's Smart Cities program proclaiming the Open Source city arrived. In that piece Berkeley references OpenPlans, which has for years tried to do something similar (and was indeed one of the instigators behind CivicCommons - a failed effort to get cities to share code. Here you can read Philip Ashlock, who was then at OpenPlans, talk about the desirability of cities creating and sharing open source code. In addition to CivicCommons, there is CityMart, a private sector actor that seeks to connect cities with solutions, including those that are open source; in essence it could be a catalyst for building municipal open source communities, but, as far as I can tell, it isn't.
To understand why some models have failed and why some models have succeeded, Andrew Oram's article in Journal of Information Technology and Politics is another good starting point. There was also some research into these ideas shared at the Major Cities of Europe IT Users Group back in 2009 by James Fogarty and Willoughby that can be read here; this includes several mini-case studies from several cities and a crude, but good, cost-benefit analysis.
And there are other efforts that are more random. Like The Intelligent/Smart Cities Open Source Community which for "anyone interested on intelligent / smart cities development and looks for applications and solutions which have been successfully implemented in other cities, mainly open source applications."
Don't be ahistorical
I share all this for several reasons.
- I want Zac to succeed in figuring out a model that works.
- I'd love to help.
- To note that there has been a lot of thought into this idea already. I myself thought I was breaking ground when I wrote my Muniforge piece back in 2009. I was not. There were a ton of lessons I could have incorporated into that piece that I did not, and previous successes and failures I could have linked to, but didn't (until at least discovering Kuali).
I get nervous when I see posts - like that on the Ash Centre's blog - that don't cite previous efforts and that feel, to put it bluntly, ahistorical. I think laying out a model is a great idea. But we have a lot of data and stories about what works and doesn't work. To not draw on these examples (or even mention or link to them) seems to be a recipe for repeating the mistakes of the past. There are reasons CivicCommons failed, and why Kuali and ADDULACT have succeeded. I've interviewed a number of people at the former (and sadly no one at the latter) and this feels like table stakes before venturing down this path. It also feels like a good way of modelling what you eventually want a municipal/civic open source community to do - build and learn from the social code as well as business and organizational models of those that have failed and succeeded before you. That is the core of what the best and most successful open source (and, frankly many successful non-open source) projects do.
What I've learned is that the biggest challenge are not technical, but cultural and institutional. Many cities have policies, explicit or implicit that prevent them from using open source software, to say nothing of co-creating open source software. Indeed, after helping draft the Open Motion adopted by the City of Vancouver, the helped the city revise their procurement policies to address these obstacles. Indeed, drawing on the example mentioned in Zac's post, you will struggle to find many small and medium sized municipalities that use Linux, or even that let employees install Firefox on computers. Worse, many municipal IT staff have been trained that Open Source is unstable, unreliable and involves questionable people. It is a slow process to reverse these opinions.
Another challenge that needs to be addressed is that many city IT departments have been hollowed out and don't have the capacity to write much code. For many cities IT is often more about operations and selecting who to procure from, not writing software. So a CivicOpen/Muniforge/CivicCommons/ADULLACT approach will represent a departure into an arena where many cities have little capacity and experience. Many will be reluctant to built this capacity.
There are many more concerns of course and, despite them, I continue to think the idea is worth pursuing.
I also fear this post will be read as a critique. That is not my intent. Zac is an ally and I want to help. Above all, I share the above because the good news is this isn't an introduction. There is a rich history of ideas and efforts from which to learn and build upon. We don't need do this on our own or invent anew. There is a community of us who are thinking about these things and have lessons to share, so let's share and make this work!
A note to the Ash Centre
As an aside, I'd have loved to linked to this at the bottom of Zac's post on the Havard Kennedy School Ash Centre website, but webmaster has opted to not allow comments. Even more odd is that it does not show any dates on their posts. Again, fearing I sound critical but just wanted to be constructive, I believe it is important for anyone, but academic institution especially to have dates listed on articles so that we can better understand the timing and context in which they were written. In addition, (and I understand this sentiment may not be shared) but a centre focused on Democratic Governance and Innovation should allow for some form of feedback or interaction, at least some way people can respond to and/or build on the ideas they publish.
This post originally appeared on Eaves.ca.
Personal Democracy Media is grateful to The Omidyar Network for its generous support of techPresident's WeGov section.