what is the best way to go about being an active, influential FOSS contributor?
The two goals I bolded that you seem to be asking about are quite different.
Many open source projects start because a person has a problem, and they want to share their solution with other people (the original developer is altruistic) as well as collaborate with others on solving the problem if it's non-trivial. This is often called scratching one's itch.
To take this path, contribute to a project that you personally use - identify what this project can do better that you would benefit from, implement those changes and submit them to the project. Start with a small change and if successful, move on to bigger changes. For example, almost all open source projects can benefit from documentation improvements.
The other thing that you asked about is influence. To answer this part, consider who develops open source projects:
- Some are developed by individuals. In most such projects, the developers are volunteers - they are not paid for their work on these projects, and they do this work either out of altruism or self-interest.
- Some are developed by full time company employees. In these cases the code is available under an open-source license just like with the volunteer projects, but people who work on these projects actually are paid to do so by various companies.
Influence is, basically, you telling the project what it should do. Sometimes you would do part of the work (such as proposing a new feature). Sometimes you wouldn't do much work (such as asking the project to triage issues). In virtually all cases, the current maintainers have to do some work to fulfill your request. It could be a small amount like responding to your inquiry. In many cases it's a lot of work, for example ensuring that the new feature you are proposing doesn't break the software for its existing users.
Why would the project do as you want?
- Volunteer developers don't get paid to implement someone else's ideas. So, the best strategy is to convince them that the idea is worthwhile. Since their time is often severely limited, this is often Very Hard. Often people may agree with you that your proposal is a Good Thing, but they don't have the resources to actually do the work. This is when you hear:
responses are typically "oh yeah, we'll get to that later."
- Companies already have roadmaps that their developers are working on. More often than not you wouldn't see these roadmaps unless you were employed by the company in question. But the effect is roughly the same - the company may agree with you that your idea is a nice one but they are already committed to implementing X other features that other teams in the company are expecting, that are in the sales/marketing pipeline, etc. You see this as:
There is a lack of transparency across large projects.
But you are likely mis-assessing their response with:
aren't accepting of new ideas and innovations even if they are backed up with facts and statistics
Most likely it's not that the companies think your ideas are bad, or wrong, but rather there are factors you aren't aware of (that may have been existing for a long time already) that inform the company's commitments and priorities.
Thus...
Open source is an area where everyone can contribute, but not everyone can be in charge.
As another answer notes, open source is for the most part a meritocracy, meaning those who do the work get the most say in how the work is done (but, especially in corporate-backed projects, following rules is a requirement, and sometimes there are many rules that must be followed, frequently too many for casual contributors to get through; this is why many large projects are in fact developed primarily by employees of the companies backing them). For most projects, the path to influence is through significant contributions, over a significant period of time (months, minimum). The more active and significant a project is, the more effort generally has to be expended to arrive at a position of influence. But if you think about this objectively it shouldn't be surprising.
One venue that you may consider is taking over maintainership. There are projects out there that were built by developers who no longer use them (because they changed jobs, industries, technologies they work with, etc.). Some of these projects say that they are looking for a new maintainer. Sometimes you can become a maintainer of a project that isn't looking for a maintainer but is clearly unmaintained (I personally have done this with pycurl years ago). This route can be easier than getting a voice in an active project, where you have to compete with other developers for the privilege, but still requires work because you would often need to convince whoever has the current admin password that giving you the admin access is good for the project and isn't just good for your ego. This, again, is easiest to do through contributions.
You say:
Most projects I've encountered have stale issues that just sit there without activity from years past.
These issues are waiting for someone to tackle them. When the issues are open, this means the current maintainers (people or companies) agree they should be done, but lack resources. You can take on any of these issues that appeal to you, but keep in mind what you are asking the maintainers to do with your contribution. Are you in fact following the rules, like commit messages? If not, a maintainer has to adjust your contribution prior to accepting it. Does your contribution have tests? Documentation? Etc. Think about all of the objections you have but instead of trying to get around them, find a project that agrees with how you would like to work, and try to comply with as many of these proactively as possible. Make it as easy as you can to accept your contribution. Try to make your contribution appear as if it came from the regular maintainers/developers on the project.
Lastly I would like to address this:
I don't think that adding another contributor to an already large project will do myself any good (as far as growth is concerned)
As a maintainer of a good sized project, I can tell you that in a large project there are many meaningful contributions that can be made, that are localized to a part of the whole project, and that require a lot of work. These types of contributions are definitely meaningful enough to, for example, talk about at a job interview, but they aren't anywhere close to changing direction, scope or functionality of the project overall. If you wish to build experience for the purposes of changing jobs, it can be more valuable to implement a change like this in a well-known project, especially in the field in which you seek employment, rather than be the boss of an obscure project, because this shows you are a team player as pointed out in another answer, can work well with others, understand scope and requirements, and can work in decently large codebases. These are skills that are hard to evaluate in a 30 minute interview.
