Tag Archives: strategy

Using Data to Make Firefox Better: A mini-case study for your organization

I love Mozilla. Any reader of this blog knows it. I believe in its mission, I find the organization totally fascinating and its processes engrossing. So much so I spend a lot of time thinking about it – and hopefully, finding ways to contribute.

I’m also a big believer in data. I believe in the power of evidence-based public policy (hence my passion about the long-form census) and in the ability of data to help organizations develop better products, and people make smarter decisions.

Happily, a few months ago I was able to merge these two passions: analyzing data in an effort to help Mozilla understand how to improve Firefox. It was fun. But more importantly, the process says a lot about the potential for innovation open to organizations that cultivate an engaged user community.

So what happened?

In November 2010, Mozilla launched a visualization competition that asked: How do People Use Firefox? As part of the competition, they shared anonymous data collected from Test Pilot users (people who agreed to share anonymous usage data with Mozilla). Working with my friend (and quant genius) Diederik Van Liere, we analyzed the impact of add-on memory consumption on browser performance to find out which add-ons use the most memory and thus are most likely slowing down the browser (and frustrating users!). (You can read about our submission here).

But doing the analysis wasn’t enough. We wanted Mozilla engineers to know we thought that users should be shown the results – so they could make more informed choices about which add-ons they download. Our hope was to put pressure on add-on developers to make sure they weren’t ruining Firefox for their users. To do that we visualized the data by making a mock up of their website – with our data inserted.

FF-memory-visualizations2.001

For our efforts, we won an honourable mention. But winning a prize is far, far less cool than actually changing behaviour or encouraging an actual change. So last week, during a trip to Mozilla’s offices in Mountain View, I was thrilled when one of the engineers pointed out that the add-on site now has a page where they list add-ons that most slow down Firefox’s start up time.

Slow-Performing-Add-ons-Add-ons-for-Firefox_1310962746129

(Sidebar: Anyone else find it ironic that “FastestFox: Browse Faster” is #5?)

This is awesome! Better still, in April, Mozilla launched an add-on performance improvement initiative to help reduce the negative impact add-ons can have on Firefox. I have no idea if our submission to the visualization competition helped kick-start this project; I’m sure there were many smart people at Mozilla already thinking about this. Maybe it was already underway? But I like to believe our ideas helped push their thinking – or, at least, validated some of their ideas. And of course, I hope it continues to. I still believe that the above-cited data shouldn’t be hidden on a webpage well off the beaten path, but should be located right next to every add-on. That’s the best way to create the right feedback loops, and is in line with Mozilla’s manifesto – empowering users.

Some lessons (for Mozilla, companies, non-profits and governments)

First lesson. Innovation comes from everywhere. So why aren’t you tapping into it? Diederik and I are all too happy to dedicate some cycles to thinking about ways to make Firefox better. If you run an organization that has a community of interested people larger than your employee base (I’m looking at you, governments), why aren’t you finding targeted ways to engage them, not in endless brainstorming exercises, but in innovation challenges?

Second, get strategic about using data. A lot of people (including myself) talk about open data. Open data is good. But it can’t hurt to be strategic about it as well. I tried to argue for this in the government and healthcare space with this blog post. Data-driven decisions can be made in lots of places; what you need to ask yourself is: What data are you collecting about your product and processes? What, of that data, could you share, to empower your employees, users, suppliers, customers, whoever, to make better decisions? My sense is that the companies (and governments) of the future are going to be those that react both quickly and intelligently to emerging challenges and opportunities. One key to being competitive will be to have better data to inform decisions. (Again, this is the same reason why, over the next two decades, you can expect my country to start making worse and worse decisions about social policy and the economy – they simply won’t know what is going on).

Third, if you are going to share, get a data portal. In fact, Mozilla needs an open data portal (there is a blog post that is coming). Mozilla has always relied on volunteer contributors to help write Firefox and submit patches to bugs. The same is true for analyzing its products and processes. An open data portal would enable more people to help find ways to keep Firefox competitive. Of course, this is also true for governments and non-profits (to help find efficiencies and new services) and for companies.

Finally, reward good behaviour. If contributors submit something you end up using… let them know! Maybe the idea Diederik and I submitted never informed anything the add-on group was doing; maybe it did. But if it did… why not let us know? We are so pumped about the work they are doing, we’d love to hear more about it. Finding out by accident seems like a lost opportunity to engage interested stakeholders. Moreover, back at the time, Diederik was thinking about his next steps – now he works for the Wikimedia Foundation. But it made me realize how an innovation challenge could be a great way to spot talent.

Game Theory: Coalition, Libya, Gaddafi and the exit strategy

Great question Andrew – one that deserves answering.

Here’s my quick assessment. My guess is that the intention of the military action is to give Gaddafi alternatives to fighting. The goal of the no-fly zone and other military activities is designed to bring about a stalemate in the Libyan conflict. It’s goal is to provide the rebels with a clear safe haven which they can defend and sustain themselves. This fact, over time, would foster circumstances by which a negotiated agreement (or internationally mediated agreement) between the Libyan government and the rebels would be seen as necessary by both parties. This could, of course, come about with (or without) Gaddafi’s endorsement – but it would leave him some leverage if he chose to go down this path. Indeed, this political negotiated outcome is an explicit goal of the UN resolution. Moreover, the removal of Gaddafi is not called for. There is a wonderful analysis of the resolution on the BBC website, I’ve extracted the relevant parts below:

Screen-shot-2011-03-20-at-4.48.03-PM

The stalemate outcome analysis also feels plausible given it is hard to imagine the Libyan rebels have either the equipment, training, resources and resolve to topple the Libyan government, with or without air support. Occupying vast swaths of the country may simply be sufficient for the rebels to achieve their goals – to force Gaddafi to accept he can no longer rule the country alone.

So in short, Gaddafi has as simple choice. He can fight and try to win outright (or gain enough leverage so as to create a negotiated outcome that would achieve the same outcome as winning). This has the benefit of huge upside if he wins (with disastrous outcomes from the west – expect some retaliatory terrorism) but it also has more dramatic downsides. If he loses, a complete loss of power, death and/or imprisonment all seem very likely. So this is a high stakes path.

Alternatively, he can choose to negotiate. This route has more ambiguity, something that presents a risk in of itself (a reason why the back channels will matter so much – see below). Here the upsides and downsides are slightly less extreme, although there is a possibility of an outright “win” for Gaddafi is not off the table completely.

Given these choices it wouldn’t be inconceivable for Gaddafi to choose to fight at first to test the resolve of the Allies and the rebels (something we are seeing now) and, should that not work (which it probably won’t, but could) he can always change gears and retreat into a stalemate negotiation and put forward offers that attempt to fracture the rebel coalition. If he can do that, he could still win back enough support to retake the country, find some way to influence the next government, or at worst, be forced to retire.

I’ve tried to sum all this up on a choice matrix below. The sum of it is, the top lefthand outcome seemed a certain outcome a few days ago. Now the allies are forcing the right column back into the picture. Have downsides down the left become significant enough? And the upsides or exit strategies for Gaddafi on the right certain enough to chance the calculus? That’s really the question – but I do think it remains a possibility.

david-eaves-gaddafi-analysis

There are, of course, at least two other parts of the puzzle that need to be in place to ensure that Gaddafi isn’t forced into fighting.

1. Someone would need to back channel to him the allies intentions: that the UN resolution is designed only to force a stalemate, not oust the current government. It might be logical for Gaddafi to then try to continue fighting and see if he can win despite the airstrikes (as this would maximize his leverage) and, he can always choose to back down later.

2. The western allies and the rebels would need to not interpret the retreat or adoption of a defensive posture by Gaddafi forces as signs of imminent collapse and try to press the advantage.

Obviously I do not know if condition number 1 is in place. In regards to condition number 2, this is also unclear, although I suspect the risks are relatively low. The UN resolution would appear to suggest this isn’t as possible but maybe the biggest unknown is France, which appears unusually keen for battle. The worst case scenario here is that Sarkozy sees the conflict as a way to establish is “presidentialness” in the lead up to an election and so seeks to exploit it, dragging the rebels, and the rest of the allies down a path that needn’t be trodden. But even here, the likelihood feels relatively low.

Of course, there are always thousands of other variables and I’m sure there are more than a few holes to poke in this analysis (I’m all ears for those who want to take a stab – would be great to hear more), but hope this is a helpful attempt to answer that important question. If the only choice you give someone is to fight, expect a fight. And it isn’t clear that we have the resources or stomach to fight back to the bitter end, so I hope someone in Paris or Washington DC has thought this through from this perspective.

Open Source Strategy: OpenMRS case study

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.