[HN Gopher] Cypress.io Blocking of Sorry Cypress and Currents
___________________________________________________________________
Cypress.io Blocking of Sorry Cypress and Currents
Author : madmax108
Score : 51 points
Date : 2023-10-11 10:24 UTC (5 hours ago)
(HTM) web link (currents.dev)
(TXT) w3m dump (currents.dev)
| doctorpangloss wrote:
| 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.
| mmmeff wrote:
| 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
| crabbone wrote:
| 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.
| the_gipsy wrote:
| 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.
| LunaSea wrote:
| Good ole cartel oriented programming
| ramesh31 wrote:
| 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.
| bdcravens wrote:
| 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)
| dvngnt_ wrote:
| 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
| no_wizard wrote:
| 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
| spankalee wrote:
| 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.
| dvngnt_ wrote:
| 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
| no_wizard wrote:
| 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
| paularmstrong wrote:
| Playwright has experimental component testing[1] and it's
| been working great at my company for months.
|
| [1]: https://playwright.dev/docs/test-components
| justinclift wrote:
| > 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.
| dvngnt_ wrote:
| possibly, but the default playwright installation creates a
| github action which makes Microsoft money so there's less
| pressure to gate features
| justinclift wrote:
| Interesting. That makes sense too. :)
| martypitt wrote:
| 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?
| justinclift wrote:
| 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.
| [deleted]
| supriyo-biswas wrote:
| 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.
| agg23 wrote:
| 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.
| madeofpalk wrote:
| > 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.
| agg23 wrote:
| 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.
| madeofpalk wrote:
| 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.
| agg23 wrote:
| 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.
| gurchik wrote:
| 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.
| agg23 wrote:
| 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.
| gurchik wrote:
| 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.
| fezzez wrote:
| 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.
| dpflan wrote:
| Can you share a link that shows their leadership?
___________________________________________________________________
(page generated 2023-10-11 16:01 UTC)