[python has paid projects]
Andreas Raab wrote:
> Uhm, well I don't think this is a bragging point ;-) Looking at it I 
> notice these grants were given out once (in Oct '04) where based on 
> the period of the grant (12 months) it was clearly intended to be 
> repeated. Why it wasn't repeated I'm not sure about but it may have 
> something to do with the fact that the above page says for two of the 
> three projects that they were still under development as of Jan '06 
> and only one was finished. These are volunteer communities after all.
That some projects will never be "complete" is to be expected - that's 
risk for you ;-) This doesn't make sponsoring projects impossible or 
automatically unwise... Its possible the Google summer of code model is 
a better one http://code.google.com/summerofcode05.html they at least 
link to plenty of CVS/SVN repositories :-)
>
>> BTW, its quite possible that someone might get pissed off no matter 
>> how you do it, but that's part of life. The question is doing it in a 
>> manner that only upsets few people, and encourages active people. If 
>> we can vote in a board, we can certainly award some funds.
>
> Unless it affects upfront promises, yes, I think we can. For example, 
> I could easily imagine the SqF awarding some money to further the 
> development of traits, spoon or whatever else. What I could *not* 
> imagine is any upfront promise that the result of that work will be 
> the basis for any particular Squeak release. Unfortunately, there 
> seems to be a tendency to think that way because otherwise the money 
> is considered "wasted" not counting that the gain in knowledge may be 
> more valuable than the artifact.
Sure. So you're not against sponsoring SummerTalk projects next summer, 
as long as nothing gets promised? to me it even makes sense that the 
mentor should be the maintainer of some code (so inclusion is obviously 
controlled where it should be), and that his decision whether the 
project is complete (and deserving payment) is only partly linked to his 
taking the code (so he can decide a project is good, but not good enough).

Daniel