I ran a major code beautifier for about 10 years used by tens of thousands of developers. Having a major project like this didn’t turn me into a celebrity or win me any opportunities. I still needed a resume and had to wait for people to reach out to me as any other regular applicant.
It did, however, differentiate me at interview time. I could demonstrate an ability to solve hard problems with original solutions in a way others could not. I could demonstrate product management like an expert where other developers where not even a beginner. A massive project like this really allowed me to utterly destroy the competition when trying to get that job, but only as I talked through the value of that experience.
Having this sort of experience also created some major frictions, though. You might look like a rock star during the interview but there is a huge difference between what they want in theory versus practice. If you are coming into an organization that isn’t as obsessed with product quality or user fulfillment as you they won’t care how good you are or how good the product could be. This is especially true of your developer peers who have never contributed to open source. Instead they will care only for the popular mediocre way of doing things that you have learned hard to abandon in search of quality and performance. Any attempt to raise the bar, increase developer performance, or execution speed with be met with disdain and immediate hostility.
After going through frictions like those for years I have learned to settle. I still hate giant frameworks and the billions of packages developers with hide behind to avoid writing code or learning anything works, but have learned to accept that nobody cares until the business is ready to fire people. I just wish developers would at the very least give two shits about writing some basic documentation but even that feels like asking for too much.
At the very minimum at least learn to write good documentation.