Application development strategy - rev.0.1

Application development strategy - rev.0.1

Post by Mario Miyoji » Mon, 23 Aug 1999 04:00:00

[ open_source_development 10K ]
                Open Source Application Development Strategy - rev.0.1

1. Introduction

I have been rereading Richard Stallmans's `GNU manifesto' an understood
that he was envisaging a world where programmers could freely exchange
source code, and that the people at large should be able to obtain
software at low cost, not necessarily free. The `GNU manifesto' has
generated a successful body of software, but I do not know whether its
momentum and appeal will continue forever. Stallman's original action,
in summary, was caused by greedy corporations hoarding source code and
charging licenses to use the binary at high prices, acquiring wealth and
power at the expense of the rest of the world. He saw a serious social
problem building up, so he decided to counteract that trend.

I am proposing a way to address the original problem that gave way to
the `GNU manifest'. A few months ago, it might have been too bold, but
now, I think there is a possibility to be accepted by the world society.
This idea, if implemented, will produce profound changes in the way
people view industry and corporations. It will eventually ripple into
all industries. Let us introduce it initially into a subset: the
application software development industry.

2. Example

2.1 Real situation

Let us take, for example, the Opera browser, developed by the Norwegian
company OperaSoft. This software has received positive opinions from
everybody, due to its good design. It has two problems, from the Linux
users' viewpoint: its license costs $35.00, and it does not run under
Linux. The reason for being so is that the company wishes to maintain
the source code proprietary, so it is having difficulties to generate
the Linux version under a traditional contract due to cost. I have no
idea how many licenses Opera has sold, but I don't think that they sold
many millions to Windows users, because Internet Explorer and Netscape
are available at zero price. I paid $35.00 for the Windows version,
which I do not use, as an incentive for their Linux version. Let us
assume that they sold half a million licenses so far. Then, they had a
revenue of $17.5 million in license fees, with which they are paying
their personnel and the contractors for porting to other platforms.
If the contractors for Linux were being well paid, I imagine that we
would have a working Linux version for the Opera browser already.

2.2 Imaginary scenario

Now, imagine that the OperaSoft company had taken a radically different
path two years ago. Imagine that they had opened the source to the
Internet, invited the entire world to participate in adding features and
removing bugs from their initial design, and that they allowed a copy to
be downloaded at one dollar initially and at twenty cents per upgrade.
Assuming that there are about 100 million computer users in the world,
I imagine that half of them would risk one dollar to have a better
browser, without much thinking. I would. In this case, Opera would have
a revenue of $50 million. To encourage the worldwide open source team to
continue contributing to this and future projects, Opera could put aside
let us say, 30% of this revenue to reward the contributors. If 1000
persons contributed equally to the project, then each person could earn
15 million / 1000 = $15,000 for having participated in the project so far.
However, in every project of this size, there will be major contributors
and minor contributors. The project leader would then do an arbitration
and find that the largest contributor deserves 10% and the smallest
contributor deserves 0.02% of the pie. In this case, the major contributor
would receive a reward of $1.5 million, and the minor contributor would
receive a reward of $3,000. All the other 998 contributor would receive
some value between these two. Because there are too many people involved,
then the project leader would play it safe, and expose to the 1,000 team
members the criteria used to reach those reward values. If the leader does
not do that, then he(she) might be risking to lose the respect of the
team members, who would no longer contribute, until the injustice is
undone, or until the leader be replaced by someone they trust.

Suppose that all 50 million users decide to buy the first upgrade, then
they will pay $0.20 x 50 million = $10 million. A portion of this will be
distributed to the contributors in the development, too.

2.3 The differences

Essentially, two parameters stand out in this hypothetical story:
(1) A much lower unit price to make it attractive to average consumers,
(2) No need to hire regular employees.

Only one or a few persons having the initial idea would be required to
arbitrate what changes will be inserted in the next version to be made
public, and manage the money. An immediate consequence if this story
became reality, is that OperaSoft would have created 1,000 jobs without
painful admission interviews and no costs up front. The company had a
lot more earnings than in the traditional model, and the product came
out for practical use faster, for all platforms. Would it beat Internet
Explorer and Netscape in quality and time to market? I bet it would.
I do not know the reasons for the Mozilla project taking long to generate
a product, but I think one of them is a lack of financial incentive.

In my idea of how it should be, there would be no traditional company as
middle entity. There would be the development project as the long-lasting
entity, and no owner, just like the Apache, or the Linux projects. The
project leaders and contributors would gravitate around the project, but
would participate in it as long as they have any contribution to make,
otherwise they are allowed to gravitate away to other projects or personal
matters, no questions asked. The life of the project is then dissociated
from the lives of the persons working on it. A meritocracy indeed.
Therefore, in the case of the example, if there was a revenue of $50 million,
the entire value will be justly distributed to all direct and indirect
participants in the project, and the information will be OPEN to all
concerned, to guarantee continuity.

3. Main component for implementation in real life

One US dollar or twenty cents are much closer to the cost of a bank check
or credit card transaction cost, than a regular commercial transaction.
I do not how much about credit card transaction costs; let us assume  
that it is ten cents of a US dollar. Banks and financial houses still
tolerate occasional low-value transactions because the average value
is much higher. In the case of the above hypothetical sales strategy,
the average value will be less than one dollar, against which banks and
credit card companies may raise a barrier.

To harmonize the real world with our hypothetical development methodology,
we would need to create a trusted entity, that I will call OSB (Open
Source Bank).

The majority of functions of the OSB would be similar to those of a
regular commercial bank: maintain accounts, transfer values among accounts,
accept deposits, honor withdrawals, interact with other banks and
clearinghouses, issue account reports, etc.

The OSB needs to be radically new in the following aspects:

1) Some of its accounts are not corporate accounts, but project accounts,
   that is, they handle money related to open source projects.

2) It will handle small values per transaction, because those will
   the basis of its operation.

3) It will interact closely with open source project leaders, regarding
   distribution of open source earnings to project contributors, who will
   have personal accounts in the same bank.

4) The project accounts will be open to all concerned, i.e., the leader,
   the contributors, perhaps even to the potential buyers of products.
   This will severely reduce the possibility of frauds. Everybody will
   know at any time how many sales were made so far, how much has been
   distributed to contributors, to the leader, to the bank, taxes, etc.

With the concept of open source project account, projects may survive
through many generations of leaders and contributors. Projects would have
longer lives than small enterprises, especially because they will become
stronger as they attract more contributors, who will introduce features
to grant it a longer life.

Projects without a perspective of growth will not live long enough to
open an account in the OSB.

I have considered creating a new currency, which would be called OSC
(open source credit, or currency) to dissociate values from the US dollar,
but do not see an immediate necessity for this concept. It might
facilitate the valorization of products and contributions in countries
outside the US, but I am not well versed in international economy. If
anyone knows better, please comment.

4. Potential consequences of implementing this proposal

1) Good ideas become products quickly with highest quality without
   traditional corporate intervention.

2) Motivate and sustain a large pool of contributors in the whole world,
   some of them dedicated full time to open source projects.

3) Persons with an Open Source Contributor credit card will be recognized
   all over the world.

4) A new important role will emerge: that of Open Source Banker, due
   to the importance of the OSB to maintain the profile and stability
   of open source projects.

5) Projects that cannot get traditional funding but have social value
   will be able to jump start.

6) People with computer knowledge will find on the Internet a site
   announcing open source application projects classified by area of
   health-oriented, mission-critical, industrial, research, networking,
   entertainment, etc. In this site, there will be no discrimination
   regarding computer language, operating system, dbms, visa status,
   location, education level, availability, anything. All of them will be
   telecommuting, so participants can be on several projects simultaneously
   depending on their interest and availability, and no questions will be
   asked when you join or quit a project. You can reuse a programming
   tecnique you invented as many times as necessary, and projects will pay
   for it if the contribution is accepted.

7) Large projects requiring improvement through research in depth will be
   possible, because graduate students could earn titles with research work
   for this purpose. The choice to contribute will be from the researcher
   and not his(her) advisor. If there is a payback during the researching
   period, it will be as good as a traditional research grant.

8) Major contributors may evolve to become project leaders, and project
   leaders may become contributors to other projects.

9) Experienced project leaders may become coaches to project leader

This document underwent a revision on August 22, 1999, based on comments
from reader Michael Fowler in comp.os.linux.misc.

I request further comments from the community at large.