|
|
In this section I am going to make some theoretical reflections based on conventional IS theory and FLOSS. First I will use ST to reflect on the formation and social practices of the FLOSS community. Then I will reflect on PD, HISP and FLOSS and lastly I will make some reflection about technology translation.
In chapter 4 I gave a historical narrative to show how the social practices of FLOSS have changed and replicated over time and space. The practice of code sharing is not a newly invented practice, but has been present since the dawn of computing. As long as there was no business interest in selling software the natural thing to do was to share code. The only reason to keep code secret is if it enable you to sell software, or if it gives you a competitive advantage to keep a piece of code secret.
The social practice of sharing code is the most important social practice in the FLOSS community. Individual actors have different motivations to do this. Some do it for moral reasons because they have the opinion that code should be free. Others do it because of more pragmatic reasons. It is my opinion that the true test of whether source code is shared for moral reasons, is if there is a business opportunity in keeping the code secret, but where the developer chooses to share the code anyway.
The practice of code sharing based on pragmatic reasons have emerged in places where there are no interest or no opportunity in selling software, and where the network effect of sharing code is greater than the competitive advantage it gives to keep the code secret. In the case of Unix, AT&T had no opportunity to sell software (not until the 1980s anyway). The academic computer science research community quickly adopted Unix as an experimental toy. This community got its money from doing research, not from selling software. Sharing information is a basic value in the academic research community that enable researcher to “stand on the shoulders of giants”. The academic community do not always practice this value, often pride and glory seeking gets in the way. The Unix users did not share code for any moral reason, but because the network effect of sharing was that you got access to much more software than you provided.
An other important lesson to draw from the Unix history is that it is more important to make something work, than it is to implement a grand vision. The most important reason Multics did not succeed was that it sought to implement a grand vision, to complex for the state of technology at the time. Unix became a success not because it was a technical master peace, but because it worked and was available. Most important, the source was available. When you have something that work you can attract the attention of people willing to contribute if you are willing to share. This was what Unix did. Even if the first instant of the software is simple, a more complex and modular design will emerge if it attract contributions from more than a few programmers. The modular design will not emerge spontaneously, but to manage the contributions and to keep the interest up it is forced into existence.
Linus Torvalds did not make Linux because he was interested in selling it, but because he wanted an operating system he could experiment with. The first version of Linux was to simple to sell anyway. Linux would not have been possible without many people contributing. The more morally motivated FSF worked on the Hurd kernel. The Hurd kernel did not succeed because it did not deliver, being based on a too ambitious micro kernel design. The Minix kernel was available, but Tanenbaum was not interested in making it into anything more than a learning tool. Tanenbaum did not step up to manage all the contributions. Linux was available and Torvalds did step up to the challenge. Linux have, from its humble beginning, evolved into a kernel with a modular design facilitating contributions.
In the TCP/IP and OSI-stack case we see this story again. One grand vision, the OSI standard, failed because it was too complicated. Even if it was technically superior to TCP/IP it was not a working solution. TCP/IP was working and had been working for some years. Over the years the TCP/IP protocol stack have evolved and other protocols have been made at the application layer to implement some of the functionality present in the OSI standard. On the other hand, if TCP/IP was too simplistic it would not have attracted as large a following. TCP/IP did replace the more simplistic UUCP protocol. UUCP is much more cumbersome to use compared to TCP/IP because of its simplicity.
My opinion is that the Unix and Linux stories illustrates the importance of modular design and communicative code in distributed development common in FLOSS projects. Modular design and distributed development is not limited to FLOSS project, but in FLOSS project of some size it is a necessity. To build a modular application with easily understandable code require more work up front, but in the long run it is a great assess. The cost of maintaining software is usually much higher than the cost of first making the software, and it is easier to maintain good quality code. The Unix, Linux and Internet protocol stories also show that it is more important to have a simple working solution than to have a grand vision. There is a conflict of interest between modular design and to have a simple working solution. Modular design require more work up front. By designing a system with too much extensibility you risk never being able to deliver. This was the case for the Hurd kernel and for my plug-in framework. A balance between a simple working solution and modular design has to be struck.
In addition to the practice of sharing code there are other important social practices in the FLOSS community. The social practise of structuring a project around a piece of software is one example. It is possible to just give software to others without starting a project. The practice of listing important contributors in a credits file is another example. Many of these social practices are mentioned in chapter 5. In Figure 11.2 I have made a model of the modalities of signification, domination and legitimisation giving structure to the FLOSS community. The figure also show other social systems influencing FLOSS. The line are intentionally dashed to show that the boarder between the social systems are open ended.
Within the HISP network the participatory design strategy is important for the development of DHIS and even more for the translation of DHIS to a new context. It is important to seek user feedback throughout the design process. In Tigray we involved the users through the formation of a team to decide on data elements and reports. Most of the reports that this team decided on could not be used in a computer based IS. Regular users often need guidance throughout the design process to be able to participate effectively. Users often lacks a clear understanding in what is technical feasible. For this reasons I made significant changes to the reports decided by the user team, and even added and removed some data elements. I sought user feedback by asking the departments what they wanted the reports to contain, and by showing them the reports I had made.
PD focuses solely on the design of a system. If the design is isolated from the actual implementation of the software, there is good chance that the design obtained through user involvement becomes bloated and difficult to implement. User feedback should not only be sought throughout an isolated design phase, but should be sought after throughout the actual implementation of the system as well. If reality shows that some design decisions cannot be met, user feedback on the changed design should be sought.
On the FLOSS scene it is not uncommon for some of the actual users of a piece of software to be programmers as well as users. In these cases it makes sense to extend the term participatory design into participatory development. It is not necessary to seek user feedback for project where the actual users are also programmers, feedback comes to the project in the forms of patches, bug reports and feature requests. For projects where the actual users are not programmers it is unreasonable to expect users to be able to contribute patches or to give precise bug reports. Regular users can contribute with feature requests and give superficial bug reports, however. Regular users can also contribute with user support and user documentation. Feedback from regular users have to be actively sought after, and they generally need more guidance in communicating feature requests and bug reports.
To assure continuous user feedback it makes sense to develop an evolutionary prototype. It is much easier to comment on an actual running system compared to mock-ups. All FLOSS software are in a sense evolutionary prototypes, constantly changed at the same time as it is in active use. FLOSS takes small steps at the time, no grand releases after an extended period of isolated development. Throwaway prototypes can be well suited for experimenting with different solution to a difficult problem. Experimentation with different solution can be done in parallel and the most suited solution can be incorporated in the evolutionarily prototype. Throwaway prototypes are also useful for getting user feedback in the initial design phase.
Relating to my presentation of technology translation in section 2.3.2. FLOSS offers unique opportunities for translating software, both translation of the language and the functionally, making software more useful for a developing country. It also takes the term configurable to a new level. FLOSS give the control of the software to the user, and configuration of software can be done down to the source code level. Source code changes requires advanced computer knowledge and hard work, this is not an option for most individual users and small non-computer related businesses. For a country, however, this is indeed possible.
Three points was mentioned in connected with the presentation of technology translation:
This points are relevant whether the software is FLOSS or not, but FLOSS facilitate indigenous capacity building. It is in the process of customisation that the availability of the source code is especially relevant. See Figure 2.5.
DHIS is built to enable visual customisation. It is common in proprietary software as well as FLOSS software to enable customisation. If it was possible to do all the necessary changes to DHIS in the translation process, through customisations, then DHIS could be distributed with a non-FLOSS license. This has not been the case, however. Frequently there has been situations where source code changes were necessary. For context insensitive software like operating systems and word processors the customisations offered by the software is usually enough. For more context sensitive applications like DHIS the customisations offered is often not enough. In this cases it is a life saver to have access to the source code. The ability to change source code empower the people translating software, both those who do language translation and those who change the design and functionality of an application.
