Subject: should/can FSBs give grants?
From: Tom Lord <lord@regexps.com>
Date: Wed, 3 Jul 2002 03:26:31 -0700 (PDT)



What, if anything, can FSBs accomplish by giving away grants?  Is
there a business reason to accomplish those things?  How does the
cost of the grant-giving approach compare to other approaches?

I speculate that grant giving is a useful means for implementing
__standardized engineering practices__ among projects.  That
standardization is one thing FSBs could accomplish by giving grants.

For exaple, an FSB can publish a list of its 1000 favorite projects
and make an announcement.  The FSB can say: "we will give a gift of
$300 per year to up to 1000 individuals, each designated by one of
these projects _if_ at least 60% of the projects on this list take the
following steps:

	*) always keep the ".tar.gz" link on freshmeat up to date
	*) always use ascending, three-digit version numbers
	*) include an up-to-date `PKGCFG' "spec" file with every release"


There is a business justification for engineering practice
standardization: it can lower the transaction costs between FSBs and
FS-projects, thus lowering FSB operating costs.

For example, if the Freshmeat records and PKGCFG files in 60% of the
projects save the FSB two hours of labor per project per quarter, that
comes out to $720,000 (which is $720 each divided among all 1000
or $1,200 each divided only among a conformin 60%).

A $300/project-year grant still leaves a quite substantial net-savings: I
suspect the cost of this approach (which is incurred only if it works)
is competitive with others: The "trick" employed by this approach is
to move the data-gathering task from an inappropriate location (inside
the FSB) closer to where it can be performed more efficiently (near
the maintainers).  Because they perform this simple task more
efficiently -- say 15 minutes per quarter instead of two hours --
projects can profitably perform the task at 1/8 the cost, 1/4 the
price.

There is a subtle difficulty with the business justification:

Sure, the justification applies unproblematically when deciding how
much FS-project grant money to give away compared to non-FSB
competition.  Giving away a successful grant pool lowers my FSB's
operating costs but doesn't help my non-FSB competition at all.
Compared to non-FSBs, I should certainly give grants.  It's just like
making a labor-intensive internal investment, but with a different
legal structure.

The problem is trying to apply the justification to competing FSBs.
If _one_ pays a grant, _both_ get the same cost savings.  Whoever paid
the grant has a _lower_ net savings.  Should neither, then, give a
grant?  Should both be willing to risk a grant regardless of what the
other does?  Should they try to give coordinated grants?


			"decision table (I) for FSB grant-giving
			 to implement FS-industry standard 
			 engineering practices among projects"



			his FSB			his FSB
			gives a			doesn't give
			grant			a grant

		--------------------------------------------------
		|	big win 		smaller win
	my fsb	|	against 		against
	give a	|	non-FSBs		non-FSBs
	grant	|
		|	tie among		win for his FSB
		|	FSBs			against my FSB
		|
		|
		|		-----------------
		|
		|	smaller win		slight loss
	my fsb	|	against			against non-FSBs
	doesn't	|	non-FSBs
	give a 	|
	grant	|	win for me 		tie among FSBs
		|	against his FSB
		|



That's an interesting table, but it doesn't tell the whole story.

As it stands, the table says "to win against non-FSBs, FSBs should
be giving grants" but it also says "if there are no non-FSBs on
the scene, the only way to win is to not give grants, and 
the only way to not lose is by not giving grants."

But that table isn't complete because it doesn't consider the value
that FSBs obtain just from having "more" or "better" projects.

Here is the software equivalent of Moore's law: the number of
distinct, useful applications of a set of `N' (loosely defined)
software components grows proportionately with `2^N' (the number of
subsets of those components).  The cost of assembling an application
of `K' components falls in proportion to `O(2^K)' (the number of
potentially interacting subsets of components within the application)
for every measurable increment in "engineering quality" made to all
`K' components.

Consequently:

			"decision table (II) for FSB grant-giving
			 to implement FS-industry standard 
			 engineering practices among projects"



			his FSB			his FSB
			gives a			doesn't give
			grant			a grant

		--------------------------------------------------
		|	
	my fsb	|	FS-industry		FS-industry           
	gives a	|	potential mkt-cap	potential mkt-cap grows  
	grant	|	grows O($2^(N+1)):	O($2^N), worth        
		|	a tie worth 		O($2^(N-1) - $grant)  
		|	O($2^N - $grant)	to my fsb, O($2^(N-1) to  
		|	to each participant	his fsb, a net        
		|				win of $grant for him
		|
		|
		|
		|	
	my fsb	|	FS-industry		No industry-potential
	doesn't	|	potential size grows	growth; a tie worth $0
	give a 	|	O($2^N), worth		to each participant.
	grant	|	O($2^(N-1) - $grant)
		|	to him, O($2^(N-1) to
		|	my fsb, a net
		|	win of $grant for me.


which is a classical prisoner's dilemma, interestingly enough.  Didn't
someone once suggest using the prisoner's dilemma as an intellegence
test :-)?


-t