Date: 18 October 2005 11:20:26 PM
To: incom <incom-l incommunicado.info>
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 sohne.net]
Subject: An analysis of OSS thinking and assumptions within the
context of the African programmer
Hi,
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
incom-l incommunicado.info
http://mail.kein.org/mailman/listinfo/incom-l