Deprogramming the rat race spirit : Teaching students FOSS etiquette
FOSS now occupies a place with Internships, Projects, Hackathons and Competitive Programming as a must have on student resumes. Several startups and well established companies value Open Source contributions very highly. An increasing number of students are also participating in open source programmes such as Google Summer of Code, The Linux Foundation Mentorship Programme, Major League Hacking's Fellowship among many others.
However, some concerning behavior has emerged -
Major League Hacking (MLH) banned Indian Students from participating in its fellowship over concerns of 'low effort proposals', 'spam' and 'negative impact of a few individuals'.
Lee Calcote, the maintainer of Meshery, got death threats and verbal abuse from a couple of Indian students because their GSoC proposal was not selected.
Several GSoC orgs including CRIU have reported a flood of low effort, AI slop proposals. Once again mainly from India.
Incidents of Project Proposals, Pull Requests and source code being plagiarized.
Hacktoberfest, a programme created to introduce newbies to Open Source, had several participating projects flooded with Spam PRs after a YouTuber 'CodeWithHarry' made a video telling students how they'd win a free T-shirt by participating in Hacktoberfest.
These are just the tip of the iceberg. Every year there are multiple instances of abusing the spirit of open source contributions by both newbies and maintainers, and a lot of these incidents originate from India. Whether we like it or not, we represent our country on the Cyberspace, and these incidents make it harder for new, genuine contributors to be taken seriously.
Is a contributing.md file enough? Is a tutorial on 'How to make your first PR' enough? Is there something we are not teaching first time contributors?
In this talk, I go over the history of such events, examining them through the lens of the 'rat race' that begins with Board exams and entrances like the JEE and how this mindset is very damaging in an Open Source context. I suggest a few solutions that I've applied during my time running a student club at college, Point Blank. Finally, I conclude with a few pointers that can help project maintainers ensure civil behavior.
We have a FOSS etiquette problem, with first time and even experienced contributors behaving in a way that is counterproductive to the values that FOSS strives to inculcate.
This is a result of most students being brought up in a hyper-competitive environment and viewing FOSS contributions through the lens of another competition. In simple words, the JEEfication of GSOC, LFX and many other such programmes has begun.
Introduction to Open Source tutorials focus a lot on the technical aspects of contributing - how to use github, how to open a PR, how to resolve bugs without any focus on the ethical aspects - when is it good to contact the mentors? how to engage with the community in a meaningful way? what kinds of behaviors are off limits?
Just preaching platitudes is not enough - you have to convince young contributors that such behavior is counterproductive to their goals, and do so in a judgement free way.
What measures can maintainers take to ensure that their project is a safe, inviting space for all contributors?
Which track are you applying for?
Ashutosh Pandey
The proposal does a great job highlighting the problem but it doesn't mention how exactly does this "reprogramming" happen. At a FOSS conference of this scale, you would be talking to people that will most likely already agree with you that this is a serious problem. What solutions you have in mind unfortunately do not reflect in the proposal :/
I think it's a great talk that will appeal to the students. The problem is real. IMHO, I would prefer this talk to be a lightning talk.
There's a talk about how corporates are screwing over OSS. This is a talk about the grassroots spoiling the OSS spirit. Should the two be combined?
For the same reason as Reviewer #1 I have to reject this proposal.
I'd suggest the proposer add more details on solutions that they might have experimented in their club.
The talk though relevant, is not setting the right approach. The background and incidents that may have happened are not as useful as how to fix this. I would recommend screening before taking a call.
The reviewers felt that while your talk highlights a very real and serious problem, the proposal falls short in outlining concrete solutions and also talks about claims that can't be publicly verified. The consensus was that a conference audience, especially one at this scale, would already be aware of these issues and would be more interested in learning how to fix them.