A few often overlooked ways to contribute:

• artistic contributions: logos, banners
• user interface design (I wish more UX folks participated in OSS, many projects could use the love)
• improving documentation: as a new and/or novice user, you’re probably more sensitive to jargon that developers overlook and can help make documentation more useful to others like you
• accessibility testing: testing software using accessibility settings like high contrast color schemes and screen readers. these use cases are often overlooked
• project management: participate in the issues, see if the team wants help triaging or managing a discussion/chat platform

Even if not code, some of these are quite specialized. Just be realistic about where you can add something useful.

For all of these, it is critical that you first contact the maintainers and ask what they would find useful. Be mindful that it’s also work for the maintainers to manage your help. The only “wrong” way to participate in open source is to drop a bunch of work on someone unprompted.

Generally, if a project already has a clear call for contributions or a contribution guide, that is a good indicator that the maintainers are willing to do a bit of community management to bring in help. I would only suggest investing energy in those projects if you have the choice.

If you’re just looking to get started with 3d modeling, it’s hard to beat Blender. At the cost of free, it’s by far the most affordable way to dip your toes in some modeling tools.

For many workflows it’s world class. If you plan to do more organic forms or don’t need technical precision, then it’s very competitive or preferable to paid software.

You might find it lacking if you plan to do parametric or technical CAD-style modeling. Even then, I think Blender can be a low cost way to learn what you want in your software before investing in more specialized software. You’ll learn enough of the modeling basics to more fluently navigate what other software provides.

Permissive licenses permit a broader range of use compared to “copyleft” licenses.

“copyleft” here just being a cute way of being the opposite of copyright - instead of disallowing others from what they can do with “copyrighted” code, “copyleft” requires that they (upon request) share modifications to your code.

Permissive takes away this requirement to share your modifications. “copyleft” is considered more free and open source (FOSS), permissive is more business friendly.

I’ve been there, but over the years I’ve gotten better at avoiding being in this situation.

If you are implementing something for yourself, and merging it back upstream is just a bonus, then by all means jump straight to implementing.

However, it’s emotionally draining to implement something and arrive at something you’re proud of only to have it ignored. So do that legwork upfront. File a feature request, open a discussion, join their dev chat - whatever it is, make sure what you want to do is valued and will be welcomed into the project before you start on it. They might even nudge you in a direction that you hadn’t considered before you started.

Be a responsible dev and communicate before you do the work.