Communities Help Open Source Electronic Health Records Thrive (Part 1 of 3: Justification)

Posted on December 2, 2014 I Written By

Andy Oram is an editor at O'Reilly Media, a highly respected book publisher and technology information provider. An employee of the company since 1992, Andy currently specializes in open source, software engineering, and health IT, but his editorial output has ranged from a legal guide covering intellectual property to a graphic novel about teenage hackers. His articles have appeared often on EMR & EHR and other blogs in the health IT space. Andy also writes often for O'Reilly's Radar site ( and other publications on policy issues related to the Internet and on trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business. Conferences where he has presented talks include O'Reilly's Open Source Convention, FISL (Brazil), FOSDEM, and DebConf.

The value of community participation is a major topic among open source software projects. When people draw together around a project, talk about it (and argue passionately about it) among themselves, offer advice, contribute code, fix bugs, and generally consider themselves one of the family–a robust, highly engaged community seems to be a magical force that determines whether an open source project succeeds.

The correlation is strong. Great community participation: the project lasts forever. Poor community participation: the project stagnates and is widely seen as irrelevant.

The company I work for, O’Reilly Media, in recognition of the bond between community and open source, has sponsored a Community Leadership Summit for the past seven years in conjunction with our Open Source convention. Many other Community Leadership Summits are now held around the world. The founder of the summit also wrote a book called The Art of Community for O’Reilly. The health of an open source community is also assessed as one of the factors that let potential software users judge the project’s maturity, and therefore whether they feel trusting enough to put its software at the center of their own endeavors.

The next two articles in this series will examine various open source projects in the health IT space that have developed vibrant communities. But before we can appreciate the importance of those efforts, we need to understand why community is central to growth. That is the subject of this article.

Naturally, we have no randomized clinical trials to draw on, so we don’t really know why community and success are correlated in open source. It could simply be that good software draws interested people around it. But there are persuasive explanations for the apparent positive effect that communities have on projects.

Community members help each other get started with projects, solve problems among more knowledgeable users, advocate for the projects, make substantial contributions to code, and find ways to reward project developers and make them feel appreciated. Of course, some of these activities are done for proprietary projects as well, and for other companies of all types–just witness the loyalty of Apple users, Harley Davidson motorcycle drivers, In-N-Out Burger gourmands, and so forth.

Witnessing the value of community, many companies nowadays try to develop communities around their products or services. Many do it through social media campaigns (seeing how many “likes” they can get on Facebook, for instance), but these small boasts pale before the tangible contributions of an open source community. I believe community offers open source an unshakeable advantage over proprietary software in three ways.

  • Setting direction: by extending the software in ways they care about, and even creating the new building blocks at the core of a software project, community members ensure that a project stays relevant to its users. If the leaders of a project don’t recognize an important trend in the field, someone else will create the code to make sure the project supports that trend, and users will champion the adaptation. Whereas proprietary projects have to choose one or two directions that promise the most revenue, open source projects can permanently support niche uses. Nowadays, there is no stigma involved in changing the software and creating a whole new project based on an older one.

  • Continuity and trust: purchasers of proprietary software–and nowadays, users of online services–are at the mercy of the vendor. The developers of the software you depend on every day may go out of business, raise prices precipitously, or drop features you consider critical. I’ve heard numerous such horror stories and experienced a couple myself. Therefore, many users insist on open source software because it will stay around even if the original developers lose interest or try to move it in a different direction. A well-educated and motivated community can pick up an abandoned project and generate new developers.

  • Education: open source provides examples and models for people learning how to program, and these programmers in turn can serve the users of open source. Nothing gives you more insight into a project’s robustness and performance than looking inside the software. Paging through code gives a user a bond with the software comparable to that of a musician who makes his own instruments or a motorcyclist who services his own vehicle. Not everyone who uses software has the time and expertise to study the source code, but the few people who do can be resources for the rest of the community. They can usually describe the quirks and problems of the software better than the developers, who are too close to their own work to have the same empathy for users. Organizations can also hire a competent programmer to customize the code and meet their unique needs.

Community has been credited with one of the most notable successes in computing history: the rise of the Linux operating system. Many people–most notably, BSD proponents–have wondered why the august BSD operating system didn’t achieve the fame and dominance of Linux. Community is a formidable component of the answer.

BSD (which stands for Berkeley Software Distribution, a nod toward the university where it originated), a variant of the Unix operating system, was mature and widely used more than a decade before Linux was famously invented by 19-year-old college student Linus Torvalds. BSD was generally credited with having better programming interfaces than the original Unix developed by AT&T, and many of its library calls made it back into the “real” Unix. BSD was also adopted by many proprietary companies, and became in particular the basis of the great company Sun Microsystems, the most popular source for modestly priced computer systems for decades.

But BSD was not as innovative organizationally as it was technically. It was developed by a closed team that experienced disagreements and splits. Three different, incompatible versions of BSD still exist today (not even counting the version that underlies Apple products, and some other smaller branches).

In contrast, Linus Torvalds announced his project by posting it to the Internet and inviting others to contribute. He has proved an extremely adept project leader during the ensuing 23 years, a “benevolent dictator” in open source parlance.

Certainly, the computer field has evolved a great deal between the founding of the BSD project and the founding of the Linux project, and many factors can be credited in Linux’s success. But the organizational woes of the various BSD factions contrast strikingly with the fiercely fought but successfully contained debates within the Linux community.

Having surveyed the history of open source and the role of community, I’ll turn in the next article to successes within health IT.