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

[Daniel Mose <imcol@unicyclist.com>]

First:
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 <davidsen@tmr.com>
>   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


P.S. 

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

D.S.