> For each of my emails, I got a reply, saying that they "sincerely apologize" and "@Dalibor Topic Can you please review...", with no actual progress being made.
then
> Sorry to hear this. .... @Dalibor Topic <dalibor.topic at oracle.com>, can we get this prioritized?
This is pretty morbidly funny.
Next sentence is: I don't fear to not get my money, but currently I don't know if you pay or someone else...
My suspicion is that you get ghosted if you don’t have a @google or @redhat email address and really the only way to become a contributor is to be buddies with someone who works on the project already.
I have considered going to one of the CNCF committee meetings and being like, hey you guys are not accepting new contributions which goes against your mandate. But in the end I just maintain local patches that don’t get upstreamed which is easier.
My experience of the few patches I have received though is they are 100% without exception, bad patches. Bad in that, without me putting an hour or 2 of work into them I can't just accept them. The most common case is no tests. The patch fixes an issue, but the issue exists because there was no test for the case the patch is fixing. So, to accept the PR, I have to download it and spend time writing a test.
Other common experiences are bad coding practices and non-matching styles so I have two choices
(1) spend 30-60 minutes downloading the patch, fixing these issues myself
(2) spend 40-60 minutes adding comments to try to get the person who posted the PR to make their patch acceptable (40-60 mins includes the back and forth).
More often than not, (2) never gets a response. The contributor's POV is they provided a fix and I should be happy to take it as is. I get that. At a certain level they are correct. But, these projects are hobby projects and I have limited time. So I generally don't do (2) because if they ignore the comments then it's wasted time, and (1) has the hurdle that I need to take an hour out to deal with it.
Nonmatching styles can be mostly solved with linting and static analysis
There’s no fix for bad code outside of manual review beyond that. But doing those things should significantly cut down on your noise.
90% of contributors won’t read it at all or only some parts of it and ignore the rest.
Most PRs you get solve some super specific individual problem and aren’t relevant for the wider community that uses your OSS.
It’s not their fault really but most contributions are so bad it doesn’t serve to spend any time on reviewing them earnestly.
(Been maintaining several popular projects for the last 7 years)
Edit: https://judahmeek.com/p/we-need-frogs-to-defend-foss may be the better link to start with.
Companies such as Google have billions at their disposal yet still can’t figure out simple project management?
Google of the past is no more, unfortunately.
Trust me I tried many many times.
This has nothing to do with Google being evil it’s just one of the realities of maintaining a big open source project.
Kubernetes is such a huge project that there are few reviewers who would feel comfortable signing off an an arbitrary PR in a part of the codebase they are not very familiar with.
It's more like Linux, where you need to find the working group (Kubernetes SIG) who would be a good sponsor for a patch, and they can then assign a good reviewer.
(This is true even if you work for Google or Red Hat)
You could analyze the repo to identify others who have modified the same files. and reach out to them specifically.
I get that the current system isn't working, but I don't think you should just go emailing random committers, that seems likely to just piss people off to no benefit.
Sorry to say this, but this is natural. Writing patches is easy. Reviewing them is hard. Writing patches (and getting them accepted, merged) is rewarding and demonstrable (as a form of achievement). Reviewing patches, educating new contributors is sometimes rewarding, sometimes not (it's an investment into humans that sometimes pays off, sometimes doesn't), but mostly not a demonstrable achievement in either case. Therefore there is incentive to contribute, and hardly any incentive to review. This is why reviewers are extremely scarce in all open source projects, and why all sustainable projects optimize for reviewer/maintainer satisfaction, not for contributor satisfaction. As an external contributor, you just don't get to allocate scarce resources financed by some commercial entity with no relation to you.
If you want to become a maintainer, or at least want others to review your stuff, don't start by writing code. Start by reading code, and make attempts at reviewing code for others. Assuming you get good at it, established project members should start appreciating it, and might ask you to implement some stuff, which they could be willing to review for you. You first need to give the real kind of effort before you can take it.
And this is why "open development" is a total myth today. Resource allocation and work (chore) distribution are aspects of reality that completely break the wide-eyed, bushy-tailed "new contributors welcome" PR message. Opening up the source code (under whatever license) is one thing, collaborating with randos is an entirely different thing. Can you plan with them in advance? Do they adhere to your deadlines? Can you rely on them when things break? When there are regressions?
> you get ghosted if you don’t have a @google or @redhat email address and really the only way to become a contributor is to be buddies with someone who works on the project already
Yes, and the way to become buddies is to help them out where they are hurting: in their infinite patch review backlogs. Of course, that means you have to invest a whole lot of seemingly thankless learning, for the long run's sake. You have to become an expert with effectively nothing to show for it in the git history. It's totally fair not wanting to do that. Just understand that a ticket that remains open indefinitely, or an uncalled-for contribution that never gets reviewed and merged, may genuinely be better for the maintainers than taking on yet more responsibility for your one-off code contribution.
> I have considered going to one of the CNCF committee meetings and being like, hey you guys are not accepting new contributions which goes against your mandate
According to the above, I bet that "mandate" is a total fake; a PR move only. It does not reflect the actual interests of the organizations with the $$$, which is why it doesn't get followed.
You are right that those orgs should at least be honest and own up to NOT welcoming newcomers or external contributors.
That's broadly the point of CLAs, but for a beefy project like OpenJDK with so much shared code baked deep into enterprise deployment, Oracle will feel it's critical they can pull freely given code into the depths of their closed Java builds.
It's their project. It does absolutely block contributions (employers are unhappy sacrificing their engineering output to Oracle). If you don't like it, fork it.
This was more of an unfortunate lack of attention/prioritization.
Don't assume malice where a simpler explanation exists.
So they create draconian "agreements" and "codes" to tilt the playing field entirely in their favor. It's entirely antithetical to the whole idea of open source.
These projects should be ruthlessly forked and all corporate development efforts ignored.
Wait what? Source on this? GRUB is supposed to be a GNU Project, I would've thought they'd rather die than accept any sort of Oracle ownership of it.
Many projects behave this way, particularly those with corporate overlords. At best, it will take weeks to get a simple patch reviewed. By then, I have moved on, at least with my intention to send anything upstream. I commend the author for giving them a whole year, but I have found that is best a recipe for disappointment.
Maintainers: how you react to patches and PRs significantly influence whether or not you get skilled contributors. When I was maintaining such projects, I always tried to reply within 24 hours to new contributors.
It would be interesting to see how quickly the retention rate drops off as the time to review/accept patches goes up. I imagine it looks like an exponential drop off.
I submitted a patch to Go once, and never got anything resembling a response. Told me that Go is more or less completely inaccessible; I should treat it as a Google product rather than a FOSS project I can contribute to. The Go standard library documentation bug I submitted a fix to still exists to this day.
They will ignore a big patch from a rando and obviously process a big patch from themselves.
You can become somehwere in between and no longer be a rando, but have to start from the rando end.
https://mail.openjdk.org/pipermail/hotspot-dev/2026-January/...
The process was much more involved than anything I'd previously signed, and it was slow, but in my case eventually got approved.
It mostly involved some emails with an actual human and PDF's to be docu-signed.
I know first-hand the frustration of having PRs ignored and it can be quite demoralizing, so I do feel for the author. It sounds like the author is getting to a place of peace with it, and my advice from having been down that path before is to do exactly that, and find something else interesting to hack on.
https://mail.openjdk.org/pipermail/hotspot-dev/2026-January/...
Having said that, I would never contribute to a project with a first contributor experience like this one.
> perfect for first contributions, especially to get through the myriad of bots requesting you to sign/review stuff
At the same time as they
> can often end up taking more time away from contributing engineers doing reviews and testing than they are worth
OpenJDK: where Java is developed
Temurin / Zulu: where OpenJDK is built, tested, packaged, and supportedNever forget: One Rich Asshole Called Larry Ellison still runs this company.
By my reading, it's not merely that the standard doesn't require the "d" suffix, it's that the standard doesn't allow the "d" suffix, and the code won't compile on anything but gcc.
1. Is "anything but gcc" actually supported by the project? Do they have a goal of supporting other compilers or possibly an explicit decision not to support other compilers?
2. If they do support other compilers, how did the "d" suffix make it in the first place? That's something I would expect the dev or CI to catch pretty quickly.
3. Does gcc behave any differently with the "d" suffix not there? (I would think a core dev would know that off the top of their head, so it's possible they looked at it and decided it wasn't worth it. One would hope they'd comment on the PR though if they did that). If it does, this could introduce a really hard-to-track-down bug.
I'm not defending Oracle here (in fact I hate Oracle and think they are a scourge on humanity) but trying to approach this with an objective look.
A project should take on useful small patches, thats how you onboard contributors.
I absolutely get that it was an unfortunate interaction from the email writer's perspective, and it's really unfortunate.
But there are a lot of concerns/bureaucracy, etc in case of large projects like this. It may just never got to the person responsible, because it is a cross-cutting concern (so no clear way to assign it to someone) with a low priority.
My initial comment was maybe unfair but I can completely sympathise with the maintainers etc. that separately these PRs look like random small edits (e.g. from a linter) with no specific goal
If it's such a massively huge project like OpenJDK, then not really.
You might also check how non-trivial it is to get a change into the Linux kernel.