lkml.org 
[lkml]   [2002]   [Jul]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Funding GPL projects or funding the GPL?
    On Fri, 26 Jul 2002, Alexander Viro wrote:

    > What you and the rest of armchair generals do not get is that "adding
    > features" is _not_ the hard part of work. Doing that in a way that
    > wouldn't be a permanent source of bugs afterwards and cleaning up the
    > existing sources of bugs _IS_. So is doing infrastructure work. So
    > is auditing code. So is removing crap code.
    >
    > None of that is covered by your "model". 99:1 that your "working driver
    > for card" is going to contain a bunch of root holes. _And_ be unmaintainable.

    This is totally unrelated to the ecconomic model, we have many proofs that
    code quality is unrelated to financial compensation. People write crap
    code for both fun and profit. So what you say is totally true, but has
    zero to do with why the author wrote the code. You have to QA any code
    before using it, why the developer wrote it is irrelevant.

    That said, let me suggest another possible model for funding free
    software. It's in two parts. It would be helpful perhaps to discuss "is
    this a good thing to do" first, before "how could you do that," and I do
    know some similar things have been proposed and tried in the past.

    First the user driven part:

    1. User wants functionality X. Defines a functional spec. Also defines
    the open source license to be used for the finished work. GPL, LGPL, BSD
    or similar.

    2. Concept approval. If the functionality is a library change, driver,
    kernel hack, or similar, the entity in charge commits to accept the
    functionality *if and only if* it meets some standard of fitness,
    reliability, and maintainability. Otherwise some neutral party (user
    group, FSF, individual) is selected as the acceptor.

    3. Bidding. At that point the proposal goes up {somewhere} with a price (I
    will pay $Y for functionality X). Developers may offer to do the work, and
    most importantly other users may add to the offer. Not a fixed $20, but
    whatever it's worth to them. After some time either an acceptable
    developer is found or the offer expires.

    4. Acceptance. Developer tests the software, publishes the result. The
    acceptor tests the software and either accepts it or rejects it for a
    objective reason related to not meeting the functional specs.

    5. Deployment. Developer gets paid, software released under open source
    license, if it's part of a package it's queued for the next release.

    Developer driven part (only changes from user shown):

    1. Definition. Developer states s/he wants to develop X, states functional
    spec, license, and price of the work.

    3. Bidding. If the stated desired price is not met after some time, other
    developers may accept the current pledge (with user approval, of course).

    --
    bill davidsen <davidsen@tmr.com>
    CTO, TMR Associates, Inc
    Doing interesting things with little computers since 1979.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:27    [W:4.418 / U:0.040 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site