I know what happens each summer

The onset of summer is generally characterized by stifling heat, mangoes and, a rush of CVs from students who want to do summer internship projects. That is, GSoC notwithstanding. It happens each summer, unfailingly and inevitably. There are two specific trends that are observed in the CVs:

  • 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.


Deprecated: ltrim(): Passing null to parameter #1 ($string) of type string is deprecated in /home/sankarshan/sankarshan.randomink.org/blog/wp-includes/wp-db.php on line 3031

7 thoughts on “I know what happens each summer”

  1. With respect to the first problem, maybe advertising the fact that there is work for people with those skill sets to do. I think it’s all too easy for people who aren’t in Computer Science areas to think there’s no way they can help, so even the ones who are interested and follow along won’t be sending their applications.

  2. There’s one problem with that: It’s likely a very discouraging experience for the student. Upstream projects often are of very high code quality and often require a very good understanding of both the programming language and the codebase(s) used. Students new to FLOSS likely have neither of those.

    Plus, if your first experience is getting a patch (that you likely not even understand fully) rejected multiple times (for reasons you likely don’t fully understand either) will not make you appreciate working on FLOSS.

    I think you should try to find some work that does not require this much knowledge, but encourages acquiring that knowledge and gives them a feel of accomplishment. Bug triage, testing, translation or working on new or experimental code bases that aren’t of such a high quality yet come to mind there.

    From my own experience in 2001 or so: It took me roughly half a year of working on GStreamer’s unstable branch before the patches I sent to the glib people were useful to them. Most of my early bugs were closed “WONTFIX, it’s supposed to work this way” 😉

  3. Speaking as a history student, I can confirm what JonRob was saying. I’d love to help developing FOSS, but I fail to see how having studied the foundation of the People’s Republic of China and the lead up of Japan into the Pacific War will be of any help to open-source projects.

    I mean, personally, I do have some skillsets that would help, there was another lifetime where I graduated community college as a database programmer and I am currently studying Japanese in Japan, but I’m not confident enough in my Japanese abilities to translate very much and I’ve left the programming world in frustration so…

    If anybody can show me what a history major can contribute, I’d be glad to look into it.

  4. It is a bit like GHOP and yet, it isn’t. What would be interesting is figuring out how projects can maintain a dashboard of entry-level tasks throughout the year instead of specific ‘project/program’ initiatives.

  5. And, that has been a nagging question for a while. History/Arts/Literature majors and people from other non-technical education backgrounds. The sad part is that stating “why don’t you look around the project wiki to figure where you can start” doesn’t really cut it. There really has to be a bit more effort in terms of attracting these talents. What specific form/shape the effort needs to be, I really don’t have any idea now. The intent of mentioning this was to put out the notion in some public forum so that it gets discussed.

  6. I agree with your point of view. It is a very hard and uphill problem. However, the alternative is asking students to pick up “toy” projects and implement whatever they want to do. That is equally hard and somewhat counter productive as well. The underlying theme of the blog was to put out in the open the need for projects to start considering easy_to_do tasks in form of tags. Not all such tasks would end up getting the hard-boiled disapproval from upstream. And, one of the objectives for such a dashboard is to build up the confidence to attempt tasks of increasing complexity.

    Having a dashboard and, then obtaining teacher buy-in at the institutions ensure that there are in-situ mentors/coaches who can provide that positive vibes to carry a student through the initial phases.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.