>what are developers going to do when Google inevitably acquires GitLab?

Fork it and move on with their day.

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.

Dunno. The thing is, Microsoft knows they are ruthless. The thing that worries me about Google is, they are completely inaccessible, exist in a bubble and think they're the hero.

Okay, three things.

Yes, I do think this is the worrying part and worse, all the others try to become like them (Google). That future is scary.

Google in the past had Google Code, which was fine and had some level of success.

Microsoft had Codeplex and was rather similar. Didn't use it enough to form an opinion about it.

Both were largely left behind by Github.

You can also use another instance, like https://framagit.org, which is hosted by an independent org who fights for Libre Software since many years.

All your links will point to gitlab.com, you'll have top change everything again. The problem is centralization.

Which links ? Because if I host my projects on framagit, there’s no link to gitlab except maybe for documentation

There'll be a link to framagit.org. Links from other parts of the web. When someone blogs about your software, it'll be a link to that URL etc

Ok, you can also setup your own domain name I guess if you want to avoid that (like with github pages)

Google acquiring Gitlab is very inevitable. GV (which is a Alphabet and not Google subsidiary) always stated that their priority is to be a VC that is as neutral as possible, and should a Google competitor be interested in acquiring a portfolio company they are open to that.

Of course if you have them as an investor they will obviously try to help you with their network which can definately steer a company to a more Google friendly path.

> Google acquiring Gitlab is very inevitable.

From the rest of your post, I think you mean “...very much not inevitable.”

No.

If the portfolio company wants to be acquired by Google, then taking the network they get via GV certainly makes that route easier for them.

If the portfolio company decides if acquisition by another tech giant is the better route, they are free to do that and GV won't sabotage that deal. AFAIK there have been GV exits to all of the big Google competitiors.

> Google acquiring Gitlab is very inevitable

This means "Google is going to acquire GitLab".

> If the portfolio company decides if acquisition by another tech giant is the better route, they are free to do that and GV won't sabotage that deal.

To me, this reads as "Google might not acquire GitLab".

Yeah, wow had a brainfart their. I thought about "unavoidable" every time I wrote inevitable.

"Google acquiring Gitlab is very unavoidable" would also mean that Google IS going to acquire GitLab!

Yeah... I think I should get off HN for the day :D

Except for the “No”, that whole description is consist with “not very inevitable”.

“Inevitable” means “unavoidable", but what you've described is “possible, and maybe slightly more probable than if it wasn't a GV-backed firm, but by no means guaranteed.”

Buy a $5/mo VPS and self host your repositories? It’s really not that hard.

And spending how many hours a month maintaining it and applying updates and security patches and setting up monitoring and dealing with downtime?

The promise of these hosted services isn't the free storage/servers, its the maintenance of them.

We're running our own private GitLab server but we thought long and hard before doing it.

> And spending how many hours a month maintaining it and applying updates and security patches

Looks like GitLab puts out one release a month. Not a big deal. One day a month you can roll out the latest and greatest if you really want to. I probably wouldn't even do it that often, depending on what's included.

As far as all the underlying stuff, depending on what Linux distro you pick it should be pretty self maintaining nowadays for everything that's required to self host GitLab. nginx, PHP, etc. will all self update with your package manager of choice.

> setting up monitoring and dealing with downtime?

If you're buying a VPS you shouldn't need to worry about these. Any decent host will make sure your VM is up and have a high enough uptime to be solid for any use case short of enterprise. If you're an enterprise you might want to spend more than $5/mo.

> We're running our own private GitLab server but we thought long and hard before doing it.

Well that's up to you but it's really not hard.

To be fair, maintaining an (internal) gitlab server really only costs you the upgrade time. You make a snapshot, upgrade (and optionally rollback if something breaks). It takes exceptionally little time - unlike say, running your own email server.

I think Gitlab will be bought by Google soon

> what are developers going to do when Google inevitably acquires GitLab?

There are downsides to MS owning Github, but Google is in a whole separate universe of Evil.

So the answer is: Move out, don't hesitate, and if there's no other viable choice, yes, move back to Gitgub.