11–20 of 66 posts
edit-> i'm a student and gsoc's stipend would help me a lot.
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.
This is sad. 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 ni…
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.
This is sad. 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.
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 pay…
> 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…
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.
Earlier quoted context omitted.
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 ni…
> 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 proba…
(i.e. less emphasis on experimenting and more emphasis on quality and being accepted by upstream, perhaps by assigning "smaller" tasks)
Earlier quoted context omitted.
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 ni…
> 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 proba…
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.
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).
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 c…
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.