OBS smashing XSplit comes to mind

Git is an interesting case in its obscure ergonomics. Maybe Linus was right in that for his initial user target group that turned into advocates, algorithmic elegance was a more important quality, so git won regardless of ergonomics for wider audience.

So various projects have come up ever since to try to patch the UX.

Interesting thought. "Nerds as advocates" is how Firefox rose to prominence, and later giving the nerds the finger contributed to its downfall, IMO.

Git ergonomics were far far better than the rest because of one reason that all the supposedly more ergonomic projects like Bazaar, Mercurial, SVN, ClearCase and lots of others failed miserably at:

Performance.

Since the CVS days, Version Control Systems got slower and slower. Centralized servers worsened the problem by doing everything in a synchronous manner, making people wait for locks, wait for checkouts, wait for diffs, wait for everything. But even the distributed ones like bzr or hg were slow as hell. What git enabled was the far superior ergonomics of not having to get a coffee while running a "git diff" on a project the size of the Linux kernel, X.org or LibreOffice. All the whining about inconsistent command line options and weird subcommand naming is totally secondary to this.

Nowadays, many of the aforementioned competitors either died out or worked on their performance problems. Nonetheless, git is still unmatched in this regard.

TeX is arguably the only application amongst these, as opposed to tool (and that’s debatable). OSS definitely dominates in tooling, but successful open source end-user applications are rarer.

Where do you draw the line between tool and application?

Even the qualifier "end user" application doesn't seem obvious to me. Is Photoshop an end user application or a tool for artists?

It’s debatable. Everything is layered, and one layer’s application/product is the higher layer’s tool/platform.

In the context of understanding where and why OSS is dominant, I think the tool/app distinction is whether the thing solves a software problem or whether it solves a business problem.

Through that lens, Photoshop is an application, while VSCode is a tool.

Tool, application, utility... sighs

Why is not Photoshop considered a tool? You use it to [...], as a tool. But then I do not see the difference between application, like an application can be a tool, can it not? It makes my head spin and English is not my native language.

So if we turn the clock back ten years, Visual Studio (the behemoth sold by MS to C# and C++ developers) would be an application, wouldn't it? It solves a clear business need, otherwise why would businesses pay so much money for it (more than for Photoshop). MSSQL and Oracle DBMS clearly solve business problems, they have slick UIs and sale people with powerpoint decks. Perforce P4 is an application that solves business needs for creatives (and also comes with P4V for a slick UI and costs photoshop-level money)

But at the same time Visual Studio is in the same category of software as VS Code, Oracle DBMS in the same category as postgresql, Perforce P4 in the same category as git. Surely that can't be it?

I'd agree in a heartbeat that developers are better at solving problems for developers. The less disconnect there is between developer and customer the better development goes, and the disconnect doesn't get lower than building developer tooling. But those things aren't any less apps or more tools than the things artists or technical writers or accountants use

VSCode is absolutely an application.

> I can think of a few more: Git obsoleted an entire category of commercial software seemingly almost overnight

Hmm, what commercial software would that be? Visual SourceSafe (lol)? ;)

Git mostly replaced SVN, and that is free and open too. But in scenarios where specialized version control software (like Perforce) is needed, git (and git lfs) breaks down too, and quicker than SVN does - e.g. for versioning large binary files git has actually been a massive step backwards and without a real solution showing up in 2 decades.

Git was created to replace BitKeeper. There used to be a whole industry of commercial version control software. I grabbed the following list from Wikipedia (but I image there where even more companies around):

- AccuRev SCM (2002)

- Azure DevOps Server (via TFVC) (2005)

- ClearCase (1992)

- CMVC (1994)

- Dimensions CM (1980s)

- DSEE (1984)

- Integrity (2001)

- Perforce Helix (1995)

- SCLM (1980s?)

- Software Change Manager (1970s)

- StarTeam (1995)

- Surround SCM (2002)

- Synergy (1990)

- Vault (2003)

- Visual SourceSafe (1994)

A lot of companies was also building their own internal version control software. Either from scratch or as a bunch of loose scripts on top of other existing solutions. Often turning version control, package management and build scripts into one single complex messy solution. I worked for a company early in my career that had at least 4 different version control systems in use across different projects and even more build systems (all a mix of commercial software and home grown solutions on top).

These days almost everyone uses Git. Some companies uses Mercurial or SVN.

One commercial actor that is still around is Perforce, which is still popular in the game industry. Since managing large game assets isn't optimal for Git (but is possible with Git LFS or Git annex, or similar solutions).

There are fully open adaptations of VS Code.

I use VSCodium.

Godot as well, whilst not an existential threat to Unity is certainly a big enough player to be considered in generalist game engines