Hacker News new | past | comments | ask | show | jobs | submit login
Cypress.io Blocking of Sorry Cypress and Currents (currents.dev)
78 points by madmax108 9 months ago | hide | past | favorite | 54 comments



While I see a number of comments mentioning disdain for the move by Cypress, I'd like to know the core issue claimed by them due to which they state they're "defending their intellectual property".

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.


The software in question is open source, which means it would be legal even ìf they directly copied and modified it.


If you look at their leadership. They have no one who knows how to code & understand's their core product at the helm. No one in their leadership team could use cypress themselves.

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.


A few years ago I was evaluating cypress as an eng director at a large tech company. The cypress team came out to visit. It’s true the ceo was a sales guy but the founder came also and he was a true hacker. Maybe he’s not involved anymore?


Did you also consider Playwright?


It was brand new then and puppeteer was chrome only. We ended up using cypress but we hacked it into our existing ci/cd.


Thanks. I assumed this was recent and was just curious what options you were considering.


Can you share a link that shows their leadership?


> Can you share a link that shows their leadership?

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.


Disclaimer: I previously worked at Cypress for a relatively short period, though I don't really think that affects my thinking on this matter.

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.


> I would argue, however, that other companies choosing to replicate Cypress's service with Cypress's (open source) project is in bad taste.

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.


I agree, but that doesn't make it not bad taste, and by the same token, it's not against the MIT license to attempt to block (albeit trivially) companies from trying to do that.


The only bad taste thing that's happened, imho, was a (commercial?) project for self hosting calling themselves 'sorry cypress'. I wouldn't be surprised if there's legitimate trademark issues here.

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.


The legit trademark issue is https://npmjs.com/package/cypress-cloud (package owned by the Sorry Cypress dude) and then the OP article above links to a bunch of packages that seem to be from disparate owners, but are actually all the same guy OR come from code originally written by that guy and _THEN_ forked (Deploy Sentinel).

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.


Thanks for sharing your concerns, Jessica, we tried to be fully transparent and share our findings with the interested audience. I have added a disclaimer that explicitly mentions the owners of the packages to avoid confusion.

- 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?


I want to make it very clear that I do agree with you.

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.


If Playwright et al didn't exist, that might lead to an "OpenCypress" fork... but given that alternatives exist, this sounds like Cypress is going to die a lonely death, trying to pump as much money as possible out of Enterprise sales before it is forgotten.


"bad taste" is bold commentary when the offender is accused of producing zombie binaries to block competition.

> 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.


I'm generally sympathetic to the difficulties of building a sustainable business around open-source project stewardship but I'm not sure I agree with your conclusion that they were justified in this decision. The decision they've made here isn't actually much to do with the open-source project at all, and in fact, commercial products with no open-source component go through this every day. For example, every cloud provider nowadays offers "s3-compatible" storage which is built on the back of the work Amazon did early on. Currents (and co.) have taken what is effectively the Cypress protocol and built their own compatible product for it.

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.


I have no problem with a company discouraging other companies from offering a paid competing product that relies on your code. But why prevent you from using self-hosted open source software? For example, Terraform had that licensing change which prevents you from running a competing company but (as I understand it) you can still point Terraform to your self hosted Terraform Enterprise alternative. This Cypress change would prevent you from using Cypress with a self hosted sorry-cypress dashboard.


Yes, I 100% agree. They should have always supported a self-hosted install, even if it was via sorry-cypress. In my mind it's completely antithetical to being an "open source company" and not also providing some sort of (maybe incomplete) self-hosting capability.


Playwright is MIT licensed and as far as I see they won't try to lock anyone into Microsoft offering like Cypress is doing.

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.

[1] https://chromedevtools.github.io/devtools-protocol/


We switched from cypress to capybara+selenium. I do really like playwright but it looked like more work to fit in with our app. Cypress had some flakiness issues that we just could not get fixed despite putting in considerable effort. Even if we had fixed them, the api wasn't great and I'd have low confidence that all devs would be able to continue writing non flaky tests.


Someone maintaining a dependency of cypress itself should add a dependency on cypress-debugger out of protest. Every single cypress installation would begin failing en masse


Can someone with a little more context expand here?

Cypress is MIT licensed, so I don't understand what Currents were doing that was so bad?


Sounds like they were getting in the way of Cypress.io's attempts to monetise, which that company considers "bad" for obvious reasons.

Whether there's actual intellectual property (of the legal definition) being abused is anyone's guess.


I like Cory Doctorow's version of intellectual property crime: "Felony Contempt of Business Model".


Tough reminder to chose carefully for what projects/products you decide to pour your efforts into. If some VC backed company can pull the rug anytime, maybe reconsider.


These weird in-between self-hosted and cloud companies. RudderStack too is guilty. Is Sentry fully, truly self hosted? What about PostHog? IMO, the test is, "is there a Kubernetes operator for it?" But a Kubernetes operator for X is the entirety of the business.


If you haven’t given it a try, I think Playwright is a much nicer open source offering for e2e testing and general web automation tasks. It’s the first such tool that I actually enjoy using.


Recently, we hat to add some front-end tests for the admin panel of the product. QA jointly with front-end team decided to use Cypress. I think, front-end were already using it for unit tests (aptly named by Cypress end-to-end tests), and QA decided to piggy-back on that...

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.


So I’ve been using Cypress on and off for a while at different jobs, and recently pushed for it for our front end E2E suite.

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.


The writing has been on the wall for Cypress since 12.0, where they started funneling everything into the cloud SaaS workflow. It sucks because Cypress was 10x better than the nightmare (literally) we had before. Hopefully Playwright doesn't go down the same road.


The advantage Playwright has is that it isn't a startup trying to leverage an open source project into a money-maker. (It's Microsoft)


Cypress also blocked deploysentinel.com which introduced Session Replay for Cypress and Playwright tests last fall.

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.


What abiguity is there here to clarify? They're pretty explicit in what their stance is.


Good ole cartel oriented programming


This is most likely going to be the push I need to get me over to Playwright. I really like the Cypress API, particularly `cy.intercept`, compared to some of the Playwright equivalents. I'm sure that is just because I am used to Cypress now, and eventually I'll feel the same about Playwright.


Playwright is far far more nice to work with. Leveraging Chrome Developer Tools Protocol it gives you so much more power. Don't even think of comparing Cypress to Playwright. Playwright is the winner in the first minute of comparison


Playwright can also support tests with multiple windows/user sessions (great if you support collaborative editing). Additionally, you can run test that span multiple domain origins. Both of these are easy with Playwright, but not possible with Cypress.


They're implementing technical controls to scan what NPM packages you have installed and refuse to run if you have some "unsupported" ones installed. Their repo still appears to be MIT licensed though. Why not change their license like Terraform recently did? What's stopping someone from having a synchronized fork of cypress but with this commit removed? The blog article doesn't discuss licensing or why ending support was the option chosen.


Cypress cannot claim they are open-source, to be fair.

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.


sad move from cypress. they make you pay just for the ability to run tests in parallel on your own hardware.

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


> Microsoft can afford an open source testing tool ...

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.


possibly, but the default playwright installation creates a github action which makes Microsoft money so there's less pressure to gate features


Interesting. That makes sense too. :)


Playwright doesn't have a good component testing story yet though. It really needs to come out of beta into mainline.

At this point, its the only reason I use Cypress, as E2E testing via Playwright is a joy to write


Playwright has experimental component testing[1] and it's been working great at my company for months.

[1]: https://playwright.dev/docs/test-components


its been in experimental for over a year I think, my worry is, in typical Microsoft fashion, they do the bizarre thing and actually kill it off. They haven't signaled any intention to move this into production ready status, and I don't want to write tests in a way where I have to port them again.

Vitest is also adding browser support of this nature and if that hits enough maturity its all moot anyway


RTL exists and is probably faster than cypress.

is component testing from cypress really needed. the only "benefit" I see is using a single tool


It is to me, testing arbitrary tree of components in live browsers can be invaluable, espcially for things like a design system, where snapshot testing can actually be really valuable[0].

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


Component testing is trivial in test runners that run tests in browsers, like @web/test-runner. We use that exclusively on Lit and Angular is adopting it too. It'll run tests in Puppeteer, Playwright, local browsers via WebDriver, Sauce, etc.


I extremely dislike that I can't use vite with @web/test-runner. It runs its own thing, which means I have to use a different pipeline than the one I already use to build the app.

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.


I think Cypress.io is a tool in its death throes. So like, wildly out-of-touch responses like this, and wacky new pricing/lock-in monetization schemes should be expected. Think Myspace or AOL near the end.

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: