In tech people are always inventing newer, faster, better ways of doing something. When you’ve been struggling or just annoyed with how a particular existing tool works then switching to the shiny new thing that’s better in some way is very tempting. It can be worth doing this but if the new tool is pre 1.0 then you’re also taking on some risk. You will have to deal with breaking changes. It’s possible a feature you are using could be removed or changed into something that doesn’t fit.

It could be well be worth the risk if what the new tool does is worth it for your process. Assuming it’s open source, you should definitely pay more attention to what’s happening with the development process of the tool. Checking issues and commits as if the project was internal to your org lets you figure out where things are likely to go. Having a canary build that runs your tests against the master branch daily will also help you catch issues as they happen.

If there are issues that are specific to how you are using the tool then you’ll likely have to make PRs and advocate for getting them merged. If you have to do this then, of course, try and make what you want to add as generically useful as possible. There are lots of different workflows out there so if your PR forces things to happen the way you do them it might be harder to get it in.

What libraries or tools are you relying on that are pre 1.0? Do you know what’s happening with them?