News for hackers. Stuff that matters.
Re:Tripping over the potholes in too many libraries by Ar-Curunir on Monday August 10, 2020 @03:14AM (#24106473)
And by re-implementing a library, you're just importing dependencies into your code, with the difference that now you're responsible for bug fixes and security patches, without the opportunity to inherit performance improvements contributed by others.
Re:Tripping over the potholes in too many libraries by KSteffensen on Monday August 10, 2020 @03:33AM (#24106568)
You also have a much easier route to fixing issues, since there will be far less politics involved. Probably you will also have a deeper understanding of the code since you wrote it.
Re:Tripping over the potholes in too many libraries by consolenaut on Monday August 10, 2020 @03:43AM (#24106620)
This is true, but I've found it far more common that a predecessor at the company I'm at wrote the code and isn't around to support it anymore. For simple components it's no biggie, but for non-trivial components it can take about the same time to debug as an external module, the benefit of the external module generally being better documentation, although thats not a given.
Re:Tripping over the potholes in too many libraries by armada651 on Monday August 10, 2020 @05:13AM (#24107137)
If you find the fix yourself you don't need to deal with politics if you don't want to. Submitting pull requests is optional after all.
Re:Tripping over the potholes in too many libraries by KSteffensen on Monday August 10, 2020 @05:23AM (#24107206)
If you don't submit a pull request and get your fix merged, essentially you have given up on the benefits of an open source library maintained by other people. You will have to maintain your fix. At that point, you might as well have written the thing yourself, especially for trivial stuff.