Last month I published the following article in the Municipal Information Systems Association’s journal Municipal Interface. The article was behind a firewall so now that the month has gone by I’m throwing it up here. Basically, it makes the case for why, if government’s applied open source licenses to the software they developed (or paid to develop), they could save 100’s of millions, or more likely billions of dollars, a year. Got a couple of emails from municipal IT professionals from across the country
MuniForge: Creating Municipalities that Work like the Web
Introduction
This past May the City of Vancouver passed what is now referred to as “Open 3”.This motion states that the City will use open standards for managing its information, treat open source and proprietary software equally during the procurement cycle, and apply open source licenses to software the city creates.
While a great deal of media attention has focused on the citizen engagement potential of open data, but the implications of the second half of the motion – that relating to open source software – has gone relatively unnoticed. This is all the more surprising since last year the Mayor of Toronto’s also promised his city would apply an open source license to software it creates. This means that two of Canada’s largest municipalities are set to apply open source licenses to software they create in house. Consequently, the source code and the software itself will be available for free under a license that permits users to use, change, improve and redistribute it in modified or unmodified forms.
If capitalized upon these announcements could herald a revolution in how cities currently procure and develop software. Rather than having thousands of small municipalities collectively spending billions of dollars to each recreate the own wheel the open sourcing of municipal software could weave together Canada’s municipal IT departments into one giant network in which expertise and specialized talents drive up quality and security to the benefit of all while simultaneously collapsing the costs of development and support. Most interestingly, while this shift will benefit larger cities, its benefit and impact could be most dramatic and positive among the country’s smaller cities (those with populations under 200K). What is needed to make it happen is a central platform where the source code and documentation for software that cities wish to share can be uploaded and collaborated on. In short, Canada needs a Sourceforge, or better, a GitHub for municipal software.
The cost
For the last two hundred years one feature has dominated the landscape for the majority if municipalities in Canada: isolation. In a country as vast and sparsely populated as ours villages, towns, and cities have often found themselves alone. For citizens the railway, the telegraph, then the highway and telecommunications system eroded that isolation, but if we look at the operations of cities this isolation remains a dominant feature. Most Canadian municipalities are highly effective, but ultimately self contained islands. Municipal IT departments are no different. One municipality rarely talks to that of another, particularly if they are not neighbours.
The result of this process is that in many cities across Canada IT solutions are frequently developed in one of two manners.
The first is the procurement model. Thankfully, when the product is off the shelf, or easily customized, deployment can occur quickly, this however, is rarely the case. More often, larger software and expensive consulting firms are needed to deploy such solutions frequently leaving them beyond the means of many smaller cities. Moreover, from an economic development perspective the dollars spent on these deployments often flow out of the community to companies and consultants based elsewhere. On the flip side, local, smaller firms, if they exist at all, tend to be untested and frequently lack the expertise and competition necessary to provide a reliable and affordable product. Finally, regardless of the firms’ size, most solutions are proprietary and so lock a city into the solution in perpetuity. This not only holds the city hostage to the supplier, it eliminates future competition and worse, should the provider go out of business, it saddles the city with an unsupported system which will be painful and expensive to upgrade out of.
The second option is to develop in-house. For smaller cities with limited IT departments this option can be challenging, but is often still cheaper than hiring an external vendor. Here the challenge is that any solution is limited by the skills and talents of the City’s IT staff. A small city, with even a gifted IT staff of 2-5 people will be challenged to effectively build and roll out all the IT infrastructure city staff and citizens need. Moreover, keeping pace with security concerns, new technologies and new services poses additional challenges.
In both cases the IT services a city can develop and support for staff and citizens is be limited by either the skills and capacity of its team or the size of its procurement budget. In short, the collective purchasing power, development capacity and technical expertise of Canada’s municipal IT departments is lost because we remain isolated from one another. With each city IT department acting like an island this creates enormous constraints and waste. Software is frequently recreated hundreds of times over as each small city creates its own service or purchases its own license.
The opportunity
It need not be this way. Rather than a patchwork of isolated islands, Canada’s municipal IT departments could be a vast interconnected network.
If even two small communities in Canada applied an open source license to a software they were producing, allowed anyone to download it and documented it well the cost savings would be significant. Rather than having two entities create what is functionally the same piece of software, the cost would be shared. Once available, other cities could download and write patches that would allow this software to integrate with their own hardware/software infrastructure. These patches would also be open source making it easier for still more cities to use the software. The more cities participate in identifying bugs, supplying patches and writing documentation, the lower the costs to everyone becomes. This is how Linus Torvalds started a community whose operating system – Linux – would become world class. It is the same process by which Apache came to dominate webservers and it is the same approach used by Mozilla to create Firefox, a web browser whose market share now rivals that of Internet Explorer. The opportunity to save municipalities millions, if not billions in software licensing and/or development costs every year is real and tangible.
What would such a network look like and how hard would it be to create? I suspect that two pieces would need to be in place to begin growing a nascent network.
First, and foremost, there need to be a handful of small projects. Often the most successful source projects are those that start collaboratively. This way the processes and culture are, from the get go, geared towards collaboration and sharing. This is also why smaller cities are the perfect place to start for collaborating on open source projects. The world’s large cities are happy to explore new models, but they are too rich, too big and too invested in their current systems to drive change. The big cities can afford Accenture. Small cities are not only more nimble, they have the most to gain. By working together and using open source they can provide a level of service comparable to that of the big cities, at a fraction of the cost. An even simpler first step would be to ensure that when contractors sign on to create new software for a city, they agree that the final product will be available under and open source license.
Second, MISA, or another body, should create a Sourceforge clone for hosting open sourced municipal software projects. Sourceforge is an American based open source software development web site which provides services that help people build cool and share software with coders around the world. It presently hosts more than 230,000 software projects has over 2 million registered users. Soureforge operates as a sort of market place for software initiatives, a place where one can locate software one is interested in and then both download it and/or become part of a community to improve it.
A Soureforge clone – say Muniforge – would be a repository for software that municipalities across the country could download and use for free. It would also be the platform upon which collaboration around developing, patching and documenting would take place. Muniforge could also offer tips, tools and learning materials for those new to the open source space on how to effectively lead, participate and work within an open source community. This said, if MISA wanted to keep costs even lower, it wouldn’t even need to create a sourecforge clone, it could simply use the actual sourceforge website and lobby the company to create a new “municipal” category.
And herein lies the second great opportunity of such a platform. It can completely restructure the government software business in Canada. At the moment Canadian municipalities must choose between competing proprietary systems that lock them into to a specific vendor. Worst still, they must pay for both the software development and ongoing support. A Muniforge would allow for a new type of vendor modeled after Redhat – the company that offers support to users that adopt its version of the free, open source Linux operating system. Suddenly while vendors can’t sell software found on Muniforge, they could offer support for it. Cities would not have the benefit of outsourcing support, without having to pay for the development of a custom, proprietary software system. Moreover, if they are not happy with their support they can always bring it in house, or even ask a competing company to provide support. Since the software is open source nothing prevents several companies from supporting the same piece of software – enhancing service, increasing competition and driving down prices.
There is another, final, global benefit to this approach to software development. Over time, a Muniforge could begin to host all of the software necessary to run a modern day municipality. This has dramatic implications for cities in the developing world. Today, thanks to rapid urbanization, many towns and villages in Asian and Africa will be tomorrow’s cities and megacities. With only a fraction of the resources these cities will need to be able to offer the services that are today common place in Canada. With Muniforge they could potentially download all the infrastructure they need for free – enabling precious resources to go towards other critical pieces of infrastructure such as sewers and drinking water. Moreover, a Muniforge would encourage small local IT support organizations to develop in those cities providing jobs fostering IT innovation where it is needed most. Better still, over time, patches and solutions would flow the other way, as more and more cities help improve the code base of projects found on Muniforge.
Conclusion
The internet has demonstrated that new, low cost models of software development exist. Open source software development has shown how loosely connected networks of coders/users from across a country, or even around the world can create world class software that rivals and even outperforms software created by the largest proprietary developers. This is the logic of the web – participation, better development and low-cost development.
The question cities across Canada need to ask themselves is: do we want to remain isolated islands, or do we want to work like the web, working collaboratively to offer better services, more quickly and at a lower cost. If even only some cities choose the later answer an infrastructure to enable collaboration can be put in place at virtually no cost, while the potential benefits and the opportunity to restructure the government software industry would be significant. Island or network – which do we want to be?
eaves.ca 
The concept here is great, but I don't see why cities would need to all adopt a particular software project management toolset in order to benefit from adopting open-source software collaboration practices. Sourceforge is useful as a metaphor, perhaps, but in its specifics, it's a disaster, and most major open-source projects have long since abandoned it for tools that better fit the needs and cultures of their particular projects.
Jon – I agree the Sourceforge is best used as a metaphor (it has become somewhat of a gong show and is one of the reasons I threw in the reference to GitHub, to allude to the fact that there are other tools out there). The key challenge is that whatever platform get used that it a) be searchable (which I believe GitHub is not) b) have sometools for sharing code (which GitHub does have in a superior manner; and c) possibly have some reputational system for evaluating code contributors and/or project founders.All ideas to explore further.
I contend the biggest obstacle in making this happen is each municipality firmly believing that it's needs are unique. Of course, this could not actually be true given given that most municipalities provide the same types of services, but it is very much entrenched in the minds of municipal decision makers. I blame this, in general, on for-profit software companies. They convince municipalities of this and promote their products' ability to be customized/configured as the answer. Almost invariably, there is a host of professional services costs associated with these – a source of a great deal of revenue for these firms. Until municipal government start thinking “maybe we are actually much more LIKE those other guys, than unique” I see major obstacles.
I contend the biggest obstacle in making this happen is each municipality firmly believing that it's needs are unique. Of course, this could not actually be true given given that most municipalities provide the same types of services, but it is very much entrenched in the minds of municipal decision makers. I blame this, in general, on for-profit software companies. They convince municipalities of this and promote their products' ability to be customized/configured as the answer. Almost invariably, there is a host of professional services costs associated with these – a source of a great deal of revenue for these firms. Until municipal government start thinking “maybe we are actually much more LIKE those other guys, than unique” I see major obstacles.
Pingback: Tweets that mention MuniForge: Creating municipalities that work like the web | eaves.ca -- Topsy.com
Pingback: uberVU - social comments
Pingback: Held hostage — The Civic Hacker
I don't think that the obstacle around uniqueness is related to the belief that services are different as much as a belief that city's Information Architectures are unique and thus the integration needs are too specific to see a benefit in sharing software. The recent example of the sharing of Niagara's H1N1 registration software might be a relevant example (possibly for both sides of this conversation).However, the obstacle that I hear people talk about most when asking around about this, is the idea that the “public” will object to the City of X donating a piece of software that cost $500K to develop, or even if it's sharing in development that this sharing is equal. Of course, I see this point very differently. In fact it's likely that the “public” would think it insane not to be sharing our applications across cities when we're all offering essentially the same service. And I think that this perspective could be easily and presented to the community in a convincing manner. Perhaps the province has a stake in helping this happen?
France has something like this http://www.adullact.org/ for a while. I am working one a Drupal installation and service for municipalities as well: http://muniduweb.com/P.S.: I added facebook and openid credentials to my disqus account, still couldn't use that to login here and post.
From an tech-engineering perspective, this is a non-problem. The observation about municipalities over-estimation of their idiosyncratic nature touches on a potential problem – the solutions, versatile or not, would likely be documented or structured in a fashion unpalatable to all but their specific clients (many open sourced projects are like this). Not a deal-breaker, but certainly something that needs to be considered in the framing of the system.An important distinction not often made is between customization and configuration. Too much software is built with customization in mind – that is, the changes are made at the code-level and this is facilitated through clever engineering of the code-base and dependencies. Customization is expensive, configuration is cheap.What SAP, MSFT and IBM all do is sell configuration AS customization – frequently however, it's a matter of clicking some tick-boxes and changing some variables in a config.ini file and voila fully “custom” software. Figuring out a way to build easily configurable software and guide municipal representatives through a) identifying available options b) identifying the desirable and relevant options c) connecting the dots between the default configuration and the desirable configuration. Will be, I think, the killer-feature.
Sorry Flag, though I agree with the theory you offer, the reality is quite different. There is a very thin line between customize and configure and it is continually blurred by for-profit software companies. I was part of this game for 15 years and I played it very well. Rob, again I have to disagree. Each municipality I have consulted to, sold software to, or worked for (20 plus of them) each firmly believed that the way they did business was the right, and in infact, the only way they could do it. This perspective is as big, and I offer, a bigger challenge than the technical issues at stake.
Thank you for the well thought post. I work for a company specializing in open source development and frequently speak with government clients. There certainly is an awareness – lately even a preference – for open source software. From this vantage point, I see many exciting new business opportunities for up-start firms such as ourselves due to the Vancouver's Open 3 motion and others like it.We'd love to share the work that comes out of government projects liberally (and look forward to being able to make some announcements in 2010). The value for us is not having pre-built code available for sale. That is already a dying business model on its way out. The value in open source is being at the epicenter of new developments and the community surrounding a project. This leads to new consulting work and sponsored development. Word of mouth from installs and further development in turn increases the value of your open solution, creating a virtuous cycle. You may end up creating competitors, which is perfectly fine as long as the solution you're a part of keeps growing. As Tim O'Reilly says, “create more value than you capture”.
Pingback: Cities Powered by Open Source — The Civic Hacker
I work in the IT department of a large regional government organization in the US. The adoption of FOSS has been significantly hampered in local government by a combination of factors. Surprisingly, it is not so much IT department policies as purchasing policies that have caused this. Software purchases are subject to “Request for Proposal” (RFP) policies which are designed to keep bids for purchases fair and competitive. RFPs do not address utilizing free alternatives.Another factor is “vendor lock in”. This occurs when a vendor has such an enormous share of a market that, when it is time to acquire the software or renew software licenses, alternatives are not sincerely considered and are all too often easily dismissed. Vendor lock in also occurs when an organization has so much invested with a particular software vendor that migrating to a new system, even if it were free, is beyond their means and resources.Then there is the “fear factor”. This is, in part, caused by software vendor “propaganda” about “issues” with FOSS ranging from security to reliability. This has so permeated many local government IT departments that they do not realize that there are just as many failures associated with proprietary software; they are just better hidden by the vendors. Another component of this “fear factor” is something I call the “blame game”. IT departments want a vendor they can blame if something goes wrong AND local government employees deeply fear the consequences of failure since elected officials are known to use the “blame game” on employees who have the guts to try new ideas. Not all new ideas work 100% of the time.The organization I work for spends way too much of it’s time monitoring and policing software licenses and, thanks to RFP policies and vendor lock in, does not consider FOSS alternatives. Don’t “rock the boat”. Just sign that software license renewal and send those software vendors our budget and hard earned tax dollars. It’s how we have always done these things…Recently one of the “big two” software giants performed a “contract audit” on us and found that, due to a poorly worded, decade old contract, they felt we owed them over $1,000,000 in (totally unexpected) licensing fees. These fees were paid and we continue using their software…because, like the man with failed kidneys and not enough money, the dialysis machine is a cheaper alternative than a kidney transplant.And it’s not only licensing that is hurting local government, the ludicrous maintenance fees some vendors charge (upwards of 20% per year!) are sapping local government IT budgets.The university community saw this coming some years ago and formed the Kuali (http://www.kuali.org) organization to develop higher education administrative systems. Their member list reads like a who’s who of the biggest universities in the country. Their financial system and student administration software is being implemented across the country offering their adopters big savings and a say in their destiny.Local government would be wise to organize a similar organization. “Muni-forge” just isn’t going to hack it. If a significant federal or private grant could be used to boot strap such an organization, local governments, not feeling that they were “going it alone” would flock to join it and, in the process, save the tax payers big bucks while having a say in their destiny.In order for FOSS to take off in local government, the following changes need to occur:The first is an attitude change. Other municipalities should follow Vancouver and San Francisco's lead. FOSS solutions need to be treated fairly and sincere choices made. Personally, I would say that FOSS needs to be given preferential treatment since it can save budget and tax payer dollars. FOSS, however, does not address everything. There are some complicated or specialized applications for which no FOSS solution exists. But where a FOSS solution exists, it should be given a fair and unbiased evaluation. This is the basis for a “Sincere Choice” policy which all government organizations should adopt..Local government needs to become “software agnostic”. IT departments need to change their motto from “We are a (fill in the vendor) shop.” to “We are a standards based shop.”. Less attention needs to be given to what I call vendor added “bells and whistles” which are often extra features and functions that are much like frosting on donuts. The concentration needs to be on “Does the software do the job?” not on who the software vendor is or what kind of whiz bang extra features does it do. Adoption of open “standards based” software needs to be a focus so as to avoid the trap of “proprietary standards” that inhibit systems from communicating with one another and facilitate “vendor lock in”. Microsoft Word documents and Excel spreadsheets are prime examples of this. Try opening an old Word document or Excel spreadsheet that was created using Windows 3.The “blame game” needs to stop. Vendor support for mission critical software is vital whether it is FOSS or proprietary but often “community support” for non-critical FOSS applications is quite adequate. The IT department needs to learn to utilize “community support” (through wikis and the like) and also become involved in and support those FOSS projects on which it depends. Fear of failure should not inhibit innovation.FOSS Alternative Review (FOSSAR) policies should be instated. Local governments need to establish a policy that FOSS solutions are investigated well before new software is acquired and well before existing software licenses are renewed. This is because with FOSS “no salesman will call”. It is up to the IT department in conjunction with the the departments who use it, to investigate, install, test and evaluate appropriate FOSS solutions and then make a sincere choice as to whether the FOSS solution is acceptable. As I stated above, FOSS does not address everything. There are many complicated or specialized applications for which no FOSS solution exists. But where a FOSS solution exists, it should be given a fair and unbiased evaluation and, because of it’s nature, be exempt from the RFP process. However, if appropriate FOSS solutions are not discovered or are deemed unacceptable after being sincerely evaluated, the RFP is in order. RFPs for consulting or vendor support of mission critical FOSS are certainly appropriate.Formation of Citizens Open Source Advisory Boards (COSAB) chaired by a citizens knowledgeable in FOSS, elected local government officials and members of local government IT departments. These boards would exist to facilitate the adoption of the FOSSAR policy and assist the IT department with initial and on-going FOSS adoption issues.These times of “no money” are the perfect time for FOSS adoption by local government to start. Let’s stop wasting tax payer money and start working together to forge a new and better destiny for local government IT systems.Unfortunately, for now I must remain anonymous as my job depends on doing what I am told with the proprietary tools that I am given.
Anonymous – thank you so much for submitting this thoughtful comment. Lots to read here for municipal CIOs. The idea of Kuali as a model for cities is very, very intriguing and exactly the type of information I love finding out about.THank you for taking the time to write this out. I hope some of the work various people are doing at the municipal level to change things will begin to make your life easier (and save your city some money).cheers,dave
Pingback: Saving Millions: Why Cities should Fork the Kuali Foundation | eaves.ca
Have you seen http://www.osor.eu ?
Have you seen http://www.osor.eu ?
Pingback: Saving Cities Millions: Introducing CivicCommons.com | eaves.ca
Pingback: The Crowdsourced City: at SFU City Program, and Open Gov West 2011
Pingback: Lessons from Michigan’s “Innovation Fund” for Government Software | eaves.ca
Pingback: Open government talk buzzes across Canada | IT World Canada News