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. The purpose of this is to help to make a decision as to
whether to support this effort or not.
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.
