|
|
A key principle for HISP is that DHIS should be licensed with a FLOSS license. DHIS 1.x is in fact licensed under the GNU LGPL. This is not because HISP is affiliated with the hacker culture or the FLOSS community. The decision to make HISP FLOSS is like the decision to make DHIS 1.x in MS Access, based on pragmatic reasons. This reasons and the similarities and differences between how DHIS is developed compared to the community model of development common for many FLOSS project, is what I will explore in this section.
DHIS being licensed under a FLOSS license gives clear advantages to the user. Unlike when negotiating to make a deal with a proprietary vendor the health authorities do not incur any financial risk by testing DHIS. HISP will not take the health authorities to court for not having enough licenses or for breaking contracts agreements relating to DHIS. The user can copy the software to as many computer as they wish, and if the need should arise they can even modify it. Modifying DHIS can make further updates of DHIS difficult if the changes breaks compatibility with the official branch of DHIS. Modifying DHIS in this way will effectively make a fork. Users outside the HISP network of students and developers will rarely make changes of this sort.
In the process of translating DHIS to a new context, developers sometimes need to look into the source code to make necessary changes. If DHIS was proprietary software the developers working on translating DHIS to a new country would have to sign NDAs, and this would have to happen within the legal framework of each country. HISP would have to hire lawyers. DHIS being FLOSS makes it possible for the people doing the adoptions of DHIS to a new country to make rapid changes based on user demands, making DHIS more acceptable to potential users. FLOSS is a prerequisite for informal collaboration across national and organisational boundaries, with a minimum of legal obstacles. The decision to base a FLOSS program like DHIS 1.x on a proprietary platform like MS Office, might seem a bit contradictory. Both the decision to license DHIS 1.x with a FLOSS license and the decision on build it using MS Access was based on pragmatic consideration seeming obvious at the time.
The HISP community is predominantly made up of health workers and academics and is not affiliated with the hacker culture. It is important to note that the overall goal of HISP is to empower the poor and marginalised. In this regard FLOSS is seen as a mean rather than an end in it self. FLOSS, however, lends itself naturally to a project with a goal to use IS as a tool for empowerment. Free software being, as it usually is, free as in “gratis” serves the poor, and free software being free as in “freedom” serves the marginalised. FLOSS serves HISP well, especially because HISP is not a profit seeking enterprise, and is based on what in the FLOSS context is called a community model with many more or less independent actors.
Unlike Linux which is based on the POSIX standard it is very hard to give an exact requirement specification for DHIS, so the participation of health workers are essential. Health workers are users and cannot be expected to contribute directly with bug fixes and patches. Health workers have to get guidance formulating what they want, and in what is technically reasonable. This put more challenge on the design of the system. There is a clear separation of the actual users of the systems and the core programmers making the system. Between the actual users and the core programmers of DHIS are the people who do the translation of DHIS, this people configure the system and do other forms of adaptations of the software. The translators plays a mediating role between the actual users and the core programmers. Within the HISP network the translators are the closest we come to user-programmers. The translators do more than translating language. The translators translate all aspects of the software that are necessary to make it useful in a particular context.
Members in other FLOSS communities tend to be more technically knowledgeable. In the later years FLOSS have crawled out of the hacker community and the academic computer science communities. Hackers have intrinsic interest in exploring programmable systems and can cope with software that is not particularly user friendly, and can change the software themselves if they are not happy with it. For enterprise ISs like DHIS with an user base consisting of people who do not care about programming and the inner workings of a computer, the actual users are not programmer. DHIS is not unique in this regard, FLOSS is used in many different kinds of enterprise systems. It make sense to base a new systems on proved FLOSS libraries, like the Spring framework and WebWork in the Java context. In this context the users of the FLOSS libraries becomes the user-programmers, not the users of the enterprise system. In the DHIS 2 context there is a group of core programmers working with DHIS 2. They base the development on a number of FLOSS libraries to make the development of DHIS 2 easier. DHIS 2 is a system that is meant to be used in many different context, so in addition to the core developers we have the translators. The core developers develop the stable core, and the translators adapt the flexible exterior. The actual users of the system do not have any programming skills, so for the translators the social perspective is most important. An illustration of this can be seen in Figure 11.1.
Many of the academics in the HISP community are people with no passion for programming. This people concern themselves more with the social than the technical aspects of IS, and are more likely to act as translators interacting with the actual users of the system. I worked as a translator in Tigray, but because I have a more technical inclination I concentrated more on the DHIS software than the organisational context. Even withing the different boxes in Figure 11.1 the different actors can have a varying emphasis on the social or on the technical aspects.
In general there are very few people from developing countries participating in FLOSS development. HISP is an exception to this. DHIS 1.x was and still is being developed by a team in South Africa. Most of the contributors to DHIS 2 are from Norway, but there are more contributors from developing countries like Vietnam, India and Vietnam than what is common in other FLOSS projects. More contributions will most likely come from developing countries when DHIS 2 gets into production.
HISP is also more than a community around a program, it is more importantly a community built around a common interest in improving health services by proper information management. FLOSS is not an end in it self for HISP, it is an important meant to improve health service for the marginalised. However, in the following two section I will concentrate on the motivations to participate in DHIS 2 development and the management of the DHIS 2 development.
The ideal developer in a FLOSS project would be a user-programmer who is a competent programmer and the actual user of the system. This developer would be intrinsically motivated to develop the system, have all the time in the world and demand no pay. To have such developers would be unlikely for any project. Here I will look into how developers can be motivated to participate, and how developers are motivated. I will base this discussion on both of my case studies.
My motives for starting on this thesis and for conducting the two case studies was for once that I wanted to take my degree. This is the cornerstone motivational factor within HISP, as HISP is a research network with master students, PhD students and faculty members. Most of the effort done within HISP is done by researchers doing action research. The downside to this motivation is that it is an extrinsic motivation. Participation in DHIS 2 development is within this frame only a meant to get a degree.
The course held at UiO have the same problem because participation through this course can easily be seen as only a mean to pass the course. Some of the student taking the course can become intrinsically interested in the development of DHIS 2, however. The development of the DHIS 2 core is likely to attract more technically inclined people, or hacker if you will. The DHIS 2 core is developed with a number of interesting frameworks. The frameworks that DHIS 2 builds upon, the tools used to support the development and the development practises used, this are all very handy to have learned for a future work situation. The primary motivation to participate in the development of DHIS 2 is to enhance development skills. The students participating in DHIS 2 development can say they have experience with relevant technologies when applying for a job. People participating in the development of DHIS 2 do not need to be interested in health information per se.
An other important motivation for contributing to DHIS 2 development is work related needs. The translators out in the field needs to fix a bug or needs to make specific changes to the core. In Ethiopia the ICD extension to DHIS 1.3 was made for that reason, and for that reason work is being done in Ethiopia to make the same extension for DHIS 2. Demands met by the translators in different countries, will certainly also in the future make it necessary to make extensions or changes to the core. As DHIS 2 is set into production in more countries and regions this will become a valuable source of feedback and contributions.
My second motivation to write this thesis was because I wanted to look into how FLOSS can benefit developing countries. Like most of the community based FLOSS projects, HISP is not seeking profit. I guess that it is more rewarding to participate voluntarily in making FLOSS software like DHIS better, than to do the same for a company seeking profit. The idealistic foundation of HISP and the value of empowering the marginalised in the developing world was important for me, it was the reason I chose to write a master thesis withing the HISP network. I am more technically inclined and considered writing a master thesis relating to the Distributed Multimedia Systems (DMS) group at UiO, but it felt more valuable to write my thesis within the HISP network.
HISP do pay people to do development and it is not unlikely that some contributions can come from the organisations using the systems when DHIS 2 is set into production. The health authorities in the different countries can heir people to make changes to DHIS 2, or they can give HISP money to heir people. In this instances the paycheck is the primary motivation.
Summing up I think HISP is most likely to motivate people to participate in the development of DHIS 2 through giving students a chance to improve skills, by work-related needs in the field, by idealism and the paycheck.
To harvest contribution to a project it is important how the project is managed. In this section I will look at the eight points in section 5.4 and how this points relates to the management of the DHIS 2 development. I will not restrict the discussion to this points, but will use them as a framework for the discussion.
The first point is to make it interesting and make sure it happens. The project leadership should act as motivators and encourage contributions. It is important that the people who contribute feels that their efforts are appreciated. Patches and suggestions should be seriously considered. The DHIS 2 project is a little bit different from conventional FLOSS projects since not all contributors are strictly voluntary, many contributors takes the INF5750 course where contributions are mandatory and many are master students who have to contribute to get their degree. The students taking INF5750 are not strictly free to what and how much to contribute. The course is important as a base for recruitment of master students and later voluntary contributors. Similar courses can and are being held at other universities in the HISP network.
Closely related to motivation is the concept of “scratching an itch”. Health information is unlikely to be a personal “itch” for a programmer, so contributions based on meeting a need in the developers immediate environment is unlikely. There is other kinds of “itches” that can be “scratched” in the DHIS 2 context. There can be an “itch” to learn to be a better programmer and how to use interesting frameworks. This can help a developer to position himself in a competitive job marked. In other words the “itches” that can be “scratched” comes from the motivations mentioned in the previous section.
DHIS is designed to avoid having to reinvent the wheel in each country and region DHIS is implemented. The stable core of DHIS contains features relevant across health systems, and the flexible exterior is designed to be relatively easy to change. DHIS 2 also use many FLOSS Java libraries and frameworks to ease the development. In addition to the core framework and development tools, DHIS 2 uses libraries for report generation and data analysis. Sometimes, however, it can make sense to implement some functionality directly into the application without using external libraries. That is if you only need a small fraction of the library’s functionality. It can become difficult to manage all the external libraries, each which have its own update life-cycle. It is important to not drown the application in frameworks, this was the primary reason I did not recommend using a pure plug-in framework, at least not what I managed to make, for DHIS 2. The framework added more complexity than it added value, which is exactly what EJB is frequently criticised for.
There have also been some efforts at solving problems through parallel work processes. In connection with DHIS 2 some research and development projects have been conducted apart from the DHIS 2 development. My experimentation with a plug-in framework is one example of this. It make sense to spin off some experimental sub-projects for possible later inclusion in the DHIS 2 code. This sub-project produces more or less throwaway prototypes which can be amended for inclusion in DHIS 2.
To attract contributors and to facilitate the work of the translators, it is important that the entry barrier to effectively use, configure and change DHIS 2 is as low as possible. A sensible interface for configuring the flexible exterior of DHIS 2 is important. For more complex changes and extensions it is important with well documented and understandable code. No matter how good the code is written and no matter how good it is documented, it is not easy to read code. There should be documentation in a more human readable form. There should be documentation for the developers of the DHIS 2 core, for extensions developers, for the translators and for the actual users. A potential DHIS 2 core developer need to understand the architecture of DHIS 2, and the concepts and abstractions used. A potential DHIS 2 core developer also need to understand the frameworks and libraries used. A potential extension developer need to know how to proceed in making an extensions. The translators in the field need to know the interface for configuration, how to submit bug reports and feature requests. The users need to know how to input data, produce reports and how to do data analysis. Documentation for, and perhaps by, these categories of DHIS 2 participants should be made.
Currently DHIS 2 do not benefit from massive peer-review. As DHIS 2 is set into more widespread use I think we will see more bug reports and feature requests from the DHIS 2 translators. This will also create a greater need for support. A lot of support can be given through good documentation, but this is often not enough. To release the core developers from the support burden, there should be mechanisms in place to help the users (the translators and actual users) help each other. This can be facilitated through a user e-mail lists, a support discussion forum, a IRC chat channel or similar means. The advantage of an archived e-mail list or discussion forum is that the support answer get stored, then a user facing similar problems do not have to ask.
DHIS 2 is dependent on other projects. DHIS 2 can function as a proxy for bug reports from its users. Some of the bug reports and feature requests can be related to the libraries and frameworks DHIS 2 depends on. The DHIS 2 developers can make a fix to a bug, or make a patch implementing changes necessary to support a feature request. This can be sent upstream to the relevant library or framework project. The DHIS 2 developers do not need to fix a bug or make a patch themselves. The bug report or feature request can be forwarded to the relevant project. This is similar to the way Linux distributions function as proxies for the Linux kernel and many other pieces of software.
The DHIS 2 project have still not finished a full release of DHIS 2. Up until the time of the full release intermediary milestone releases are made. For each milestone more functionality are implemented. After the full release I think it would make sense to divide the code into two branches. One unstable development branch with cutting edge features, and one stable branch which is debugged and where only features which do not require major code changes and do not break compatibility with extensions, is incorporated. This is similar to the way the Linux kernel is developed. It is a compromise between releasing early and often, and having stable software for production.
Both DHIS 1.x and DHIS 2 are FLOSS and are conceptually the same application. The major differences between this two different strains of the DHIS software are in how they are developed and on which platform they are implemented. In this section I am going to look at the advantages and disadvantages of the different development styles and platforms used by this two different strains of DHIS.
The development of the DHIS 1.x strain has since it’s beginning predominantly been done by a development team in South Africa. The development style of DHIS 1.x is that of building a “cathedral”. It is done by a tightly knit team. The design of DHIS 1.x is most definitely done in a participatory manner, but the development is not. You can say that DHIS 1.x has been developed using participatory design, but not participatory development. The software made in South Africa is transferred to the other nodes in the HISP network, where DHIS 1.x is translated to the local context. The translators give feedback to the development team making the DHIS 1.x core. It is only the core team that really understands the software, which puts a lot of support pressure on this team, and especially its leader Calle Hedberg.
The development of DHIS 2 is built around a community model. The design of DHIS 2 is for the most part based on DHIS 1.4. Years of PD experience is inscribed into DHIS 1.4. The PD approach to design is just as important to DHIS 2. The difference is that by basing the development of DHIS 2 on a community model it becomes participatory development as well as participatory design. Section 2.2.2 discusses the limits of PD. Many of these limits are relevant for any participatory approaches, you need people with sufficient time, skill and motivation. The difference is that our pool of potential participation in DHIS 2 development is not limited to the actual users of the software, and is not limited by any organisational boundary.
In Ethiopia we had to make changes to the stable core as well as to the flexible exterior of DHIS 1.3. In a way this was participatory development, but it was impossible to incorporate the changes into the official releases of DHIS 1.x. This made it impossible for the Ethiopian DHIS 1.3 to benefit from minor releases coming from South Africa. We where stuck with version 1.3.0.17. This was done due to the limitations in the DHIS 1.x architecture and platform. We could have transferred the changes made to this version to new minor releases, but this would place a quite large maintenance burden on the Ethiopian HISP team.
The limitations of MS Access, particularly in the area of modularisation, have given rise to a number of application separated from the DHIS 1.x user interface. This applications are implemented on other platforms, like Java or C++, and have its own user interface and business logic. This applications are linked to DHIS through the use of the database. The reason for making visually separate applications is to avoid making changes to DHIS that makes upgrading to new DHIS versions difficult. In Ethiopia changes to DHIS 1.3 were done through making direct changes to DHIS 1.3, effectively making the Ethiopian DHIS 1.3 a fork. It is extremely difficult to base a distributed development process on MS Access. MS Access is definite not designed with that in mind.
A great advantage with MS Access is that it is quite easy to learn. It is not necessarily more easy to learn for the actual users of DHIS, but it is more easy to learn for the people translating the software to a local context. Both DHIS 1.x and DHIS 2 offers visual configuration for many of the necessary adaptations of DHIS, like the organisational hierarchy and the data elements. There can be times, however, when this is not enough. I did not have any prior knowledge of MS Access before I went to Ethiopia, but I had no greater problems learning enough of MS Access to make necessary changes. It is also more common for developers in developing countries to be familiar with MS Access, than it is to be familiar with Java. It is highly unlikely that a local developer, like Kalkedan in Tigray, would be familiar with Spring, Hibernate, WebWork 2 and the other frameworks used by DHIS 2. I think DHIS 2 will place more demands on the translators if it becomes necessary to make changed not possible through the configuration interface.
MS Access is also great for making prototypes, mostly throwaway prototypes. For DHIS 1.x MS Access also served as a platform for making an evolutionary prototype. This enabled HISP to come up with a working solution relatively fast. Having a working solution is in my opinion the greatest argument any IS project could have. This helped HISP in the competition with other more ambitious projects in South Africa.
MS Access being proprietary software can in principle be seen as a disadvantage. Developers need to have it in order to contribute, the translators need to have it in order to translate the software and the users need to have it in order to use it. I did not have MS Office before I went to Ethiopia and I did not want to buy a license. Fortunately I got MS Office from my institute. MS Office is so ubiquitous in the developing countries where HISP operate, so this is not an important limitation. A more important limitation with the proprietary nature of MS Office is that HISP cannot legally bundle a specific version of MS Office together with DHIS. Therefore HISP have to support many different version of MS Office, and hope the client have one of the supported versions.
The greatest advantage with DHIS 2 is that it is possible to develop it using a community model. In my opinion this is in it self a sufficiently good argument to make a shift from MS Access to Java, or any other open platforms. HISP is after all a distributed community and doing distributed development have the potential of harvesting the collective effort and intellect of the HISP community. Independent of the DHIS 2 software I think it is a great advantage just having a community web site, which is the case for HISP now. Documentation and support can also be done in a distributed collaborative manner.
In DHIS 2 the “onion architecture” of DHIS 1.x is changed into an object oriented three tire architecture, using Spring to manage the dependencies between the objects. This architecture is more flexible and able to grow and be changed in the future. DHIS 2 has a higher barrier for people unfamiliar with the technology, but it has a lower barrier into understanding the code sufficiently to become a core developer because of a more sensible architecture.
Changing the flexible exterior of DHIS is done through configuration, but sometime it is necessary to change the DHIS core as well. The modularisation of DHIS 2 makes the stable core more flexible without making it fall apart through forking into many incompatible versions. Both the use of OOP and the use of Spring makes DHIS 2 more extensible. It is possible to make local changes and have it integrated with each new minor release of DHIS 2. Currently there are no standard way to make extensions to DHIS 2, however. The use of OOP and Spring makes the applications generally more flexible, but it give no clear route ahead to how a specific extensions, like an ICD extension, should be made. It is possible to extend classes, implement interfaces and change the Spring bean factory to use different classes as dependencies. DHIS 2 still lacks a general architecture for extensions, however.
DHIS 2 also offers an API which other applications can use. In DHIS 1.x other applications could only interface with DHIS through the data base, in DHIS 2 other applications can interface with the business layer. This applications will still be visually separate from DHIS 2 and are therefore not extensions, but more like other applications talking to DHIS 2. Using an API will still be handy for possible future extensions, since an API is less likely to change than the implementation.
In conclusion to the question of extensibility of DHIS 2 I will say that it is still possible to make the core of DHIS 2 more extensible. Using a pure plug-in framework is not the route to go, but it is possible to use less invasive methods, which do not require embedding a java servlet container in the plug-in framework. Using hooks is one route to go. The ICD module which the Ethiopian HISP node is making is excellent for testing the extensibility of the current DHIS 2. Can this be done without creating a dependency on a specific minor version of DHIS 2? Different ways to achieve extensibility should be experimented with in the future, and documentation on how to proceed making an extension should be made.
The Tigray case and the DHIS 2 case are very different primarily because I performed different roles in fairly different settings. In both settings I did some programming, but at very different stages in the development. In this section I am going to compare the role I played in Tigray with the role I played in the DHIS 2 development. I am also going to compare the different context in which I operated in the two cases.
In Tigray I worked as a DHIS translator, translating DHIS to the context of the Tigray health system. In this case the social aspects of IS was the most important and took the most time. First we had to negotiate with the Tigray health bureau to set up a client-system infrastructure. This involved a lot of social brokering. In this setting the DHIS software was secondary to the general goal of improving information management. The most important artifact we could offer Tigray was DHIS, but we could also offer help in developing an EDS based on an action oriented approach. I personally could not offer much help in developing an EDS, but the other team members had an more extensive information management background than I had.
For various reasons which are better explained by (Damitew and Gebreyesus 2005), there was a large number of data elements being reported in Tigray. Different departments demanded different reports, and the data elements often overlapped between the reports. It is my opinion that the work we did in Tigray can be justified solely by getting the different departments to work on an EDS. By bringing attention to the data being gathered, redundancy in reporting can hopefully be reduced, and less and more useful data can be gathered. This is an example of a situation where less is more. As we saw in section 8.4 the team appointed to develop an EDS did not actually come up with a minimal data set, but it was a reduction compared to the number of data elements that was currently in use.
The technical aspects was also important. We had to configure DHIS to be useful in the Tigray context and import some data from EPI-info to show that DHIS was a viable system. If we did not have the DHIS software we would not have much to put on the table in our negotiation with the bureau. I dedicated my time predominantly to configuring DHIS. Through this work I became familiar with the strengths and weaknesses of DHIS 1.3. In Tigray we was essentially cut of from the rest of the HISP community because of the slow and unreliable Internet connection. In this case a supportive virtual community would not help much, we could, after all, not access a virtual HISP community. I had downloaded a lot of documentation for Python allowing me to make the EPI-info to DHIS transfer script. Documentation for MS Access and VBA was also on my hard disk. To enable DHIS translators to work in places with no useful Internet connection, documentation for DHIS 2 should also be available in a form that can be downloaded to the local hard drive.
During my stay in Addis Ababa I had an usable Internet connection, and here I missed having contact with a virtual community accessible by other means than e-mail. I had no idea on who to contact about my GIS questions, and sending e-mails back and forth takes time. For the translators out in the field it would be helpful to have a responsive virtual community to help in the configuration of DHIS, and perhaps also to discuss various dilemmas of a more social nature. There are people in the HISP community who have a lot of experience from negotiating agreements with health authorities. There are also people with experience from conducting DHIS training sessions. In Tigray I had to make all the training material myself. I missed having access to training material. Training sessions has been conducted in every country in the HISP network. There must be a lot of material already made1. The context for training varies but DHIS is the same, so training material made in other context can still be useful.
In the DHIS 2 case I worked as a developer of the DHIS 2 core, not on the core itself but on an experimental sub-project. This role challenged my technical skills more than my social skills. The challenges I met in the Tigray case was predominantly social in nature. I was a stranger in a foreign county. I did not know the local language or culture, and I was not used to the local bacterias. In the DHIS 2 case the challenges was technical. I started out with a hope to make a plug-in framework for DHIS 2. This turned out to be a serious technical challenge.
The DHIS 2 case I conducted in Norway. A much better Internet connection and familiar surroundings made it much easier to work with software development. When I started on the DHIS 2 case a community web site was in the process of being made. This web site gave HISP a more clear point of presence on the Internet, and in a way this has made HISP more “real”. What really makes HISP real is the people involved in the process of structuration of HISP, but the web site makes the sense of structure more clear. Over the years there has been made many small applications in the process of translating DHIS 1.x to a new context. Most likely an ecosystem of related applications will be built around DHIS 2 as well. It would make sense for the HISP web site to offer hosting services for this applications as well.
In the DHIS 2 case I did not have any contact with any translators or actual users. The DHIS 2 development was in its infancy and the core design was taken from DHIS 1.4. Unfortunately the plug-in framework project I worked with became isolated. The technical challenges became too much for me to handle within my time constraints. In retrospect I realise I had a too grand vision for the plug-in framework. There did not exist any plug-in framework that could meet our vision of a pure plug-in framework for web applications. We made a throwaway prototype as a proof of concept, but making DHIS 2 into a pure plug-in application would add a lot of complexity to the coding of DHIS 2. Making a pure plug-in application involves a way of thinking unfamiliar to most programmers. I realise that I should have involved the other modules more into a discussion about how to make DHIS 2 extensible. The technical challenges I meet overshadowed the need to discuss how to provide extension points and where in the other modules this extension points should be. Extensibility is something that involves all the modules of DHIS 2. I should have focused less on making a plug-in framework and more on discussing with the other groups on making their modules extensible with the frameworks already in use.
DHIS 2 is currently being tested in India, Vietnam and Ethiopia. It will be interesting to see the experiences the translators in this counties have with configuring and extending DHIS 2. MS Access is well known among moderately competent developers in developing countries. In Ethiopia we hired Kalkedan to maintain and support DHIS for one year at the Tigray health bureau. He had tree years education from Mekelle University, where he had learned Visual C++, VB and MS Office. He had no knowledge of Java, and certainly not of Spring, Hibernate and WebWork. So the question I ask myself is: Would Kalkedan be able to configure and extend DHIS 2? I think he would be able to configure DHIS 2. Using an interface for visual configuration is not that difficult. If he, however, had to change or extend the code I think he would have a hard time. For DHIS 2, I think it is important to have an active virtual community where translators and the organisations using DHIS 2 can get support. It is important that the organisations where DHIS 2 are used are able to effectively use DHIS 2 without direct help from outsiders, except the help provided through the virtual community. The organisations using DHIS 2 should not perceive themselves as consumers of DHIS 2, but as collaborators in making a great application for information management in the primary health system.
In the Tigray case I worked as an DHIS translators. In the DHIS 2 case I worked as a DHIS 2 core developer. It has been a tremendous challenge to perform both these roles. I had to learn social science theory to perform my work as an DHIS translator and in order to write about the Tigray case. In order to perform my role as a core programmer I had to have programming skills, and I had to learn a lot of new technologies. It would be advisable to let new master student perform just on of these roles. The technical inclined can work with the DHIS core and the social inclined can work as DHIS translators. Dependent on the problem definition of the thesis the master student plans to write one or both of these roles can be performed.
