[derefr]

> libgit2, aka “the secret sauce”

I would describe GitHub's real "secret sauce" as the issue-tracking, wikis, project boards, and release management parts, that don't get represented in the repo itself.

Which is to say, if you wanted to commoditize GitHub (which is basically what "open-sourcing your secret sauce" means), you'd have to create some sort of library that allowed you to treat a git repo + all those other things as one structured data-object. You would be able to use said library to both operate on all those pieces of data locally; and to sync them between different Git hosting services that all share those features.

Or, better yet, figure out a way to put all those features into git itself, so that every git repo automatically transports those pieces of data alongside itself.

[enturn]

Fossil SCM has Integrated Bug Tracking, Wiki, and Technotes. It's not git but is distributed. It's used for sqlite project.

[derefr]

That's cool. I wonder why Git hasn't copied the implementation.

[dcuthbertson]

They are completely different. In fossil, commit history is sacred, where git users can rebase, and cherry pick to their hearts content

[derefr]

I meant the implementation of these side-features as objects sitting in the repo, with appropriate client commands for creating and editing them, etc.

Git already has notes, and signed commits/signed tags, which are all those same kind of "objects that just happen to be there." So they don't need to copy Fossil's architecture; they can just copy the way that said object types interact as dependents of commits (while letting them get blown away when commits themselves do.)

[tbrock]

I’m not sure. Almost every GitHub competitor does those things better: phabricator, gitlab, etc...

[derefr]

Maybe "secret sauce" is the wrong term. People ended up choosing GitHub purely because of network effects, I think. But those features are the "lock-in" preventing individual projects from easily migrating away.

If Git repos just "had" wikis, issues, etc. inside them, the lock-in wouldn't be there, so people would be switching between Git hosts all the time—and there wouldn't really be much value in a "git host" at all, beyond what just having a Git dir on your own server, plus a native-GUI Git client supporting the wiki/issues/etc. features, would get you.

[simula67]

> If Git repos just "had" wikis, issues, etc. inside them, the lock-in wouldn't be there

People clearly never cared about that, since Fossil ( https://www.fossil-scm.org/index.html/doc/trunk/www/index.wi... ) has these things and it never caught on

[jhasse]

Maybe it didn't catch on because of other reasons.

[kchoudhu]

This. Git is not a best in class solution, and the community that has coalesced around it has predictably not chosen best in class tooling.

This is okay. It's just source control at the end of the day.

[tbrock]

Yeah good point. That’s definitely true.

I think though that 99%+ repos or there have zero issues, pull requests etc.

[benologist]

Maybe there’s no secret sauce of any value and it’s just pointless github is closed source, like a form of DRM just being used against us cause we’re silly and let it be so even as we aspire to see open source flourish...

[ioquatix]

I started working on this actually. https://github.com/ioquatix/relaxo is a document database built on top of git. I recently added support for using a specific branch, so it should be trivial to allow a web app doing the things you suggest to store/run within the same git repo.

[eberkund]

The problem with trying to commoditize those additional features and creating a standard is that although these different services have similarities they also have subtle differences. I don't know if the companies that create these products or their users would want to standardize because the reason for the differences is because people have different preferences.