Perhaps you didn't read the article, but the implementation they describe is interesting and perhaps easier implemented in a new project from scratch.
It can't be any worse than current github, and since we've heard plenty of people express their dissatisfaction with github recently, this is actually a good direction for Cursor. A product people may want. We'll see.
Yeah, and the grass is always greener somewhere else.
The only way to finally end up in a happy state about your git hosting and automated workflows running, is by running the whole shebang yourself. Saves you so much sanity in the long-term, even if starting and scaling is slower.
Oh, I told my son to create an org yesterday with Cursor Origin, just in case in 10 years it becomes a thing, and he said: "Oops! Paid customers only!" A GitHub "alternative," really? Well, this is reminding me to cancel my Cursor subscription. I am paying for it but not using it because I don't need it as it offers me nothing. I won't even say that somebody already got my GitHub org name, so I'm sure there will be an aftermarket for org usernames and people who want to get 10-15-20x of their $20 investment. Cursor's shortsighted decision is definitely welcomed by parasites! They rushed out their MVP so badly that they created an identity fiasco!
I am just too old, you know. I remember Bitbucket, GitLab, and the plethora of other GitHub killers. GitHub is an ecosystem, not a product. Cursor needs at least a decade to beat that! Maybe more!
People are lazy, and when there are no standards (or when they are not followed strictly), it's no small challenge to build a generic interface that works with multiple providers transparently and interchangeably. Many moons ago, we built an LOS (Loan Origination System) for subprime mortgage companies, and I designed a service that standardized input and output for dozens of mortgage vendors - credit, title - you name it. Every vendor was adding their flavor to the standards; everybody read the standards wrongly to some extent, etc. So, when we were pitching the LOS to a bunch of lenders, many of them came back to us and asked, "Can we just buy your servicing subsystem from you?" although it wasn't a separate product at the time. So, naturally, software engineers don't like one-offs unless they support one of the vendors only (pun intended) - the GOAT. It's not so easy to create or extend a standard that works across all vendor implementations. So, it's human nature to try to avoid this process and just support GitHub. The bigger the mass, the stronger the gravity. The biggest mass has the strongest gravity.
Comments
Perhaps you didn't read the article, but the implementation they describe is interesting and perhaps easier implemented in a new project from scratch.
It can't be any worse than current github, and since we've heard plenty of people express their dissatisfaction with github recently, this is actually a good direction for Cursor. A product people may want. We'll see.
Yeah, and the grass is always greener somewhere else.
The only way to finally end up in a happy state about your git hosting and automated workflows running, is by running the whole shebang yourself. Saves you so much sanity in the long-term, even if starting and scaling is slower.
Oh, I told my son to create an org yesterday with Cursor Origin, just in case in 10 years it becomes a thing, and he said: "Oops! Paid customers only!" A GitHub "alternative," really? Well, this is reminding me to cancel my Cursor subscription. I am paying for it but not using it because I don't need it as it offers me nothing. I won't even say that somebody already got my GitHub org name, so I'm sure there will be an aftermarket for org usernames and people who want to get 10-15-20x of their $20 investment. Cursor's shortsighted decision is definitely welcomed by parasites! They rushed out their MVP so badly that they created an identity fiasco!
I am just too old, you know. I remember Bitbucket, GitLab, and the plethora of other GitHub killers. GitHub is an ecosystem, not a product. Cursor needs at least a decade to beat that! Maybe more!
Maybe what we need is actually fewer ecosystems, and more products.
People are lazy, and when there are no standards (or when they are not followed strictly), it's no small challenge to build a generic interface that works with multiple providers transparently and interchangeably. Many moons ago, we built an LOS (Loan Origination System) for subprime mortgage companies, and I designed a service that standardized input and output for dozens of mortgage vendors - credit, title - you name it. Every vendor was adding their flavor to the standards; everybody read the standards wrongly to some extent, etc. So, when we were pitching the LOS to a bunch of lenders, many of them came back to us and asked, "Can we just buy your servicing subsystem from you?" although it wasn't a separate product at the time. So, naturally, software engineers don't like one-offs unless they support one of the vendors only (pun intended) - the GOAT. It's not so easy to create or extend a standard that works across all vendor implementations. So, it's human nature to try to avoid this process and just support GitHub. The bigger the mass, the stronger the gravity. The biggest mass has the strongest gravity.