Very Computer

[ open_source_development 9K ]
                Open Source Application Development Strategy

Over the years, since the introduction of computers into human
society, the costs of developing hardware and software have
changed dramatically.

Hardware: mainframes were expensive items and only major enterprises
could afford them. Currently, home businesses can afford more than
one computer.

Software: was very limited in the beginning, then became a highly
specialized product, costing so much to develop that only copies on
specific computers were sold and high maintenance fees were charged.
With the creation of microcomputers, software prices decreased
significantly. Prices changed significantly again with the introduction
of the open source movement: GNU tools, Linux, free BSD, Apache, the
Internet as a whole, etc. But this change will only be complete
when we find a sustainable way to develop better applications that
will run on the low-cost platforms. We live in a real world, full
of greedy corporations, so we need to find a way to develop high
quality software helpful to human society, while make a living in
the process.

I have been rereading Richard Stallmans's 'GNU manifesto' to better
understand its implications. His endeavors have been toward a society
that would be able to enjoy software at low cost, not necessarily free.
The GNU manifesto has generated a successful body of software, but I do
not know whether anything will maintain its momentum and appeal forever.
Stallman's original problem, 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.

What I am going to propose is a way to address that  original problem,
which will produce profound changes in the way people view industry and
corporations in the current world. It will eventually produce changes
in all industries, but it can be more easily started from a subset:
the people-related software development industry.

Let us start by discussing a concrete case: the Opera browser, developed
by the Norwegian company OperaSoft. This software has received positive
opinions from everybody, but 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 imagine that they sold half a million
licenses; then they received $17.5 million in license fees, with which
they are paying their personnel and the contractors for porting to
other platforms.

Imagine that the OperaSoft company had taken a radically different path,
and that they had opened the source to the Internet, invited the entire
world to participate in adding features and removing bugs from their
initial good 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. In this case, Opera would receive $50 million. To
encourage the worldwide open source team to continue contributing to
this and future projects, Opera could put aside 30% of this revenue
to reward the contributors. Let us say that 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. Let us say
that all 50 million users 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.
Essentially, two parameters stand out in this hypothetical story:
much lower unit price to make it attractive to average persons,
and 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
created 1000 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 view, the main difficulty to implement this idea is the following:

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. Another thing that annoys
me is that the arbitration regarding how much of the revenue would be
distributed among the contributors would still be with a corporation,
which would permit unfair handling of the money.

I have been thinking about possible solutions to this dilemma. The more
I think, the more I get convinced that we need to create a new trusted
entity, that I will call OSB (Open Source Bank).

The basic functions of the OSB are mostly similar to 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 will 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, regardless
   of the persons who lead it, or contribute to it.

2) It will gladly handle small values per transaction, because those will
   the basis of its operation. Maybe it will issue credit cards involving
   low limits especially for e-commerce acquisitions.

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; bad projects will not even open an account.

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 a real necessity for this concept. I thought 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.

Possible consequences of implementing this idea

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 fully dedicated to open source projects, as a way of
   life.

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
   interest:
   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.

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
   candidates.

Every day I think about this direction, it gets stronger, and I am aware
that many ...

read more »

Quote:>In my view, the main difficulty to implement this idea is the following:

>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.

It is indeed the case that the costs of collecting a whole lot of
little transactions together can be substantial.

It would perhaps be a Cool Idea for 40,000 people to chip in $2 to pay
a particular developer to Do Something Useful.  Unfortunately, if they
all sent out cheques for $2, that represents a Big Pile of Cheques to
take in to the bank.  

The poor developer would average 200 cheques a day, and would wear out
his hand if he signed them manually.  And would risk "tennis elbow" if
he used a stamp.  And the administrative costs would add up in other
ways.

There does exist an agency, <http://www.kagi.com/>, that does
"clearing house" tasks, particularly to handle payments for
"shareware."  Their service has proven useful particularly to people
that live in foreign countries, as the costs of doing currency
translations often exceed the price of a typical shareware package.

Lest people accuse this of irrelevance, see
<http://www.kagi.com/FAQs/Donations.html>, which indicates that they
*do* handle contributions to non-profit organizations.

It looks like the Kagi folk take off a (variable) percentage that gets
as high as about 15% of payments received to cover their
administrative costs.  One could quibble about a percent or two here
or there; the rates seem not outrageous.  

Running a "not-for-profit" alternative to Kagi could result in shaving
off a few percent of costs that they take as profits; I frankly don't
think there's too much merit in putting in the effort to found and run
such an organization.

Long and short is that that does represent a clearing house mechanism
that could simplify the handling of "large numbers of fairly little
payments."

BUT.

That doesn't represent the *real* problem.

The real problem is that of having organizations be convincing that
they merit receiving payments.

I'll pick on Opera for a moment just for the sake of having an example
to cite.

They have successfully shown that they are quite competent at creating
a Win32-based web browser.  And I'd have no trouble agreeing with the
notion that they have staff on hand that can transform money into
"useful Win32-based Opera upgrades."  

A "strategy" whereby money was voluntarily sent to them to support
upgrades of "Opera for Windows" would have the merit that they're
clearly competent at this.

Unfortunately, they have *not* shown that they are able to create a
UNIX-based web browser, or, quite frankly, a browser for any platform
other than Windows.

The place where your proposal falls down is on the "political" side;
what happens if 10 million Linux users each send in $2, adding up to
$20M, and then do not receive a browser in return?

--> No individual has risked more than $2

--> BUT.  

    A "clearing house" that makes the decision to allocate $20M to
    OperaSoft, which does not then result in them producing the
    software, will risk Big Trouble either from nonconfidence its
    board of directors, or, worse still, in people deciding that it's
    Dumb to send them money.

The exact same issues could be directed at the Mozilla project which
has not yet had a "production" release.

The notion of rewarding some based on the later contributions of
others seems like a "shell game" to me; you can play all sorts of
arbitrary games with "later contributions," but that seems rather
dubious to me.  The benefit should be that the software is useful.
--
Rules of the Evil Overlord #75. "If my advisors ask "Why are you
risking everything on such a mad scheme?", I will not proceed until I
have a response that satisfies them."
<http://www.eviloverlord.com/lists/overlord.html>

Quote:> Let us start by discussing a concrete case: the Opera browser, developed
> by the Norwegian company OperaSoft. This software has received positive
> opinions from everybody, but 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 imagine that they sold half a million
> licenses; then they received $17.5 million in license fees, with which
> they are paying their personnel and the contractors for porting to
> other platforms.

> Imagine that the OperaSoft company had taken a radically different path,
> and that they had opened the source to the Internet, invited the entire
> world to participate in adding features and removing bugs from their
> initial good 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. In this case, Opera would receive $50 million. To
> encourage the worldwide open source team to continue contributing to
> this and future projects, Opera could put aside 30% of this revenue
> to reward the contributors. Let us say that 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. Let us say
> that all 50 million users 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.
> Essentially, two parameters stand out in this hypothetical story:
> much lower unit price to make it attractive to average persons,
> and 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
> created 1000 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.

(a) release source code on a ``semi-open'' licence -- something
which is similar of OS, but not quite. For example, they could
allow people to use the code for free for non-commercial purposes,
but if they want to use it commercially, they must pay. They could
also stipulate that any software released under this licence would
automatically become released under the GPL after a time delay (say
3 years); the idea of this would be to guarantee that the software
would eventually become OSS, therefore there would be no risk in
a company using it, only to find the developer dropping it after
a while.

(b) Invite the OSS community to contribute code to the software
product, in a form compatible with the licence in (a). (Presumably
LGPL would be compatible). Further, state that when the company
has its IPO, there will be free shares given to people who have
contributed software to the product.

Some possible problems:

* would the OSS community accept a time-delayed GPL licence?
(consider the controversy regarding the old Qt licence).

* would people trust the IPO commitment?

--

--
Integrated Information Solutions    http://www.logosnet.net
SmartWare 2000 PLUS!              You've tried the rest!

Quote:>* would the OSS community accept a time-delayed GPL licence?
>(consider the controversy regarding the old Qt licence).

--
"It's not about 'Where do you want to go today?'"; "It's more like,
'Where am I allowed to go today?'"

--

Mario Miyojim

from that later. But this recognition does not occur with everybody, only
a
few major contributors. What I am proposing will allow the project (not
the
person or company who owns the project) to reward at least with money
the actual contribution that each person has given, without losing the
right
to receive other benefits, such as social recognition, better jobs, etc.

Mario Miyojim

Something that 4000-odd years of recorded history has shown us amply
well is that this represents a political process that will attract
people with a desire for power.  
Whomever controls the:
a) Policy,
b) Signing of cheques,
c) Determination of how an assessment of the "actual contribution" is
  done,
will control the money.

Centralizing this has the merit that if you have people of "god-like"
morality and wisdom, things are far more efficient than they are if
individuals stumble around doing their own thing.

The old canard about "Absolute Power Corrupting Absolutely" comes into
play here, causing this to Not Work Out Well.
--
"I think it would be great if MS would make VB the favoured language
for Palm PC's.  Then they'd have a shaky, bloated, slow OS running the

Quote:>I am not proposing to create a new entity to satisfy the needs of
>traditionally structured companies.

Quote:>The Open Source Bank basically would be in my mind, a database

Quote:>set up in such a way as to receive electronic transactions whenever
>anyone downloads a copy of a software application for normal use.

Quote:>It will be an e-commerce transaction, with minimized cost.

Quote:>What I am expecting to receive from the net are practical suggestions on
>how to set up such a database, maybe issue special credit cards so that
>even people who do not have regular 'credit standing'  can afford to buy
>open source applications using this scheme.

or

b) A way to help sponsor the *development* of free software
applications?

I suspect that you're referring to the former; that is far more
consistent with the notion of "tiny transactions" to "buy
applications."

Quote:>That is why I am talking about a new kind of trusted entity. I would
>expect that some people who adopted the open source philosophy will
>feel the responsibility, challenge and advantages of being an Open
>Source Banker, to come forward with practical solutions to the
>problem, or with alternative ideas to make it practical.

Quote:>I thought that perhaps one dollar and twenty cents could be considered
>too little to deserve attention. Then, why not five dollars  for
>the first purchase and one dollar for upgrades? My proposal is not
>complete yet, that is why I am asking for support of the community to
>make it practical.

Debian consists of on the order of 3000 software packages.

The "nominal" licensing fee that you propose would result in the base
pricetag for a full installation of approximately $15,000.  Those that
track the "potato" release would then wind up paying out about $20 per
day just for the cost of upgrades.

No, thank you very much...
--
It is better to have 100 functions operate on one data structure than 10
functions on 10 data structures.
-- Alan Perlis

Chris Browne,
    Thank you very much for your time and thinking given
to my utterly incomplete scheme.
    Would you mind trying to rewrite the proposal, so that the
relevant points you have raised  be solved. Look at it as a
challenging software project, and imagine that the future of
open source programmers depends on how we structure these
ideas. This time you would be programming the behavior of
people in society, not only computer devices. If the resulting
set of ideas does not completely overcome the huge opposition
that you predict, it will be closer to the original goal. You
could insert suggestions of starting the OSB with what kagi.com
is doing, for example.
    You did not say that the idea is impossible; so, I believe there
are ways of removing the impractical aspects of the proposal
and make it become an initial blueprint for a wider audience to
read and comment.
    There are other initiatives from companies toward open source
developments, but I think they lead to less flexible models. I might
be wrong, though. Any untested method is painful to bring forth,
but you know that not everything has been invented yet.
    I am attaching my most recent version of the proposal, which is
still poor in many aspects.

Mario

[ Open_sou 14K ]
                Open Source Application Development Strategy - rev.0.2

1. Introduction

I have been rereading Richard Stallmans's `GNU manifesto' and 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 some common sense
reasoning and conclude that the largest contributor deserves 10% and the
smallest contributor deserves 0.02% of the pie. This distribution criteria
and all the relevant quantities (total, contribution description, values
assigned to each individual, etc.) would be published on the project home
page, subject to revision by all concerned. If there are conflicts of
opinion, they will have to be solved before actually doing the partition.
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.
The contributor community has the power to accept and reject the project
leader, so there is a balance of power built into the system. Besides, if
the leader does anything really nasty, the open source developer community
would probably be able to trace him(her) more efficiently than the US
Justice Department in any part of the world. If the money partition reaches
a successful conclusion, the major contributor would receive a reward of
$1.5 million, and the minor contributor would receive a reward of $3,000,
in our hypothetical case. All the remaining 998 contributors would receive
some value between these two, proportional to his(her) real contribution.

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 would be
distributed to the contributors in the development, periodically.

2.3 What will be changed

Major characteristics 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: lower administrative overhead.
(3) A software of much better quality is available to anyone who wants
    to improve it. The higher quality would not be attained in the
    traditional way.

Only one or a few persons starting the initial design would be required to
arbitrate what changes will be inserted in the next version to be made
public, and later, manage the gains. The company created 1,000 jobs without
the painful admission interviews or 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 (open source) project taking
long to generate a product, but I think one of them is a lack of financial
incentive; many people capable of contributing cannot afford the time to
do it, because they have to do other things for a normal survival.

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 project accounts, that is, they keep track of
   money related to open source projects, not belonging to a particular
   company, or person. These accounts belong to the contributors, and
   will be managed by the open source banker and project leaders, who will
   make the data available to all concerned in each project. A person
   who once contributed to a project will continue having rights of access
   to the data even if he/she migrates to other projects or abandons the
   open source activities. Contributing to open source projects means having
   access to open project accounts; this is fair.

2) It will handle small values per transaction, because those will
   the basis of the bank 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 data 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.

In my simplified view, an OSB would be a data bank installed on a Linux box,
with a few people managing it. Initially, it would not have a counter for the
public, and would do all transactions over the net. I expect people on the
net who have knowledge about the financial system to provide details on how
a minimal banking facility could be set up. An OSB is a new kind of bank,
with different rules and much lower operational overhead. Maybe an existing
small bank could be chosen to adjust its rules to the OSB needs.

With the ...

read more »

Quote:> Thank you for the reasonings. For a single contribution of this amplitude,
> my posting was worthwhile. It gives me ideas to improve my proposal and
> make it more acceptable to the real world.
> In the meantime, I will clarify some of your relevant questions.
> I gave OperaSoft as just a concrete example to facilitate explaining my
> proposal. I am not proposing to create a new entity to satisfy the needs of
> traditionally structured companies. The Open Source Bank basically would
> be in my mind, a database set up in such a way as to receive electronic
> transactions whenever anyone downloads a copy of a software application
> for normal use. It will be an e-commerce transaction, with minimized cost.
> What I am expecting to receive from the net are practical suggestions on
> how to set up such a database, maybe issue special credit cards so that
> even people who do not have regular 'credit standing'  can afford to buy
> open source applications using this scheme.

--

Quote:>Another, similar, way to fund and OSS project would be for a company
>to:

>(a) release source code on a ``semi-open'' licence -- something
>which is similar of OS, but not quite. For example, they could
>allow people to use the code for free for non-commercial purposes,
>but if they want to use it commercially, they must pay. They could
>also stipulate that any software released under this licence would
>automatically become released under the GPL after a time delay (say
>3 years); the idea of this would be to guarantee that the software
>would eventually become OSS, therefore there would be no risk in
>a company using it, only to find the developer dropping it after
>a while.

Which is to say that nothing new is needed to do things this way,
merely that people use schemes already in use.

Quote:>(b) Invite the OSS community to contribute code to the software
>product, in a form compatible with the licence in (a). (Presumably
>LGPL would be compatible). Further, state that when the company
>has its IPO, there will be free shares given to people who have
>contributed software to the product.

>Some possible problems:

>* would the OSS community accept a time-delayed GPL licence?
>(consider the controversy regarding the old Qt licence).

Quote:>* would people trust the IPO commitment?

In short, no, there are good reasons *not* to trust such a
'committment,' particularly if it is not set up as a justiciable
contractual obligation from the word "go."

Of course, heading back to the original claim:
   "Another, similar, way to fund an OSS project would be..."

*Neither* of these arrangements represent ways to fund projects, as they
do not allocate funds.
--
If you have a procedure with ten parameters, you probably missed some.
-- Alan J. Perlis

I would argue that a company producing OSS probably can be trusted,
for reasons of self-interest. Consider that a company like Red Hat,
for example, would lose out if it lost the trust of the OSS community.

Quote:> particularly if it is not set up as a justiciable
> contractual obligation from the word "go."

Quote:> Of course, heading back to the original claim:
>    "Another, similar, way to fund an OSS project would be..."

> *Neither* of these arrangements represent ways to fund projects, as they
> do not allocate funds.

--

["Corruption" can result from inadequate information or from error
every bit as much as it can from m*turpitude...]

Quote:>> particularly if it is not set up as a justiciable
>> contractual obligation from the word "go."

>That's a good point. OTOH, if it is set up in a legally binding
>way, and there is a dispute as to who is entitled to what, the
>whole thing gets swept up in a morass of litigation, which benefits
>no-one except the lawyers.

You can't get out of this; there are two choices:

a) Leave the valuations vague and undefined, which means that control
rests in dictatorial fashion in the hands of "whomever decides," or

b) Create a set of rules and regulations, which leads down the
slippery slope that we see in taxation systems where tax professionals
look for "exploits" and "vulnerabilities" in the system that can work
in favor of their clients.  

(This bears a striking parallel to the area of Internet security...
"Buffer overflows" might be considered to correspond to "poorly
defined clauses.")

Quote:>> Of course, heading back to the original claim:
>>    "Another, similar, way to fund an OSS project would be..."

>> *Neither* of these arrangements represent ways to fund projects, as they
>> do not allocate funds.

>It represents a way of transferring money from people who use OSS to
>people who produce OSS, while keeping (most of) the advantages of
>OSS. Of course, the money only gets transferred after the software is
>written, so it isn't funding in that sense. But if this is presented
>as a business plan, and a VC lays out money on that basis, then it
>is funding OSS.

As such, permitting people to participate in the way you describe
represents a way, not of providing funding to the outside developers,
but rather of getting the outside developers to invest in the company
for which they have written software.  

That's exactly backwards from what you think you're trying to do.
--
Rules of the Evil Overlord #94. "If I have a fit of temporary insanity
and decide to give the hero the chance to reject a job as my trusted
lieutentant, I will retain enough sanity to wait until my current
trusted lieutenant is out of earshot before making the offer."
<http://www.veryComputer.com/;