I really don't buy the "too much bureaucracy" argument. Google is really transparent in terms of GSoC and I would say they're really well managed. I read that as a sign of OpenBSD's weakness, not Google's.
I really don't buy the "too much bureaucracy" argument. Google is really transparent in terms of GSoC and I would say they're really well managed. I read that as a sign of OpenBSD's weakness, not Google's.
OpenBSD does not need GSoC to attract contributors. The project gets a good amount of new contributors on a regular basis, and they get onboarded quickly without causing much distraction, if any.
The mentor/student relationship is atypical for open source projects which are used to operating as a community of equal peers. Mentoring students who expect to be mentored takes a lot of time, and the vast majority of them don't come back. In my experience money is a key incentive for students in GSoC and that makes it hard to keep them as volunteers. Unless you are very lucky as a mentor and pick a student who turns out to be an open source enthusiast, they won't actually care about your project in the long term. And there is no way of knowing that during the application process. Unless in special cases where you already know the student, as I did in one instance, but that's an exception.
(Speaking as an OpenBSD dev, and as a former mentor of several GSoC students, over several years, at the Apache Software Foundation).
This is exactly one of the flaws in most open source projects, which projects like GSoC and Outreachy aim to improve. Mentor relationships are one of the keys to building a more inclusive community, and reaching underrepresented groups.
For a few friends I have found internships being another reason why they did not go back to their orgs. 5k$ seems like a big amount but it really isn't (even in India!)
Finally, one last reason I can think of is terrible mentors. I have been really lucky to have amazing mentors but I have heard a few horror stories from others.
Yes, this is exactly what GSoC can be good for. Ideally, it allows people like you to spend time doing what they love doing instead of working for crappy startups.
The good (and fun!) experiences I had as a mentor all shared this element.
I tried keeping up with the mailing lists for a while, but I found it difficult.
(My student ended up going on to work for Red Hat. I don't presume I had a lot to do with it, but I think the culture did.)
In a normal situation, new contributors show up and are self-motivated, and receive guidance from others so that over time they become equals. The mentor's role is spread among several people, and it is informal and temporary. There is no money involved.
Many (not all!) GSoC students do not experience what the normal situation in open source feels like.
I am happy that your student is an open source enthusiast and got a job in open source. That is great.
I have seen this kind of good experience, but also more disappointing ones. In one case, a student simply disappeared after the first payment (in the middle of the summer) had been issued.
I think this nails it.
I think that's a bit pessimistic, bottom line is that during the summer, a lot of students take on jobs to improve their finances (at least back in my days), back when I was a student I would have loved being able to work on projects I love/interested in and getting paid for it, rather than, as in my case, pretty much waste my summer time working in computer/video game retail to earn some bucks.
So yes, money is an incentive, but you could probably make that money in a regular summer job, the big boon as I see it is to work on something you find interesting during the summer, which in turn increases the chance that you will want to continue working on it once GSOC is over.
I don't think so. OpenBSD is known for having really high code quality and excellent documentation. So, it probably just takes new contributors that long, because they need to reach that same level, before they can make meaningful contributions.
Sure, yes, that does slow the project down. It'd evolve quicker, if they'd accept almost any code and then fix it up over time. But that doesn't mean that the project is unhealthy or that those 15 weeks should be shortened somehow. It just means that the project is lead differently and has different goals than most other software projects. It's from perfectionists for perfectionists, and as such it does have its niche.