If you’re looking to make money, I don’t recommend you get into open source. I wish this weren’t the case, but this is the current situation.
Unfortunately, it seems the best path if you want to do open source as a career is to do enough open source to get your name out there and then leverage that into a job offer at some megacorp. Maybe you’ll be able to get a role doing open source, but that’s rare. Hopefully you can continue to do open source in your free time at least.
That said, if you insist your goal is to get paid doing open source full-time, here are my tips:
1. Create a project that is end-user facing. No one is aware of which transitive dependencies they are using, so no matter how useful your software, you’ll struggle to get donations, sponsors, or consulting work unless the end user knows your name. Reliable, error-free transitive dependencies are invisible. Therefore, the maintainers are invisible, too. And, the better these maintainers do their job, the more invisible they are. No one ever visits a GitHub repository for a transitive dependency that works perfectly – there’s no reason to do so. But a developer investigating an error stack trace might visit the repository if for no other reason than to file an issue. At least then there’s a small chance they’ll see the maintainer’s plea in the README. (I wrote more about this here: https://feross.org/funding-experiment-recap/)
2. Make sure it’s something that the enterprise cares about. If you build a cool P2P project or a new programming language you’re gonna have a tough time. No matter how useful or innovative the project is. On the other hand, if you’re making a front end framework or a UI library for React or something like that, you’ll have a much better shot at getting companies to sponsor your project.
3. Don’t be afraid to ask for money. Contact companies that are using your library and tell them you want them to sponsor your package. One great hack for finding out who is using your package is to open an issue called “Who is using this?” and ask for testimonials or offer to put users’ logos or links in the README under a “Who uses this” section. Lots of developers will out their companies as users of your package if you do this. This gives you a good list of companies to initially reach out to. Without tricks like this it’s impossible to know who’s even using your package. That’s the first to step to finding sponsors.