I guess that's a sign of a really unhealthy community if they have no process of getting hackers into their system so that they can get productive within 15 weeks.
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.
For this particular open source project GSoC brings no advantage to the table (yes, it may be great for other projects).
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).
As a former GSoC mentor, I think it's important to have an onboarding pipeline in your project, and disagree with the notion that the mentor/student relationship is somehow atypical - such relationships pop up all the time in the natural course of projects, and are key to the health of most of them. It's up to you to select the students who you think will stick around. Given that, taking the time to onboard junior people is a really rewarding investment in the project.
(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.)
What I think is unnatural is the situation where the student is being paid, and where the mentor has a formal responsibility for the student and acts as the person who ranks the student and thus decides upon their salary (fail the student -> no money).
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.
>The mentor/student relationship is atypical for open source projects
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.
As a former student I would like to emphasize that it is not about the money. I would have worked on the same project in the summer even if I was not getting paid. There can be various reasons why students won't return or become permanent contributors. For example in my case being a double major in very distant disciplines I do not have the time to contribute when school is on. Then summer I will be working on my thesis at another university which again would leave me little time to make any significant contributions. I am still trying my best to help new people by reviewing requests and making small changes that don't take too much of my time. I plan (hopefully) to get back to contributing on weekends once I am done with school.
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.
Having been on the receiving side of GSoC students, I'd say 90% of them come from poor countries and are looking for the money. I've seen some that weren't students at all and seemed to be working for "consulting" companies already.
Can't really comment on this as I know no such people. The "consulting" companies part is hard to believe given the rules for GSoC. The new payment adjustment taking into account PPP is a welcome move in this regard even though I don't agree on the numbers they have decided.
> I would have worked on the same project in the summer even if I was not getting paid
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.
>In my experience money is a key incentive for students in GSoC and that makes it hard to keep them as volunteers.
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.
Read the porting handbook and work on updating ports of software you're interested in. That's an easy way to get your hands dirty quickly. You can learn a lot about how OpenBSD works and you can work with upstream projects to make their software port more easily to OpenBSD.
> I guess that's a sign of a really unhealthy community if they have no process of getting hackers into their system so that they can get productive within 15 weeks.
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.
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.