This is how you do a migration to another language: you lay out the benefits, fully accept the drawbacks, and try your best to be reasonably supportive of people who, for various reasons, cannot use the new version. It’s refreshing to see considering that the usual maintainer response to “I’m sorry, but I need to use the C version” I see in these kinds of situations is a combination of gaslighting (“your usecase is not really valid or is too niche for me to care”, “are you telling me that you want security vulnerabilities”) and outright refusal to accept that changes can mean that some people will be adversely affected. The author wanted use Zig, they did it, and they are polite enough to continue to provide basic maintenance for the C code for those that really need it.
>> and try your best to be reasonably supportive of people who, for various reasons, cannot use the new version.
Keep in mind that "maintainence" according to them means "pretty much what I've been doing for the past few years: not particularly active in terms of development, just occasional improvements and fixes here and there." If you're trying to apply this to situations such as "py-cryptography" -- they are not very comparable.
Pretty much every license in existence has a line like the following: "THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED". This is especially true when the upstream never declared "support" for a given use case to begin with, such as different Libc implementations, big-endian platforms, etc...
Had py-cryptography done the same thing (i.e. made the same announcement and promises, and followed through on them), I'd think we could say the exact same thing about py-cryptography as above too.
I’m actually not too familiar with the py-cryptography situation, but perhaps it is similar; I’m not sure. But what I’m talking about is projects that move to a completely different language and in the process cause problems for a lot of their users, who understandably voice their concerns. It is always nice to see projects willing to consider and make a good-faith effort to accommodate these needs. The reason I felt the need to leave a comment, though, is that I sometimes see the opposite: complete apathy, sometimes even willful shaming of those who explain why the change is problematic for them. They’re treated like luddites, or entitled, for merely mentioning that the change has affected them in ways that may not have been obvious when the decision was taken. That’s just being a jerk.
I can (and have) actually written quite a bit about this, but I’m not impressed by arguments where people quote the terms of a license to justify them being a jerk. I maintain several open source projects, and I can tell you that the license tells you nothing but what you must do to avoid being sued. It is a legal contract, not a guideline for how you should behave, unless you’re one of those people who goes around providing the bare minimum courtesy to others as is necessary to not get in legal trouble (we have a word for those people: jerks).
When I work on software other people use, I am a considerate person who understands that my code will often be used in ways I did not expect it to be. I think people that do is are really awesome! As a software maintainer, I believe it is my duty as a nice person to extent some amount of courtesy to them. Of course, there are limits to everything, but that limit is absolutely not at the point where my legal liability ends.
So, coming back to this topic: I have seen projects that take the stance you have in response to people reporting things like “I can’t compile this software for my platform anymore :(“. I think that is a legal, but jerk move. In this case the maintainer not only understood the concerns that people may have from the changes, but they also committed to providing basic support for it even though they obviously didn’t have to do anything. A good maintainer recognizes that a minimal bit of effort can pay off handsomely in goodwill, and I just wanted to call attention to that fact.
