Why Isn’t OpenBSD in Google Summer of Code 2017?
marc.info
marc.info
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.
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.
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 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.
> 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.
Am I misunderstanding?
The project applied 2 years in a row, and mentored several students. Some developers mentored more than one student.
https://www.google-melange.com/archive/gsoc/2014/orgs/openbs... https://www.google-melange.com/archive/gsoc/2015/orgs/openbs...
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.
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.
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.
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.
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?
Option A: Discuss shortcomings of a project that its members don't intend to change on Hacker News like a lot of other things. Maybe learn something.
Option B: Send email about those to the project's official mailing list. Spend some amount of time in a flame war that teaches nobody anything.
Although you want B, I think most should just stick with A. Better time/reward ratio.
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.
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.
I was thinking they would work on one project the same mentorship scheme, but I can see how it might devolve without keeping the education in mind.
edit-> i'm a student and gsoc's stipend would help me a lot.
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...
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.
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.
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.
You seem to draw a conclusion solely based upon GSOC not being a good fit for the OpenBSD devs.
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.
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.
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.
(i.e. less emphasis on experimenting and more emphasis on quality and being accepted by upstream, perhaps by assigning "smaller" tasks)
>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 have no issues attracting devs via other channels.
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.
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.
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.