Tag Archives: open source

Rethinking Freedom of Information Requests: from Bugzilla to AccessZilla

12 Replies

Last week I gave a talk at the Conference for Parliamentarians hosted by the Information Commission as part of Right to Know Week.

During the panel I noted that, if we are interested in improving response times for Freedom of Information (FOI) requests (or, in Canada, Access to Information (ATIP) requests) why doesn’t the Office of the Information Commissioner use a bugzilla type software to track requests?

Such a system would have a number of serious advantages, including:

  1. Requests would be public (although the identity of the requester could remain anonymous), this means if numerous people request the same document they could bandwagon onto a single request
  2. Requests would be searchable – this would make it easier to find documents already released and requests already completed
  3. You could track performance in real time – you could see how quickly different ministries, individuals, groups, etc… respond to FOI/ATIP requests, you could even sort performance by keywords, requester or time of the year
  4. You could see who specifically is holding up a request

In short such a system would bring a lot of transparency to the process itself and, I suspect, would provide a powerful incentive for ministries and individuals to improve their performance in responding to requests.

For those unfamiliar with Bugzilla it is an open source software application used by a number of projects to track “bugs” and feature requests in the software. So, for example, if you notice the software has a bug, you register it in Bugzilla, and then, if you are lucky and/or if the bug is really important, so intrepid developer will come along and develop a patch for it. Posted below, for example, is a bug I submitted for Thunderbird, an email client developed by Mozilla. It’s not as intuitive as it could be but you can get the general sense of things: when I submitted the bug (2010-01-09), who developed the patch (David Bienvenu), it’s current status (Fixed), etc…

ATIPPER

Interestingly, an FOI or ATIP request really isn’t that different than a “bug” in a software program. In many ways, bugzilla is just a complex and collaborative “to do” list manager. I could imagine it wouldn’t be that hard to reskin it so that it could be used to manage and monitor access to information requests. Indeed, I suspect there might even be a community of volunteers who would be willing to work with the Office of the Information Commissioner to help make it happen.

Below I’ve done a mock up of what I think revamped Bugzilla, (renamed AccessZilla) might look like. I’m put numbers next to some of the features so that I can explain in detail about them below.

ATIPPER-OIC1

So what are some of the features I’ve included?

1. Status: Now an ATIP request can be marked with a status, these might be as simple as submitted, in process, under review, fixed and verified fixed (meaning the submitter has confirmed they’ve received it). This alone would allow the Information Commissioner, the submitter, and the public to track how long an individual request (or an aggregate of requests) stay in each part of the process.

2.Keywords: Wouldn’t it be nice to search of other FOR/ATIP requests with similar keywords? Perhaps someone has submitted a request for a document that is similar to your own, but not something you knew existed or had thought of… Keywords could be a powerful way to find government documents.

3. Individual accountability: Now you can see who is monitoring the request on behalf of the Office of the information commissioner and who is the ATIP officer within the Ministry. If the rules permitted then potential the public servants involved in the document might have their names attached here as well (or maybe this option will only be available to those who log on as ATIP officers.

4. Logs: You would be able to see the last time the request was modified. This might include getting the documents ready, expressing concern about privacy or confidentiality, or simply asking for clarification about the request.

5. Related requests: Like keywords, but more sophisticated. Why not have the software look at the words and people involved in the request and suggest other, completed requests, that it thinks might similar in type and therefor of interest to the user. Seems obvious.

6. Simple and reusable resolution: Once the ATIP officer has the documentation, they can simply upload it as an attachment to the request. This way not only can the original user quickly download the document, but anyone subsequent user who stumbles upon the request during a search could download the documents. Better still any public servant who has unclassified documents that might relate to the request can simply upload them directly as well.

7. Search: This feels pretty obvious… it would certainly make citizens life much easier and be the basic ante for any government that claims to be interested in transparency and accountability.

8. Visualizing it (not shown): The nice thing about all of these features is that the data coming out of them could be visualized. We could generate realt time charts showing average response time by ministry, list of respondees by speed from slowest to fastest, even something as mundane as most searched keywords. The point being that with visualizations is that a governments performance around transparency and accountability becomes more accessible to the general public.

It may be that there is much better software out there for doing this (like JIRA), I’m definitely open do suggestions. What I like about bugzilla is that it can be hosted, it’s free and its open source. Mostly however, software like this creates an opportunity for the Office of the Information Commissioner in Canada, and access to information managers around the world, to alter the incentives for governments to complete FOI/ATIP requests as well as make it easier for citizens to find out information about their government. It could be a fascinating project to reskin bugzilla (or some other software platform) to do this. Maybe even a Information Commissioners from around the world could pool their funds to sponsor such a reskinning of bugzilla…

Getting Government Right Behind the Firewall

10 Replies

The other week I stumbled on this fantastic piece by Susan Oh of Ragan.com about a 50 day effort by the BC government to relaunch its intranet set.

Yes, 50 days.

If you run a large organization’s intranet site I encourage to read the piece. (Alternatively, if you are forced (or begged) to use one, forward this article to someone in charge). The measured results are great – essentially a doubling in pretty much all the things you want to double (like participation) – but what is really nice is how quick and affordable the whole project was, something rarely seen in most bureaucracies.

Here is an intranet for 30,000 employees, that “was rebuilt from top to bottom within 50 days with only three developers who were learning the open-source platform Drupal as they as went along.”

I beg someone in the BC government to produce an example of such a significant roleout being accomplished with so few resources. Indeed, it sounds eerily similar to GCPEDIA (available to 300,000 people using open source software and 1 FTE, plus some begged and borrowed resources) and OPSPedia (a test project also using open source software with tiny rollout costs). Notice a pattern?

Across our governments (not to mention a number of large conservative companies) there are tiny pockets where resourceful teams find a leader or project manager willing to buck the idea that a software implementations must be a multi-year, multimillion dollar roll out. And they are making the lives of public servants better. God knows our public servants need better tools, and quickly. Even the set of tools being offered in the BC examples weren’t that mind-blowing, pretty basic stuff for anyone operating as a knowledge worker.

I’m not even saying that what you do has to be open source (although clearly, the above examples show that it can allow one to move speedily and cheaply) but I suspect that the number of people (and the type of person) interested in government would shift quickly if, internally, they had this set of tools at their disposal. (Would love to talk to someone at Canada’s Food Inspection Agency about their experience with Socialtext)

The fact is, you can. And, of course, this quickly get us to the real problem… most governments and large corporations don’t know how to deal with the cultural and power implications of these tools.

We’ll we’d better get busy experimenting and trying cause knowledge workers will go where they can use their and their peers brains most effectively. Increasingly, that isn’t government. I know I’m a fan of the long tail of public policy, but we’ve got to fix government behind the firewall, otherwise their won’t be a government behind the firewall to fix.

Collaborate: "Governments don't do that"

9 Replies

The other day while enjoying breakfast with a consultant friend I heard her talk of about how smaller local governments didn’t have the resources to afford her, or her firms services.

Hogwash I thought! Fresh from the launch of CivicCommons.com at the Gov2.0 Summit I jumped in and asked, surely a couple of the smaller municipalities with similar needs could come together, jointly spec out a project and pool their budgets. It seems like a win-win-win, budgets go further, better services are offered and, well, of less interest but still nice, my friend gets to work on rolling out some nice technologies in the community in which she lives.

The response?

“Government’s doesn’t work that way.”

Followed up by…

“Why would we work with one of those other communities, they are our competitors.”

Once you’ve stopped screaming at your monitor… (yes, I’m happy to give you a few seconds to vent that frustration) let me try to explain in as cool as a manor as possible why this makes no sense. And while I don’t live in the numerous municipalities that border on Vancouver, if you do, consider writing you local councillor/mayor. I think your IT department is wasting your tax dollars.

First, government’s don’t work that way? Really? So an opportunity arises for you to save money and offer better services to your citizens and you’re going to say no because the process offends you in some way? I’m pretty sure there’s a chamber full of council people and a mayor who feel pretty differently about that.

The fact is, that governing a city is going to get more complicated. The expectations of citizens are going to become greater. There is going to be a gap, and no amount of budget is going to cover it. Citizens increasingly have access to top tier services on the web – they know what first class systems look like. They look like Google, Amazon, Travelocity, etc… and vary rarely your municipal website site and the services it offers. It almost doesn’t matter where you are reading this from, I’m willing to bet your city’s site isn’t world class. Thanks to the web however your citizens, even the ones who never leave your bedroom community, are globe traveling super consumers of the web. They are getting faster, better and more effective service on and off the web. You might want to consider this because as the IT director in a city of 500,000 people you probably don’t have the resources to keep up.

Okay, so sharing a budget to be able to build better online infrastructure (or whatever) for your city makes sense. But now you’re thinking – we can’t work with that neighboring community… their our competitors.

Stop. Stop right there.

That community is not your competitor. Let me tell you right now. No one is moving to West Van over Burnaby because their website is better, or their garbage service is more efficient. They certainly aren’t moving because you offer webbased forms on your city’s website and the other guys (annoyingly) make you print out a PDF. That’s not influencing the 250K-500K decision about where I live. Basically, if it doesn’t involve the quality of the school it probably isn’t factoring in.

Hell even other cities like Toronto, Calgary or Seattle aren’t your competitor. If anyone is moving there it’s likely because of family or a job. Maybe if you really got efficient then a marginally lower muncipal tax would help, but if that were the case, then partner with as many cities as possible and benefit from some collaborative economies of scale… cause now you kicking the but of the 99% of cities that aren’t collaborating and sharing costs.

And, of course, this isn’t limited to cities. Pretty much any level of government could benefit from pooling budgets to sponsor some commonly speced out projects.

It’s depressing to see that the biggest challenge to driving down the costs of running a city (or any government) aren’t going to technological, but a cultural obsession with the belief that everybody else is different, competing and not as good as us.

Saving Cities Millions: Introducing CivicCommons.com

7 Replies

Last year, after speaking at the MISA West conference I blogged about an idea I’d called Muniforge (It was also published in the Municipal Information Systems Association’s journal Municipal Interface but behind a paywall). The idea was to create a repository like SourceForge that could host open source software code developed by and/or for cities to share with one another. A few months later I followed it up with another post Saving Millions: Why Cities should Fork the Kuali Foundation which chronicled how a coalition of universities have been doing something similar (they call it community source) and have been saving themselves millions of dollars.

Last week at the Gov 2.0 Summit in Washington, DC my friends over at OpenPlans, with who I’ve exchanged many thoughts about this idea, along with the City of Washington DC brought this idea to life with the launch of Civic Commons. It’s an exciting project that has involved the work of a lot of people: Phillip Ashlock at OpenPlans who isn’t in the video below deserves a great deal of congratulations, as does the team over at Code for America who were also not on the stage.

At the moment Civic Commons is a sort of whitepages for open sourced civic government applications and policies. It doesn’t actually host the software it just points you to where the licenses and code reside (say, for example, at GitHub). There are lots of great tools out there for collaborating on software that don’t need replicating, instead Civic Commons is trying to foster community, a place where cities can find projects they’d like to leverage or contribute to.

The video below outlines it all in more detail. If you find it interesting (or want to skip it and get to that action right away) take a look at the Civic Commons.com website, there are already a number of applications being shared and worked on. I’m also thrilled to share that I’ve been asked to be an adviser to Civic Commons, so more on that and what it means for non-American cities, after the video.

One thing that comes through when looking at this video is the sense this is a distinctly American project. Nothing could be further from the truth. Indeed, during a planning meeting on Thursday I mentioned that a few Canadian cities have contacted me about software applications they would like to make open source to share with other municipalities, everyone and especially Bryan Sivak (CIO for Washington, DC) was keen that other countries join and partake in Civic Commons.

It may end up that municipalities in other countries wish to create their own independent project. That is fine (I’m in favour of diverse approaches), but in the interim I’m keen to have some international participation early on so that processes and issues it raises will be addressed and baked into the project early on. If you work at a city and are thinking that you’d like to add a project feel free to contact me, but also don’t be afraid to just go straight to the site and add it directly!

Anyway, just to sum up, I’m over the moon excited about this project and hope it will turn out. I’ve been hoping something like this would be launched since writing about Muniforge and am excited to both see it happening and be involved.

Bugzilla – progress made and new thoughts

A few weeks ago I published a post entitled Some Thoughts on Improving Bugzilla. The post got a fair bit a traction and received a large number of supportive comments. But what was best, about the post, about open source, about Mozilla, is that it drew me into a serious of conversations with people who wanted to make some of it reality.

Specifically, I’d like to thank Guy Pyrzak over at Bugzilla and Clint Talbert at Mozilla both of whom spent hours entertaining and conversing about these ideas with me, problem solving them and, if we are really honest, basically doing all the heavy lifting to transform them from ideas on this blog into real changes.

So in this post I have two things to share. First is an update on progress from the ideas in the last post (which will be this post) as well as some new thoughts about how Mozilla instance of Bugzilla could be further improved (which will be my next post).

So here we go…

Update!

1. Simplifying Menus

First up I made some suggestions around simplifying the bugzilla landing page. These were pretty cosmetic, but they make the landing page a little less intimidating to a new user and, frankly, nicer for everyone. We are presently drafting up the small changes to the code that would require this change and getting ready to submit it as a proposal. Status – Yellow.

2. Gather more information about our users (and, while I’m at it, some more simplifying)

Second, I outlined some ideas for streamlining the process of joining bugzilla and on the data we collect about users.

On the first part, which is about the steamlined pages (designed to help ensure that true bug submitters end up in bugzilla and not those seeking support) here too we will be submitting some new proposed pages shortly. Status – Yellow

On the second part I suggested that we ask users if they English is their second language and that we mark new bugzilla accounts with a “new” symbol. Guy is coding up an extension to Bugzilla that will both of these. Once done, I’ll suggest to Mozilla that they include this extension in their instance. Status – Green.

3. Make Life Easier for Users and the Triage Guys

I thought we could make life more efficient for triage and users if we added a status where bugs could be declared “RESOLVED-SUPPORT.” There’s been some reception to this idea. However, the second part of this idea is that once a bug is tagged as such a script automatically should scan the support database, find articles with a strong word correlation to the bug description and email the bug submitter links to those pages. Once again, Guy has stepped forward to develop such an extension which hopefully will be working in the not to distant future. Status – Green.

4. Make Bugzilla Celebrate, enhance our brand and build community

But probably the most exciting part is the final suggestion. That we send (at least non-developers) much nicer emails celebrating that the bug they submitted has been patched. It turns out (hardly surprising) that I wasn’t the first person to think that Bugzilla should be able to send HTML emails. Indeed, that feature request was first made back in 2001 and, when I blogged about this the other week, had not be updated since 2006. Once again, Guy has proven to be unbelievably helpful. It turns out that due to some changes to bugzilla many of the blocks to patching this had disappeared and so he has been working on the code. Status – Green.

Lots here for many people to be proud of. Hopefully some of these ideas will go live in the not too distant future. That said, still many hurdles to clear and if you are a decision maker on any of these and would like to talk about these ideas, please do not hesitate to contact me.

On Governments and Intellectual Property (or why we move slowly)

4 Replies

David H. sent me this short and fantastic article from Wired magazine last week.

The article discusses the travails of Mathew Burton, a former analyst and software programmer at the Department of Defense who spent years trying to get the software he wrote into the hands of those who desperately needed it. But alas, no one could figure out the licensing rights for the software it was supposed to work with… so it never went anywhere. Today Mathew has (unsurprisingly) left Defense and has open sourced the code so that anyone can use it. The lesson? The tangled mess of navigating all the license agreements isn’t protecting anyone and certainly not the public. It’s just preventing interesting new and derivative works from being used to render American safer.

In short, the crises here doesn’t have to do with size of government, but in a misplaced desire by many governments to protect “intellectual property.”

Now I understand the need of government to protect physical property. A forest, for example, can only be logged once every few generations, so allocating that resource efficiently matters. But intellectual property? Things like documents, data, and software code? It’s use is not diminished when someone uses it. Indeed, often its value increases when numerous people start to use it.

But rather than give to tax payers the intellectual property their tax dollars already paid for, our governments lock them down. Today, under the false belief that they are protecting themselves and potential revenue streams (that have never materialized) our governments copyright, patent and license all sorts of intellectual property our tax dollars paid for. In short, we treat ideas like we treat forests, something that only a handful of people can use and benefit from.

This has three happy consequences.

First, ideas and innovations are more expensive and spread more slowly. Remember the goal of innovation is not to license technology, its to use technology to enable us to be happier, safer or more productive (or ideally all three!). When our governments license technology that accomplishes one or all of these things they are, in fact, restricting the number of people who can benefit by giving a single actor a monopoly to sell this service (again, one tax payers funded to develop!) to tax payers or (worse) back to the government.

Second, we end up wasting a colossal amount of money on lawyers. With our governments pretending to be a corporation, managing all this intellectual property tax payers funded to develop, we naturally require an army of lawyers to protect and license it!

Finally, many governments are locked out of open source projects and communities. Since, by policy, many governments require that they own any code they, or their contractors develop, they cannot contribute to open source projects (in which the code is by definition, not owned but shared). This means free, scalable and customizable software and products that small companies like Google are forbidden within government. Instead they (and by they, I mean us) have to pay for proprietary solutions.

At some point I’d love to read more about how government got into the intellectual property businesses. I imagine it is a history paved with good intentions. However, the more I reflect on it, the more I wonder why the first order question of “why do governments have intellectual property” never gets asked. The costs are high and the benefits seem quite low. Maybe it’s time we radically rethink this.

Some thoughts on improving Bugzilla

60 Replies

One of the keys to making an open source project work is getting feedback from users and developers about problems (bugs) in the code or system. Mozilla (the organization behind Firefox and Thunderbird) uses Bugzilla, but organizations have developed a variety of systems for dealing with this issue. For example, many cities use 311. I’m going to talk about Bugzilla and Mozilla in this case, but I think the lessons can be applied more broadly for some of my policy geek friends.

So first, some first principles. Why does getting the system right matter? A few reasons come to mind:

  1. Engagement: For many people Bugzilla is their first contact with “the community.” We should want users to have a good experience so they feel some affinity towards us and we should want developers to have a great experience so that they want to deepen their level of participation and engagement.
  2. Efficiency: If you have the wrong or incomplete information it is hard (or impossible) to solve a problem, wasting the precious time of volunteer contributors.

I also concede that these two objectives may not always be congruent. Indeed, at times there may be trade offs between them… but I think there is a lot that can be done to improve both.

I’ve probably got more ideas than can fit (or should fit) into one post so I’m going to unload a few. I’ve got more that relate to the negotiation and empathetic approaches I talked about at the Mozilla Summit.

One additional thought. Please feel free to dump all over these. Some changes many not be as simple as I’ve assumed. Others may break or contravene important features I’m not aware of. Happy to engage people on these, please do not see them as an end point, but rather a beginning. My main goal with this first batch of suggestions was to find things that felt easier to do and so could be implemented quickly if there was interest and would help reduce transactions costs right away.

1. Simplifying Menus

First. I thought there were some simple changes that could render the interface cleaner and friendlier. It’s pretty text heavy – which is great for advanced users, but less inviting for newer users. More importantly however, we could streamline things to make it easier for people to onboard.

Take for example, the landing page of Bugzilla. It is unclear to me why “Open a new Account” should be on this page. Advanced users will know they want to file a bug, novices (who may be on the wrong site and who should be looking for support) might believe they have to open and account to get support. So why not eliminate the option altogether. You are going to get it anyways if you click on “File a bug.”

Bugzilla-landing-page

Current

Bugzilla-landing-page-v2

Proposed

In addition, I got rid of the bottom menu bar (which I don’t think is necessary on this screenƒclu given all the features were along the top as well). I also ditched the Release Notes and User Guide for Bugzilla as I had doubts about whether users were, at this point and on this screen, looking for those things)

2. Gather more information about our users (and, while I’m at it, some more simplifying)

Once you choose to file a bug you get prompted to either log in or create an account. At this point, if you want to create an account. I thought this page was hard to read with the text spanning the whole width, plus, there is some good info we could gather about users at this point (the point it feels they are mostly likely going to add to their profile).

Current

Bugzilla-registration-v2

Proposed

Couple things a like about this proposed screen.

One, if you are a lost user just looking for support we likely snag you before you fill out a bugzilla account. My feeling is the bugzilla is a scary place that most users shouldn’t end up in… we need to give people lots of opportunities to opt for support before diving in, in case that is what they really need.

Second, in this proposed version we tell people to read the bugzilla guidelines and suggest using an alternate email before they punch their email into the email field box.

In addition, we ask the user for their real name now (as opposed to relying on them to fill it out later). This nudge feels important as the more people with real names on the site, the more I think people will develop relationships with one another. Finally we ask people if English is their second language and if this is their first open source project.

Finally, with the extra data fields we can help flag users as ESL or new and thus in need of more care, patience and help as they on-ramp (see screen shots below). We could even modify the Bugzilla guidelines to inform people to provide newbies and ESL’s with appropriate respect and support.

Bugzilla-Raw1

Current

Bugzilla-New

Proposed

Proposed

I imagine that your “newbie” status would disappear either when you want (some sort of preference in your profile) or after you’ve engaged in a certain amount of activity.

3. Make life easier for users and the triage guys

Here is an idea I had talking with some of the triage guys at the Mozilla Summit.

Let’s suppose that someone submits a bug that isn’t really a bug but a support issue. I’m informed that this happens with a high degree of frequency. Would it be nice if, with a click of a mouse, the triage guys could move that bug out of Bugzilla and into a separate database (ideally this would be straight into SUMO, but I respect that this might not be easy – so just moving it to a separate database and de-cluttering bugzilla would be a great first start – the SUMO guys could then create a way to import it). My sense is that this simply requires creating a new resolution field – I’ve opted to call it “Support” but am happy to name it something else.

Current

Status-v2

Proposed

This feels like a simple fix and it would quickly move a lot of bugs that are cluttering up bugzilla… out. This is important as searches for bugs often return many results that are support oriented, making it harder to find the bugs you are actually searching for. Better still, it would get them somewhere where they could more likely help users (who are probably waiting for us to respond).

Of course, presently bugzilla will auto generate an email that looks like the first one and this isn’t going to help. So what if we did something else?

unresolved

Current

SUMO-transfer-v2

Proposed

Here is the auto-generated email I think we should be sending users whos bugs get sent to SUMO. I’ve proposed a few things.

First, if these are users who’ve submitted inappropriate bugs and who really need support, giving them a bugzilla email isn’t going to help them, they aren’t even going to know how to read it.

Second, there is an opportunity to explain to them where they should go for help – I haven’t done that explicitly enough in this email – but you get the idea

Third, when the bug gets moved to SUMO it might be possible to do a simple key word analysis of the bug and, from that, determine what are the most likely support articles they are looking for. Why don’t we send them the top 3 or 5 as hyperlinks in the email?

Fourth, if this really is a bug from a more sophisticated user, we give them a hyperlink back to bugzilla so they can make a note or comment.

What I like about this is it is customized engagement at a low cost. More importantly, it helps unclutter things while also making us more responsive and creating a better experience for users.

4. Make Bugzilla Celebrate, enhance our brand and build community

Okay, so here’s the thing that really bugs me about bugzilla. If we want to be onramping people and building community, shouldn’t we celebrate people’s successes? At the moment this is the email you get from Bugzilla when a bug you’ve submitted gets patched:

BORING! Here, at the moment of maximum joy, especially for casual or new bugzilla participants we do nothing to engage or celebrate.

This, is what I think the auto-generated bugzilla email should look like.

Congrats-v2

Yes, I agree that hard core community members probably won’t care about these types of bugs, but for more casual participants this is an opportunity to explain how open source and mozilla works (the graphic) as well as a chance to educate them. I’ve even been more explicit about this by offering links to a) explain the open web, b) learn about mozilla and open source; and c) donate to the foundation (given this is a moment of pride for many non-developer end users)

Again, I’m not overly attached to this design per se, it would just be nice to have something fun, celebratory and mozillaesque.

Okay, it is super late and I’m on an early flight tomorrow. Would love feedback on all or any of this for those who’ve made it this far. I’ll be sharing more thoughts, especially on empathetic nudges and community management in bugzilla ASAP.

Awesome Interactions: More on my Mozilla Summit 2010 Ignite Talk

3 Replies

Last week I had the distinct pleasure of being at the Mozilla Summit.

This is a gathering of about 650ish people from innumerable countries around the world to talk about Mozilla, the future of the open web, the various Mozilla products (such as Firefox and Thunderbird). As Mozilla is a distributed community of thousands of people from around the world and the summit only takes place every two years, it as one participant memorably put it, “an opportunity to engage in two years of pent up water cooler talk.”

As a follow up for the summit I’ve two things I wanted to share.

First, for those who enjoyed my Ignite talk on community management entitled Making the Army of Awesome More Awesome I’ve uploaded my slides to slideshare. (Not the most flattering picture of me giving the talk, but the only one I could find on flickr…)

I’m hoping, once the summit organizers have taken a much deserved break, to get video and audio of the presentation and I’ll create slidecast and post it to this blog.

Also, if you found the talk engaging, there is a longer version of that talk where I dive a little deeper into some of the theory I mention at the end. It is a talk David Humphrey kindly asked me to give back at FSOSS a few yeas ago called Community Management: Open Source’s Core Competency.

Second, both in my talk and during the incredible time I had speaking with a number of people in the Mozilla community I brainstormed a ton of ideas. I’m committed to documenting those and sharing them. Here’s a list of some of them, in the coming week I hope to blog on each, and ideally all of these.

1. Improve the link between Bugzilla and SUMO

2. Auto-generate help topics in the Help pull down menu

3. Ask people when they download Firefox or Thunderbird if they’ll volunteer to do bug confirmation

4. Add “Newbie” to new Bugzilla registers

5. Add “ESL” (English as a second language) to Bugzilla accounts that request it

6. Rethinking data.mozilla.org and fostering a research community

7. Segment Bugzilla submitters into groups that might be engaged differently

8. Reboot Diederik Van Liere’s jet pack add-on that predicts bug patch success

8b. Add on a crowdsourcing app to call out negative language or behaviour

9. Retool questions asked in Bugzilla to “nudge” users to better responses

10. Develop an inquire, paraphrase, acknowledge and advocate crowdsourcing identfier jet pack add on for bugzilla

11. plus more, but lets start with these…

Saving Millions: Why Cities should Fork the Kuali Foundation

12 Replies

For those interested in my writing on open source, municipal issues and technology, I want to be blunt: I consider this to be one of the most important posts I’ll write this year.

A few months ago I wrote an article and blog post about “Muniforge,” an idea based on a speech I’d given at a conference in 2009 in which I advocated that cities with common needs should band together and co-develop software to reduce procurement costs and better meet requirements. I continued to believe in the idea, but have recognized that cultural barriers would likely mean it would be difficult to realize.

Last month that all changed. While at Northern Voice I ended up talking to Jens Haeusser an IT strategist at the University of British Columbia and confirmed something I’d long suspected: that some people much smarter than me had already had the same idea and had made it a reality… not among cities but among academic institutions.

The result? The Kuali foundation. “…A growing community of universities, colleges, businesses, and other organizations that have partnered to build and sustain open-source administrative software for higher education, by higher education.”

In other words for the past 5 years over 35 universities in the United States, Canada, Australia and South Africa have been successfully co-developing software.

For cities everywhere interested in controlling spending or reducing costs, this should be an earth shattering revelation – a wake up call – for several reasons:

  • First, a viable working model for muniforge has existed for 5 years and has been a demonstrable success, both in creating high quality software and in saving the participating institutions significant money. Devising a methodology to calculate how much a city could save by co-developing software with an open source license is probably very, very easy.
  • Second, what is also great about universities is that they suffer from many of the challenges of cities. Both have: conservative bureaucracies, limited budgets, and significant legacy systems. In addition, neither have IT as the core competency and both are frequently concerned with licenses, liability and the “owning” intellectual property.
  • Which thirdly, leads to possibly the best part. The Kuali Foundation has already addressed all the critical obstacles to such an endeavour and has developed licensing agreements, policies, decision-making structures, and work flows processes that address necessary for success. Moreover, all of this legal, policy and work infrastructure is itself available to be copied. For free. Right now.
  • Fourth, the Kuali foundation is not a bunch of free-software hippies that depend on the kindness of strangers to patch their software (a stereotype that really must end). Quite the opposite. The Kuali foundation has helped spawn 10 different companies that specialize in implementing and supporting (through SLAs) the software the foundation develops. In other words, the universities have created a group of competing firms dedicated to serving their niche market. Think about that. Rather than deal with vendors who specialize in serving large multinationals and who’ve tweaked their software to (somewhat) work for cities, the foundation has fostered competing service providers (to say it again) within the higher education niche.

As a result, I believe a group of forwarding thinking cities – perhaps starting with those in North America – should fork the Kuali Foundation. That is, they should copy Kuali’s bylaws, it structure, its licenses and pretty much everything else – possibly even the source code for some of its projects – and create a Kuali for cities. Call it Muniforge, or Communiforge or CivicHub or whatever… but create it.

We can radically reduce the costs of software to cities, improve support by creating the right market incentive to help foster companies whose interests are directly aligned with cities and create better software that meets cities unique needs. The question is… will we? All that is required is for CIO’s to being networking and for a few to discover some common needs. One I idea I have immediately is for the City of Nanaimo to apply the Kuali modified Apache license to its council monitoring software package it developed in house, and to upload it to GitHub. That would be a great start – one that could collectively save cities millions.

If you are a city CIO/CTO/Technology Director and are interested in this idea, please check out these links:

The Kuali Foundation homepage

Open Source Collaboration in Higher Education: Guidelines and Report of the Licensing and Policy Framework Summit for Software Sharing in Higher Education by Brad Wheeler and Daniel Greenstein (key architects behind Kuali)

Open Source 2010: Reflections on 2007 by Brad Wheeler (a must read, lots of great tips in here)

Heck, I suggest looking at all of Brad Wheeler’s articles and presentations.

Another overview article on Kuali by University Business

Phillip Ashlock of Open Plans has an overview article of where some cities are heading re open source.

And again, my original article on Muniforge.

If you aren’t already, consider reading the OpenSF blog – these guys are leaders and one way or another will be part of the mix.

Also, if you’re on twitter, consider following Jay Nath and Philip Ashlock.

Canadian Governments: How to waste millions online ($30M and counting)

26 Replies

Back from DC and Toronto I’m feeling recharged and reinvigorated. The Gov 2.0 expo was fantastic, it was great to meet colleagues from around the world in person. The FCM AGM was equally exciting with a great turnout for our session on Government 2.0 and lots of engagement from the attendees.

So, now that I’m in a good mood, it’s only natural that I’m suddenly burning up about some awesomely poor decisions being made at the provincial level and that may also may be in the process of being made at the federal level.

Last year at the BC Chapter of the Municipal Information Systems Association conference I stumbled, by chance, into a session run by the British Columbia government about a single login system it was creating for government website. So I get that this sounds mundane but check this out: it would means that if you live in BC you’ll have a single login name and password when accessing any provincial government service. Convenient! Better still, the government was telling the municipalities that this system (still in development) could work for their websites too. So only one user name and password to access any government service in BC! It all sounds like $30 million (the number I think they quoted) well spent.

So what could be wrong with this…?

How about the fact that such a system already exists. For free.

Yes, OpenID, is a system that has been created to do just this. It’s free and licensed for use by anyone. Better still, it’s been adopted by a number of small institutions such as Google, Yahoo, AOL, PayPal, and Verisign and… none other than the US government which recently began a pilot adoption of it.

So let me ask you: Do you think the login system designed by the BC government is going to be more, or less secure that that an open source system that enjoys the support of Google, Yahoo, AOL, PayPal, Verisign and the US Government? Moreover, do we think that the security concerns these organizations have regarding their clients and citizens are less strict than those of the BC government?

I suspect not.

But that isn’t going to prevent us from sinking millions into a system that will be less secure and will costs millions more to sustain over the coming decades (since we’ll be the only ones using it… we’ll have to have uniquely trained people to sustain it!).

Of course, it gets worse. While the BC government is designing its own system, rumour has it that the Federal Government is looking into replacing Epass; it’s own aging website login system which, by the by, does not work with Firefox, a web browser used by only a quarter of all Canadians. Of course, I’m willing to bet almost anything that no one is even contemplating using OpenID. Instead, we will sink 10’s of millions of dollars (if not more…) into a system. Of course, what’s $100 million of taxpayer dollars…

Oh, and today’s my birthday! And despite the tone of this post I’m actually in a really good mood and have had a great time with friends, family and loved ones. And where will I be today…? At 30,000 ft flying to Ottawa for GovCamp Canada. Isn’t that appropriate? :)