I started my open source work from Oregon, USA working on a project in the “Republic” of Texas. While that, at first glance, does not sound international in nature, I can assure you that Oregon and Texas might as well be different countries. I experienced both the joy and frustration of working with users from both places that had big cultural differences, as well as overlapping needs. This early experience laid the groundwork for the future, where I got to work at the international level on OpenEMR, an electronic healthcare records system.

I have since had the chance to work with several open source projects that have international appeal. Some started here in the USA and spread out, and also the reverse. I am always impressed by the level of effort that good projects put into making sure that they can be used effectively no matter where the user resides.

Projects I have known

OpenEMR, OpenMRS, and VisTA are three of the most well-known open source applications in the health IT genre. OpenEMR has worldwide acceptance as a complete and flexible electronic healthcare records (EHR) system that can be tweaked with relative ease to work anywhere. That is evident in its adoption by the International Planned Parenthood Foundation, the Peace Corps, and most recently by the Health Services Dept of Israel. OpenMRS is a respected tool set and API that has been predominantly used in Africa, and has been adopted for targeted healthcare needs all over the world. Despite being a US-based project, its adoption in the US is minimal. VisTA is the US Veteran’s Administration EHR and it is now, due mainly to the formation of OSEHRA.org, beginning to get traction in other countries as a solution to the high cost of proprietary EHR systems for hospitals. New on the horizon are projects like FHIR, started in Australia, and adopted by hl7.org.

Social challenges

One key issue that all projects face, but is more obvious in international projects, is the extent of developer participation. This is exacerbated in projects with international scope as the user may have a very specific problem to solve, such as tracking care for a Ebola outbreak, that isn’t funded to share the code back upstream.

Micheal Downey, the former community manager of OpenMRS and a key contributor and coordinator for LibreHealth.io, said: “Projects must have a compelling message of need in order to attract and keep developers beyond the immediate problem. Umbrella projects like LibreHealth.io and OSEHRA.org try to offer a variety of opportunities to contributors to help provide some incentive to drive ongoing contributions.”

This kind of community-based work requires a “beer fund”, that is, the group must account for the cost of socializing across diverse contributor and user groups so that good contributions are not lost. If a non-governmental organization (NGO), for instance, can’t afford the effort to integrate their work upstream, then in a well-socialized project someone is likely to pick the work up for the overall good of the community. This, of course, implies that the community itself, or a point person, understands and is able to negotiate the cultural, language, and time zone barriers that can stop international projects cold.

One of the best things about open source projects is that the default model of communication is asynchronous. This allows contributors to translate their interactions at a speed that is comfortable for them. Standard corporate models, like team conference calls, are more likely to result in miscommunication as team members struggle to understand what is being said over the speaker’s accent. Imagine being someone who learned English as a second language, and trying to understand someone from Texas or Scotland.

Technical challenges

These warrant close attention by the members of the community to avoid confusion and even rejection by potential contributors from other countries. Coding style is one good example. Some cultures read from the back to the front, right to left. The effect of that, for example, may be that some code contributions have the main()function at the bottom of a source file, and at the top in others. Both will seem natural to the different contributors. A good style guide that goes a long way towards smoothing that out. Making sure that code comments and variable names are in an agreed common language is important. I spent many hours (years back) enhancing a program that had all the comments and variable names in French, which I did not speak, and there was no Google Translate back then.

Finally, choosing a industry standard way to handle localization is crucial. The string translation method must be accessible to contributors that are not technical, and easily customized by the end user as well. Date formats, right-to-left support, and even color choices play a crucial role in acceptance internationally.

Geopolitical challenges

Differences in regulations and common-use practices are inherent in international projects, and particularly onerous in healthcare-based projects. Governments may mandate certain features that other countries (or even other counties and cities) find useless or are forbidden. A good example of this is the USA’s mandate that EHRs must be “Meaningful Use” certified. While many of the required features can be useful in other countries, the requirement for certification may require some features or functions that are undesirable. Projects must have methods of supporting both needs, such as user configurations or separately installable modules. Differences in use models can be significant. Users of EHR software in the US use a different clinical coding system, and need to bill for their services. Many countries have national systems which make that feature useless, or in need of a different design. Rules for records retention, storage and ownership also vary.

Someone, somewhere is sure to fork your project. It has been said that a successful open source project can be measured by how easy it is to fork. Your project should understand and strive to support and leverage this method of growth.

Conclusion

Working on a project that has worldwide possibilities is exciting and can be very rewarding. Open your minds to the diverse nature of an international community and be prepared for time zone busting interactions with people in cultures and places you’ve never experienced. It’s worth it!