Category Archives: open source

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.

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.

Mozilla and leadership: Rethinking the CEO

7 Replies

Last week John Lily – CEO of Mozilla – announced he will be stepping down to take a job at Greylock, a venture capital firm. I’ve only met John twice, and both times he was generous with both his time and willingness to engage some of my thoughts and (many) questions. I know he is a huge asset to Mozilla and has done a great deal to help mature the organization.

With the Mozilla now planning a CEO succession it seems like an opportune time to raise an idea that first came to me a few months ago: Should Mozilla rename the role of CEO?

Why change the title? My interest is that the title communicate the message of Mozilla mission and its method. CEO’s are usually (although, admittedly not exclusively) associated with traditional companies, and to a lesser degree, hierarchical decision making structures. Indeed, if asked what words I were to associate with the CEO I think “authority,” “command” and “hierarchy” would be among the top to jump into my mind.

Mozilla has never been, and I hope never will be, a traditional software company. It is not profit driven but mission driven – its goal is to keep the web open in part by providing a competitive, open standards compliant web-browser. More importantly, the Mozilla models depends not on a large staff to succeed, but on a community of volunteers whose donations of time and code are coordinated by a (relatively) small staff.

So what do I think the core values the titles of Mozilla’s leadership needs to communicate? I think authority and command are definitely part of the mix. Ultimately the senior leadership of Mozilla needs to make difficult strategic and management choices, just like a CEO. But one of the things that I think makes the role so difficult (and different) is that it requires other key attributes as well, including “engagement,” “fun,” and “community.” Let’s face it, if your capacity to create software depends on a volunteer community, that community had better be fun, engaging and with – ideally – low transaction costs.

None of this, I think, is new. Mitchell Baker, Mozilla’s chairman and Lily’s predecessor, retains the title she popularly used while in her previous job: Chief Lizard Wrangler (also the name of her blog). That title says it all: Fun, community-oriented, hints at decision-making that is consultative, but still a dose of authority…

So, can we find a new title that reflects these values? I know at Mozilla solutions are prized above observations but I’ll confess I’m a little short on suggestion (I actually love Chief Lizard Wrangler and wonder if that should not be the title). Community Director (as opposed to Executive Director) has come to mind. I’m ultimately not attached to a given solution, I just believe it is important that the title be consistent with the spirit and values of the Mozilla project. I know that the leadership and staff have a lot of its plate and that this is not the most critical issue, but I wanted to put the thought out there nonetheless as symbols such as these matter, I believe especially in mission driven organizations.

Datadotgc.ca Launched – the opportunity and challenge

14 Replies

Today I’m really pleased to announce that we’ve launched datadotgc.ca, a volunteer driven site I’m collaboratively creating with a small group of friends and, I hope, a growing community that, if you are interested, may include you.

As many of you already know I, and many other people, want our governments to open up and share their data, in useful, structured formats that people can actually use or analyze. Unlike our American and British peers, the Canadian Federal (and provincial…) government(s) currently have no official, coordinated effort to release government data.

I think that should change.

So rather than merely complain that we don’t have a data.gov or data.gov.uk in Canada, we decided to create one ourselves. We can model what we want our governments to do and even create limited versions of the service ourselves. So that is what we are doing with this site. A stab at showing our government, and Canada, what a federal open data portal could and should look like – one that I’m hoping people will want to help make a success.

Some two things to share.

First, what’s our goal for the site?

  • Be an innovative platform that demonstrates how government should share data.
  • Create an incentive for government to share more data by showing ministers, public servants and the public which ministries are sharing data, and which are not.
  • Provide a useful service to citizens interested in open data by bringing it all the government data together into one place to both make it easier to find.

Second, our big challenge.

As Luke C, one datadotgc.ca community member said to me – getting the site up is the easier part. The real challenge is building a community of people who will care for it and help make it a living, growing and evolving success. Here there is lots of work still to be done. But if you feel passionate about open government and are interested in joining our community, we’d love to have you. At the moment, especially as we still get infrastructure to support the community in place, we are convening at a google group here.

So what our some of the things I think are a priority in the short term?

  • Adding or bulk scraping in more data sets so the site more accurately displays what is available
  • Locating data sets that are open and ready to be “liberated”
  • Documenting how to add or scrape in a data set to allow people to help more easily
  • Implement a more formal bug and feature tracker
  • Plus lots of other functionality I know I at least (and I’m sure there are lots more ideas out there) would like to add (like “request a closed data set”)

As Clay Shirky once noted about any open source project, datadotgc.ca is powered by love. If people love the site and love what it is trying to accomplish, then we will have a community interested in helping make it a success. I know I love datadotgc.ca – and so my goal is to help you love it too, and to do everything I can to make it as easy as possible for you to make whatever contribution you’d like to make. Creating a great community is the hardest but best part of any project. We are off to a great start, and I hope to maybe see you on the google group.

Finally, just want to thank everyone who has helped so far, including the fine people at Raised Eyebrow Web Studio, Luke Closs, and a number of fantastic coders from the Open Knowledge Foundation. There are also some great people over at the Datadotgc.ca Google Group who have helped scrape data, tested for bugs and been supportive and helpful in so many ways.

Mozilla Drumbeat: Help keep the web open

1 Reply

Mozilla Drumbeat is the Mozilla Foundations new venture. An effort to reach out beyond those who have helped make the Firefox web browser to a broader community – those that care about keeping the internet open but who want to contribute in other ways.

Drumbeat will have three components:

1) Projects – many of which are already underway

2) Local events – like the upcoming on in Toronto on April 24th

3) A website – that ties it all together, a place where people can gather virtually to organize

So what can you do?

First, if you are interested in hosting a local Mozilla Drumbeat event, contact Nathaniel James at the Mozilla Foundation, there is going to be Facilitator Training event in Toronto on April 23-24th and in Berlin on May 7th-8th.

Second, consider participating in one of the Drumbeat projects listed on the Drumbeat website (still in beta).

I’m looking forward to see Drumbeat evolve and for it to become easier for people to participate in its various projects. Ultimately we need a way to protect the openness of the web – the thing that makes the web so fun and interesting for all us – and Drumbeat is a great starting point.

Articles I'm Digesting 4/4/2010

1 Reply

Why Hasn’t Scientific Publishing Been Disrupted Already? by Michael Clark

A couple of months ago I gave a talk at the Regenstrief Institute about collaboration and open science. This article sums up one part of the talk – about the evils of closed publishing models in science. Clark writes everything I was thinking plus more, dissecting the problem in a manner that is far more concise that I dreamed of. It is a joy to read.

The challenge? That that making science more open is impossible because of the technology, it is cultural/economic. The entire reward system in science is based around getting published… so while there are ways to share scientific information that would be more efficient (and thus better for both science, scientists and humanity) we are stuck in the 20th (or 19th) century because the culture and institutions of science trap us there. A brilliant read.

Government and the Good Life by Doug Saunders

Saunders article is classic globe – the very reason why I try to get a different perspective on their website. It’s a good read, thought provoking but also, very 20th century. Saunders article is about our quest to reconcile the paradox of “Now we’re all for big government. Yet we do not trust government.” We are again embarking on a question to relearn the lessons of the Great Depression and trust the state once again.

I have my doubts.

Today we aren’t choosing between the market and the state. We recognize that both are essential. But we trust neither, and I suspect, will continue to trust neither. Rather than markets or governments, we are choosing between Open and Closed. Who are the villains of today? Swiss bankers who’ve ripped millions off of families, the Roman Catholic Church that hides and protects priests who molested small children, Government’s that refuse to disclose documents (even to parliament), companies that offer enormous bonuses to executives in confidential board meetings. Who are the heroes? The whistleblowers, the journalists, the computer programmers who make government more transparent… This isn’t about trust. In a world of opacity vs. transparency, it’s about verification. If I have to pick the great paradox, it isn’t about government’s versus markets, its about opacity vs transparency…. where do draw the line. That’s the big questions that we’ll be wrestling with.

Results From Dungeons & Dragons Online Going Free: Revenue Up 500% via Techdirt

Score one for the freemies. Great article about how, after giving the entire game away for free, the game attracted another 1million users and increased revenues by 500%.

The Total Growth of Open Source by Amit Deshpande and Dirk Riehle at SAP Labs

The graph below pretty much sums up the story. Open source projects, both the total number and the amount of code being submitted to them, is growing. Fast. At an exponential rate.

Of course, Government IT departments still can’t even think about Open Source software (more on this later this week) but it is clear that this model for software development is expanding. Nice to read an article that tries to measure this growth accurately.

BC Apps For Climate Change Contest to be Announced

12 Replies

Over the past few months I’ve been working with the BC Government around the idea of an “Apps for Climate Change.” The idea, initiated by the province, is to hold a development competition akin to the “Apps for Democracy” competition hosted by Washington DC but focused around climate change.

I talked a little bit about the upcoming competition during my O’Reilly Gov 2.0 International Online talk and referenced an article by Stephen Hui in the Georgia Straight which outlines some of the competitions details. (some people have been asking for that link).

In short, the province is assembling a fairly large data catalog focused around climate change and greenhouse gas emissions, along with a number of other data sets. I expect the contest to be announced at GLOBE 2010 (Mar 24-26) with a side announcement at OpenGovWest and hope to share more information soon. There will be prize money involved – but more importantly, an opportunity to create something that could get serious profile.

In addition to interested independent developers, one hope I have is that non-profits like Greenpeace, the David Suzuki foundation and others will reach out to developers in their volunteer/activist community and encourage them to use these data sets in ways that might help the public. I’m also hoping that some private sector actors may see ways to use this data to better serve their clients or save them, or their customers, money.

Either way, I hope the competition sparks the interest of Canadians across the country and generates some interesting applications that can help citizens act on the issue of climate change.