Message 02941 [Homepage] [Navigation]
Thread: oxenT02941 Message: 1/1 L0 [In index]
[First in Thread] [Last in Thread] [Date Next] [Date Prev]
[Next in Thread] [Prev in Thread] [Next Thread] [Prev Thread]

[ox-en] FOSS and the African programmer [u]

Posted to the Incommunicado list by Guido Sohne <guido> from Accra/Ghana, in response to a mail from South Africa in which the writer proposes to replace the concept of open source with 'open choice'. /Geert

Date: 18 October 2005 11:20:26 PM
To: incom <incom-l>
Subject: <incom> FOSS and the African programmer

I posted this to the Uganda LUG and to FOSSFA about a year or two ago. I can't remember when but I have the plain text file and I thought in context of the FOSS/Africa thread, people may be able to poke some holes into it. I think it can be improved.

The basic recommendation is that Africa adopt FOSS and Microsoft simultaneously. It's the best way to contain MS in Africa at this point. The either/or option will result in more losses than gains.

-- G.

From: Guido Sohne [guido]
Subject: An analysis of OSS thinking and assumptions within the context of the African programmer


I've been doing some reading and thinking to see how my ideas of recommeding a dual strategy for Africa that includes both free and proprietary software hold up in light of the existing literature. Specifically, I have been reading "The Magic Cauldron", a paper written by Eric S. Raymond that "analyzes the evolving economic substrate of the open-source phenomenon."

While I cannot reproduce the entire article here, I have decided to take portions out that will help me explain my position. I have broken these arguments into sections for your convenience.

I would wish to add that although this is a long email, it is by no means exhaustive or conclusive, rather, it was all that I was capable of comfortably writing within a single sitting.

1) Inappropriate Assumptions

In section 2, entitled "Beyond Geeks Bearing Gifts", ESR summarizes a previous paper of his, "Homesteading the Noosphere" as below:-

"[HtN] posited that gift culture behavior arises in situations where survival goods are abundant enough to make the exchange game no longer very interesting; but while this appears sufficiently powerful as a psychological explanation of behavior, it lacks suffiency as an explanation of the mixed economic context in which most open-source developers actually operate. For most, the exchange game has lost its appeal but not its power to constrain. Their behavior has to make sufficient material-scarcity-economics sense to keep them in a gift-culture-supporting zone of surplus."

Gift culture behaviour is a model that ESR developed to explain the motivations behind OSS programmers that seeks to explain code contributions by developers by postulating that normal economic motivations are overridden, in a sense, by the desire of developers to increase their status and standing amongst their peers.

The main argument seems to be that OSS developers are engaged in an alternative valuation basis for economic exchange. Instead of money being the prime motivator, the (intangible) currency of respect, status and standing takes center stage. For the typical African developer, this does not hold true for two reasons that I will explain below.

The first problem is that the situation of the African programmer is not one where "survival goods are abundant enough to make the exchange [of cash for services] game no longer very interesting."

The second problem is that there are so few African developers, and so few of them know of each other, that the currency of valuation for software contributions as the esteem and respect of one's peers does not hold.

One might say that the esteem and respect that a developer could be said to crave can be gotten from the global pool of developers. However, I believe this is not entirely true because the African developer and the developer in the developed world are not peers.

They have not had equivalent training, they do not face equivalent economic situations, they do not command the same income, and they have not accumulated the same amount of experience (since the African developer lives in an environment bereft of technology - Africa is almost by definition, the place where technology is most scarce). This is not what the meaning of 'peer' is.

2) Software does not *have* to be free

ESR in the section entitled "The 'information wants to be free' myth" explains why it is a mistake to assume that a zero marginal cost of production for informational goods means that the price of such goods must also be zero.

He accomplishes this by reasoning through examples where information has value precisely because the information is scarce, such as when the information is on where Mobutu stashed all his billions in a hole in the ground, or when the information is a username/password combination that can be used in an ATM.

Furthermore, in the introduction to the whole paper, ESR states that:

" the discussion and advocacy of open-source development in this paper should not be construed as a case that closed-source development is intrinsically wrong, nor as a brief against intellectual-property rights in software, nor as an altruistic appeal to `share'. While these arguments are still beloved of a vocal minority in the open-source development community, experience since the Cathedral and the Bazaar has made it clear that they are unnecessary."

In recent exchanges with Richard Stallman, we have debated the need on whether software has to be free, or whether this should be at the discretion of the commissioner of the work (the client), or of the executor of the work (the developer).

I believe the comments of ESR in this regard, make it clear that it is not necessary to mandate that all software should be free, but instead the OSS model and processes themselves lend a natural advantage in the marketplace that will win in the long run.

This matches my thinking that the market should choose what it prefers. Be it free software or be it proprietary software. In such a case, the developer, should focus on deriving economic value, rather than on following the politics that are currently in vogue.

The dual strategy that I propose for the technologization of Africa with respect to the software industry, and by extension the strategy recommended for African developers, embodies this reasoning by necessity. The Stallman position, and by extension, the FOSSFA position, that only free software should be considered going forward, is IMHO, a big mistake.

3) Absence of a viable community

The absence of a viable community of FOSS developers in Africa is the biggest weakness of the FOSS movement in Africa. This is because the availability of a pool of developers, testers, documenters, translators etc is drawn from the community.

In the United States, a population of approximately 250 million people results in a technical community (both proprietary and FOSS) that is about 2 million people strong. In India, there are about 750,000 software developers against a population of 1 billion or so people.

In Africa, we instead have under 50,000 software developers as against perhaps 1 billion people. The most radically conservative estimates, which were made by myself, result in less than 500 developers against 1 billion people.

At this point, I should note that the difference is in my definition of the word 'developer'. I define a developer as someone seasoned, experienced and talented rather than someone who is learning, or on the way to becoming what I call a 'world class' developer. A developer can write a compiler, or a kernel, or a device driver. Writing a front end to the database does not make you a developer, however writing the database engine itself makes you a developer.

This absence of community, now that it has been defined and explained, can now be used to throw some light on why popular models for OSS will not work in Africa without conscious change and/or adaptation of the models.

One model, is entitled, "The Cisco case: risk-spreading" in the ESR paper. The model explains how the presence of a community spreads the risk of developing and maintaining software across the technical community. This is often cited as an advantage of OSS, where the failure of a vendor does not have much impact because the software is developed in a distributed fashion.

In the African context, the absence of a viable community poses serious challenges for this model, unless one postulates that the software will not be developed in Africa. However, my thinking is that if software is not developed in Africa, then no progress has been made towards increasing the capacity and depth of the African software development industry as well as the overall technology position of Africa.

Various other models for OSS business sometimes operate by assuming that the increase in market share that will be derived by going OSS, or developing a product as OSS, is by itself a fundamental source of value. One such model is the RedHat model, where a company gives away everything for free, and in doing so, gains access to a much larger market than it could otherwise have been capable of reaching.

However, all these models, operate on the assumption that there is an undisclosed source of software development, where the software develops itself, by virtue of the community. Without our own development community in Africa, we will not be able to provide the input that creates this value and will therefore only adopt the technology as users and resellers rather than creators.

While this is fine for the non-developer, this is a strategy that spells doom for the African software industry, because it will remain at best marginalized, even within its own borders of influence. This is presently the problem facing African proprietary software developers as well. Their own market fails to support and sustain them, instead preferring to purchase externally produced goods. This is a strategy that guarantees continued underdevelopment as software continues to gain in importance as a determinant of economic power and value.

4) Open versus Closed

In his section, entitled "When To Be Open, When To Be Closed", ESR posits the following discriminators as favouring an OSS development model instead of a proprietary software development model. His reasons are given in quotes, followed by a short analysis.

"(a) reliability/stability/scalability are critical"

In the African case, the first reason is almost never critical. This is because failure from power outages, from operator negligence or for malicious reasons are much more common as cases of software failure than the software design or construction itself.

If it is hard to keep the power grid going, the telephone system running, the road system paved and pothole free or it is almost impossible to call from a mobile phone network to another network, then what importance should reliability, stability and scalability have?

"(b) correctness of design and implementation cannot readily be verified by means other than independent peer review"

In the context of the absence of a community of African software developers, this criteria becomes extremely unimportant. To put it mildly, if there is no one to review the software, does it matter if that review is conducted internally, or from independent peer review?

Moreover, if that review is conducted outside of Africa, then there is zero impact on the African decision to go OSS or not - since the production is not in Africa, what does it matter the mode of production?

"(c) the software is critical to the user's control of his/her business"

In the majority of African businesses, software or even technology, does not play much of a role.

For example, in the banking sector, in most of Africa, the clearing system for payment is still very much a manual process. Where the banks are computerized, this only affects their internal operations, there is little automation of interbanking or clearing operations, unlike the case in the more developed countries.

Therefore, it is clear that this does not hold for the vast majority of Africans. Software is not important or critical at all to the majority of Africans in the business context.

"(d) the software establishes or enables a common computing and communications infrastructure"

This is an area that clearly applies to the African situation. Africa has become increasingly reliant on the Internet and keeping this infrastructure common to all is a clear priority going forward.

"(e) key methods (or functional equivalents of them) are part of common engineering knowledge"

This is also an area where it is advantageous for Africa to adopt OSS software and to create such software. The key phrase here is 'common engineering knowledge'.

What is common engineering knowledge in the developed countries is clearly not common engineering knowledge in Africa - how else would we be able to explain the low level of technologization in the African continent, or the fact that almost all technology utilized in Africa is imported. If it were common knowledge, surely, we would produce more than we are producing now ...

In order to catch up with the rest of the world, it is critical that Africa adopts OSS and uses the source code to rapidly adopt the knowledge that is embodied in the code itself.

5) Conclusion

It is clear to me that there are compelling reasons to use OSS software in the African context. However, it is not at all clear that exclusive use of OSS is the best strategy for Africa due to the different underlying circumstances and resultant assumptions that differ between the African context and the more widely studied global context.

incom-l mailing list

Contact: projekt

Thread: oxenT02941 Message: 1/1 L0 [In index]
Message 02941 [Homepage] [Navigation]