I'd start with the question of "why do you consider yourself significantly better?" Are you better at designing clean API's than your peers with the same number of years of experience? Are you a better writer/communicator? Do you have an unusual depth of experience with the end to end sales/design/implementation/support cycle? Or are you a really good coder who makes everyone around you better?

The answer to your question depends on what your answer is. There's no single objective measure of "better". If you're in a big company, the thing that sets a senior engineer apart from a strong almost-senior engineer is mostly about soft skills, so if you're a strong almost-senior engineer trying to convince someone to hire you as a senior engineer and you're focusing on communicating your coding feats, that might be sending the exact opposite of the message you intend. But if you pivot the same concept to "improving the people around you" it probably works in your favor.

There's no universal way to do it, because it depends heavily on what the hiring company/team values, so my personal advice is to (1) focus on your particular strengths, (2) assemble a portfolio to back it up, and (3) package it based on what the team/company values. It doesn't have to be open source. As a hiring manager (to be clear, I was one but am not anymore) I would have happily accepted any incidental materials that interviewees wanted me to see.

What do you consider to be your particular strengths?

I'll give an example in my own case. I was a product person who became an engineer. I have a "senior" title. In terms of the number of years I've been out of college and working, the "senior" title is pretty typical. However, I had actually only written code professionally for 1 year before I got the role. (Though I've actually been coding since I was ~13.) Whether I deserved it isn't for me to judge, but I think my story counts as an example of what you're asking about.

The way I maneuvered it was:

1. I was historically an algorithms nut, which means I do particularly well in a specific type of interview, so I targeted companies that interview this way.

2. As a former product person, by necessity I have over-developed product instincts and soft skills relative to engineers with similar amounts of experience, so I made sure to package that well and target roles that asked for those things. My branding was basically: "You want me because I'm really good at aligning people to get things done without authority, especially when there are lots of stakeholders." Engineering teams almost always prefer having more of that in their engineers to reduce reliance on PM's.

3. I networked like hell. Seriously. Nothing is better at telling hiring managers that you are a dark horse than a mutual professional acquaintance telling the hiring manager that you are a dark horse.

4. I sent out a LOT of applications. I think I sent out somewhere around 50 applications for roles at various levels from entry level (<= 1-5 years) to senior level (5+ years). The vast majority of entry level roles I never heard back from simply because of the number of years of experience. It is what it is. Their loss... or that's what I tell myself anyway.

I don't think any one of those four things was singularly responsible for the eventual outcome, but I can say for sure that they all made a difference. Also, I can say that #3 was the single biggest factor in my yield rates. If you look at the split, I got a first interview in something like 80% of my referred applications and 10% when it wasn't a referral. That's both evidence that networking really works, and evidence that the hiring pipeline sucks. The best way to consistently punch in above your general metrics is to not go in through the front door.