«OpenScrum: Scrum methodology to improve shared understanding in an open-source community Saptarshi Purkayastha Department of Computer and Information ...»
Over 3000 tickets were analyzed for factors such assignee, reporter, priority, creation time to resolution time, linkage to source-code and linkage to a sprint or software release. This was done through the use of JQL queries that allow retrieving issues based on selective options from JIRA. Source-code was analyzed in co-relation to the tickets and measured according to the changes in lines of code per developer, number of commits, refactoring of existing code, unit tests and code comments. The research covers code from OpenMRS svn 1 repository for distributed modules, as well as code from git 2 for the OpenMRS core, migration to which happened in August 2012. An Ohloh.net project was created for code analysis by listing various code locations. Additionally, a tool called Fisheye from Atlassian Inc. was used for analyzing activity by developer in terms of code commits and code reviews. Nabble.com was used to get aggregate information about individual contributors on the mailing list. Text mining was not done on the contents of the mailing list, but analysis was done only on the name, email and known organization from the sender’s list. Documents on wiki pages which describe design, development and use were analyzed through an interpretive perspective. The wiki is used to collect summary information about discussions and often as a knowledge base about design decisions taken by the community.
This quantitative data was interpreted in relation to the different concepts of agility as presented in the previous sections. This analysis was then shared with each individual core developer through a set of semi-structured interviews which last about 45min to 1hr. A total of 25hrs of interviews were done and 3 group discussions were organized with the core developers. The interviews were transcribed and entered into Nvivo, qualitative data analysis software. Then performed coding based on concepts of “learning”, “agility”, “knowledge”, “release cycle”, “participation” and performed thematic synthesis . The resulting themes from the analysis were matched against quantifying words like “more”, “less”, “increase”, “decrease” to verify that the interviewees described the concepts across the interview in the same increasing or decreasing order. Beyond discussing interpretations of quantitative data, opinions were asked on a wide variety of topics such as community participation, developer workload, project management and software development methods in the OpenMRS community. This resulted in deeper understanding of the phenomenon and allowed drawing upon interpretations of core developers. These discussions helped meet the principles of interpretive research  such as - principle of contextualization; principle of interaction Svn or Subversion is a centralized version control system where source code is stored and versioned Git is a distributed version control system, which allows developers to fork code and work separately on same parts of the source-code.
between researcher and subjects; principle of dialogical reasoning; principle of multiple interpretations - each of which helps bring rigor and validity to the findings.
As in any research approach, case study has its strengths and weaknesses  . Case research is important for this type of research, as it allows for study of a large number of variables in a given setting, while these variables do not have to be previously defined .
The weakness of such case research is that it is hard to make generalizations or be able to draw conclusions that can be claimed to be valid for all open-source projects. But I take the view that OpenMRS is indeed representative of many similar open-source software communities that work in a vertical domain and have a similar governance and participation model. The OpenMRS governance model is community-driven. Issues are created by community members, weekly developer meetings, weekly implementer meetings, design discussions are on public mailing list or during the weekly meetings. Code review happens in public, voting is used to prioritize features etc. There is a newly formed OpenMRS Foundation with an executive board and community members vote to put a member on the board of directors. Most day-to-day decisions are not taken by the board, but instead through community discussions. The leadership of the OpenMRS community has tried to model itself similar to Mozilla, including having the ex-CEO of Mozilla on the OpenMRS board to get a better understanding of governance principles.
3.1 CONTEXT AND RESEARCHER ROLE
In the paper, I attempt to contextualize ASD in OpenMRS as much as possible. Krutchen  highlighted the importance of contextualizing. However, due to length constraints, we don’t describe the context of ASD using the full “frog and octopus” model , but make maximum attempt to describe all areas, although not as separate sections. OpenMRS is a software platform and a reference application which enables design of a customized medical records system with no programming knowledge (although medical and systems analysis knowledge is required). It has a modular design, where modules are add-ons that extend the functional scope of the system. There are 76 modules installable from the OpenMRS module repository, 125 modules have their source-code in OpenMRS svn. While there are close to 220 OpenMRS modules that are openly available from different sources (github, bitbucket, sourceforge), yet this is only a rough estimate of available modules. Most modules are developed by developers who are not part of the core team. These modules cover broad range of functionality and there is a clear separation of openmrs-core, which has distinct software development lifecycle from modules. While the focus of this research is openmrs-core, we include some modules which are distributed along with the reference application called core & bundled modules. These include FormEntry, HTMLFormEntry, Logic, XForms, DataEntryStatistics, SerializationXStream, Reporting, ReportingCompatibility, HTMLWidgets and PatientFlags. Unless mentioned otherwise, the paper refers to OpenMRS as the “core + distributed modules”.
I have been involved in the project as an independent developer for about 6 years, without direct funding from any organization to be part of the software development process. I have also spent a summer internship through Google Inc. at OpenMRS in 2008, through which closer engagement in the community had started. I have been identified as a contributor to the core for many years and have been actively engaged in different roles – as developer, implementer and consultant at for-profit and not-for-profit entities that use the OpenMRS platform. I have participated in many design discussions, roadmap decisions and overall community management discussions before this research. Over the years, I have developed few open-source modules that are used by implementations all over the world as well as proprietary modules that are used by for-profit and not-for-profit global organizations. All of this highlights that I already had a deep understanding of the community and its practices (implicit and explicit) including roles of core developers and other community members.
Walsham  classifies such style of involvement as “involved researcher” while doing interpretive research. Yet, the motivation and the decision-making process of changing to agile method, (specifically a customized Scrum method) from a global, distributed software development model were not known to me clearly before this research. This is because the decision was taken by the OpenMRS leadership group and was announced to the community through the developer mailing list. More on the motivation and decision-making process for adoption of agile methodology is covered in the next section.
4. THE EVOLUTION OF SOFTWARE DEV METHODOLOGY IN OPENMRS
OpenMRS is inter-twined software and community, similar to many open-source projects, where the software application development community describes itself as product developers as well as clients of the product. This intertwining is fairly evident in how developers are implementers and implementing organizations contribute developer resources.
Yet, some community members are purely implementers who do not have developer resources, while some OpenMRS core developers are allocated only to “core OpenMRS tasks” and not to implementation-specific requirements. As we have found out in the study, this is a fairly hard task to balance.
4.1. The globally distributed open-source development model
OpenMRS software development before the move to ASD was like most other communitydriven open-source projects. Certain developers are maintainers of specific modules or parts of the system. These developers work for different organizations and have their organizational interests or personal interests. The project started in 2004 as collaboration between two health care organizations and quickly expanded into a global, open-source software community . The project at the time of research had 218 code contributing developers distributed across the globe. Only 41 of these developers are from organizations that implement or support OpenMRS installation. The independent contributors are those who have “come-and-gone” into the project from time to time. The unknown developers are possibly individuals who want an internship position or give a shot at contributing to OpenMRS, but do not actively contribute. In Table 1, we see activity of developer in the community with reference to emails responses, code commits, code reviews. A 30-day period of no-activity makes the developer dormant and continuous activity count is reset.
This shows that although the core developers are moving forward with development, there is active participation from a larger community of developers, who participate in all types of activities ranging from engaging in discussions to doing code reviews. The role of unknown developers, independent contributors and large number of interns is different and unique to open-source organizations.
In OpenMRS a major percentage of the new developers to the project are student interns, who contribute for a summer or limited period of time. Nearly 75% of the developers fall into category of “community developers” and make up for largest opportunity for the organization to increase commits from these developers from the current 23% levels. This means that without any additional direct cost to the organization, the number of commits can be increased, if the potential of these contributors can be tapped into. On the other hand, OpenMRS has approached the challenge of growth by hiring intern students as Full-time Engineers (FTE), either as core developers or into support organizations. While other opensource projects, mainly run by for-profit organizations have introduced the concept of “bounty”, either monetary or “in-kind”  to developers who submit code or find specific bugs, OpenMRS has not done anything similar. Thus, the motivation for code submissions to OpenMRS has generally been intrinsic.
As highlighted in the introduction section, volunteer contribution gives rise to a sustainability challenge. OpenMRS also does not make concerted effort to reach out to dormant developers, as highlighted by a core developer. “We would like to see developers return, but student developers generally remained active only due to Google’s funding over the summer and go away to other paying jobs after graduating”. When asked why, there is no effort to reach out to dormant developers, a general consensus was lack of analytics to know, when and why people drop out of the project. One interviewee mentioned, “We are experimenting with a CRM system that will be used to track contributors and developers. This will allow us analytics and look at these contributors as leads”.
While analytics and tracking of developers till date has been somewhat easy, OpenMRS leadership realizes that as they’ve moved to distributed version control and also grown in the number of participating organizations, it continues to become harder to trace code changes across the community. Multiple forks of modules as well as core have been done in recent months by different organizations and developers. But much of the features from these, experimental forks has not returned to the mainline of development. One core developer highlighted, “We are less concerned about forks. We don’t know whether to encourage or discourage forks, when we don’t have a mechanism to lure those forks to submit pull requests. We have moved to github and forks are inevitable, but at least easy to track”.
While, this suggests the general approach in open-source, that “free will” of the partnering organization or contributing developers be respected, it is important to realize that governance and management need active action, instead of passive observation.
In the past, OpenMRS developers have been responsible to maintain and contribute to their own modules. Core developers would generally choose tickets on parts of the system that they are familiar with, and new developers have a set of introductory tickets that have been identified for attempt by new contributors. The developers come from different time zones and are expected to work on the tickets over their estimated time. Before the scrum methodology was adopted in March 2011, developers would generally not have a scheduled meeting, but would hang out in the IRC room. There would be discussions around problems, if a developer had trouble resolving the issue on their own. But there was no formal group communication through which one developer could communicate with all other developers.