I'm a GSoC org admin for a few years now. To be honest, the bureaucracy that comes with GSoC is really negligible from my point of view. The application form is fairly short, the evaluations during the summer are literally done in five minutes... there really isn't that much overhead.
The part that takes a lot of time for us is mentoring students. You'll very likely invest more time into the student than it would take you to write everything yourself (which also would be more fun). Unfortunately, some students don't stick around, but if everything works out, you'll get fantastic long-term contributors (we did). The upfront investment on the mentor' side may not be everyone's cup of tea (and that's ok), but I think it's unfair to attribute that to bureaucracy. GSoC may just not be a good fit for OpenBSD in that regard.
"it was too much effort on the part of the foundation organizers mentors to deal with the bureaucracy involved, and we didn't really see enough return in terms of new developers to the project"
I don't think Bob's statement is a criticism of the bureaucracy itself, but rather that the amount of time spent on the GSoC project as a whole is better spent doing other things that need doing on the OpenBSD project. He explicitly says so shortly after the above quote.
I'm not sure why this is even an issue to be discussed. Are people here trying to figure out what GSoC could do better so that projects like OpenBSD might find it worthwhile to participate? Or is the purpose to criticize OpenBSD, or Bob Beck individually, or both, for daring to say publicly that they have better ways to spend their time and effort than participating in GSoC? Clarity on those questions would be helpful in determining whether it's worth talking about.
Incidentally, the thought I had when I saw this on the list is that if the person who originally posted the question on misc@ really wants to contribute to OpenBSD, he can begin the way other contributors begin without GSoC: port a favorite app that's not already available to OpenBSD, test patches that the devs post and provide meaningful feedback, propose a patch that provides a solution to some problem you have run into while using OpenBSD, etc.
I think OpenBSD offers a great environment for real mentoring while maintaining their high standards for correctness and security. Sure, a student doesn't get paid any stipend to do it, but what they can learn in the process of contributing something that has long-lasting value to a project with OpenBSD's standards will surely pay off in career development in other ways.
If OTOH they need money to pay the rent over the summer or to burnish their resume for their application to Google, apparently they'll be better off contributing to another project that has the resources to participate in GSoC.
From what I read, they applied 2 years in a row, and nothing happened. From the link it's not really clear what happened.
> we didn't really see enough return in terms of new developers to the project.
It's not clear in just this context what the author means. Were they looking to add significant numbers of full-time contributors? If so, I don't really think that's what GSoC is about. Isn't GSoC geared towards smaller projects that can nominally be completed in a student's summer break?
I mean, seems to me that expectations on the 2 sides are different: OpenBSD was looking to recruit full-time (I don't mean full-time in the 40-hours a week sense, but rather year-round part-time contributors) vs GSoC looking to fund individual efforts on OSS projects for 3-4 months during summer break.
Even if you have students that are already contributing to your project, and just want to allow them to do so full-time during the summer, GSoC is often not worth it.
You need all the mentors available, although they won’t be used, and while the code will be of good quality and kept, the bureaucracy is too much.
One project I (I’m a student with too much free time) am contributing to has discussed entering GSoC before, but we don’t have the manpower to provide the required mentors.
> Even if you have students that are already contributing to your project, and just want to allow them to do so full-time during the summer, GSoC is often not worth it.
Having an already-existing contributor sign up for GSoC actually backfired on us. He had to come up with a "project" rather than the minor, drive-by contributions he'd been making (a project which he probably wasn't that excited about, to be honest). He then got behind and didn't finish, and then I guess was embarrassed, as we never heard from him again. So we lost a useful contributor.
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 don't know exactly how big the OpenBSD volunteer team is but I think it must be substantially larger than most open source projects because of their user base. This is a weak argument to not participate in GSoC. There are multiple projects with a much smaller volunteer base than OpenBSD who participate in GSoC.
At the same time I do recognize that the effort involved for mentoring someone is huge and the actual payout is not much for the mentor (it was $500 the time I participated).
I think it is viable to see GSoC as a platform through which you can reward your existing student contributors as well - ask them apply through GSoC and they can get paid for their contributions. This eliminates the effort involved in onboarding new contributors and also provides a nice reward for the existing contributors.
> This is a weak argument to not participate in GSoC
Hey, at least have the courage and in integrity to tell them directly how to run their project. On the mailing list. Not here.
Open source drive-by project management is one of the most fascinating (and sad) phenomenon to me. How can people who have no association with some other group of individuals have the audacity to tell them how to spend their time and how to run their project. It's bewildering.
I guess I wasn't very clear in my comment. I don't use OpenBSD, I don't subscribe to their mailing list and I am not a contributor. Hence, it will be nonsensical of me to go and criticize their decisions there.
Also I can't tell if you are directing the last part of your comment towards me or towards Google, but I certainly respect their decision to not participate. They participated previously and decided that the payout in terms of new contributors wasn't worth it (and I agree with them there) - at the same time there is a second angle to look at GSoC from and that is what I pointed out in the last part of my comment.
Well, the way they spoke out about their lack of participation kinda hurts the perception of GSoC, thus I'd say it's a good moment to talk about it.
Also, is there a list of software development taboos we shouldn't discuss here or it's just my impression that it's a bit too easy to get you angry by a simple comment?
An open source project I am involved with had the same experience. We were expecting to get idealistic young people as students who had a passion for the project. Instead, we got people from poor countries who were doing it for the money and didn't care about the project at all. I understand that this money may do some good and I don't blame the students for going for it, but it really tainted the whole process in my mind.
GSoC also has this this weird master/slave (or if you like, employer/employee) dynamic that is very artificial. If you are a mentor, you are basically a manager for the student. You have to give status reports, feedback, evaluate how they are doing, decide whether to pass or fail them at the end, and so forth. It's very different from how a real open source project operates. If you want to know what being a middle manager operating an outsourced project feels like, then being a GSoC mentor is for you. If that is something you would run screaming from, then I would stay away.
IMHO GSoC should be something like "hacktoberfest" where contributors for the projects get paid for squashing bugs not for making "new features" nobody needs.
That would be an interesting project. Have projects submit a list of bugs they would like some help with and then pay the selected students for each bug fixed (maybe with a base stipend). Probably teach quite a bit about the daily grind of software development.
At that point it seems like a glorified version of a bug bounty list[1].
The convenience of GSoC is that the students get to intern with pay on open source projects. If squashing bugs is the only goal, then going through their bug bounty lists and getting paid for it really is just picking a company on that list and doing it yourself. However, with a Google program behind it and the company's agreement, I'm sure the amount paid will be higher and/or more consistent.
Including my old link [2] for security/bug vulnerability discovery as well, since you get paid for these by the companies based on bug fixes or discoveries.
The value of "mentorship" or "internship" at FOSS projects are overrated, most of this projects run without clear goals and improvements are made only by "interested parties" like intel wanting their technologies to run better on Linux or the devs at GitHub optimizing "Git" for the sake of their business operations but yet not a single improvement on the UI side (obviously because it will hurt their business if suddenly people realize how easy could be using Git without GitHub).
Is there some statistics out there for number of students whose code is still used and/or are now developers/contributors on the project the did GSoC for?
On the other hand, i was discussing a gsoc project on Debian since last year (was very excited about it), and guess what, Debian was not accepted as a gsoc organization for this year, nice...
edit-> i'm a student and gsoc's stipend would help me a lot.
I'd say I am very happy for every project they accepted. It's obvious they have limits on how many and how different organizations they can accept and it's not fun job to tell those who got declined that they should try next year.
I don't know what the timeline for GSoC is so maybe it's too late, but Haiku (BeOS-inspired/compatible open source OS <www.haiku-os.org>) was accepted again this year and might be of interest to you.
Anyone interested in brainstorming how to make GSOC work, as it apparently doesn't?
The first thing that comes to mind is pay a stipend to the project and the student. So if the student gets $6K and 99.99% of them skip town at the end of summer no further contact, the project gets nothing but unmaintained code and wasted effort. However... what if the project ALSO got $6K of cold hard cash? Or credit for google services, adwords, donated hardware, who knows...
It didn't work out for OpenBSD. I wouldn't generalize so quickly.
Mentoring students does take work, some do try and game the system. That happens no matter if GSoC or not. With GSoC, you basically have a form of financial support for hiring students. The GSoC paperwork is also rather minimal.
If you can, going through local universities and colleges is also a great way to have students work on community-driven Free Software projects. On a project, we had 4 engineering students do the equivalent of an internship on our community mesh network project. They did really great work and it's nice to have ties with university communities. We also had profs in social science classes inviting us to give talks, or had networking workshops during the weekends.
The student and the project already get a stipend. I'm not certain what it is now, but when I was a mentor the student got $5000 and the project got $500. In theory, of course, the project is getting more than $500, because they are also getting a "free" paid intern for a summer, and (for small projects who might need this) exposure.
IIRC, the student gets half the payment on completion of the first half of the project, and half after the second, both on the condition of positive reviews from the org. So if a student just blows it off, they don't get their payment.
This will be an unpopular opinion, but paying students to work on OSS seems entirely backwards, and sends a confusing message about open source. It makes no sense for an experienced volunteer, contributing for free, to mentor a student being paid to contribute.
I think a better system would be some kind of endorsement program, where Google donates money to projects and in return the projects agree to mentor one or more student contributors. At the end of the summer if everything works out, Google can endorse the student for the work they've done. The project gets something done, the extra cost of bureaucracy is covered by Google, and the student gets real world experience verified and endorsed by Google.
It means that Google Summer of Code imposes too much bureaucracy onto Free Software projects. In other words, GSoC is only viable for those projects whohave enough spare volunteers to begin with.
I think in OpenBSD's case it was that, plus the fact that they got essentially zero code that was anywhere near their standards, or any devs willing to commit longer-term to improve it. If the results had been better, more mentors/devs would have been willing to step up.
GSOC promotes dumps of low to mid quality code that then goes unmaintained. After all its focused on relatively junior programmers doing it for a nice stipend as part of their school experience for a summer (or so).
GSOC is just a bad fit for the sort of quality and maintainership OpenBSD demands from its codebase and contributors. They have had a lot of years of experience with academic code mostly written as a proof of concept without an eye to maintainability that later rots in tree and makes everyone else's job worse.
> They have had a lot of years of experience with academic code mostly written as a proof of concept without an eye to maintainability that later rots in tree and makes everyone else's job worse.
Well you don't have to use interns to get production code. If that's a concern, they can be put to work doing something outside the main code base, like perhaps writing tools that speed up some tedious process. There's probably opportunity for OpenBSD to get something out of GSOC, but if the standard is "shippable code or bust", well, no wonder they're disappointed.
Sure, id say that shippable code really isnt the point of GSOC, but if they arnt getting long term contributors or useable code out of it, there isnt really any advantage for them to participate.
How exactly is OpenBSD planning on getting more coders that can code to their standards if they aren't willing to teach anybody? NIH + an unwillingness to let anyone else into the house seems like an excellent way for a project to find itself facing the brink should 1 or 2 core developers leave the project for any reason.
>without an eye to maintainability that later rots in tree and makes everyone else's job worse.
...that's the whole point of the mentors. IF that's what OpenBSD is getting out of GSoC, it's the mentor(s) fault, not GSoCs.
They were willing to mentor people via GSoC, nobody stuck around (almost all the applicants do it for the money, rather than an interest in volenteering), ergo its not worth their time. Even in organizations that have a high priority towards onboarding new devs, GSoC retention rates are typically very low.
They have no issues attracting devs via other channels.
2 core developers? It's a fact of life that college students suck in deep and vexatious ways at writing multithreaded C. They aren't even good 1 core developers. OpenBSD's recruitment targets should be more experienced people.
"It means that Google Summer of Code imposes too much bureaucracy onto Free Software projects. In other words, GSoC is only viable for those projects whohave enough spare volunteers to begin with.
"
Except, as at least two people in this discussion, who are org admins, have said, they basically see no bureaucracy or overhead.
So ...
Usually, what this means is folks had unrealistic expectations.
The truth is the coding level of even the average high end BS freshout is really not that great, so it usually takes actual mentorship and guidance to get good code out of GSoC.
That's not "bureaucracy" though, unless you have an endless source of high quality coders willing to join your project, that's how you get anyone to be a good contributor.
On the other hand, if a student wishes to do OpenBSD-related work during the GSoC, they need to find another mentoring organization. Most are related to specific projects, but I think at least some of them, like the Apache Foundation, are general enough to at least consider mentoring such a project.
Even if the current contributions are slim, wouldn't the long term benefit of perhaps gaining a permanent contributor outweigh the current effort to educate more people?
Experience (across many open source projects) is that the majority of students are gone at the end of summer. The long term benefits you cite are great when they exist, but for a project they just don't happen.
Most students seem to treat GSOC as a way of getting experience for the commercial world, with no intent to sticking with the project long term. There is nothing wrong with this, and it is a good thing that there are mentors willing to put in effort to help these students. However this is NOT good for the project itself.
I think it depends on how slim, the mentors have to take out time from their own projects, so you'd have to detract that from the gain. You'd also have to factor in maintenance on new code produced by GSoC students that don't stick around.
Honestly I don't get why people are upset, the explanation from Bob seems completely reasonable. If the OpenBSD developers don't believe that they see sufficient result from their work, then nobody is forcing them to participate.
For a community to thrive it must respect their elders and teach their young. How do you survive in the face of inevitable death if you won't take in more young? Someone has to think past 2038.
Or they might have too short a horizon on measuring the goal. Someone might start contributing later. It's a numbers game. The stable contributor might be something of a unicorn but you have to try to find one.
The part that takes a lot of time for us is mentoring students. You'll very likely invest more time into the student than it would take you to write everything yourself (which also would be more fun). Unfortunately, some students don't stick around, but if everything works out, you'll get fantastic long-term contributors (we did). The upfront investment on the mentor' side may not be everyone's cup of tea (and that's ok), but I think it's unfair to attribute that to bureaucracy. GSoC may just not be a good fit for OpenBSD in that regard.