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 was at FOSDEM last week-end. As usual there, I spent an excellent week-end. It was really nice to see all those friends again (and even meet some friends for the first time, hi gaston/carxwol/atmaniak!) Only problem is, FOSDEM is definitely too short ;-)
To make this post a bit more interesting, I did some homework. The opening talk about FreeBSD had those stats about developers’ age, so I made the same ones for Debian (using the birthDate LDAP field, which was filled in by 340 DDs). Here is the graph. It would be interesting to compare that with other communities, which are sometimes perceived as “younger”.
From Adrien Lebre, who seems to be having fun working on kDFS:
$ dd if=/dev/random of=file bs=1024 count=2
0+2 records in
0+2 records out
256 bytes (256 B) copied, 0.000705717 s, 363 kB/s
$ ls -l file
-rw-r--r-- 1 lucas lucas 256 2008-02-08 17:53 file
Can be easily explained using strace:
open("/dev/random", O_RDONLY|O_LARGEFILE) = 0
open("file", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 1
read(0, "p(\361\241,\360-\330~M\245y\10=\274U\201c\207\v\336a\273"..., 1024) = 128
write(1, "p(\361\241,\360-\330~M\245y\10=\274U\201c\207\v\336a\273"..., 128) = 128
read(0, "\362,LW5l.?\242\22\252\223\206\375\10\326\335\316\374\372"..., 1024) = 128
write(1, "\362,LW5l.?\242\22\252\223\206\375\10\326\335\316\374\372"..., 128) = 128
close(0) = 0
close(1) = 0
Given three groups of groups of people A, B, C, responsible for 3 queues Qa, Qb, Qc ; and an elements e which have to go through Qa, then Qb, then Qc.
- A doesn’t process Qa because he sees that B doesn’t process Qb, so there’s no point in filling Qb
- B doesn’t process Qb because he thinks that C won’t process Qc, so there’s no point in filling Qc
- Qc is empty, which “proves” that C doesn’t think he isn’t the bottleneck
Possible solution: A, B, C, please prove your point!
- A, please process Qa, and put the pressure on B!
- B, please process Qb, and put the pressure on C!
- C, please process Qc (when you will have a queue)!
Now, let’s find a practical example to apply that … Any suggestions? :-)