> For a lot of people and teams, having to know about and rely on a bunch of third party dependencies (not seldom the effort of one or a few developers without financial support) is not a positive thing. Not saying these specific gems are a problem.
I think this is a really great discussion point btw because depending on a ton of 3rd party libraries that come and go can be an issue for sure.
But at some point you need to live in the moment and align your expectations with the current reality and think about what happens to your code base if the library stops being maintained.
For example, strong migrations has a 5+ year track record and shows no signs of dying. It doesn't make sense to live your life in fear and avoid 3rd party libraries because one of them might go away in the future because the maintainers get bored or stop using it. Because what happens if that doesn't happen and it ends up being wildly popular and maintained for years?
The reality is a lot of people develop libraries, use it for a while time and then move on. This happens in Elixir too. The ExAWS package comes to mind (the most popular AWS package for Elixir). Similar things happened with Arc (file uploads) too. Eventually those tools got replacements or new maintainers.
If you're developing an application it makes sense to weigh the pros and cons on using certain libraries but it's not like these libraries immediately go away. Usually there's a huge amount of notice before a library becomes officially dead. There's also tons of opportunities to talk with the authors and collaborate with the community to keep it going. And in this case, the outcome is likely a lot better than you trying to develop a custom solution in total isolation that's not open source.
So yeah, there's really no downside to using most 3rd party libraries. Either it fits your app well enough and continues to be maintained while you happily use it (and maybe contribute back changes), or it fizzles out and you got some value out of it and now you have a great head start in implementing a custom solution from it for your unique use case.
I think this is a really great discussion point btw because depending on a ton of 3rd party libraries that come and go can be an issue for sure.
But at some point you need to live in the moment and align your expectations with the current reality and think about what happens to your code base if the library stops being maintained.
For example, strong migrations has a 5+ year track record and shows no signs of dying. It doesn't make sense to live your life in fear and avoid 3rd party libraries because one of them might go away in the future because the maintainers get bored or stop using it. Because what happens if that doesn't happen and it ends up being wildly popular and maintained for years?
The reality is a lot of people develop libraries, use it for a while time and then move on. This happens in Elixir too. The ExAWS package comes to mind (the most popular AWS package for Elixir). Similar things happened with Arc (file uploads) too. Eventually those tools got replacements or new maintainers.
If you're developing an application it makes sense to weigh the pros and cons on using certain libraries but it's not like these libraries immediately go away. Usually there's a huge amount of notice before a library becomes officially dead. There's also tons of opportunities to talk with the authors and collaborate with the community to keep it going. And in this case, the outcome is likely a lot better than you trying to develop a custom solution in total isolation that's not open source.
So yeah, there's really no downside to using most 3rd party libraries. Either it fits your app well enough and continues to be maintained while you happily use it (and maybe contribute back changes), or it fizzles out and you got some value out of it and now you have a great head start in implementing a custom solution from it for your unique use case.