Comments inline.

> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:africasource-l-
> [EMAIL PROTECTED] On Behalf Of Robert J. Chassell
> Sent: Thursday, May 13, 2004 5:48 PM
> To: Public Software Mailing List
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: [AfricaSource-L] Re: [PubSoft] An analysis of OSS thinking and
> assumptions within the context of the African programmer
> 
> "Guido Sohne" <[EMAIL PROTECTED]> writes,
> 
>    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 ...
> 
> Yet Sohne says
> 
>     African proprietary software developers ...  own market fails to
>     support and sustain them ....
> 
> Proprietary software development fails.  Nonetheless, Sohne makes a
> statement of preference:

Proprietary software development in Africa has difficulties however it does
not fail. Failure is the total inability to develop software.

If the company producing this software is still able to make money in spite
of the difficulties, then is has not failed. The market fails to support and
sustain them but the companies due to persistence and ingenuity as well as
the ability to weather hard times manage to avoid failure in a lot of cases.

This is a matter of relative difficulty. Developing software in Africa is a
difficult undertaking. Developing the software for free is a more difficult
undertaking. This arises because people who purchase free software are
expecting lower prices. Lower prices mean lower developer income.
 
>    ... 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.
> 
> But you cannot act on what you prefer when that alternative does not
> exist.

See above. Both alternatives exist. Both have difficulties. It may be
possible to combine them both to avoid some of the difficulties yet reap
some of the benefits.
 
> As a practical matter, for proprietary software to succeed, either
> 
>   * a government must be able to enforce economic restrictions
>      successfully; or,
> 
>   * secrecy must work well enough.
> 
> Few, if any, African governments can successfully enforce patent and
> copyright laws; they cannot enforce economic restrictions.
> 
> Because software has a low incremental cost of reduplication it is
> harder technically to restrict it than to restrict rivalrous goods.

Unlike the case in other countries such as yours, companies here do not rely
on legal protection as a means of survival. They rely on technical measures.


Let me examine the case of the most successful Ghanaian software company,
called SOFT. 

Their market share locally is perhaps 90% in the payroll market, 80% in the
point of sale market, 70% of the accounting software market. They experience
hardly any piracy for two main reasons:-

 - the software is difficult to install and to use without training and
support.

 - the anti-copying measures that they have in place are not yet
successfully broken by their customers. Perhaps one in a thousand has
succeeded, not many more than that.

This is not to say that they operate without difficulty. The figures above
may paint the picture of a very healthy company but they have their own
problems to worry about. These problems are part of the intrinsic difficulty
of developing software in Africa.

You state that:-
 
 "As for secrecy, there is no doubt that it works for a while, some of
 the time.  Software secrecy will be successful in Africa because so
 few will bother to reverse engineer binary code.  Also, software
 secrecy is easy:  just don't give out source code."
 
and
 
 "But software secrecy fails if a program is a success.  Secrecy is a
 way for losers to keep on losing."

However, evidence on the ground shows that software secrecy has worked well
enough to sustain a company for over ten years now. I do not believe that
this is the case of a loser.

It may be that with tremendous additional growth in their market share,
there will be a time when their technical circumvention measures are broken.
However, by that time, the company would have made so much money that it is
worth not taking the free software route.

The most relevant question this raises is: Would this company have made as
much money by releasing its software as free from the beginning? My guess is
no.
 
> Without effective governments that successfully enforce trade secrecy,
> patents, or copyrights, you cannot succeed with proprietary software.
> At least, not for more than a few years, and only if your programs are
> not worth stealing.

This is an incorrect assumption. Using a legal environment (and hence the
government) to restrict competition is not valid here since as you have
correctly pointed out, the environment does not support such strategies.

The presence of a legal environment for enforcing software usage in the more
developed countries has contributed to the companies there relying on that
as a means of protection.

The case of Vietnam, as Stefan Probst has pointed out before, suggests that
the reliance on the legal environment as a means for software protection
could be mainly present only in the Western countries.

> Indeed, to quote Sohne more completely,
> 
>     African proprietary software developers ...  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.
> 
> But a `gift' culture is not viable either, not as a way to make a
> living.  Sohne points out the key lack:
> 
>    ... 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."

It then becomes a matter of finding out the best way to make a living and
increase income to the point where participation in the 'gift' culture
becomes interesting and rewarding.

An increased consciousness in the market of the value of a software
development capability and the value of local production as opposed to
importation of technology will make it easier to develop software, whether
on a proprietary or libre basis.

This points to the need for software developers to work together to make
their situation and prospects better. After that has been done, they are now
better placed and more free to decide which 'fork in the road' to take. 

Before that point has been reached it is premature to choose one option or
the other. We must reserve the right to choose.

> As a practical matter, options are limited:
> 
>   * Because of the lack of effective government, the first option,
>     putting restrictions on sales, will fail.  At least, it will fail
>     if the software becomes successful.

Data from on the ground does not support this. Developing free software has
however proven to be more difficult, mostly because of the resistance of the
market to accepting it. 

I've tried hard to do this but the market does not yet properly understand
the need to support local technical development, how much more the mode of
actual development.

Failure is different from difficulty. It is possible to make things less
difficult than they are now.
 
>   * Because of poverty, the second option, living in a gift culture,
>     will also fail.  Software developers cannot stay alive without
>     selling something.

Yes. However, imposing free software on Africa will make this poverty worse
by removing the chance to develop proprietary software. This increases the
difficulty level.
 
>   ==>  Software developers need a third way.
> 
> Since they cannot successfully, over the long run, sell software at a
> higher than free market price, and since they cannot work `for free',
> software developers must redefine their work as selling services.

Agreed. It is interesting to at this point explain the business model of the
company that I cited. 17.5% of the purchase price of the software is paid
yearly as support/maintenance. 

The need for training and support is part and parcel of being able to use
the software they develop. Without this support and training, successful
usage of their software is not very likely. This is effectively part of the
technical measures that prohibit copying of their software, though it is not
a conscious part of those measures.

Selling software as services is one way in which OSS is suggested to a
software development business. However, this is not something that only OSS
is capable of doing and it is interesting to see that the software
development companies here, have out of necessity, evolved to use OSS ideas
such as this.

There are benefits to be had from combining both approaches and as mentioned
before the right to choose either approach is important.

> This means they must treat software as a community resource. It means
> they must treat their own skills and time as valuable products to be
> sold, rather than as inputs to something quite different, that is then
> sold.

Or both. I see no reason why both cannot be done.
 
> Developers need to become more like doctors or architects.  I expect
> this to be hard, but given the circumstances, this is the only
> practical alternative.

The analogy is not accurate. Architects build fixed assets that belong to
someone else. Doctors work on others who can never belong to them. 

The nature of these professions are fundamentally different from that of the
developer. For instance, there is no such person as a hobbyist doctor. Or an
architect who designs without caring if the buildings will collapse or not. 

The developer can always fix it later and expects the program to crash at
some point. It's entirely normal.

Developers can have the code and yet sell it to someone else. Why shouldn't
the developers have the right to choose what to do with their own time? 

To make developers behave like other professions will remove some of the
intrinsic benefits and flexibility inherent in the special nature of digital
goods. 
 
Thanks for your comments!

-- G.



---------------------------------------------
This service is hosted on the Infocom network
http://www.infocom.co.ug

Reply via email to