> 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?
Never had this issue. Its just as simple as start to work without contract and the promise of department head to get a contract and after two weeks mention to the contracting that you work since two weeks and have still not signed a NDA.
Next sentence is: I don't fear to not get my money, but currently I don't know if you pay or someone else...
I confess, I'm an old guy, who was around when Open Source was still young. Being able to read the code, learn to be z better programmer, tweak it to my needs, control what was running on my machine.
Reading other comments on this thread it seems like the mood has shifted. Now there seems to be an expectation that Open Source means "you should promptly review and accept my changes".
There is much wailing that corporates (who, by the way, never used to release code at all) are somehow at fault for either existing, or not responding quick enough or requiring paperwork(!).
I'm not sure when pushing code upstream to Open Source became an entitlement. I'm pretty sure it wasn't there at the beginning and it's nor part if any license I'm aware of.
Well, there's a flip side of that, which is that all our critical infrastructure is now open source.
And if you're comparing where we're at now, culturally, with where we were at in the early days of the internet - John Postel, the RFC process, the guys building up the early protocols, running DNS and all that - there's been a different kind of shift.
The way I look at it is, a lot of us hackers (the category I'd put myself in), academics, and hardcore engineers who worked in industry but didn't give a damn about anything except doing solid work other people could rely on - we built up the modern tech stack, and then industry jumped to it as a cost cutting measure and it's been downhill from there.
And this puts us all in a real bind when the critical infrastructure we all rely on is dominated by a few corporate giants who still have the mindset that they want to own everything, and they only pay lip service to the community and even getting bug fixes in if it's something they don't care about is a problem.
This mindset invading the Linux kernel is a huge part of the reasons for the bcachefs split, btw. We had a prominent filesystem maintainer recently talking openly about how they'll only fix bugs if they feel like it or as a part of a quid pro quo with another established player - and that's just not OK. Open source is used by the entire world, not just Google/IBM/Facebook/Amazon.
"How we manage critical infrastructure as a commons - responsibly" needs to be part of the conversation.
Maybe you are saying this is an improvement over the old days, in that the corporations now at least accept open source contributions, even if they are slow at doing it. I think the contention is that corporations are not merely slow at handling open source contributions, but in fact they are a drain on those contributors time and goodwill because they are incompetent. The end result is that some contributors give up and go elsewhere, and corporate-backed projects lose trust over time.
It might have been better if Oracle just said "we don't have the bandwidth to handle open source and we don't want to waste your time, please submit your patches to this other fork and we will merge when we get around to it."
There’s also entitlement from just using it: my org uses your software and there’s what we consider is a bug so you MUST fix it as asap as possible and in the future don’t release buggy software because it costs us time and money.
"Self-service doacracy" rather than "look at me and fix my 'world-ending' problem for me for free right now". While I applaud creating patches and submitting them upstream, there's zero obligation to review or accept them... just throw them out there and let whatever happens happen in its own time.
It's my tailbone and an old torn back injury; I can't sit or stand for longer than 2 hours and I think I need to swap my Aeron classic size B for a C.
Most of Meta's groups' approach to FOSS is throwing piles of sticks over a wall. They don't even check code can build, that it doesn't have some internal-only dependencies, and don't even care if they break other groups' code. The timeline for very minor bug can also be on the order of months to years because everyone working at the business is focused on shipping "impact" to keep their job when the next performance review/layoff round comes along.
And that's... fine. They're still giving away their code, and anyone is free to step up and mke sure that it builds or that internal dependencies are replaced.
And it's a completely standard situation for non-corporate open source software, too. OpenSSH, for instance, has OpenBSD-specific dependencies and can only be run on Linux because of the porting efforts by a separate group of volunteers.
Sure, it'd be event better if they went out of their way to facilitate external participation, but they don't have to. Not even GNU does so for everything they publish!
tl;dr: There's a spectrum of FOSS varying from performative crap to usable.
You're conflating the differing treatment of projects where there is much investment and community usability like react, ones that are half-assed like edenfs, and the zillions of others that aren't even explained clearly what they do or what they're for.
> anyone is free to step up and mke [sic] sure that it builds
On thrown-over-the-wall projects, there's too many inside-baseball gotchas and little/no documentation. Effort by others are generally unrealistic and a waste of time that won't be merged since there are rules and limitations for community contributions. The vast majority of tiny and obscure projects, MAANG code is useless to average people working on average problems because the burden to make it work is as much or more than reinventing it themselves.
> or that internal dependencies are replaced.
This is hand-waving away reality. No average engineer for reasonable effort is going to be able to reproduce an undocumented API for unreleased kernel extensions/FUSE/etc. for Mac, Windows, and Linux to make edenfs work.
Another case in point: Hack. No documentation and no portable build instructions/toolchain.
React and react native are in a different class where there is meaningful community participation and investment. Whereas hack, edenfs, and chef cookbooks is/was mostly thrown-over-the-wall stuff. There are a few projects in the middle like watchman that update code using an opaque internal->external export process without a whole lot of documentation or clear changelogs, but it's still semi-useful.
The spirit of FOSS is cheapened by flooding the zone with too much stuff on the side of crap. It's better to release less stuff that's well-supported with meaningful community engagement rather than create noise. But if you're fine with a blizzard of noise that isn't useful to anyone else, that's cool for you. Everyone is free to do what they want to do, even if it's trying to make partially-released stuff work when it would've been faster to rewrite from scratch.
I have been trying to upstream patches to kubernetes and etcd for about a year and ended up giving up. It is impossible to get someone from the project to review my PRs, and since I cannot get PRs under my belt I can not become a maintainer either.
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.
I haven't seen your PRs and I don't work on those project. I have small projects that receive few patches.
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.
Your first example should be solved by the maintainers outlining clear contribution guidelines. It’s not hard to point some automation at a pr and comment if someone didn’t follow contribution guidelines.
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.
I don’t think there is a simple “fits-all” solution.
In my case there is a monetised proprietary “enterprise” edition of the projects available.
Contributions only get accepted if they fit into the commercial roadmap, which is shaped by the (paying) customer needs.
It’s not perfect but the OSS “community” edition is still usable and valuable to many
Thanks for taking the time to reply. I agree that there's no "fits-all" solution & I think that's a good sign of the open-source ecosystem's diversity.
I haven't seen static analyis cover the things I'm concerned with.
Examples, calculating something twice instead of pulling the calculation out of the loop (one case) or into a separate function so that 2 separated places where it's calculated don't get out of sync (a different case). Another might be using an let x; if (cond) x = v1 else x = v2 (which is 3-9 lines depending on your brace style) vs const x = cond ? v1 : v2. When v1 and v2 are relatively simple expressons. I haven't seen a checker that will find stuff like this.
If just close pr without explanation. In contributing guidelines I’d mention that low quality prs will be closed as they waste time and "why was it closed without explanation?" won’t be answered either because it would waste time and the whole point is not to.
It isn’t a me problem, I have had no issues upstreaming patches to other projects which have responsive maintainers but etcd and k8s just seem to be straight up mismanaged. I read contributors.md, I make sure all the linters pass, I make sure all the tests pass, I sign off the commits with my real identity to fulfill the CLA.
Yes there is a lot of garbage out there, but for the people who are actually trying to fix issues it is impossible without an insider within the project.
I say almost exactly the same thing about agent changes, but the impression I get from people heavily using agents is that they are plenty more flexible about what the code looks like than I am.
I am starting to suspect that it is a personal failing of mine to require that all my code looks consistent within a single project.
Well run projects I have contributed to have linters which fail on bad code style. Ask the submitter to make the linter happy before you review the code.
> Well run projects I have contributed to have linters which fail on bad code style. Ask the submitter to make the linter happy before you review the code.
Linters can't catch most things that are not syntax-style; i.e. linters can't catch semantic style.
Here is code CC generated this morning for me:
size_t bvks_tls_read (bvks_tls_t *tls, void *dst, size_t dst_len)
{
int ret = wolfSSL_read (tls->ssl, dst, (int)dst_len);
if (ret > 0)
return (size_t)ret;
if (ret == 0)
return 0;
// ret < 0, error case
int err = wolfSSL_get_error (tls->ssl, ret);
switch (err) {
case WOLFSSL_ERROR_WANT_READ:
case WOLFSSL_ERROR_WANT_WRITE:
errno = EAGAIN;
break;
case WOLFSSL_ERROR_SYSCALL:
// errno already set by the underlying socket call
break;
default:
errno = EPROTO;
break;
}
return (size_t)-1;
}
size_t bvks_tls_write (bvks_tls_t *tls, const void *src, size_t src_len)
{
int ret = wolfSSL_write (tls->ssl, src, (int)src_len);
if (ret > 0)
return (size_t)ret;
if (ret == 0)
return 0;
// ret < 0, error case
int err = wolfSSL_get_error (tls->ssl, ret);
switch (err) {
case WOLFSSL_ERROR_WANT_READ:
case WOLFSSL_ERROR_WANT_WRITE:
errno = EAGAIN;
break;
case WOLFSSL_ERROR_SYSCALL:
// errno already set by the underlying socket call
break;
default:
errno = EPROTO;
break;
}
return (size_t)-1;
}
One of those is both hard to maintain and has precision (and potential overflow) bugs.
The other isolates the potentially buggy behaviour, validates it, and ensures that future changes to fix size_t/int precision loss bugs only has to be done in a single spot.
No linter is catching that style. It's more "coding style" than "syntax style".
It’s not worth the time. You will spend uncountable hours of (unpaid) extremely exhausting labour talking to people who only care about solving their personal super specific problems. This is true for 90%+, there are exceptions but they are exceedingly rare
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.
I'll add that for small projects, (and I suppose large ones) it's also a "unwelcome" task. Kinda like docs is.
Open Source projects are typically done by people who like coding. Writing docs, reviewing PRs, "management" are all chores, not fun parts of the project.
I manage a couple of projects that get submissions. Handling that is really not the fun part of my day. Fortunately I get very few. I can understand why ones that get a lot see it as a burden, not as the great gift the submitter thinks it is.
Personally I don't want to spend hours each day reviewing PRs. That's not what I signed up for.
One problem with tests is that every project has different philosophies on how to write and how to organize tests. Others have no way of running them locally because it‘s all CD, and often figuring out how to write and organize tests takes longer than fixing the bug itself. Or the stack has little support for running just one specific test (aka the test you‘re trying to write). Or tests need resources you don’t have.
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)
I think if I were a random Google employee submitting Kubernetes patches at my day job-- i.e. not a project maintainer, but just someone in the K8s org chart-- I'd be kind of annoyed if I got cold-emailed asking me to help merge their patches. I'd probably trash that email and assume it was some kind of scam.
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.
Github suggests reviewers to PR authors based on who's been modifying nearby code recently (ok, I don't know whether that's a general policy, but it happens to me all of the time). And for the past year or so I have been getting tagged to review more and more AI slop from newcomers to the project that we chose to maintain in public. I just immediately nope out of all reviews now if I don't recognize the submitter, because I don't scale enough to be the only actual human involved with understanding the code coming at me. This sucks for the newcomers who actually wrote the patch themselves, but I can't always tell. Put some misspellings in your comments and I'm actually more likely to review it!
> It is impossible to get someone from the project to review my PRs
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.
> According to the above, I bet that "mandate" is a total fake; a PR move only.
The CNCF is a registered non-profit and they have a legal duty to fulfill their mandate.
Like I said, it isn’t worth my time fighting this, I just keep local patches now. Etcd is such a dead project that my patches almost never have had conflicts with new releases, because nothing actually changes in etcd because they don’t facilitate external contributors.
If getting people to review code is that hard that seems like a problem for our new AI age. AI coding appears to rely on getting people to review a lot code and assumes those people will catch the errors.
From my view a lot of the problems of current AI is that people assume others will review and catch any issues. The manual work is getting pushed around like a hot potato.
I know Java has a complicated history of ownership, but I'm not sure I understand why Oracle is able to block contributions to OpenJDK. I thought the point of OpenJDK was to be separate from Oracle. I'm not a Java developer, just curious how this works.
It's still their project and the Oracle Contributor Agreement means they get to asset joint ownership of your contributions.
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.
So TL;DR I'm right to be skeptical of everything Java because even OpenJDK is pretty much owned and controlled by Oracle? Good to know. I'll keep avoiding it like the plague then, with slightly more confidence:
Not really. OpenJDK is exactly what OpenJDK is, and there are plenty of builds provided by other vendors who have nothing to do with Oracle. All Oracle "owning" it really means is that they basically have unilateral ability to make changes to Java[1], where said changes will be reflected in their official binary releases. And they charge for their releases (and have some auditing / licensing terms which many find off-putting) which is only important if it's really important for you to use an Official Oracle Build for some reason, as opposed to Eclipse Temurin, Amazon Corretto, BellSoft Liberica, Red Hat's build, etc.
Personally I just use the OpenJDK builds provided by my linux distro and never give it a second thought.
[1]: And so far, Oracle haven't shown much, if any, propensity for abusing their control of Java. There's a process and they seem to mostly stick to it.
Oracle might only accept upstream contributions but OpenJDK is GPL2, so anyone can host their fork of OpenJDK with whatever GPL2-licensed patches they like, regardless of the OCA/CLA being signed. Indeed there are enough distributions of OpenJDK that there's a site for picking which is best for you. I can't really speak to how current that information is, or how good it is, but it exists: https://whichjdk.com/
But yes, you might be right to be suspect of Java as a whole if this is how they treat contributors.
It's worth noting that many larger open source projects have contributor agreements to strengthen their rights for redistribution that a standard license might not cover. What if they want to change the license? They don't want to be hamstrung by a million contributions. Moral rights are something you often see. And severability might also be a concern. Some like the OCA are worse than others. The Python one is pretty good because it limits any future relicensing to open source. https://www.python.org/psf/contrib/contrib-form/
OpenJDK is the "default" implementation of Java and it's maintained by Oracle. Beyond that, there exists at least OpenJ9, which is a completely independent implementation, maintained by Eclipse Foundation.
It's not common for a random company to gatekeep contributions to a community project, and OpenJDK brands itself as a community project that's more or less independent from Oracle.
Corporations love open source when it delivers working code to their doorstep. They hate open source when it comes to actually maintaining and managing a community of developers who really do care about and use the core product.
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.
I'll be honest, I'm not sure why you're aggrieved here.
There's absolutely nothing in the "idea of Open Source" that suggests upstream has to accept contributions. Open Source allows you to tinker with the code, not force your changes on others.
Equally you are welcome to not sign anything you font want to sign. There are reasons for those docs, there are reasons to not sign them. It's completely your choice.
And of course you are free to fork anything anytime you like. You're even free to encourage others. So no beef there.
I presume you have at least followed your in principles here? I'm guessing you have forked Linux, and your browser, and your favorite language? And office suite? Posting links here would likely attract others who object to corporate development joining you.
There are active forks of the SDK. What are you talking about? You're mad at me for razzing a corporation in the name of open source?
Did I accidentally leave "hacker" news?
Or is this "hope to get a job in the valley" news? Apparently the best way to do this is become a rank bully and operate in bad faith wherever possible. I'm glad I left when I did.
When I want to contribute to an open source project, I throw together some trivial but useful patches and see how the project responds.
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.
This is the way. I disagree with your 24-hour timeline -- give it a week -- but whether and how they respond tells you a lot. Being welcoming to new contributors is crucial for the health of a project.
One time I was interested in contributing to an important part of some project, a part where they were nowhere and in dire need of help. As a first try I submitted a small patch correcting the README's build instructions, which were obviously wrong in one place. I got a lot of attitude and hostility, and they refused to accept the fix. Yeah, bye.
Have you found this actually works? I wouldn't be surprised if many projects happily accept trivial PRs (because they're easy to deal with) but then ignore or naysay anything more substantial.
Despite their OSS contributions, and the fact that they have their own Linux distro, oracle is one of the worst companies to deal with in terms of OSS. Very NIH syndrome, very gatekeep-y. I refuse to use grub because I know I'll never get bugs fixed since oracle claims ownership of the repo there as well.
All of the https://github.com/AOSC-Tracking/jdk/ links 404 for me, so it's difficult to get a sense of what was being done. Going off of the "loongson fork" links though they look rather trivial. Not saying they should be ignored, but I do think trivial PRs to large critical open source projects like JDK can often end up taking more time away from contributing engineers doing reviews and testing than they are worth.
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.
But that's not what's happening here, right? They're blocked on having their 'Oracle Contributer Agreement' approved; they're not even at the stage where their PRs are eligible for being ignored.
Oh yeah, Oracle; if you want to see where contributions come die see mysql-operator - ton of stuff broken, pull request fixes (like most obvious, no-brain bugfixes) slurped into bugs.mysql.com oblivion never seeing the light of day
I have this theory that with LLMs getting better at writing code our current open source model (relatively few large projects that everyone contributes to, relatively rare to maintain your own fork) will invert and it will be easier and more common for people to have personalized forks and a lot of the problems around managing large open source projects will just become irrelevant
Temurin and others are "distributions" of OpenJDK, basically their compilation results of it, not their own codebase. They're not "forks" in terms of source code, but they have patches, build systems, QA, and everything else around it that they apply, then offer you their version of it.
OpenJDK: where Java is developed
Temurin / Zulu: where OpenJDK is built, tested, packaged, and supported
> The phrase "Chinese Mainland" when used in English comes loaded with the suggestion that Taiwan is rightfully part of China — it is an unavoidable implication.
I'm really curious - what people did you get this idea from? I've never heard this before. I have heard "mainland China" to mean, specifically, "China, not Hong Kong or Macau", from:
- Taiwanese people
- Hong Kong people
- Mainland Chinese people
- Taiwanese-americans
- Chinese-americans (immigrated from the mainland)
It's just mainland China (大陆）. I have never met Chinese or Taiwanese people who feel this is a politically loaded term.
> The phrase "Chinese Mainland" when used in English comes loaded with the suggestion that Taiwan is rightfully part of China
For better or for worse, many people on both sides of the strait have used language along these lines that suggests that Taiwan is part of China for decades and probably even since a bit before 1949 (I was not alive at the time). I think that, at this point, the term “mainland China” is just the default.
That being said, a person from China could just say they’re from China and no one would be confused. This is in contrast to someone saying they’re Chinese, which can be ambiguous.
Interesting, when I've come across this before I have always interpreted it as "not from Hong Kong", especially in a context like this where it's raised in the context of engaging with a western counterpart's potential suspicion.
It's been my experience that westerners (I am a westerner) do have different assumptions about "mainland" Chinese people than people from Hong Kong who are assumed to be more cosmopolitan, "westernized", or even "politically neutral" from a western liberal capitalist perspective, so it seems reasonable to point it out in this context.
AFAICT both the Beijing's narrative and the Taipei narrative assume that "mainland China" and Taiwan should ideally be the same state, but the completely diverge in their notion of what state that should be: PRC or ROC.
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.
Agreed, although things I immediately think of are:
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.
That again assumes a project is looking to 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.
They keep stringing him along in the process to onboard him as a contributor. The issue is the split personality in wanting but not acting on onboarding, with no meaningful communication. Your last paragraph about bureaucracy is exactly the complaint of the post. I don't see it as a defense. We can all throw our hands up and say "shit happens", and we can all agree it invariably does happen sometimes, but it's not a defense, per se.
Is the project clearly documented as being written in GNU C++ rather than standard C++? If not, anything that's accidentally invalid C++ is fair game for bug fixes, is it not?
If all of these things are about making it build under clang though they need to better explain it or maybe group these changes together though.
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
Even if the changes aren't "meaningful" (which it seems like they are), they still have an impact in how it makes the contributor more comfortable with working on the project. No new contributor is going to start with making massive patches without starting out with some smaller things to get a feel for working with the project.
Agreed, these seem like ideal patches to me for a first contribution. Solves a specific problem, doesn't require a lot of effort on maintainers side to review, and should give them a straightforward path to familiarise themselves with the process.
Regardless of the contents,
> 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.
Anyone who has been a freelancer negotiating a contract with a big company feels this sort of thing in their bones.
Never had this issue. Its just as simple as start to work without contract and the promise of department head to get a contract and after two weeks mention to the contracting that you work since two weeks and have still not signed a NDA.
Next sentence is: I don't fear to not get my money, but currently I don't know if you pay or someone else...
compiler error: `since(time_point_t)` cannot be called with `time_duration_t`
were you trying to use `for(time_duration_t)` ?
I confess, I'm an old guy, who was around when Open Source was still young. Being able to read the code, learn to be z better programmer, tweak it to my needs, control what was running on my machine.
Reading other comments on this thread it seems like the mood has shifted. Now there seems to be an expectation that Open Source means "you should promptly review and accept my changes".
There is much wailing that corporates (who, by the way, never used to release code at all) are somehow at fault for either existing, or not responding quick enough or requiring paperwork(!).
I'm not sure when pushing code upstream to Open Source became an entitlement. I'm pretty sure it wasn't there at the beginning and it's nor part if any license I'm aware of.
Well, there's a flip side of that, which is that all our critical infrastructure is now open source.
And if you're comparing where we're at now, culturally, with where we were at in the early days of the internet - John Postel, the RFC process, the guys building up the early protocols, running DNS and all that - there's been a different kind of shift.
The way I look at it is, a lot of us hackers (the category I'd put myself in), academics, and hardcore engineers who worked in industry but didn't give a damn about anything except doing solid work other people could rely on - we built up the modern tech stack, and then industry jumped to it as a cost cutting measure and it's been downhill from there.
And this puts us all in a real bind when the critical infrastructure we all rely on is dominated by a few corporate giants who still have the mindset that they want to own everything, and they only pay lip service to the community and even getting bug fixes in if it's something they don't care about is a problem.
This mindset invading the Linux kernel is a huge part of the reasons for the bcachefs split, btw. We had a prominent filesystem maintainer recently talking openly about how they'll only fix bugs if they feel like it or as a part of a quid pro quo with another established player - and that's just not OK. Open source is used by the entire world, not just Google/IBM/Facebook/Amazon.
"How we manage critical infrastructure as a commons - responsibly" needs to be part of the conversation.
But nothing stops you forking it right?
So, if you think a project is too corporate, then fork it.
If the code is any good, sure. Sometimes you gotta start from the ground up and show people how it's done :)
Maybe you are saying this is an improvement over the old days, in that the corporations now at least accept open source contributions, even if they are slow at doing it. I think the contention is that corporations are not merely slow at handling open source contributions, but in fact they are a drain on those contributors time and goodwill because they are incompetent. The end result is that some contributors give up and go elsewhere, and corporate-backed projects lose trust over time.
It might have been better if Oracle just said "we don't have the bandwidth to handle open source and we don't want to waste your time, please submit your patches to this other fork and we will merge when we get around to it."
No, I'm saying that whether a project takes contributions or not has nothing to do with open source.
Yes, lots of projects big and small accept contributions. And lots do not. You might think that's good or bad, but it's unrelated to open source.
You are free to submit patches to whatever fork you prefer. If oracle don't suit you then submit somewhere else.
They. Owe. You. Nothing.
There’s also entitlement from just using it: my org uses your software and there’s what we consider is a bug so you MUST fix it as asap as possible and in the future don’t release buggy software because it costs us time and money.
I have similar thoughts.
Lots of people have to think about “just because you did the work, doesn’t mean it’s valuable for someone else”.
I'm very much from the same era, "stfu and fork it", "PoC or GTFO".
And as I got older, I realized "I am not the customer, there is no money in responding to me, I am a net negative cost to your business".
And uhh... I'll shuffle the F out now then? And try and catch-up on 200 years of math.
I don't think anything has changed IRL, aside from my knees hurting
"Self-service doacracy" rather than "look at me and fix my 'world-ending' problem for me for free right now". While I applaud creating patches and submitting them upstream, there's zero obligation to review or accept them... just throw them out there and let whatever happens happen in its own time.
It's my tailbone and an old torn back injury; I can't sit or stand for longer than 2 hours and I think I need to swap my Aeron classic size B for a C.
Most of Meta's groups' approach to FOSS is throwing piles of sticks over a wall. They don't even check code can build, that it doesn't have some internal-only dependencies, and don't even care if they break other groups' code. The timeline for very minor bug can also be on the order of months to years because everyone working at the business is focused on shipping "impact" to keep their job when the next performance review/layoff round comes along.
And that's... fine. They're still giving away their code, and anyone is free to step up and mke sure that it builds or that internal dependencies are replaced.
And it's a completely standard situation for non-corporate open source software, too. OpenSSH, for instance, has OpenBSD-specific dependencies and can only be run on Linux because of the porting efforts by a separate group of volunteers.
Sure, it'd be event better if they went out of their way to facilitate external participation, but they don't have to. Not even GNU does so for everything they publish!
tl;dr: There's a spectrum of FOSS varying from performative crap to usable.
You're conflating the differing treatment of projects where there is much investment and community usability like react, ones that are half-assed like edenfs, and the zillions of others that aren't even explained clearly what they do or what they're for.
> anyone is free to step up and mke [sic] sure that it builds
On thrown-over-the-wall projects, there's too many inside-baseball gotchas and little/no documentation. Effort by others are generally unrealistic and a waste of time that won't be merged since there are rules and limitations for community contributions. The vast majority of tiny and obscure projects, MAANG code is useless to average people working on average problems because the burden to make it work is as much or more than reinventing it themselves.
> or that internal dependencies are replaced.
This is hand-waving away reality. No average engineer for reasonable effort is going to be able to reproduce an undocumented API for unreleased kernel extensions/FUSE/etc. for Mac, Windows, and Linux to make edenfs work.
Another case in point: Hack. No documentation and no portable build instructions/toolchain.
React and react native are in a different class where there is meaningful community participation and investment. Whereas hack, edenfs, and chef cookbooks is/was mostly thrown-over-the-wall stuff. There are a few projects in the middle like watchman that update code using an opaque internal->external export process without a whole lot of documentation or clear changelogs, but it's still semi-useful.
The spirit of FOSS is cheapened by flooding the zone with too much stuff on the side of crap. It's better to release less stuff that's well-supported with meaningful community engagement rather than create noise. But if you're fine with a blizzard of noise that isn't useful to anyone else, that's cool for you. Everyone is free to do what they want to do, even if it's trying to make partially-released stuff work when it would've been faster to rewrite from scratch.
I have been trying to upstream patches to kubernetes and etcd for about a year and ended up giving up. It is impossible to get someone from the project to review my PRs, and since I cannot get PRs under my belt I can not become a maintainer either.
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.
I haven't seen your PRs and I don't work on those project. I have small projects that receive few patches.
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.
Your first example should be solved by the maintainers outlining clear contribution guidelines. It’s not hard to point some automation at a pr and comment if someone didn’t follow contribution guidelines.
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.
Trust me it’s not being solved by a CONTRIBUTING.md with guidelines.
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)
Can I get your opinion on https://github.com/Judahmeek/frogs as an open-source maintainer?
Edit: https://judahmeek.com/p/we-need-frogs-to-defend-foss may be the better link to start with.
I don’t think there is a simple “fits-all” solution.
In my case there is a monetised proprietary “enterprise” edition of the projects available. Contributions only get accepted if they fit into the commercial roadmap, which is shaped by the (paying) customer needs.
It’s not perfect but the OSS “community” edition is still usable and valuable to many
Thanks for taking the time to reply. I agree that there's no "fits-all" solution & I think that's a good sign of the open-source ecosystem's diversity.
I haven't seen static analyis cover the things I'm concerned with.
Examples, calculating something twice instead of pulling the calculation out of the loop (one case) or into a separate function so that 2 separated places where it's calculated don't get out of sync (a different case). Another might be using an let x; if (cond) x = v1 else x = v2 (which is 3-9 lines depending on your brace style) vs const x = cond ? v1 : v2. When v1 and v2 are relatively simple expressons. I haven't seen a checker that will find stuff like this.
If just close pr without explanation. In contributing guidelines I’d mention that low quality prs will be closed as they waste time and "why was it closed without explanation?" won’t be answered either because it would waste time and the whole point is not to.
> Nonmatching styles can be mostly solved with linting and static analysis
Only syntactical styles. Style also include things like how I want errors to be propagated, how failures are to be handled, etc.
It isn’t a me problem, I have had no issues upstreaming patches to other projects which have responsive maintainers but etcd and k8s just seem to be straight up mismanaged. I read contributors.md, I make sure all the linters pass, I make sure all the tests pass, I sign off the commits with my real identity to fulfill the CLA.
Yes there is a lot of garbage out there, but for the people who are actually trying to fix issues it is impossible without an insider within the project.
Feel free to link your PRs, happy to take a look.
As said in other comment, my PRs are using my real name and my HN account does not, so I don’t want to connect the two by linking my PRs.
https://github.com/google/flatbuffers/pull/8251
https://github.com/google/flatbuffers/pull/8252
Flatbuffers Lua implementation has basic fundamental flaws, couldn't even get an "idc" on their Discord
That's funny :-)
I say almost exactly the same thing about agent changes, but the impression I get from people heavily using agents is that they are plenty more flexible about what the code looks like than I am.
I am starting to suspect that it is a personal failing of mine to require that all my code looks consistent within a single project.
Well run projects I have contributed to have linters which fail on bad code style. Ask the submitter to make the linter happy before you review the code.
> Well run projects I have contributed to have linters which fail on bad code style. Ask the submitter to make the linter happy before you review the code.
Linters can't catch most things that are not syntax-style; i.e. linters can't catch semantic style.
Here is code CC generated this morning for me:
Here is my preferred style: One of those is both hard to maintain and has precision (and potential overflow) bugs.The other isolates the potentially buggy behaviour, validates it, and ensures that future changes to fix size_t/int precision loss bugs only has to be done in a single spot.
No linter is catching that style. It's more "coding style" than "syntax style".
Wouldn’t it be best to ask contributor to reproduce the bug with a test rather than just completely ghost them?
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.
It’s not worth the time. You will spend uncountable hours of (unpaid) extremely exhausting labour talking to people who only care about solving their personal super specific problems. This is true for 90%+, there are exceptions but they are exceedingly rare
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.
I'll add that for small projects, (and I suppose large ones) it's also a "unwelcome" task. Kinda like docs is.
Open Source projects are typically done by people who like coding. Writing docs, reviewing PRs, "management" are all chores, not fun parts of the project.
I manage a couple of projects that get submissions. Handling that is really not the fun part of my day. Fortunately I get very few. I can understand why ones that get a lot see it as a burden, not as the great gift the submitter thinks it is.
Personally I don't want to spend hours each day reviewing PRs. That's not what I signed up for.
One problem with tests is that every project has different philosophies on how to write and how to organize tests. Others have no way of running them locally because it‘s all CD, and often figuring out how to write and organize tests takes longer than fixing the bug itself. Or the stack has little support for running just one specific test (aka the test you‘re trying to write). Or tests need resources you don’t have.
Can you link your PRs here?
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)
My PRs are submitted under my real name and my HN account is not under my real name, so I cannot share.
For my etcd changes I did submit to the correct SIG, but nobody reviewed it.
maybe you’ve already done this and I’m sorry if i’m telling you the obvious.
You could analyze the repo to identify others who have modified the same files. and reach out to them specifically.
I think if I were a random Google employee submitting Kubernetes patches at my day job-- i.e. not a project maintainer, but just someone in the K8s org chart-- I'd be kind of annoyed if I got cold-emailed asking me to help merge their patches. I'd probably trash that email and assume it was some kind of scam.
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.
Github suggests reviewers to PR authors based on who's been modifying nearby code recently (ok, I don't know whether that's a general policy, but it happens to me all of the time). And for the past year or so I have been getting tagged to review more and more AI slop from newcomers to the project that we chose to maintain in public. I just immediately nope out of all reviews now if I don't recognize the submitter, because I don't scale enough to be the only actual human involved with understanding the code coming at me. This sucks for the newcomers who actually wrote the patch themselves, but I can't always tell. Put some misspellings in your comments and I'm actually more likely to review it!
The CNCF may or may not take it seriously. They definitely won't if they don't know.
> It is impossible to get someone from the project to review my PRs
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.
> According to the above, I bet that "mandate" is a total fake; a PR move only.
The CNCF is a registered non-profit and they have a legal duty to fulfill their mandate.
Like I said, it isn’t worth my time fighting this, I just keep local patches now. Etcd is such a dead project that my patches almost never have had conflicts with new releases, because nothing actually changes in etcd because they don’t facilitate external contributors.
If getting people to review code is that hard that seems like a problem for our new AI age. AI coding appears to rely on getting people to review a lot code and assumes those people will catch the errors.
From my view a lot of the problems of current AI is that people assume others will review and catch any issues. The manual work is getting pushed around like a hot potato.
"AI for me, not for thee" kind of thing.
Thanks for your time on this comment.
I know Java has a complicated history of ownership, but I'm not sure I understand why Oracle is able to block contributions to OpenJDK. I thought the point of OpenJDK was to be separate from Oracle. I'm not a Java developer, just curious how this works.
It's still their project and the Oracle Contributor Agreement means they get to asset joint ownership of your contributions.
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.
So TL;DR I'm right to be skeptical of everything Java because even OpenJDK is pretty much owned and controlled by Oracle? Good to know. I'll keep avoiding it like the plague then, with slightly more confidence:
Not really. OpenJDK is exactly what OpenJDK is, and there are plenty of builds provided by other vendors who have nothing to do with Oracle. All Oracle "owning" it really means is that they basically have unilateral ability to make changes to Java[1], where said changes will be reflected in their official binary releases. And they charge for their releases (and have some auditing / licensing terms which many find off-putting) which is only important if it's really important for you to use an Official Oracle Build for some reason, as opposed to Eclipse Temurin, Amazon Corretto, BellSoft Liberica, Red Hat's build, etc.
Personally I just use the OpenJDK builds provided by my linux distro and never give it a second thought.
[1]: And so far, Oracle haven't shown much, if any, propensity for abusing their control of Java. There's a process and they seem to mostly stick to it.
Dude, Oracle controls who can contribute. I don't understand how you can say it has nothing to do with Oracle.
Well, kind of.
Oracle might only accept upstream contributions but OpenJDK is GPL2, so anyone can host their fork of OpenJDK with whatever GPL2-licensed patches they like, regardless of the OCA/CLA being signed. Indeed there are enough distributions of OpenJDK that there's a site for picking which is best for you. I can't really speak to how current that information is, or how good it is, but it exists: https://whichjdk.com/
But yes, you might be right to be suspect of Java as a whole if this is how they treat contributors.
It's worth noting that many larger open source projects have contributor agreements to strengthen their rights for redistribution that a standard license might not cover. What if they want to change the license? They don't want to be hamstrung by a million contributions. Moral rights are something you often see. And severability might also be a concern. Some like the OCA are worse than others. The Python one is pretty good because it limits any future relicensing to open source. https://www.python.org/psf/contrib/contrib-form/
OpenJDK is the "default" implementation of Java and it's maintained by Oracle. Beyond that, there exists at least OpenJ9, which is a completely independent implementation, maintained by Eclipse Foundation.
Isn't OpenJ9 "just" the VM and not the class library? Also it's IBM-backed so it's more a case of pick your poison there.
Where does oracle block contributions?
This was more of an unfortunate lack of attention/prioritization.
Don't assume malice where a simpler explanation exists.
I assumed nothing.
This is very common in all open source projects, not just Java/Oracle.
It's not common for a random company to gatekeep contributions to a community project, and OpenJDK brands itself as a community project that's more or less independent from Oracle.
Corporations love open source when it delivers working code to their doorstep. They hate open source when it comes to actually maintaining and managing a community of developers who really do care about and use the core product.
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.
I'll be honest, I'm not sure why you're aggrieved here.
There's absolutely nothing in the "idea of Open Source" that suggests upstream has to accept contributions. Open Source allows you to tinker with the code, not force your changes on others.
Equally you are welcome to not sign anything you font want to sign. There are reasons for those docs, there are reasons to not sign them. It's completely your choice.
And of course you are free to fork anything anytime you like. You're even free to encourage others. So no beef there.
I presume you have at least followed your in principles here? I'm guessing you have forked Linux, and your browser, and your favorite language? And office suite? Posting links here would likely attract others who object to corporate development joining you.
> that suggests upstream has to accept contributions
Which is why I said they should be forked. There's nothing that suggests "upstream" has any actual significance.
> I presume you have at least followed your in principles here?
Yes. Thanks for asking. I appreciate questions in good faith.
> I'm guessing you have forked Linux, and your browser, and your favorite language?
Hmm.. do I have to sign an agreement to contribute to those? I'm not sure I have. Is this actually comparable?
> Posting links here would likely attract others who object to corporate development joining you.
That's sweet of you.
> These projects should be ruthlessly forked and all corporate development efforts ignored.
Please do and show that it can be sustainable. It’s easy to complain at home. It’s hard to actually keep it going.
There are active forks of the SDK. What are you talking about? You're mad at me for razzing a corporation in the name of open source?
Did I accidentally leave "hacker" news?
Or is this "hope to get a job in the valley" news? Apparently the best way to do this is become a rank bully and operate in bad faith wherever possible. I'm glad I left when I did.
> You're mad at me for razzing a corporation in the name of open source?
No, just that you're just complaining for the sake of it.
> I'm glad I left when I did.
How were you able to read and reply?
When I want to contribute to an open source project, I throw together some trivial but useful patches and see how the project responds.
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.
This is probably the best approach.
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.
This is the way. I disagree with your 24-hour timeline -- give it a week -- but whether and how they respond tells you a lot. Being welcoming to new contributors is crucial for the health of a project.
One time I was interested in contributing to an important part of some project, a part where they were nowhere and in dire need of help. As a first try I submitted a small patch correcting the README's build instructions, which were obviously wrong in one place. I got a lot of attitude and hostility, and they refused to accept the fix. Yeah, bye.
Absolutely. I look at the commit and PR history. Are the maintainers responsive and welcoming?
Have you found this actually works? I wouldn't be surprised if many projects happily accept trivial PRs (because they're easy to deal with) but then ignore or naysay anything more substantial.
The point is only 50% to see if they respond, it's also to start establishing yourself as a known entity to them.
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.
Despite their OSS contributions, and the fact that they have their own Linux distro, oracle is one of the worst companies to deal with in terms of OSS. Very NIH syndrome, very gatekeep-y. I refuse to use grub because I know I'll never get bugs fixed since oracle claims ownership of the repo there as well.
>I refuse to use grub because I know I'll never get bugs fixed since oracle claims ownership of the repo there as well.
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.
GNU GRUB is a GNU project, yes. No idea what OP is talking about https://www.gnu.org/software/grub/
The maintainer section lists 2/3 maintainers being from Oracle -I guess thats what OP means
All of the https://github.com/AOSC-Tracking/jdk/ links 404 for me, so it's difficult to get a sense of what was being done. Going off of the "loongson fork" links though they look rather trivial. Not saying they should be ignored, but I do think trivial PRs to large critical open source projects like JDK can often end up taking more time away from contributing engineers doing reviews and testing than they are worth.
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.
But that's not what's happening here, right? They're blocked on having their 'Oracle Contributer Agreement' approved; they're not even at the stage where their PRs are eligible for being ignored.
The email thread suggests his PRs were reviewed promptly and rejected. Nothing was ignored.
https://mail.openjdk.org/pipermail/hotspot-dev/2026-January/...
iiuc, this mail isn't about his PRs being rejected, it's the OCA submission e.g. the CLA obtention form.
(So his ping "any progress?" apparently fell on the wrong ears, if he wasn't told he had to submit a new application with something corrected...)
I disagree. Trivial PRs are perfect for first contributions, especially to get through the myriad of bots requesting you to sign/review stuff.
Having said that, I would never contribute to a project with a first contributor experience like this one.
I don’t think you and GP disagree. Trivial PRs can be
> 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
I agree but I would also never contribute to a project with a CLA in the first place.
I signed the OCA in 2021 as part of some contributions to GraalVM.
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.
Oh yeah, Oracle; if you want to see where contributions come die see mysql-operator - ton of stuff broken, pull request fixes (like most obvious, no-brain bugfixes) slurped into bugs.mysql.com oblivion never seeing the light of day
Any asipiring commentor should note that dalibor has responded, and it doesn't sound like he's unreasonable
https://mail.openjdk.org/pipermail/hotspot-dev/2026-January/...
And the OP responded too, apologizing for causing confusion
https://mail.openjdk.org/pipermail/hotspot-dev/2026-January/...
I have this theory that with LLMs getting better at writing code our current open source model (relatively few large projects that everyone contributes to, relatively rare to maintain your own fork) will invert and it will be easier and more common for people to have personalized forks and a lot of the problems around managing large open source projects will just become irrelevant
Or a ton of "personalized agents" will start bugging upstream to complain about suspected issues with all those forks all the time...
Why would you want to manage your own fork of everything?
Because that cost can be less than dealing with upstream.
Would there be a difference in contributing to OpenJDK vs to, say, Temurin or Zulu Java? How separated are those Java JDKs really from OpenJDK?
Temurin and others are "distributions" of OpenJDK, basically their compilation results of it, not their own codebase. They're not "forks" in terms of source code, but they have patches, build systems, QA, and everything else around it that they apply, then offer you their version of it.
Thanks for the explanation!
Judging from the whole thread, might just be some misunderstanding of the workflow?
In a response Dalibor Topic claims that he rejected some of his submission have been rejected. So one of them is lying?
why do they waste all that ai writing new patches instead of helping them upstream existing patches?
I am not surprised. Oracle acquiring Sun Microsystems has been the death kneel of open source Java ecosystem.
Never forget: One Rich Asshole Called Larry Ellison still runs this company.
[dead]
[flagged]
> The phrase "Chinese Mainland" when used in English comes loaded with the suggestion that Taiwan is rightfully part of China — it is an unavoidable implication.
I'm really curious - what people did you get this idea from? I've never heard this before. I have heard "mainland China" to mean, specifically, "China, not Hong Kong or Macau", from:
- Taiwanese people
- Hong Kong people
- Mainland Chinese people
- Taiwanese-americans
- Chinese-americans (immigrated from the mainland)
It's just mainland China (大陆）. I have never met Chinese or Taiwanese people who feel this is a politically loaded term.
I think most questionnaires that ask about sanction-related things use the phrasing "Mainland China," I would be unsurprised if Oracle's CLA said that
> The phrase "Chinese Mainland" when used in English comes loaded with the suggestion that Taiwan is rightfully part of China
For better or for worse, many people on both sides of the strait have used language along these lines that suggests that Taiwan is part of China for decades and probably even since a bit before 1949 (I was not alive at the time). I think that, at this point, the term “mainland China” is just the default.
That being said, a person from China could just say they’re from China and no one would be confused. This is in contrast to someone saying they’re Chinese, which can be ambiguous.
Interesting, when I've come across this before I have always interpreted it as "not from Hong Kong", especially in a context like this where it's raised in the context of engaging with a western counterpart's potential suspicion.
It's been my experience that westerners (I am a westerner) do have different assumptions about "mainland" Chinese people than people from Hong Kong who are assumed to be more cosmopolitan, "westernized", or even "politically neutral" from a western liberal capitalist perspective, so it seems reasonable to point it out in this context.
I always parsed it the other way... "Mainland" suggests there's some other part, while China means unified
[dead]
[flagged]
AFAICT both the Beijing's narrative and the Taipei narrative assume that "mainland China" and Taiwan should ideally be the same state, but the completely diverge in their notion of what state that should be: PRC or ROC.
The PRs they link mostly seem like noise? “Remove the d prefix from this number because the C++ standard doesn’t require it”. Yeah great.
That's a pretty unfair characterisation of the commit in question: https://github.com/loongson/jdk/pull/125/commits/ee300a6ce73...
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.
Agreed, although things I immediately think of are:
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.
Given they have one to fix usage of llvm-config, I assume clang is also supported or being worked on.
That sort of patch is clearly fixing something that blocked him, and probably blocked many others who didn't get as far as trying to fix it.
A project should take on useful small patches, thats how you onboard contributors.
That again assumes a project is looking to 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.
They keep stringing him along in the process to onboard him as a contributor. The issue is the split personality in wanting but not acting on onboarding, with no meaningful communication. Your last paragraph about bureaucracy is exactly the complaint of the post. I don't see it as a defense. We can all throw our hands up and say "shit happens", and we can all agree it invariably does happen sometimes, but it's not a defense, per se.
Is the project clearly documented as being written in GNU C++ rather than standard C++? If not, anything that's accidentally invalid C++ is fair game for bug fixes, is it not?
If all of these things are about making it build under clang though they need to better explain it or maybe group these changes together though.
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
Shouldn't small trivial changes be easier to review (and thus maybe even have higher prio)?
If there is a single maintainer of the project, sure.
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.
Even if the changes aren't "meaningful" (which it seems like they are), they still have an impact in how it makes the contributor more comfortable with working on the project. No new contributor is going to start with making massive patches without starting out with some smaller things to get a feel for working with the project.
Agreed, these seem like ideal patches to me for a first contribution. Solves a specific problem, doesn't require a lot of effort on maintainers side to review, and should give them a straightforward path to familiarise themselves with the process.
The d suffix makes it not compile under clang. The PRs seem like mostly small changes that are clear improvements.
The correct quote is: "Remove invalid 'd' suffix for double literals".