-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Dinesh Joshi wrote:

| This is NOT. I've seen this kind of "optional requirements" A LOT and | I have to totally disagree with them. By encouraging such "PLUSes" you | guys are NOT encouraging new entrants but rather encouraging the | already contributing members to earn a quick buck. I know its great to | have people contribute and when money is involved it becomes even | better. But by adding such PLUSes to your "requirements" applicants | who are willing to learn BUT dont have experience are thrown out and | downright discouraged. This is not the point of GSoC and the whole | reason it was started for.

I don't know whether you have read the recent blog post from pradeepto (http://pradeepto.livejournal.com/12565.html) but what he quotes from Till puts the bits into perspective. Yes, it is unfair for new contributors who don't have experience and perhaps in some ways it is not what the GSoC is about. But GSoC is not the average college / university project where some lecturer picks out a random bit from some IEEE or ACM paper and a bunch of students attempt to implement that without checking whether someone has already been-there and done-that (in the last 2 weeks, I have had a grand total of 30 such papers e-mailed to me by students who desire to do "projects" and in a year I get around 200 odd, including some applications talking about the same paper thus proving the college commonality).

However, having said that, the GSoC period is fairly well timeboxed and a rank newcomer (even if they are equipped with programming competence) would find it difficult to "get it". The "it" over here refers to the programming practices that are part of producing free and open source software (patches, code review, version control, IRC, mailing lists etc) as well as the entire architecture of the project to which contribution is offered.

Existing contributors who have code to show have a better chance of earning the trust of the mentor. Note, the mentor at a GSoC can be someone who just nudges the candidate in the proper direction and wrangles on his / her behalf with his upstream or, someone who does a deep dive into code. Either way, the mentor does not write code for the candidate and keeps up with his own contribution as well.

Applications where [i] the candidate does a random copy paste [ii] the candidate doesn't actually demonstrate that there has been thought behind the application [iii] the candidate uses templates and then is lazy enough not to erase details of the of the template cruft [iv] the candidate does not provide a draft timeline [v] the candidate contradicts him / herself within the application itself [vi] the candidate proposes a cosmetic change [vii] the candidate proposes a change that is not consistent with the project direction will end up having the odds stacked against them.

The mentors have a small time window to go through, review and score the applications and the process is sometimes more brutal than what Till mentions. A contributor who does not require too much hand holding is a contributor whom the mentor sees as most promising to deliver.

The harshness of GSoC selection is somewhat offset by GHOP and perhaps institutions would take it upon themselves to get some contributors to come down and undertake talks about "producing open source software".

On 19-Mar-08, at 8:28 AM, Siddhesh Poyarekar wrote:

On Wed, Mar 19, 2008 at 1:36 AM, Dinesh Joshi dinesh.a.joshi@gmail.com wrote:

...

who are willing to learn BUT dont have experience are thrown out and downright discouraged. This is not the point of GSoC and the whole reason it was started for.

I don't quite know about the motives of GSoC

I think the prime motiviations for google are two:

1. google uses a lot of foss stuff and so has an interest in the foss products it uses getting better. 2. google gets an evaluation of the 900 best students around as well as introduction to the best open source programmers around

the motivations for projects are:

they get free paid labour for two months to improve their applications. That said, the attitude of different projects differ. Some of them plan carefully, monitor their students closely and interact well. They also do not hesitate to fail students if necessary, but always after giving them several chances and asking fellow mentors to vote on the issue. In other projects anything goes - if the mentor and student are good some good work results. Often the mentor just signs off on the student without even looking at the code. There are organisations which have selected students otherwise than on merit - I know a case where the organisation was bullied into accepting a student.

I would rate the success rate at 50% or so - which is very good compared to the average success rate of FOSS projects which is about 5% or less.

So, for the good organisations a lot of pluses are necessary. In some places newbies to foss programming get accepted and succeed too. And by and large, the success of the student depends on his own initiative - very few developers have the time to mentor a student closely over a period of two months.