38 ms·

Fork it, fix it, then ship it. Open source developers don't have an obligation to provide free support for the rest of their lives. But if the code is easily

Fork it, fix it, then ship it. Open source developers don't have an obligation to provide free support for the rest of their lives. But if the code is easily viewable, then that's a perfect opportunity to either: 1) build upon it, or 2) pay someone else to build upon it for you Option #2 would still be faster and cheaper than recreating the whole implementation from scratch.

laurent123456 9y ago
My approach has been to keep everything as modular as possible, to create wrappers around major packages, so that I can switch to a different package once a major bug is found. Unfortunately fixing unmaintained open source packages is often a waste of time since your improvements won't be merged to upstream (since the owner is gone), and it's unlikely that your fork will take off. Even if the owner add contributors to the repo, the changes still won't make it to npm. Maybe for very large projects it makes sense since then a group of multiple dev can start a fork, and it's more likely to get some traction.
- dentemple 9y ago
  Presumably there was a reason why you were searching for the package in the first place? A challenge that you were trying to overcome? If there's no perfect solution that exists (which there never is)--and if bringing in someone else's partial implementation "as is" doesn't work--then the only other options available are to write 100% of the solution yourself or to write (100-x)% of the solution yourself. Also, presumably, that you're not in the business to write library tools. So unless the broken OSS package is written in complete greek, why wouldn't it be more efficient to use it as a template for your solution?
jakobegger 9y ago
The problem is that most open source projects solve the easy part, and skip the hard part. When someone else comes along and sees that, they say, why should I fix this thing when I can just as well start a new project that just does what I need? That‘s why you end up with dozens of half assed solutions to your problem on Github, but in the end you‘ll have to write it yourself anyway.

laurent123456 9y ago

My approach has been to keep everything as modular as possible, to create wrappers around major packages, so that I can switch to a different package once a major bug is found. Unfortunately fixing unmaintained open source packages is often a waste of time since your improvements won't be merged to upstream (since the owner is gone), and it's unlikely that your fork will take off. Even if the owner add contributors to the repo, the changes still won't make it to npm. Maybe for very large projects it makes sense since then a group of multiple dev can start a fork, and it's more likely to get some traction.

dentemple 9y ago
Presumably there was a reason why you were searching for the package in the first place? A challenge that you were trying to overcome? If there's no perfect solution that exists (which there never is)--and if bringing in someone else's partial implementation "as is" doesn't work--then the only other options available are to write 100% of the solution yourself or to write (100-x)% of the solution yourself. Also, presumably, that you're not in the business to write library tools. So unless the broken OSS package is written in complete greek, why wouldn't it be more efficient to use it as a template for your solution?

jakobegger 9y ago

The problem is that most open source projects solve the easy part, and skip the hard part. When someone else comes along and sees that, they say, why should I fix this thing when I can just as well start a new project that just does what I need? That‘s why you end up with dozens of half assed solutions to your problem on Github, but in the end you‘ll have to write it yourself anyway.