I failed to complete this year’s Hacktoberfest. Same as last year. Having a whole month to post 6 meaningful contributions to (tons of) participating open-source repositories sounds easy enough but turns out to be harder than it seems. However, this time I have a solid excuse - the spare hours I could have worked on my own PRs I spent with curating a Hacktoberfest project by checking others’ submissions. This is a look back at my experience over the last month.

The project I am carrying on is called Java Demos. Its ultimate goal is to provide an explanation/demo implementation for each and every Java Enhancement Proposal (JEP) that exists. There are hundreds of them already and new keep popping up every half a year with each new JDK release. The project started as a small collection of new language features presented to my colleagues at work when Java 17 came out, but I felt like it should continue and grow.

For a long time, I was struggling with it, because I don’t have enough time (or will) to keep up with the Java evolution pace. The status at the end of September 2025 was - code at JDK 23, only a few features covered. I decided to take opportunity of the upcoming Hacktoberfest, a gamified open source promoting initiative by DigitalOcean which I found couple of years ago. So I updated the project to run on newest JDK 25 (through fresh GraalVM distribution), created hacktoberfest labelled tasks on GitHub to cover at least new JEPs from Java 24 and 25 (42 in total - Java team seems to be outperforming themselves lately 🤯) and wait for things to come.

I really wasn’t expecting much. There are a lot of projects participating, many of them very well known and established. I didn’t even care too much - I think I only posted the link to my repo under one or two articles here on dev.to. No big promotion. No advertising everywhere - come and help me plox...

But the developers came. I guess Java Demos have one big advantage over many other projects - we are by nature beginner friendly, as setting up little coding demo is literally the most basic thing to do. And unlike other projects for newbies, we are far from being completed. So there were a lot of relatively easy things to do, and this get noticed without me having to do a thing.

By the end of the month, 29 new contributors have more than a hundred of their PRs merged. While those might not be an astonishing numbers, for me it really means a lot, because it means (at least) 29 unique persons cared so much about something I have created, they spend their time to fork the project, studied it to understand how it works and raised a PR trying to make it better. While it is hard to describe, it is really a great feeling. It probably won’t change the world, but it still matters at least a little. We did much more than I hoped for. There are now demos for everything since Java 17 and most of other things back to Java 13. While the quality of some submissions will yet to be checked (at least I have a topic for 2026 Hacktoberfest :)), the project made a big leap forward. Thanks to complete strangers who just found it somehow.

It was also hard in a way. Suddenly, there were people asking for assignments, having questions and opening PRs awaiting feedback. It put a bit of a pressure on me, because I was trying to respond as soon as possible and it was not always comfortable. Going through the code and writing requests for changes here and there also takes time. But it was worth it.

I have also learned a few things - the most important and also hardest lesson is to say “no” and stay firm in rejecting changes until they are ready. Well, TBH, I still need to learn this. I still tend to accept PRs that are “good enough already” despite I know I will have to do some changes later. Afterall, the author probably gave his/her best effort and for me it is just a snap. I should rather encourage him to keep trying than booing him away, or?

On the other hand, significant portion of PRs were with no doubt created with AI including “explanatory” ( = useless) comments left by the agent inside the source code. I am a big fan of using AI to ease up developer’s daily work. But I always encourage everyone to think about the code LLM spits out. And I seriously doubt some of the contributors did. This again leads me to necessity of being stricker in judging the PRs. Strict but polite and not toxic as some “seniors” tend to be.

The abusing of AI especially popped up, when I opened couple of advanced tasks during the month where I drafted some future upgrades going beyond the usual “Implement a new demo for JEP xyz”. People reached out and asked “Please, assign this to me”. And I was like “Ok, but this isn’t even a proper task yet, just a vision. How would you approach the problem? I need you to understand what you should do and why”. And I got an answer back, but it was so obscenely obvious it is a “plan” written by AI with zero value added by the author... Those were moments when I also got disappointed. And left stricken with the fact they probably don’t even understand they did something wrong. That’s how things work now, don’t they? No more coding, no more thinking, just type in the prompt and copy-paste the result. What could possibly go wrong, eh?

This was not meant to be a rant against AI. I am using my ChatGPT and my Copilot on daily basis. And I encourage everyone else to boost his/her productivity by embracing its capabilities. But once again - don’t use it blindly. Follow the principles of The AI Manifesto. And for open-source maintainers it means to stay vigilant and verify what are potential contributors unintentionally trying to smuggle in the projects. I always tried to explain why I insist on their own understanding. Some get discouraged and asked for some easier task instead, but I also made some of them to think more and they bring useful solution in the end. I believe this was worth my time, although I would be happier if I didn’t have to explain such basic things.

My article is becoming long, so there is one last thing I want to point out. Despite my best efforts to catch them during reviews and despite improved instructions in contribution guide, errors kept bubbling into the main branch with some PRs. We saw compilation errors (mostly from incorrect handling of merge conflicts) but even some runtime exceptions.

The best thing to prevent such issues? Establish mandatory checks - every PR must compile and (added later) the program must run. With GitHub, it is surprisingly easy to introduce a workflow that does it. Did I know that before? No. But it took literally minutes to consult with ChatGPT Plus model 5 and I got a solution. But the important thing is - I didn’t accept the solution blindly. I got through it carefully and I made sure I understand everything. It was a bit easier, because I already knew a thing or two about GitHub action pipelines (after all, I already forked and adjusted one). But even if you know it will take long, you should always invest your time into demystifying code you got back from the clever, yet mindless machine. To be completely honest with you, the second part of the action that checks if the program can still run with no runtime exception, is one of the Hacktoberfest submissions by one of the more active contributors. Self-initiative wasn’t that common, people mostly pick tasks I prepared for them, so kudos to him for that (and more).

I am pretty sure I’d have more to say, but the train is getting close to my town, so I need to finish. I expect the project will get more quiet now, so I will have time polish what have been added and make it ready for the next year’s Hacktoberfest. I am already looking forward to it.

Follow me for more updates on Vue, Nuxt, Vite - and maybe even more!