• most of them are from students pursuing some form of Computer Science and Engineering or Information Technology
• a larger percentage of them would be making their first contributions to the world of FOSS if they end up working on a FOSS project

The first part is an area that sometimes make wonder if we cannot reach out to folks from other streams to spend their summers productively. There is an increasing need to have cross-discipline interaction and, while CompSci and IT may be an easier path to matchmaking, how do we end up getting other people interested as well. For example, say folks from the Arts and Fine Arts, other Engineering disciplines etc. Ideas and comments welcome on that.

The way to solve the second part of the problem is somewhat simpler – devise a very “high touch” mentor-protege driven system wherein the first_time_participant is given an intensive orientation in the basics of how to participate in a project, how to provide bug reports, how to create patches etc. Additionally, teaching them the basics of using FOSS infrastructure bits like mailing lists, IRC, version control systems and so forth. The point of failure in this path is of course when there is a project/task to be identified and handed over to the student to attempt to solve. The following issues come up:

• most upstream projects do not seem to have bugs/tasks marked with something like “student project” which makes it a somewhat tedious job to sift through a whole lot of possibilities before hitting on a particular cache of tasks
• there are no ‘defined’ upstream mentors for the tasks, so, even though a student might be able to deliver most of the tasks by {him|her}self, there is a lack of upstream ‘buy-in’
• the above two couple together to the conclusion that there is no proper assessment of the time estimate for a task/project

I often hear the question that “if there isn’t any interest from upstreams, why not get them working on projects that are relevant for problems at hand ?” And, the answer to that is something along the lines of “having first time participants contributing to upstream projects is a quicker means to coach them into good citizens than having them think up, design and deliver their own projects”. There are days I wish that each upstream had something like “summerprojects.upstream.domain” kind of filtered view of tasks/projects with a mentor who could provide a bit of abstract/summary of what that task means. It isn’t really a big ask – and a little bit of push from the bodies that oversee the project could make this happen.

And, since the upstreams are nothing but what their contributors make them out to be, I keep on doing my bit to coax and cajole them into seeing the value in this. Especially so because with each passing summer I notice that the caliber of the students are somewhat on the upside of the scale.

Turns out that India has the second highest number of accepted proposals. I recall reading earlier that the number of proposals/applications from India was significantly high as well. However, I’d say that this is just a beginning and 101 isn’t really a number to be going to town about. Sure it is better than where we were 3 years ago. But, the world has also progressed since then and, we just cannot keep on benchmarking without adjusting for that change. There are certain trends which are nice though. Things like second time applicants, applicants turned mentors. These indicate the willingness to participate, to contribute, to collaborate and to coach – all important ingredients in the great rush to become a better FOSS citizen.

It is a privilege to be a mentor because it gives one a chance to read the proposals before hand, help in scrubbing and polishing them and, to take a dipstick test into the trends of FOSS adoption and awareness in the country. And, the T-Shirt is a nice incentive Among the few things that do come to mind include the need by all the projects to lay frameworks that can coach the young participants more effectively – work towards bringing them up to speed throughout the year and, show them how to think. The last point was hammered home in a number of proposals that seemed to have a distinct lack of originality. While we rejoice and blog triumphantly about the increase in India’s contribution, we need to keep in mind that this is just a start of the contribution process and, the virtuous cycle ends when the contributors of today become confident enough to take the role of mentors of tomorrow.

I am sure that the following have been written again and again, but I’d say it is never enough. For those who want to participate in GSoC and work towards a good application, it would be nice to keep in mind some of the following.

• Participate early, participate continuously – a project can become confident of the student’s ability to deliver if there exist proof that the student has what it takes to take the idea from a concept stage to a deliverable. So, do not land up on a project during GSoC, give it some deep thought and engage in a structured fashion much earlier so that the developers know who you are and what you can do.
• Think, don’t just read – if there is constant participation, anticipating a potential GSoC project becomes much easier. Thinking about it in the perspective of relevance and value to the project gives it the much needed shine. This also means that it is easy to write a proposal around an idea than just verbatim copy of the text of the idea into the proposal
• Talk, don’t just write – it is important to indulge in public discussion of the ideas, the proposed paths and initiate discussion. GSoC proposals are not fire-n-forget type documents. They need constant attention
• Listen, don’t just talk – a good proposal is one that discusses it with potential mentors and, can evolve through discussions and suggestions. Keeping eyes and ears open to good ideas also demonstrate a willingness on part of the candidate to become a better contributor and a good participant