Yeah I know that they didn't. Even though they didn't invent it and don't own it, it's still the cornerstone of the wall that has become the Github empire.
The specific problem is that all the competitors to Github have to use git, and that limits how different they can really be than Github and thus how aggressively they can compete to win users
Problem for whom? Users who are happy using git? Or conartist86 who is thinking about how to get money?
> the competitors to Github have to use git
Why? Syncing between various VCSes has been a thing since forever. If you can't handle a compatibility layer to support git+new-better-thing, you don't have the technical chops to build new-better-thing in the first place.
I do want forwards compatibility, I don't want backwards compatibility.
The way I think about it, if I make a backwards compatible product I might end up with users who never really wanted any change at all, and those people would be almost impossible to make happy. Those are the "faster horse" users. What I need is to find the people whose life would be changed by a car!
Why would users who never wanted change proactively switch to your product in the first place? And putting them aside, you haven't listed a single concrete technical idea that would indicate you have the vision for a car. Maybe you should spend more time on that than drumming up your grift-adjacent persecution complex.
They wouldn't. Every adoption curve needs early adopters, who will be people not satisfied with the current state of things. But obviously most people aren't early adopters.
If you would like me to list a single concrete technical idea, I am pleased to oblige. The idea is: universal gaps. Our syntactic-semantic documents can have holes in them, places where we know some content is missing. That allows a document to behave like a template which lets us fill in the blanks. In a text-editor-based IDE there is no equivalent, which means that when I go to make a new sticky regex in Javascript I type //y and the IDE thinks I meant to comment out the rest of the line. It has no way of expressing the concept that between those two slashes something is known to be missing, which is exactly what I want to be able to tell it so that it can understand the difference between the state when I'm about to write a regex body and the state where I'm about to write a comment body
That idea has nothing to do with source control that would replace git. It also already exists in the form of TODO tags and is handled exactly as you describe in JetBrains IDEs[0] (plus helpful semantic highlighting), and probably others as well.
I'm talking about a universal placeholder, something that you're free to use anywhere, in any language, for any part of a syntax tree that is missing.
A TODO comment can't do that because the syntax conflicts. For a regex the conflict would look like `//* TODO *//`, and for a comment it would look like `// /* TODO */`. Both have an existing meaning, and in neither case is that the meaning I want.
If I could have a magic "stuff goes here" character this would be solved. I often use · to represent the idea of this magic character. That gives you /·/ and //· at least, but of course it isn't safe to assume that no language will ever assign meaning to the · character so we can't literally use it as the universal gap. To get something universal, you need to move from using a sentinel token to using embedded/encoded data.
Maybe, but the way they captured the market was by offering a differentiated product. We already had cabs and buses, yes, but Uber wasn't just summoning cabs and selling bus tickets, where they? The core experience was still A to B but Uber discovered that there was a lot more consumer innovation possible within the confines of the A to B problem...
Yes, exactly? And closer competitors to Uber came later and are I assume successful. Just like there is Gitlab, Bitbucket, sourcehut, and several others all 'within the confines of the hosted git problem'.
There were players for hosted SVN too before git and Github came along. Github got big in part because they weren't in the same crowded market. That others eventually emerged to play in the market with them did little to hurt the return on their initial investment...
I don't know if they were the first git forge, but they were certainly among the first.