Cypress.io Blocking of Sorry Cypress and Currents
currents.dev
currents.dev
After all, just intercepting certain API calls to report to a different service instead of the one chosen by the developers is ultimately legal; in most jurisdictions there are laws that allow for compatible implementations to be developed as long as it is done using clean-room techniques.
If that's not considered legal, it's probably even problematic to run AWS CLI to a self-hosted Minio instance or one of the S3 compatible service; using the Sentry SDK to report errors to Glitchtip (a similar API-compatible service), and so on and so forth.
Decision like this come from the leadership team, and I don't think they have people with enough sense of what they're actually doing -- breaking trust with their end customers to understand this is terrible idea.
It smells a lot like what happened with Unity a few weeks ago. It's the same story. Leadership team weren't actually users of the product, they didn't understand that the company's key value was the trust they've built with the customers and they broke it.
I don’t know how accurate this is, but it’s a start https://craft.co/cypress-io/executives. It also appears that in February they added former MongoDB CEO, Max Schireson to their board.
Optically this looks very bad, and I don't think there's any way around that. I would argue, however, that other companies choosing to replicate Cypress's service with Cypress's (open source) project is in bad taste. When I first read about the issue, I was pretty annoyed with Cypress, but after reading about the other companies profiting off of the project, I felt they were probably justified.
Obviously given the MIT licensing, people can do whatever they want with the project, including start a business, and I'm perfectly fine with that. But I also think it's within the company's rights to discourage such behavior, particularly when the businesses are just trying to undercut Cypress's only funding model. People who are particularly aggrieved can fork it, and go on with no hard feelings, but stewardship of a OSS project comes with a significant ability to guide its direction, and saying "don't kill us" doesn't seem unreasonable.
----
On the other hand, Cypress's funding model is completely stagnant (from what little I know) and they have been unsuccessful at differentiating their paid offerings, other than by coercion (you must pay us for distributed CI, etc). In that way it would be sensible for other companies to provide new functionality/features, but not while drawing on the company's resources/goodwill, _and_ when some of them don't actually differentiate, they just replicate.
_I_ would almost never make this decision with my own product, but then again, I've never accepted VC funding or had many employees to look after.
If you don't want people using your open source project in a particular way, then license it appropriately to forbid that.
Go relicense it under AGPL or one of the other "don't compete with us" licenses like BSL. It's confusing because this is just the obvious choice for Cypress to do here. Opting to add postinstall DRM to restrict who uses your otherwise open source software is a bizzare move.
But Cypress volunteered their work product under the MIT licenses which very clearly states what you can and can't do with it. We cannot hold others to this additional arbitary standard that you coward behind. The 'obvious' thing that will happen if you open source your software that someone else may use it to compete against you. Duh!
Cypress is trying to have their cake and eat it too. Zero sympathy for them here.
However, by the exact reasoning that allows companies to replicate, Cypress can try to block, however stupid that may be. It's no more wrong, because both things are allowable under the license, it's just how we look at the situation and what we consider to be "morally acceptable" rather than what is actually required.
The dude also has some pretty nice namesquatted packages (cypress-vscode, cypress-debug) that he references in that article. It made me think that there was serious anti-competitive energy in there and that made me worry for the community.
I rolled back the tweet because it was getting too much traction... and I lost trust in the article once it seemed to be a personal thing that Cy was responding to with radio silence and legalese.
Once I realized the article was misleading, I deleted the tweets that drove the traffic to HN today.
- The article clearly states what entities are affected - Currents, Sorry Cypress and Deploy Sentinel; it doesn't claim those are random package authors.
- Not all the listed packages are written by the dude or written and _THEN_ forked, we provided a detailed breakdown of each package origin. For example, @deploysentinel/cypress-debugger is a completely standalone, innovative software released more than a year before Cypress Test Replay and cypress-debugger
- The article lists all the blocked packages we were able to discover. We published the full list to be totally transparent. Obviously, we create and work on cypress-related packages - e.g. a vscode extension for cypress. There was also a rename from Cypress Dashboard to Cypress Cloud. NPM lists ~1.6K packages with "cypress-" prefix. Another example: we ran a survey on a community Slack channel with ~500 members to pick a name for cypress-debugger - the options were: cypress-debugger, cypress-debug, cypress-tracer; cypress-debugger won.
An interesting experiment would be to rename those packages. Do you believe they will be unblocked?
> company's rights to discourage such behavior
sure, it's their right. as was Unity's right to make a poor choice. it's a consumer's right to make a judgement call on the choice.
The benefit of being a commercial operation responsible for open-source project stewardship is that you have a low-cost marketing engine and most importantly you're able to set the direction of the project, you're able to operate at the cutting edge, delivering the best service to end users, in a way that others cannot. For example, the work Chromatic do in stewarding Storybook means their service is by far the best paid Storybook service and the alternatives (regardless of price) are rarely worth it.
If you're executives at the commercial arm of an open-source project and you're incapable of differentiating so much so that what Cypress are doing here makes sense, you've failed in your duty to shareholders and employees and should be removed. Cypress aren't protecting employee's livelihoods, they're protecting the executives in the short-term at the expense of the employees in the long term. They've bought their employees at best another 6 months with this.
There's examples of egregious commercial behaviour in open-source (like Amazon's situation with elasticsearch) where it's pretty easy to moralise about reselling free software with very little value-add. However, the entire internet is built on people taking concepts and ideas and iterating on them: building a product that is compatible with Cypress is worlds apart from ripping off the Cypress commercial arm.
I think the decision probably makes sense for the executive team at Cypress at this point in time: the writing is on the wall for the company, and taking this drastic action gives them a little more breathing room to somehow salvage a future... but the justifiable decision is to actually use their very advantageous position. If Cypress are threatened by Currents, that's embarrassing for the leadership, because they started a marathon at mile 20 while Currents was still sat at mile marker 0.
Playwright is built on top of Chrome Developer Tools Protocol[1] by the ex-Chrome folks and the API is far superior than Cypress. It gives you so much more flexibility and stability compared to Cypress.
I am having a blast switching our e2e test suite from Cypress to Playwright. Things just work and debugging is much more easier.
Cypress is MIT licensed, so I don't understand what Currents were doing that was so bad?
Whether there's actual intellectual property (of the legal definition) being abused is anyone's guess.
I was involved with some automation process where I also had to touch the contents of these tests. Dear lord... I never liked Selenium, but this thing... it's so hilariously bad. Well, maybe I've not touched anything front-end related for a while, so I'm getting out of touch with the depth of stupidity modern Web development plunged into.
But... if this decision (of blocking someone) adversely affects Cypress and helps them disappear, I will only be happier. This is just an insanely bad product with insanely bad ideas. I struggle to comprehend how something like this gets so much attention and so much work put into it.
Personally, it’s always been a breeze to use and rather straightforward. It took me a day to mock logins in our relatively complex login system, and not even half a day to get a suite of backend interceptors written to mock our GraphQL backend for when we need to run tests without access to the backend. Test suites are fairly quick to write up, and there’s nothing overly complex or “weird” I’ve had to do with the syntax.
This is all coming from a biased perspective for sure - I’d love to hear some specifics about what gave you this kind of reaction to Cypress.
If Cypress users want to view a dashboard or session replay of their failed or flaky tests, they'll need to pay for Cypress Cloud which can easily be 6 figures.
I'm hopeful that after the dust settles, Cypress will clarify their stance on the ecosystem. It's clear that Playwright has the momentum, but Cypress can still be successful if they are able to innovate alongside their community and rationalize their pricing.
They are injecting arbitrary proprietary code into the binary app, which is different from what the public MIT-licensed repo.
I don't understand why don't they just change the license.
this combined with performance, iframe, tab support, and others is why playwright has been eating cypress' lunch
Microsoft can afford an open source testing tool whereas a VC backed Cypress must engage in enshittification
At this point, its the only reason I use Cypress, as E2E testing via Playwright is a joy to write
is component testing from cypress really needed. the only "benefit" I see is using a single tool
RTL is great, but jsdom and similar solutions have limitations, being able to run similar tests in live browsers is really validating, in many cases allows us to cut down on writing somewhat more brittle E2E tests
The biggest win with playwright its like writing vitest / jest tests, it uses a similar `expect` function (I believe its a modified version of Jest expect but that may have changed) and I like their Pages API
The only thing I haven't used Playwright for yet is API testing
[0]: as you get more than just a DOM tree snapshot, you get the styles too. Great for catching regressions
Vitest is also adding browser support of this nature and if that hits enough maturity its all moot anyway
Both Cypress and Playwright can use vite out of the box, on the other hand. I like this, since I can use the same configuration for production for running tests (we do this to run tests against prod builds)
Its more overhead currently than I want to take on.
Microsoft can also afford to keep the tool fully free and open source until the VC funded competitor expires, at which point MS can switch things around by introducing paid options. Open Core, paid add-ons/plugins, etc.
Where I work, there was a guy in 2018 who made an internal video presentation about how awesome Cypress was, and how many of our projects might benefit from adopting it.
And at the end of last year, since that guy was me, I sort of felt obligated to do a follow up internal presentation about my team's experiences with it (very good at first, very bad by the end), why no project should adopt Cypress anymore, and the reasons that projects using it should consider switching to Playwright.
It's not just that Playwright works better, in every conceivable way, than the open-source parts of Cypress. Although that is also true.
It's that that no-longer-up-to-par[1] E2E web testing implementation is also tied to this obvious "let's ramp-up the lock-in and increase prices" strategy. I love paying for stuff that saves my development team time, but we're paying Cypress thousands of dollars a year and if we kept using Cypress it would keep going up and up and up, because Cypress wants you to pay for parallelization.
Flaky test identification, possibly-redundant time-wasting analysis... those are (to me) valid things to pay extra for — or not pay for, if the budget gets tight. Paying extra for simply running your tests in parallel, or being locked into one provider for it, is a huge red flag. It means that the better your test coverage gets, the more you have to pay.
But pay-to-parallelize is just crap. It's table stakes, and has to be part of the open-source component, not the premium tier. (NOTE: To be clear, Cypress makes you pay to parallelize on your own instances. If they had a Cypress cloud that also provided the CI instances running the test, I wouldn't have a problem with paying... although I suspect in that case, I would have a problem with price-gouging, because they still presumably wouldn't open source that part.)
Contrast with Playwright: you just append "--shard=1/30" (if you have 30 instances). It's not as sophisticated as Cypress Dashboard's dispatcher which... waves hands coordinates in realtime and feeds instances tests as soon as they become idle (?). But it is open source, free, and if one shard fails in CI you can run the Playwright command locally with the same shard number to debug it.
So, if you use one of the services affected by this move, well ouch, but OTOH you probably shouldn't be using Cypress in the first place. So maybe take this as a final nudge that least freeze your Cypress tests and start writing new tests in something not only more open, but also just... better.
[1]: Off the top of my head, the critical flaws that make Cypress not as good as its 2023 competition:
- A model for async that is not based on — and not compatible with — standard async/await (promises). You have to use this bizarre alternative "Cypress.Chainable" thing instead, and it makes debugging a failing test much harder than the same test in Playwright (or anything that uses normal JavaScript async). Many people have complained about this, and to me it is a no-brainer, but Cypress basically doubled down on it like "No no, sure async/await is OK, but Cypress Chainable is better because hage hige hoge..."
- Colocating Cypress in the same browser instance as your app, and using an iframe to "isolate" the app under test. IRL this results in "Cypress-only" test flake (things happen in Cypress that never happen otherwise) and just outright "the browser crashed during CI".
- Slow. As. Dog. Shit. (It wasn't slower than the competition a few years ago. But the competition has gotten dramatically faster (at executing tests, I mean), and Cypress has not.)
- Due to the above things, presumably, our Cypress tests exhibit a much higher level of flake, and therefore maintenance cost, than our post-Cypress tests (mainly Playwright). This, though, could be partly due to just being older tests. For instance, Cypress response mocking support was first bad, then OK, and now I dunno but maybe it is good. All our tests that need to use response mocking have failed and needed some engineer to fondle their balls and whisper sweet nothings into their ear to coax them back to functionality... but that maybe wouldn't happen if they'd been written with Cypress 13 instead of Cypress 3 or whatever. So only blaming Cypress partially for this.