I wonder if this means they migrated away from Honeycomb, which often lists Stripe as a prominent customer (e.g. "HelloFresh, Stripe, Slack, Fender, Vanguard, LaunchDarkly, and many more rely on Honeycomb" in most blog entries).
It's important to resolve changes to the package environment as a whole. Pip doesn't really do this, and as of a few years ago didn't even resolve multiple CLI-specified packages together, and this causes major compatibility and consistency issues.
Doing this correctly can be difficult to get fast, but performance does matter. Resolving Conda environments adds way too much time to CI jobs. The Pkg.jl resolver is pretty great and we never have to wait for resolution. It's my understanding that this was a non-trivial technical problem that went through a few implementation iterations.
Explainability on failure to resolve is a really useful tool that becomes more difficult the more features you add. Pkg.jl has struggled with this in some cases where it hides certain version restrictions (e.g. "by explicit requirement" is rough when your project hasn't set that particular requirement). Lots of people have spent lots of time trying to identify incompatibilities over the years, and we've had to rely on people developing arcane knowledge to interpret resolution failures.
Immutable, cached packages is important for avoiding spending a lot of time downloading. It's very important to completely distinguish different versions/configurations though, i.e. you don't want a configuration setting that affects which code gets put at `~/mypkg/packages/<pkg-version-id>`.
The package source should be reliable/redundant. People will install packages in the course of normal work (automated updates, testing, etc.) and will need an always-on package manager. GitHub has proven not to be reliable enough.
At the same time, an offline mode should be available.
Getting installation configuration options right can be a big value add. I love cargo's feature flag implementation, and even Python now has "extras".
Every package manager eventually regrets not adding a "yank" feature.
Enterprise users will always eventually want to see multiple sources (private and public).
I appreciate when package managers consider the audience for their output and don't output line-by-line progress meters when running in a non-interactive environment.
Querying the package dependency tree is really useful! Both dependants and dependencies, flat and recursive. Even better if there's a library to do this that you can script and experiment with.
I still prefer to use Julia, but this is a good summary of the problems that affect me personally as an experienced user (although I do like dynamic typing for most of the work I do).
Invenia's approach to interface testing ("Development with Interface Packages" on our blog) does some of the things you suggest as a standard of practice, by providing tools to check correctness that implementers can use as part of package tests. ChainRulesTestUtils.jl is a decent example (although this one doesn't come with fake test types). I think this is typically good enough, and only struggles with interface implementations with significant side effects.
One little win could be publishing interface tests like these for Base interfaces in the Test stdlib. I appreciate that the Generic* types are already exposed in the Test stdlib!
I've only ever engaged on Twitter when companies do not provide an avenue for direct customer support in private, but this has become more and more important over the years. Twitter provides a platform for public shaming; if the company directs you to a private channel and doesn't respond effectively there, you can report back publicly that the company has failed to respond. The situation may be changing, but in the past this has resulted in internal escalation and my problem was resolved in a way that was not possible through official private channels (if those even existed).
IMO the best way to avoid publicly advertising when you've failed a customer is to provide a clear and effective private avenue for complaint resolution. Most people who are looking for a resolution will only resort to social media complaints when they're desperate, either because they can't figure out how to get help or they are being denied help and/or communication.
It’s an arms race of bad faith complaints leading to watered down responses, and mediocre responses leading to faux-outraged complaints, all involving a peanut gallery of online haters.
I agree with avoiding publicity (in this sense e.g by replying to online complaints or attacks, other than to redirect to a private channel), though I don’t like it.
When is a bad faith complaint not actually intelligence gathering to see what behind the scenes or non public safety/security measures they have in place to ensure they dont fall foul of bad faith complaints?
Social Media is a classic "if you have nothing to hide you have nothing to fear" spook ideology turned on the business sector, and various coping strategies are highlighted in this article.
I'm interested in the shift in terminology. Previous coverage has referred to them as a software company or device manufacturer, but this round is referring to them as "hackers", which seems like a framing McDonald's would benefit from in lawsuit proceedings.
