Paid For Free Software to replace Entropic's ESPS/Waves products

Sprex here proposes and explains a new business model called Paid-For
Free Software, and initiates commercial exploitation of this business
model through a particular software development project, namely the
replacement of Entropic's ESPS/Waves signal display and analysis
environment, by an open-source software product.

Please understand how each role can contribute, 
determine whether and how you wish to participate, 
and follow the steps indicated for your participation.

If this works it will result in high-quality open-source software
being designed and built rapidly and economically by well-motivated
expert developers under the management of a competent manager,
providing documented user satisfaction to all process investors as
well as significant financial returns to the initial investors
(exponentially decreasing with delays in making the commitment).

Process Participants include these:
    Process Investors
    Developers
    The Administrator (Sprex, Inc.)
    The Project Manager (chosen by the Administrator).

Process Overview:

A specification is created through moderated discussions on a list and
posted by the Development Manager.  Process Investors attach funds to
the specification, putting the money in one of two bank accounts, this
one called the Input Account.  Early PI's get a large return on their
funds; later PI's get exponentially decreasing returns; all PI's get
the password for the current development snapshot. 

Developers are then led by their enthusiasm or by the funds building
up in the Input Account to contact the Project Manager to negotiate
terms and sign agreements for building or integrating selected
components.  The Project Manager selects and directs the Developers in
implementing the Specification as a Program; the PM may replace
unsatisfactorily performing Developers or renegotiate terms as
warranted by changing conditions.  Also the PM may find it necessary
to try to convince PI's to modify the way they have attached their
funds to the various parts of the Specification, so that the financial
impact of impossible-to-implement features can be reduced; however,
PI's can refuse, since it's their money and they can put it on
anything they want to.

As soon and frequently as possible current snapshot releases are made
available to the PI's to test, report bugs, and otherwise aid the
development process.

When the Program is declared complete by the PM, PI's have the
opportunity and obligation to detect and report bugs in the Program or
inadequacies of the Program w.r.t. the Specification.  When the bug
list for the Specification has been cleared for one month, or when the
PI indicates their acceptance of the Program, then funds are
transferred to the second account, the Output Account.

Funds in the Output Account are immediately made available for
disbursement to the Developers, PM, and Administrator according to
their negotiated contributions, multiplied by the ratio of the
accumulated Output Account funds to the Funding Completion Threshold
for the Specification.  (So for example, if the total contributions
have only attained 50% of the Funding Completion Threshold, then they
will get only 50% of their negotiated contribution).

When the Funding Completion Threshold is attained in the Output
Account, that is the time of Transfiguration.  Upon Transfiguration,
all debts are paid: all the Developers, Administrator, and PM are paid
off; the PI's also get their returns.  And upon Transfiguration, the
Program is made publicly available for free, thereafter to remain
under an Open Source license.  Later modifications and enhancements
will be treated as new and separate Specifications, which can attract
Process Investors, money, and Developers; the Administrator will again
choose a Project Manager (probably the same person), and the process
will cycle.

All disbursements from the Output Account are subject to a
minimum administrative fee, so disbursements smaller than that
minimum are cancelled.

Pricing Policy.  This is the toughest issue, since if a PI could
contribute even just a little bit, that'll help, but then noone wants
to contribute more than anyone else.  Briefly, we could have a
communist system or a democratic system.  In a communist system, the
rich contribute as much as they can, and the poor contribute what
little they can, and everybody receives the same thing.  In a
democratic system everyone contributes the same amount, which keeps
the poor people from using the Program until after Transfiguration.

Pricing Policy has to have a number of characteristics: The total
income must pay for the project.  The return ratio for the initial
Process Investors should be proportional to the size of the total
market value (total project income).  The contributions of academic
PI's should be half that of non-academic PI's.  The contributions of
PI's representing multiple users at one site should include a
full-price contribution for the first user, and a half-price
contribution for each additional user (if the base price is P, and N
users are at a site, then the price for that site should be P *
(1+(N-1)/2)).  Sliding projections can be made of the Funding
Completion Threshold (projected development costs plus PI returns) and
of the total market size subcategorized as to academic and
non-academic users, and as to initial and additional users.  From
these two projections, the base and discounted prices can be
calculated.

The number of sites with a given number of users is a noisy negative
exponential, about half as many sites have N+1 users as sites that
have N users.  The number of academic customers is about 40% of the
total number of customers.  With these numbers, we can convert
an estimated total number of paying sites N into an estimated
multiple of base price units B that the market will bear.
If all sites paid B, then the total income would be B*N.

However, since 40% of the sites are academic and pay half price,
the total income would be .6*N*B + .4*N*B/2 = 0.8*N*B.
This also assumes, incorrectly,
that all sites have a single user, but actually many have more than
one.  Given N sites, roughly N * 1/2^^M of them have M users, M>0.
The total income for all sites on this exponential is the
sum from M=1 upwards of B * N * (1/2^^M)(1+N/2^^M/2) 
which by my calculations is pretty close to B * N * 1.5.
The multiplier accounting for income due to additional users at many
of the sites, is 1.5.

With an academic discount multiplier of 0.8, and a multi-user
extra-charge multiplier of 1.5, the total income for N sites
given base price B will be about 0.8*1.5*B*N = 1.2*B*N.

I would estimate the number of buying sites at 20% of the Entropic
buyer population, since most of them will be happy with what they
have.  That means about 140 sites, or a total projected income of
170*B. 

Considering both effects together, 
(academic and non-academic sites as well as single and
multi-user sites), the total income should be 
0.8*N*B*1.5 + 0.4*N/2

Given Entropic's experience with ESPS/Waves, which has kept 4 to 8
engineers busy for around 15 years, the development costs of a really
high quality speech signal display and analysis system are probably
not less than 20 engineer-years; Silicon Valley costs to keep good
engineers on staff are about US$200k/year (assuming a salary of $80k
and a load factor of 1.5).  So that's on the order of $4M in developer
costs, plus 10% to the PM, plus 10% to the Administrator, plus some
percentage to be allocated as a return to the PI's, let's say 25%.

The exponential decline of return according to the sequence order of
the contribution should be not so fast that relatively-early PI's
still get significant returns; the projected returns should remain
high up to the point that there is enough to really pay for enough of
the development that the end is in sight.  It's a judgement call; I'd
say that the first 1/6 should actually get their money back or more,
and the next 1/6 should on average get half their money back.

A specification tree is gradually developed through discussions
mediated by an Administrator or designated Project Manager.  For
example, the first node in the tree is "speech signal display and
analysis system" with numerous daughter nodes including spectrogram,
formant, and pitch-track generators, command interpreter,
record/playback GUI and commandline programs. 

Process Investors are users with need, money, and vision.  They attach
their money to a specification that meets their needs, as early as
their vision convinces them to bet on the Process.  Their signature on
the PI Agreement is obtained and their money is deposited into the
Input Account.

When the PI accepts the software implementing a Specification, or
alternatively, after completion is declared and the bug list is
cleared for one month, then the funds attached to the Specification
in the Input Account are transferred to the Output Account
for disbursal to the Recipients.

  Your job is to attach money to a product specification (or parts thereof)
  to generate bug reports for the work as it is in progress,
  to indicate your acceptance when you are satisfied with the result.
  
  The commitment time/date of record for your contribution is the
  time/date that it hits the project's Input account.
  Your bug reports go into a bug list for the project.  


 
Copyright © 1999
Sprex, Inc. 
All rights reserved.
Last Modified: October 31, 1999.