Category Archives: OpenMRS

Weaving Foreign Ministries into the Digital Era: Three ideas

1 Reply

Last week I was in Ottawa giving a talk at the Department of Foreign Affairs talking about how technology, new media and open innovation will impact the department’s it work internally, across Ottawa and around the world.

While there is lots to share, here are three ideas I’ve been stewing on:

Keep more citizens safe when abroad – better danger zone notification

Some people believe that open data isn’t relevant to departments like Foreign Affairs or the State Department. Nothing could be further than the truth.

One challenge the department has is getting Canadians to register with them when they visit or live in a country labeled by the department as problematic for traveling in its travel reports (sample here). As you can suspect, few Canadians register with the embassy as they are likely not aware of the program or travel a lot and simply don’t get around to  it.

There are other ways of tackling this problem that might yield broader participation.

Why not turn the Travel Report system into an open data with an API? I’d tackle this by approaching a company like TripIt. Every time I book an airplane ticket or a hotel I simply forward TripIt the reservation, which they scan and turn into events that then automatically appear my calendar. Since they scan my travel plans they also know which country, city and hotel I’m staying in… they also know where I live and could easily ask me for my citizenship. Working with companies like TripIt (or Travelocity, Expedia, etc…) DFAIT could co-design an API into the departments travel report data that would be useful to them. Specifically, I could imagine that if TripIt could query all my trips against those reports then any time they notice I’m traveling somewhere the Foreign Ministry has labelled “exercise a high-degree of caution” or worse trip TripIt could ask me if I’d be willing to let them forward my itinerary to the department. That way I could registry my travel automatically, making the service more convenient for me, and getting the department more information that it believes to be critical as well.

Of course, it might be wise to work with the State Department so that their travel advisories used a similarly structured API (since I can assume TripIt will be more interested in the larger US market than the Canadian market) But facilitating that conversation would be nothing but wins for the department.

More bang for buck in election monitoring

One question that arose during my talk came from an official interested in elections monitoring. In my mind, one thing the department should be considering is a fund to help local democracy groups spin up installations of Ushahidi in countries with fragile democracies that are gearing up for elections. For those unfamiliar with Ushahidi it is a platform developed after the disputed 2007 presidential election in Kenya that plotted eyewitness reports of violence sent in by email and text-message on a google map.

Today it is used to track a number of issues – but problems with elections remain one of its core purposes. The department should think about grants that would help spin up a Ushahidi install to enable citizens of the country register concerns and allegations around fraud, violence, intimidation, etc… It could then verify and inspect issues that are flagged by the countries citizens. This would allow the department to deploy its resources more effectively and ensure that its work was speaking to concerns raised by citizens.

A Developer version of DART?

One of the most popular programs the Canadian government has around international issues is the Disaster Assistance Response Team (DART). In particular, Canadians have often been big fans of DART’s work in purifying water after the boxing day tsunami in Asia as well as its work in Haiti. Maybe the department could have a digital DART team, a group of developers that, in an emergency could help spin up Ushahidi, Fixmystreet, or OpenMRS installations to provide some quick but critical shared infrastructure for Canadians, other countries’ response teams and for non-profits. During periods of non-crisis the team could work on these projects or supporting groups like CrisisCommons or OpenStreetMaps, helping contribute to open source projects that can be instrumental in a humanitarian crisis.

 

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…

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.

Open Source Strategy: OpenMRS case study

4 Replies

Last week I had the pleasure of being invited to Indianapolis to give a talk at the Regenstrief Institute – an informatics and healthcare research organization – which also happens to host the founders of OpenMRS.

For those not familiar with OpenMRS (which I assume to be most of you) it is open-source, enterprise electronic medical record system platform specifically designed to respond to those actively building and managing health systems in the developing world. It’s a project I’m endlessly excited about not only because of its potential to improve healthcare in developing and emerging markets, but also because of its longer-term potential to serve as a disruptive innovator in developed markets.

Having spent a few days at Regenstrief hanging out with the OpenMRS team, here are some take aways I have regarding where they are, and where – in my mind – they should consider heading and what are some of the key places they could focus on to get there.

Current State: Exiting Stealth Mode

Paul Biondich and Andrew Arenson point me to this article about Community Source vs. Open Source which has an interesting piece on open source projects that operate in “Stealth Mode”

It is possible to find models similar to community source within the open source environment. For example, some projects opt to launch in a so called ‘stealth mode’, that is, they operate as a truly open source development from inception, but restrict marketing information about the project during the early stages. This has the effect of permitting access to anyone who cares enough to discover the project, whilst at the same time allowing the initiating members to maintain a focus on early strategic objectives, rather than community development.

OpenMRS has grown in leaps and bounds and – I would argue – has managed to stay in stealth mode (even with the help of their friends at Google summer of code). But for OpenMRS to succeed it must exit stealth mode (a transition that has already been steadily gathering steam). By being more public it can attract more resources, access a broader development community and role out more implementations for patients around the world. But to succeed I suspect that a few things need to be in place.

Core Opportunities/Challenges:

1. Develop OpenMRS as a platform to push people towards cooperating (as opposed requiring collaboration) whenever possible.

One of the smartest things Firefox did was create add-ons. The innovation of add-ons accomplished two benefits. First, it allowed those working on the trunk of the Firefox code to continue to do their work without being distracted by as many feature requests from developers who had an idea they wanted to try out. Second, it increased the number of people who could take interest in Firefox, since now you could code up your own add-on cooperatively but independently, of the rest of the project.

With OpenMRS my sense is that then entire UI is a platform that others should be able to develop or build add-on’s for. Indeed, the longer term business model that makes significant sense to me is to treat OpenMRS like WordPress or Drupal. The underlying code is managed by a core open source community but installation, customization, skinning, widgets, etc… is done by a mix of actors from amateurs, to independent hackers and freelancers to larger design/dev organizations. The local business opportunities to support OpenMRS and, in short, create an IT industry in the developing world, are enormous.

2. Structural Change(s)

One consequence of treating OpenMRS as a platform is that the project needs to be very clear about what is “core” versus what is platform. My sense is that members of the Mozilla team does not spend a lot of time hacking on add-ons (unless they have proven so instrumental they are brought into the trunk). Looking at WordPress the standard install theme is about as basic as one could expect. It would seem no one at WordPress is wasting cycles developing nice themes to roll out with the software. There is a separate (thriving) community that can do that.

As a result, my sense is that OpenMRS should ensure that its front-end developers slowly begin to operate as a separate entity. One reason for this is that if they are too close to the trunk developers they may inadvertently prevent prevent the emergence of a community that would specialize in the installing and customizing of OpenMRS. More importantly, those working on the platform and those working on the trunk may have different interests, and so allowing that tension to emerge and learning how to manage it in the open will be healthy for the long term viability of the project as more and more people do front end work and share their concerns with trunk developers.

3. Stay Flexible by Engaging in Community Management/Engagement

One of the challenges that quickly emerges when one turns a software product into an innovation platform is that the interests of those working on the product and those developing on the platform can quickly divide. One often here’s rumblings from the Drupal community about how drupal core developers often appear more interested in writing interesting/beautiful code than in making Drupal easier to use for businesses (core vs. platform!). Likewise, Firefox and Thunderbird also hear similar rumblings from add-on developers who worry about how new platforms (jetpack) might make old platforms (add-ons) obsolete. In a sense, people who build on platforms are inherently conservative. Change, even (or sometimes especially!) change that lowers barriers to entry means more work for them. They have to ensure that whatever they’ve built on top of the platform doesn’t break when the platform changes. Conversely trunk developers can become enamored with change for change’s sake – including features that offer marginal benefits but that disrupt huge ecosystems.

In my mind, managing these types of tension is essential for an open source project – particularly one involving medical records. Trunk developers will need to have A-level facilitation and engagement skills, capable of listening to platform developers and others, not be reactive or defensive, understand interests and work hard to mediate disputes – even disputes they are involved in. These inter-personal skills will be the grease that ensure the OpenMRS machine can keep innovating while understanding and serving the developer community that is building on top of it. The OpenMRS leadership will also have to take a strong lead in this area – setting expectations around how, and how quickly OpenMRS will evolve so that the developer ecosystem can plan accordingly. Clear expectations will do wonders for reducing tensions between disparate stakeholders.

4) Set the Culture in Place now

Given that OpenMRS is still emerging from Stealth mode, now is the time to imprint the culture with the DNA it will need to survive the coming growth. A clear social contract for participation, a code of community conduct and clearer mission statement that can be referenced during decisions will all be essential. I’m of course also interested in the tools we can role out that will help manage the community. Porting over to Trac the next generation of Diederik’s bug-fix predicter, along with his flame monitor, are ways to give community the influence to have a check on poor behaviour and nudge people towards making better choices in resolving disputes.

5) Create and Share Data to Foster Markets

Finally, I think there is enormous opportunity for a IT industry – primarily located in the developing world – to emerge and support OpenMRS. My sense is that OpenMRS should do everything it can to encourage and foster such an industry.

Some ideas for doing this have been inspired by my work around open data. I think it is critical that OpenMRS start asking implementations to ping them once complete – and again whenever an upgrade is complete. This type of market data – anatomized – could help the demonstrate demand for services that already exists, as well as its rate of growth. Developers in underserved counties might realize there are market niches to be filled. In addition, I suspect that all of the OpenMRS implementations that have been completed that we don’t know about represent a huge wealth of information. These are people who managed to install OpenMRS with no support and possibly – on the cheap. Understanding how they did and who was involved could yield important best practices as well as introduce us to prospective community members with a “can do” spirit and serious skills. I won’t dive into too much detail here, but needless to say, I think anonymized but aggregated data provided for free by OpenMRS could spur further innovation and market growth.

Postscript

I’m sure there is lots to debate in the above text – I may have made some faulty assumptions along the way – so this should not be read as final or authoritative, mostly a contribution to what is an ongoing discussion at OpenMRS. Mostly I’m excited about where things are and where they are going, and the tremendous potential of OpenMRS.