[conartist6]

I'm writing OSS code with the intent to replace git. I know my position is very different, but to me openness is not a critical vulnerability when facing big companies but my secret weapon.

For me the best outcome is taking over all the market currently held by git and GitHub, and the worst outcome would be that Microsoft somehow pulls an embrace-extend-extinguish on us. But my goal, and I think I've been successful here, is to slam the door in the face of anyone who would be able to easily improve on my work and therefore would be able to undercut my value proposition with theirs. We want to be the first people offering a strongly differentiated service by building a platform that does not in any way sit on top of the MS platform, so that nothing we do is actually a direct benefit to them anyway and we actually get consumers excited about change!

This is the same death grip that Microsoft currently has on OSS. They made their tools so ubiquitous that even their most vigorous competitors make things that just feel like knock-offs because the competitors can't afford not to build on top of the same open core as MS: git and LSP. If you can't beat them you have to join them, and so I know exactly what I need to do to win: tweak the economic incentives until joining me is preferable to competing with me, and then instead of charity we'll simply take GitHub's billions in revenue as our revenue.

[init1]

Git is an OSS project and is not owned even slightly by Microsoft.

Github the website however is.

You don't need to replace git.

[conartist6]

I think I do need to replace it to gain a competitive advantage against an incumbent the size of Microsoft. But to replace it at all I would have to build something that is, at least in a few ways, much, much better, otherwise people wouldn't have any reason to give me a moment's consideration. This market has to be won over from the bottom up.

But yes, even though git is as FOSS as FOSS can be, to me it's still a crucial element of Microsoft's power. It has not escaped my notice that Github managed to turn a popular piece of OSS into a successful, profitable company. Apparently many young coders are surprised to learn that Git and GitHub are not the same thing...

[midnitewarrior]

Vendetta code is not going to get you far.

git works perfectly well. git is an afterthought. Engineers need to know git the same way they need to know markdown or SQL.

The complexity of git is becoming less relevant by the day as coding agents take over coding responsibilities.

If your git replacement is optimized for LLM use in ways that git cannot be optimized, you may get some traction.

By all conventional measures, git appears to be peak human-centered source control, with nearly every major company, software authoring tool, agent and SWE invested in using it.

This may be one of the reddest oceans out there.

[conartist6]

If I have two advantages it's that nobody else is crazy enough to try this, and I'm not doing it as a vendetta at all. It started out as a toy project; I was just pushing the boundaries of what was possible with streaming parsers for fun. I only realized much later that I'd accidentally solved problems that were critical to version control.

[yencabulator]

Also, the git killer is already here, already open source, and mostly just a different front for the same old git data model: https://jj-vcs.dev/

[s1mplicissimus]

I agree githubs dominant position is an issue very much worth gnawing at. What's wrong with git though?

[steve1977]

And how would OP differentiate from example Forgejo?

[conartist6]

By being nothing at all like them. The best current analog for the kind of code forge we'd build is Unison's forge, e.g. here's a library hosted on it: https://share.unison-lang.org/@ceedubs/folds

Notice that lines and columns are completely absent in this UX! It's a forge for semantic trees of code rather than text files of code.

I think they're only scratching the surface of what you can do when you shatter the line/col paradigm. Most importantly you have to use the Unison programming language to use the Unison code forge. I won't have this limitation at all. Anything you can parse into a standard syntax tree you'll be able to host on my semantic forge, and also I'll be able to put a fully-featured code editor right in the forge site so contributors can get started without ever even leaving their browser.

[reactordev]

Curious your thoughts on how we got here, with git being the dominant VCS. You do know how git rose to fame? Who wrote it? Why it was adopted?

It came from a need.

So what needs do we have that you solve?

I agree GitHub is evil. There’s GitLab, gitea, codeberg… self hosting, ssh like its old school git, you have other options.

[conartist6]

Line and column.

There's 50 years of tech debt in lines and columns which can be traced back through git to patch and then to TTY and to actual typewriters on which you had to feed the paper a line and return the carriage. Line and column are how you break down (and address into) code when code is written on a simulation of a stack of punchcards

[rcxdude]

Interesting, because one of git's philosophies is to not try to be clever about that (in reaction to a general trend in version control at the time of trying to make diffing and merging more clever: Linus felt this just tended to make the breakage less obvious).

[conartist6]

I respect the hell of those philosophies because of how far Linux and git have made it, which they've done by winning people over with good, solid choices. I would hope I'd be a good enough engineer to make the same choices if I saw the same things Linus saw 20 years ago. But it's 20 years later and I'm looking at the next 20 years and I see a different landscape and it causes me to have a different outlook. I think code literacy is a hugely important right now as a battle is fought over whether people will own their technology.

If many people are literate in code, the likelihood is far greater that they will own the tech and it will be open source and built according to principles that make software accountable to them. If most people are illiterate in code, they will become subjects to proprietary technology forced to use products which they have no control over.

The problem is that code literacy hasn't moved beyond the era where developers are people who own a physical keyboard and a full-size computer monitor, use a filesystem regularly, and are able to install and run native applications on their laptop or desktop. But here you've got the next generation of programmers who need to become literate in code (so that they won't become subservient to it) and for many all they have are touchscreens: phones and tablets. Maybe they're on a shared device where they can't or don't want to install software. They might not know what a filesystem or x86 machine code is. That's why I'm on mission to make code literacy and the ability to contribute to open source a matter as simple as having a screen and a browser.

[conartist6]

To reply more directly to the difference in philosophy around merging diffs, I think the git philosophy on preferring to expose potential conflicts rather than glossing over them is basically exactly right, because it creates a system to resolve ambiguity by capturing user intent. If I have any complaint it's that some types of ambiguities are not captured because they are not the result of textually overlapping changes. The canonical example would be a scenario where one developer renames a function and another adds a new usage of it. Git can see no text conflict and so it glosses over the semantic problem. A semantic system would be able to expose not only all the potential conflicts/ambiguities that git can see, but also some that it cannot. And in the case of an add/rename conflict the system should just handle it because the semantic intent of each change was recorded in the system: not "change these 8 call sites" but "change every site that calls this function."

[franktankbank]

I suppose this canonical example would be papered over easily with minimal test coverage.

[conartist6]

Yeah it can be, but you'd really prefer to know without having to go do an exhaustive search I think. The closer to the root cause you catch the problem the easier it will be to tell what happened. Plus, it's not always easy to run exactly the right tests and to run them at exactly the moment they're needed. I usually won't run the whole test suite on each commit if I'm just doing a rebase, say, but it would still be nice if I didn't sail past a problem that I would later have to retrace my steps to fix.

[hsbauauvhabzb]

Microsoft could probably look to run things like GitHub at a loss, picking up equity via their integrations and leveraging any data customers publish on GitHub to ingest into their own AI or sell to others.

[conartist6]

Sure, but if I wanted to I could also look to run at a loss for pretty much the same reasons. In either case it's a (profit-motivated) strategy to capture and hold a critical market.

[sys_64738]

https://en.wikipedia.org/wiki/Mercurial