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.