Move their repositories back to GitHub, switch to BitBucket or something else entirely?
[1] https://techcrunch.com/2017/10/09/gitlab-raises-20m-series-c...
[2] https://venturebeat.com/2018/04/06/why-and-how-gitlab-abando...
[3] https://about.gitlab.com/2018/04/05/gke-gitlab-integration/
Fork it and move on with their day.
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.
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.
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 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.
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.
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).
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...
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.
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.
Okay, three things.
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.
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.
From the rest of your post, I think you mean “...very much not inevitable.”
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.
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".
“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.”
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.
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.
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.