Funding Linux kernel -fringe and -future devel. projects ?

From: Daniel Mose (
Date: Thu Aug 01 2002 - 13:42:51 EST

I have received a rather harsh complaint email that told
me that it was considered to be RUDE to post to Subject:
"Funding GPL projects..(etc)" in context of LKML.

I agree in that Subject Sentence is rather [OT], but it
seems like SUBJECT is of interest to air for many LK
developers (and others). Therefore I propose the above change
in subject line to narrow the subject down to specifically
mean kernel related development projects. I hope that no one
is offended by this remark of mine. Most postings so far in
subject does in practise touch funding of kernel related
development in one way or the other.

Bill Davidsen wrote:
> On Fri, 26 Jul 2002, Alexander Viro wrote:
[ snipped ]

> 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 <>
> CTO, TMR Associates, Inc
> Doing interesting things with little computers since 1979.

I believe that a lot of kernel development funding is
already ruled somewhat (unofficially of course ) by similar
structures as above. Only: The User in point 1. is a larger
company such as f ex IBM. By making the scheeme above available
to anybody would probably be a nice improvement. Some question
that remains to be solved is however:

A. Who will want to make the nescessary work that is
        involved to achieve this? I do believe that most of
        the Linux kernel development team are a bit too buzy
        making linux patches, while working on ordinary jobs
        on the side.
B. How should the work be organized in order to achieve
        project credibility and fair progress ?
        There are numerous court examples of funding abuse.

C. The scheeme above might actually turn out to "need" funding
        for it self. There is even a big "riscue" that it will it
        self eat up all the funding that it receives. ( Old bad own
        experiences. )
Kind regards
/Daniel Mose


If any body actually find my posting in subject above
to be rude I would of course be happy to know this by mail.
Being rude is certainly NOT my intention. Of course any
kind of feedback besides this is always welcome


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Wed Aug 07 2002 - 22:00:16 EST