I'm writing this essay to really gather my thoughts on this, so I can finally put them to rest and stop getting distracted by the discourse surrounding it all. If you don't know what Hacktoberfest is, don't worry; I'll explain it in "Background" below.
I'm someone who has participated in the past 3 Hacktoberfests, completing them all with at least 4 genuine useful pull requests. I've never attended any of the events surrounding Hacktoberfest. I am not an active DigitalOcean customer, nor have I ever really been. I have signed up for Hacktoberfest 2020.
This shit was inevitable.
If you're already familiar with what's happening, feel free to skip this section. I'll keep this as factual and to the point as possible.
Hacktoberfest is a yearly online event spanning the entire month of October, organised by DigitalOcean celebrating "open-source" software on GitHub. If you contribute to any project on GitHub by opening four pull requests (a request to the repository owner to accept changes you've made into the project), they will send you a shirt. This applies to your own repositories as well; you can send 4 pull requests to your own repository and get a shirt. Every repository across GitHub is included automatically, though repository owners may now opt-out of it through a manual e-mail process.
Hacktoberfest during the past years has always had an issue with people spamming to get their shirts, but it has also lead to useful contributions.
However, this year, a certain Indian YouTuber has made a Hindi language YouTube video in which he advertised the possibility of winning "free swag" by just making some pull requests; the one he showcased on video was of the lazy spam variety that has been replicated many times. While he claims to have stated in the video that he reiterated that prospective contributors should only be sending in quality contributions, that's not what was shown on video. The video has since been deleted.
However, the damage has already been done. Complete garbage pull requests to random repositories came rushing in from India, usually with the title "Improved Docs", which in most cases only adds a completely unnecessary statement to the README in poor English.
Hacktoberfest has reiterated that they do in fact Heart Emoji "open-source" and have stated that they have a shared responsibility with maintainers to prevent spam. They also stated that they will be making adjustments to Hacktoberfest to prevent further spam, of which they have made none so far. Spam continues to happen, the vast majority of it originating from India.
From here on out, you're getting my opinion. LinkedIn Suit Avatar Dudes beware, you might get a little upset.
It's easy to immediately blame said YouTuber for the fallout. However, the problems have been brewing for much longer. In previous years, "Hacktoberfest check-in" repositories were popular; an easy way to +1 your pull request count by simply adding your name to a text file. Not really in the spirit of things, but also not actively detrimental to anyone who has a repository on GitHub. Of course, the spam PRs to actual projects have also existed, but at a much lower volume.
So in other words, the Indian YouTuber was merely the Mentos™ added to the liquid shit cola, the catalyst that finally pushed the dark side of Hacktoberfest into the limelight. I don't particularly blame him, as you may read in the following paragraphs, he was simply doing what everyone was encouraged to do by the "everyone can be a part" mindset.
As it turns out, this is a big fat lie. "Open-source" projects large enough to be part of any sort of "community" willing to guide newcomers are often complex pieces of software. The official messaging that even people who have never written a line of code or used Git in any capacity can make meaningful net positive contributions is going to come crashing down once it hits the relentless wall of reality, leaving those misguided frustrated and confused.
Here's one example interaction to showcase this:
- New contributor: I've reworded the documentation to be more clear about this.
- Maintainer: Thanks, can you rebase onto master and force-push? Also please make your commit message follow contribution guidelines.
- New contributor: What? Sorry I'm new, how do I do this?
Maintainer is now in the awkward position of having to teach someone, who likely just used the web interface, on how to set up Git and use it like an everyday developer would. Or they could just rebase it themselves, which might be equal amounts of work as making the changes themselves has been.
Okay, at this point you might say I'm a gatekeeping asshole who simply wants his cool guys club to stay closed to uncool people. This is absolutely untrue. I wish there were more people out there who knew how to properly use git, and who knew how to write code. The false messaging about accessibility is doing more harm to this than good in my opinion, as new contributors will inevitably get frustrated and figure they're not cut out for it after all.
Above, I've also mentioned that having written some code is a prerequisite. One may argue that documentation changes and translations are worthy contributions, and I'd agree with this point, but someone who does not know how to program is unlikely to be able to read program code, and therefore unlikely to be able to write documentation. Even if documentation is written from a pure user's perspective, my experience with such contributions has been that they will misjudge the scope of what code documentation should include.
If you're doing translations without knowing how to code, how do you integrate these translations into the application? Okay fine, maybe a workflow for this already exists. So you add translations. What if someone changes the reference version of the text down the line, but cannot update the translations because they don't speak the language? Maintaining an entire translation of all text in your repository is a huge burden, and potentially confusing when it's not done in a timely fashion.
Going back to the argument about complex pieces of software, the biggest problem people have is "where do I get started?"
Getting into new codebases is not easy. Getting into a new codebase without knowing where its deficiencies are that need cleaning up is nearly impossible, unless you're already very well versed in software development.
"Hacktoberfest task" labels on issues only get one so far; identifying an "easy issue" to tackle and then documenting it is usually about as much work as simply fixing it right away. In my experience, the simplest way to get started contributing to a new codebase is to be an active user of the code and determined to fix an issue one has already been bothered by. This leads me to my next point.
During the past decade, most everyday users (not me) have gone from using software that they run on their own computer to using mostly closed-source services provided by some company that selectively publicly releases parts of their infrastructure code. You're consuming video content on Netflix or YouTube, not in Windows Media Player. You're checking your e-mail in GMail or Office365, not Thunderbird. Think about other tasks you use a computer for, such as word processing, and try to figure out which ones are software you run yourself and which ones are services you merely interact with.
The point is that while all of these services likely include open-source components, none of those components is a finished product of its own of which you run a copy yourself every day. You probably have gripes with the interface of your chosen webmail service, but no way to fix this. You'd probably like to be able to import a certain document file type into your word processing service, but have no control over this.
You have fallen victim to the software service industry that extracts free labour from outside contributors for their most boring pieces of code under the guise of an egalitarian and fair open ecosystem.
Naturally, this does not apply to all software. Native standalone applications that are not "services" are still developed and used. A popular one you know is VLC. Another one might be Firefox (yes, you can still actually compile it from source and get the Firefox, unlike Chrome!) If you're looking towards the Linux desktop landscape, there is a whole truckload of them; GNOME and KDE both implement an entire desktop shell with all its everyday utilities such as calculators, text editors and MS Paint clones.
But a lot of these projects don't really go by the moniker "open-source" anymore. Many of them consider themselves "free (as in free speech, not free beer) software", with some even going as far as to label themselves "Libre", resulting in the very marketable "Free Libre Open Source Software (FLOSS)" terminology.
And most of them aren't on GitHub. Many of these projects are large enough and with a long enough history that hosting their own "code forge" infrastructure is not unreasonable. Add to that that many eschew GitHub for the sake of being able to keep control of their data for decades to come.
So in other words, corporations hijacked the term, abused it for free labour and brownie points, while selling a more restricted experience to users than ever.
Enter DigitalOcean, a service provider who financially benefits from this new wave of "Software as a Service" that requires ever-expanding server infrastructure. Naturally, they are concerned that their steady flow of free labour into the ecosystem dries up, while also wanting to promote their platform to prospective future customers. Giving out T-shirts to a fixed amount of people and presenting it as a "challenge" through which a T-shirt must be earned is the ideal marketing move. They get their brand out there and talked about, and they've already spent the money required to print all those shirts anyway. For them, no leftover shirts is the ideal condition.
I'm not really mad at corporations. I'm simply pointing out that it is in DigitalOcean's nature to cause spam like this even if it hurts their brand in the end. Much like it's in the nature of a deer without any predators to eat all tree saplings even if the damage done to the ecosystem will lead to its demise.
It's important to recognise why things are the way they are, and how two-faced corporations tend to be at the end of the day. Claiming in public that you stand for a truly equal world in which everyone can improve technology regardless of their race, gender and sexual orientation is in stark contrast to gating off the ability to make meaningful contributions behind a job interview that is anything but egalitarian. But people can still contribute fixes to whatever bits and bobs they might or might not use in their "stack".
For me, because it's an incentive to actually work on something. I tend to sink into a swamp of unproductivity without any extrinsic motivation. However, I only contribute to software I actually use myself. There is no point in contributing to a library that I don't use, or a CLI tool that has no relevance to me. My contributions would likely miss the mark, or would be things so trivial the time to review and merge a change could've been used by any maintainer to simply make the change themselves if they saw it fit.
Physical rewards such as T-shirts or stickers need to go completely. They're good quality shirts, I enjoyed wearing them, but at this point I'm embarrassed of being seen in one. I'm also no longer willing to act as a walking billboard for a company that exhibits bad behaviour and then treats any fallout resulting from it as a PR incident that needs to be smoothed out with a blog post (and only a blog post.)
As an aside note, the tree planting is cute, but if you're internationally shipping textile products to residential addresses worldwide then any pretence of being concerned about the impact you're having on the climate goes straight out of the window.
Secondly, the messaging and target audience needs to change. Either you target first-time open-source contributors who don't have much experience with code and you have mentoring in place (with, as a result, much decreased overall engagement), or you target enterprise developers or students who have experience with code but have never contributed to a public git repository before. The latter group can probably get by with written help resources and online seminars.
Last but not least, change the brand and refocus on select software projects with who you either partner or for whom you're willing to curate all contributions made in relation with the event. I've never liked the "Hacktoberfest" name much, but now that it's irredeemably soiled there's definitely no reason to keep it around.
Having an actual team to curate Hacktoberfest contributions before they hit actual project maintainers sounds like a big investment, but it's a well known paradigm in other circles: in the Linux kernel, contributions usually go to subsystem maintainers, who then merge them into their tree and later on submit their entire tree up the hierarchy as a pull request, all the way up to Linus himself eventually. If your company is not willing to pay people to do this maintenance work, it means you don't actually value the time of maintainers.
I've seen a lot of suggested bandaid fixes pop up, against some of which I shall provide some counterpoints.
Why don't they only count merged pull requests?
Big pull requests can take a while to get merged. That's good. They should be reviewed appropriately and only when the maintainer has time and energy to review them. Making only merged PRs count disincentivises more complex PRs, makes PRs made late into the event completely pointless unless you delay the tallying up appropriately, and worst of all, incentivises the very annoying behaviour of endlessly bugging maintainers about open pull requests. You absolutely do not want to have some person mention you every day about their pull request, it leads to burnout real quick.
Why don't they make spam PRs count negatively towards the total?
Because then you can submit 8 PRs, of which 2 are against active repositories that bothered to count them as spam, and the other 6 against either inactive repositories or repositories that did not bother to label the PRs correctly, and still "complete the challenge" as 6 - 2 = 4. It's no fix, one spam PR is already annoying enough, asking maintainers to then be the judges of your gamified marketing scheme is ridiculous.
Why don't they just not count single line PRs?
You can fix some pretty awful bugs with a single line change, and much of the spam has multiple lines of changes anyway.
Can't they just increase the review period to 14 days?
I suspect that most of the spammers do not know or care about the review period at all. The problem isn't that the spam is taking up a lot of one's time to the point where, during a busy week, nobody has any time to close and label some PRs. It's that they shouldn't be having to do this in the first place. This is once again the garbage idea that it's somehow the responsibility of the maintainer to prevent spam or opt out; it's absolutely not. It's not their marketing campaign. They're rarely getting anything out of this event.
What about a better onboarding process to explain the spirit of the event?
Pointless, as the spammers are aware that what they're doing is gaming the system. They don't care to submit actual contributions. Feel free to ask any Indian FOSS mentor who has tried to somehow shape this flood of nonsense into real work; what I've heard from one is that the current atmosphere is mostly just frustration and horror.
Do not be swayed by empathetic but ultimately empty PR statements and vague promises. There is no easy solution to save Hacktoberfest, as the entire industry it was birthed from has fundamental issues. An industry in which open culture is merely a fashion statement cannot profit from widespread public interest, as the opportunities for genuine participation of inexperienced contributors are few and far between.