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