4 ms·

I see this from a different perspective. The developer using the API or tool has a valid expectation that their software should continue to work as-is for years

I see this from a different perspective. The developer using the API or tool has a valid expectation that their software should continue to work as-is for years even as outside changes are made to the underlying tools, libraries and features. The flaw here is instead, in my opinion, a willingness on the providers of these tools and libraries to pull the rug out quite frequently on their end users. If there is a security risk, you can mitigate that by redirecting your users who still use the feature to what I'll call a "diversion" along with a warning that they will no longer receive updates and to consider the feature obsolete. Perhaps with a popup or console blurb that warns the user of the problem, this way the end user developers eventually do have to fix it because users will bother them about the issue. I understand it creates clutter that maintainers would like to avoid, but the alternative is constant rug pulling that undermines productivity and the usefulness of your tool or library. You created your software or tool to help others whether for financial gain, altruism or ego boosting. I think you forget that when you decide to throw your hands in the air and rug pull. It is irresponsible and lazy. You are shirking your duties onto others. We need a new system, process or design pattern to help alleviate this issue in our industry. Because end user developers and system or library developers are constantly butting heads over this. There is a strong smell here that needs to be resolved. It is a problem in search of a solution. I think we can potentially engineer our way out of this. For example, if you developed software for the first Google Android phone, it no longer works on the latest phone. It should. Why wouldn't it? I wrote a piano app that no longer works, it would require a full rewrite and recompile. And, this isn't just between an ancient version and a new version of the phone. Just one SDK update and they've suddenly changed all of the interface names, function arguments, etc. Just because they thought a name sounded cooler or clearer. This is irresponsible design. Microsoft does a great job with their APIs being backwards compatible as much as possible. But, the cost is having to carry a massive history of APIs and tools they can never truly sunset. If you develop something for the first DirectX SDK it still works on the latest release. Because, they number their interface names. I'm not saying this is the ultimate solution, but it is one way to address the problem. But, it has problems of its own. I'd like to see a large effort to address this, we keep avoiding it as an industry.

compiler-guy 4y ago
"You are shirking your duties onto others." That might be true if you had a duty to them. But you don't.
- palisade 4y ago
  If I maintain a tool or library used by others, I do see it as a personal duty to maintain it on their behalf. And, clearly the volunteers in the post we're referring to here feels a duty, or they wouldn't be concerned about making the necessary changes to update the tool and libraries provided. Their argument in the post is that their duty to update the tool and its libraries supersedes the perceived entitlement, as they put it, the end users have to an expectation of support. I'm pretty certain what we're discussing here is a feeling of duty, they just have a different opinion on what that duty entails. There has to be a better way. The reason I think the distinction is important. One is a world where we spend more time as developers struggling to keep our balance as the floor constantly moves. And, therefore less time spent on solving actual problems. While the other potential world is one where we create a self-healing structure that somehow makes life easier for both the maintainers and end users. I honestly don't know how it would work, but I definitely feel it exists somewhere in our future.
  - mrtranscendence 4y ago
    > And, clearly the volunteers in the post we're referring to here feels a duty, or they wouldn't be concerned about making the necessary changes to update the tool and libraries provided. I'm not sure you're on the right track by thinking of this in terms of "duty". Someone might be working on open source for any number of reasons, possibly none of which are because they feel a duty towards any particular user of the tools they're working on. They may simply wish to produce the best, most secure tool possible at the lowest cost to themselves. That doesn't mean they have a duty to (say) keep around older, insecure versions just so users who haven't done their own due diligence can minimize work disruptions. Given the lack of an existing "better way", I'm more than willing to cut open source maintainers a bit of slack until such a time as I'm paying them decent rates.

compiler-guy 4y ago

"You are shirking your duties onto others." That might be true if you had a duty to them. But you don't.

palisade 4y ago
If I maintain a tool or library used by others, I do see it as a personal duty to maintain it on their behalf. And, clearly the volunteers in the post we're referring to here feels a duty, or they wouldn't be concerned about making the necessary changes to update the tool and libraries provided. Their argument in the post is that their duty to update the tool and its libraries supersedes the perceived entitlement, as they put it, the end users have to an expectation of support. I'm pretty certain what we're discussing here is a feeling of duty, they just have a different opinion on what that duty entails. There has to be a better way. The reason I think the distinction is important. One is a world where we spend more time as developers struggling to keep our balance as the floor constantly moves. And, therefore less time spent on solving actual problems. While the other potential world is one where we create a self-healing structure that somehow makes life easier for both the maintainers and end users. I honestly don't know how it would work, but I definitely feel it exists somewhere in our future.
- mrtranscendence 4y ago
  > And, clearly the volunteers in the post we're referring to here feels a duty, or they wouldn't be concerned about making the necessary changes to update the tool and libraries provided. I'm not sure you're on the right track by thinking of this in terms of "duty". Someone might be working on open source for any number of reasons, possibly none of which are because they feel a duty towards any particular user of the tools they're working on. They may simply wish to produce the best, most secure tool possible at the lowest cost to themselves. That doesn't mean they have a duty to (say) keep around older, insecure versions just so users who haven't done their own due diligence can minimize work disruptions. Given the lack of an existing "better way", I'm more than willing to cut open source maintainers a bit of slack until such a time as I'm paying them decent rates.