There’s an interesting discussion about Google Summer of Code going on debian-devel@. The question can be summarized as “Should we allow current Debian contributors to be students in GSOC?“?
The GSOC FAQ says:
Google Summer of Code has several goals:
- Get more open source code created and released for the benefit of all;
- Inspire young developers to begin participating in open source development;
- Help open source projects identify and bring in new developers and committers;
- Provide students in Computer Science and related fields the opportunity to do work related to their academic pursuits during the summer (think “flip bits, not burgers”);
- Give students more exposure to real-world software development scenarios (e.g., distributed development, software licensing questions, mailing-list etiquette).
The problem is that those goals are clearly conflicting:
- If you think that “get useful code written” is more important than “get fresh blood in Debian”, it is stupid to choose students that are not existing contributors to Debian. It’s a much better idea to choose people that already know Debian very well, so they will be very efficient.
- If you think that “get fresh blood in Debian” is more important than “get useful code written”, it is stupid to choose students that are already contributing to Debian. You should choose outsiders, of course.
Another problem is that in the past, some students that were also debian contributors had problems organizing themselves: they used some of their GSOC time to work on their usual Debian tasks, leading to results that were a bit disappointing. But it’s possible that this is mainly a management problem (however, mentoring people takes a lot of time, and only students are paid, not their mentors).
How do you deal with that in your project?
I don’t see anything wrong with allowing current Debian contributors to be students in GSoC, as long as they don’t use their GSoC-time to work on their usual Debian tasks. But for me, GSoC is more about getting “fresh blood”, as you put it, in Debian.
And who said that you can’t “get useful code written” when you have students that’s not already contributing to Debian?
I think it might be good to decide on a per-project basis whether to prioritize one thing or the other. In my opinion, some of the projects offered last year, and I guess this year probably too, might be quit complex for an outsider even to understand what is about. It takes quite a long time to understand the dynamics of Debian and its needs.
I’m more for the idea of getting new fresh blood into Debian, but I think that would mean either offering projects that might achieve that, or doing some heavy mentoring to cover that gap. We don’t have any serious teaching or mentoring program in Debian for newcomers, do we?
Greetings,
Miry
I would think that what actually should be done is set goals that include integration of the work into Debian and only accept projects for which that is realistic.
From my personal sample of projects (Debian, pyjamas, rockbox), the latter two have had bad success with more or less outsiders. Pyjamas has had at least one somewhat successful project that didn’t get merged to the trunk because the student did not have enough authority, and both seem to have had projects that failed because the students did not have enough knowledge about the project.
Hello,
Mentors are paid actually but much less. It is only intended as a compensation and most of them do like me and contribute it to the mentor umbrella organisation (XMPP Standards Foundation for me).
I think there is no real conflict and you can produce good code with people that are not regular contributors.
I think your argument points out that the “targets” are more than one group of individuals rather than there being an inherent conflict of goals. An analogy is found in marketing. An organization’s goals may be to both improve retention of existing ideal customers AND to acquire new ideal customers. The goals are distinct, but not in conflict. As a result, the audience targeted is different to support both goals.
My two cents anyway…
Google is trying to grow the developer community. Sure, they could give money to people who are already Debian developers, to do things those developers would do anyway, and while it would be nice for for those developers to get some money, they’d find a way to contribute anyway.
It’s a short-term vs. long-term issue. Certainly, a rookie student is going to be less effective over a three-month period than a more experienced person, but the hope is that the SoC students will continue to be contributors after the summer is over.
Lucas, lets talk numbers. Starting with how many students in GSoC for Debian last year were existing contributors? And how many were not?
For WordPress, last year being our first year, only 1 out of the 10 students was an existing WordPress participants. This year based on feedback so far that will probably be 2 or 3 active WordPress participants, but I also hope to have even more mentors this year. Our mentors will, of course, choose what project and applicant they want to work with.
Even half would seem like a good balance to me. In almost all cases, the student could be getting paid much more to work on something else, and it would seem particularly wrong to turn away people already committed to open source and specifically your project when they have presented a project that would be a good learning opportunity for them and good for your project. Is them advancing their learning and experience in open source less valuable than someone that hasn’t yet made the same commitment and sacrifices? Anthony Towns speaks to this well.
I agree with Francesco P. Lovergine, it sounds like possibly the real issue was mentoring of those students to achieve there GSoC commitments — the one existing contributor was the most successful in this, and others success varied greatly. I have no secrets to share here, but I plan to encourage the mentors to even be more proactive and engaged this year.
Reading the discussion, I also see that I need to do much better this year about presenting our results, if we are accepted again.
#4. Mickael Remond, mentors do not get paid. The mentoring organization gets a small amount of money/mentor (~$500 last year).
Lucas, thanks for presenting these interesting discussion points. Based on your strong beliefs, I take it you are volunteering to admin and mentor this year?
The answer to improving Debian’s results is dead simple: the organization should compensate the mentors. Recall that each accepted project means 500 towards the organization. If all that money is given to the mentors, then you’re looking at about a 9:1 ratio of developers to mentors, assuming equal work and pay. This is probably a better maneuver than the Duc-Tank project or whatever, though bound to be controversial simply for the matter of choosing who gets to be a mentor.
Presumably, the reason Google doesn’t compensate mentors directly is because they want to give organizations flexibility in organizing costs and balancing mentors to students. Plus, some organizations may already employ the people they intend to appoint as mentors. Debian is probably in a good position to try a direct quid pro quo, as the SPI handles the purse strings and accounting quite… accountably.
i assume the reason for paying students has something to do with the assumption that other contributers have jobs and therefore are using their free time to contribute. students on the other hand, may not have income to pay bills and use a lot of their time in school and studying. furthermore, students have contributed VERY useful code to projects.
I think it’s ok to encourage existing contributors to apply
for GSoC if it will make them stronger. Consider a student
who was in GSoC for your project last year, and was productive,
but hasn’t had time to contribute since then. Should she be
encouraged to apply again? Sure! Or consider somebody who
is a promising developer, but has to choose between contributing
this summer and flipping burgers. Should they be encouraged to
join? Sure! In both cases, the student becomes a stronger
contributor to the project, and is more likely to be able to
contribute in the future.
But I agree, bringing in new developers is key. The Wine project
has benefitted greatly from the new students that GSoC attracted
to Wine.
As long as it keeps your young developers developing instead of flipping burgers it must be a good thing.
I sincerely think that SoC should be limited to new people. I wrote in my blog about a similar problem in Gentoo.
I sincerely think that is not asking too much, if someone has the option to either contribute via SoC, or to flip burgers, to find a _different_ project to contribute to. It would at least provide some more insight on a non-usual environment.