You will not be able to easily move away from any dominant platform because it will be not just the code but the community you leave behind. Also it's quite possible that github will add CI stuff directly into Azure and if you start using that, there may be no other product to move to with the same functionality.

Vendor lock-in is a strategy that works even if you know its there. I'm building my code with the excellent CI stuff built into Gitlab today and I really don't want to move away from it because of its amazing ease of use.

> You will not be able to easily move away from any dominant platform because it will be not just the code but the community you leave behind.

I find it hard to believe that an audience of developers can't point their browser to a different url, or search for your project using Google.

Right but because they're otherwise decentralised it would take co-ordinated effort and ultimately it fragments the community. What we need, if we want to solve this issue, is a federated network of servers which provide the functionality of github today.

That is already the case. The underlying "protocol" is git.

And if the functionality of github became the basic minimum, each provider will still provide their value-added on top of that.

If that sort of thing is forbidden, then there will be no motivation for improvement.

Then I'm curious what kind of data would be shared on the federated protocol. Why can't projects be independent?

I think primarily identity and git locations.

I want stuff like the issue tracker/merge request dialog to be consistent across the federation (and of course for projects elsewhere in the network to be able to be the source for those merge requests)

I don't want an account on everybody's git{lab,hub,ea,xxx} instance I want a single identity that people can trust is me.

I want a way to discover and index other projects on the network. The same way that I often just go to github without knowing the name of a project just roughly what I'm looking for.

> I don't want an account on everybody's git{lab,hub,ea,xxx} instance I want a single identity that people can trust is me.

I know blockchain is excessively overhyped, but to my limited understanding this appears to be a good fit...

Look at how cryptocurrencies work, a wallet is singular (i.e your identity), exchanges and mining pools are numerous and independent (hosts and services for git repos).

The vital part to make this work is a specification for storing the social aspects of collaborating on these platforms in a git repo itself - it can definitely be done, git is so flexible, it doesn't have to interfere with the project code or even need to be present in the visible tree of any branch - but we need that for interchangeability. This first step could be made before figuring out how to make neatly interacting network to add portability to existing platforms.

Yes, I think identity management/authentication/trust is a problem space that should be separate from version control, because it can serve so many other interesting applications.

By the way, I'm not sure if something like a blockchain is necessary here. You could use a simple public key cryptosystem, where your identity equals the public key, and you prove that you have that identity by using your private key in a challenge/response scheme, and you can also sign messages/commits/whatever by using your private key.

> By the way, I'm not sure if something like a blockchain is necessary here. You could use a simple public key cryptosystem.

I think you're right public crypto is enough... i'm just applying blockchain unnecessarily.

I can see this working in a really nice way: right now people are dealing with "migrating" and having to choose to loose PR/issues starts etc that these platforms provide, all of that could be implicit to the repo with zero effort to use a different platform.

- Public crypto for repo authority (who can commit, who can merge PRs, who can manage issues etc - preferably more granularity than current platforms)

- A common Issues/PRs etc format is saved into the repo

- Hosts are networked, they sync repos with each other allong with any platform data... anyone can add (sync) a repo from github to gitlab without being the author (ownership is done by crypto not platform accounts, each platform/host would verify the repo content when syncing from some other host).

In other words, platforms like github and gitlab etc just become a viewport and a node in the network, like there are GUIs for git, github would be just another GUI for the collaboration protocols... at this point you could even do it offline with a headless server, the purpose of github/gitlab is to provide hosting and good UX etc. This would mean that a repo can simultaneously exist on any platform, there is no platform boundary, you could accept a PR from a user using gitlab on github... it wouldn't matter where they came from. Or if you hate all these platforms you can just use the cli and accept a PR from someone using these platforms (you would just need a public git host that the other host/platforms can sync with).

How the crypto integrates with the repo would have to be well thought out as it's essentially completely independent of platform accounts, anyone could locally clone the repo and attempt to push something to your public server (or a hosting platforms server on your behalf).

> I think primarily identity and git locations.

Accounts/authorization is already semi-federated through oauth etc. You can sign in to gitlab.com using your github.com account.

We still have only one kind of namespacing and for users and projects: domains, leveraged by Java (and go, others?) for packages, and email for identity.

Discoverability is really a matter of indexes and catalogs; npm, pypi, Google and duckduckgo.

Delegating login is actually useful for self-hosted vcs/issue trackers: not as low friction as just sending an email with a patch; but it's easier to be able to "sign in" with an existing account, add an issue/code - and get notifications via email - rather than having to manage an account for every program you use and find bugs in...

This is why I'm very wary of recommending any serverless solutions. All the consultants we work with are lusting for them. It's pretty hard to push back against it.

As long as GitLab remains also deployable on your own infrastructure and not become a SaaS-only platform, I'll worry less about this.

You know that GitLab offers commercial add-ons?

You know that in most cases, they are "neat-to-have" and not essentials?

Not all of GitLab is open source, you know that, right?

That's a valid argument against GitHub, since they open source a ton of code, but you can't run GitHub yourself.

That's not a valid argument against GitLab, which offers you the option to host it yourself, and then builds features on top of the free version.

While GitLab EE isn't released using an open source license, its source is publicly available and you're allowed to make modifications to it, satisfying 2/4 essential freedoms of free software, as defined by FSF[0]: https://gitlab.com/gitlab-org/gitlab-ee/

[0] Open Source Initiative's definition contains 10 rights, I'm too lazy to memorize them.