> Joel Spolsky in 2002 identified a major pattern in technology business & economics: the pattern of "commoditizing your complement"
> This pattern explains many otherwise odd or apparently self-sabotaging ventures by large tech companies into apparently irrelevant fields ...
> ...they are pre-emptive attempts to commodify another company elsewhere in the stack, or defenses against it being done to them.
After having read this article, it's been interesting how a lot of these investments have started making more sense. They often aren't primarily about the product itself, rather they serve the function of minimizing any leverage other companies could have over them.
As Github offers an access to a valuable resource for tech companies, developers, Microsoft could use it to promote its products/services and to attract talent. This isn't good for Google, so they are hoping to reduce Microsoft's leverage.
In some sense this is obvious, but I hadn't consciously identified this as a pattern before.
Me too; I've moved my active projects to Gitlab quite a while ago and haven't looked back. I just prefer everything about the Gitlab user experience over GitHub.
Gitlab _could_ be a brilliant SaaS product. It has many more features than github, Runner integration allows simple and easy building, instead of having to bust out to circleCI.
As a self hosted product, it is difficult to be beaten.
but as a Saas product, its just horribly unreliable.
In the last two months it has improved, but there are still outages every two weeks or so. (https://twitter.com/gitlabstatus) I'm hoping that with this extra cash, they'll be hiring in some infrastructure people (people who will look at this in horror: https://about.gitlab.com/2016/12/11/proposed-server-purchase... ) who actually know how to make a stable platform using _proven "boring"_ stuff, not sexy slow and supposedly HA stuff like Ceph and forcing it to serve NFS.
Thanks for your comment, we really appreciate the feedback. Our team is working hard on improving the availability and stability of the platform. Our goal is currently to achieve 99.95% availability on GitLab.com.
According to Pingdom, over the last year our availability has been 99.81%, although this includes the large (multi-hour) maintenance window on 11 August 2018 when we migrated GitLab.com from Microsoft Azure cloud to Google Cloud Platform (GCP).
Since the migration, our availability has improved greatly (caveat: we obviously have much less data than from Azure).
Using the data publicly available from Pingdom, here are some interesting stats:
Mean-time between outages in Azure (September 2017 through August 11 2018): 1.3 days
Mean-time between outages in GCP (September 2017 through August 12 2018): 7.3 days (if you ignore some problems we experienced on the first day after the migration, this rises to 12 days!)
Since, migrating to GCP, our overall availability, according to Pingdom, has risen to 99.92%. Again, if you exclude the few hiccups that we experienced on the Monday immediately following the migration, this rises to 99.97%.
There are multiple reasons for this improvement. We chose Google Cloud Platform because we believe that they offer the most reliable cloud platform for our workload, particularly as we move towards running GitLab.com in Kubernetes. It is worth pointing out that we also used the migration as an opportunity to improve our infrastructure, simplify some components and otherwise make things more stable and more observable. Finally, we've also been focusing on building the infrastructure team up, having hired many new team members over the past few months. This means that the team has been better able to balance the job of running GitLab.com with making it more stable.
Part of the problem is that these, at least the ones making the fundamental decisions, are likely to be software people, with not enough ops/sysadmin experience.
> who actually know how to make a stable platform using _proven "boring"_ stuff, not sexy
The ones who do may have gotten bored of it, themselves, and no longer admit it, instead leaning toward as much of the "Dev" part of DevOps (as a title) as possible, since that's where the excitement (and decision making power) tends to be. The rest of us are borderline unemployable.
In the past we have had few "code repos" from Savannah to Sf and few sites like freshmeat to spread the news, the code, the idea. Of course we also have had and have used usenet.
IMVHO today it's time to evalutare ZeroNet for project sites/blog and something like IPFS (not much convinced by this project but...) for code and repos to AVOID depend on someone else server's switching to relay only on us all.
For me there is no difference in GitHub or GitLab or Bitbucket etc, nor between Google and Microsoft. In an era of diversity companies are not a problem, in an oligopolistic era like today, in an era of proprietary platforms instead of open standard companies are a problem and should be avoided, especially if they are big, especially if they push mix of proprietary and FOSS solution.
I use github a lot but I'm not too worried about the vendor lock-in. Since git is by nature distributed it's trivial to migrate the code elsewhere. The real problem is migrating the issues (but there are solutions for that as well, even if it's a bit more clunky) and the "social network" aspect but I don't care much for that myself.
But you're right, maybe IPFS plus something like Fossil (including issues in the VCS directly) could be a good solution to have a truly decentralized "platform".
>ZeroNet is a decentralized web-like network of peer-to-peer users.
so how do you "spread the word" by using a peer to peer network that no one has signed up for? might as well share a link to the project on your google drive on a subreddit you maintain but don't publicize
Actually I trust Microsoft more with Github than I would trust Google. Never imagined I would say this until few months ago. Also I just left free google consumer services few days ago.
Microsoft, since Satya took over, is a developer-first company. Everything they're doing is designed to give developers better tools on whatever platform they choose.
As we're all aware by now, Google is an advertising company (with a heap of technology, but it's still a company which primarily sells advertising).
The bigger and more authority something wields the more people should be should be inclined to be skeptical of it.
More than a decade ago the behemoth was Microsoft. Now it's Google. I guess if those positions reversed again I'd go back to being more skeptical of Microsoft.
I just have mail left to migrate, which in itself is proving quite difficult. Mail services are plentiful, paid or free, but mail for 5+ custom domains, where i'm not paying $5/mo per user, those are hard to come by.
I'm planning on, once again, spinning up my own mailserver on a $5/mo VPS. Have lots of domains, but not that many users/traffic.
Microsoft only left US Federal oversight seven years ago. Satya has only been in charge for four years. Do you think the mindset of an international 130,000 employee company can change that fast?
Gitlab, from my outside perspective, seems to be a company run with commonly accepted (here) best practicies through and through.
Very transparent to users, open core, very modern tech stack, entirely remote workforce, what more could you ask of a company? They aim to do things basically the way we as a community would ask.
For self-hosters like me, I like and recommend Gitea [1] (based on gog). Same workflow as GitHub, but in your own hands. You can open it up to the masses or keep it close to the vest, your call. A Docker version is available, but its Go-ness makes it super easy (and even lighter) to deploy on its own anyway.
I third this. I've installed/maintained and used gitolite, gitlab and gitea.
- gitolite: easiest to install and manage. But there's no web interface. Your entire workflow is with git itself (and maybe some SSH/Unix tricks/scripts).
- gitlab: huge, bloated beast. Many, many different components. Difficult to understand all the pieces. Uses a ton of ram and CPU cycles. UI and workflow is different from Github.
- gitea: single, stand-alone package. UI and work-flow is identical to Github. Given all that it does, it seems about as simple and light-weight as it could be. (My only pain point is that it's written in Go, with Go packages, and I don't really know anything about Go...)
Some programmers were concerned about how Microsoft -- historically critical of open-source tools like GitHub and GitLab -- would change the platform as its new owner.
I wasn't aware MS was critical of GitHub and GitLab. Does anyone has more info on this?
It's a misleading sentence, I would say - Steve Ballmer was very critical of open source (he once called Linux "a cancer"), but this was certainly "historically", ie. quite some years before GitHub and GitLab even existed.
"Alphabet’s role in funding the 350-person firm comes soon after it lost out to Microsoft in the bidding for GitHub. "
Can someone describe to me how bidding for companies like GitHub works? Is it a blind bid where the highest bidder is selected? Or are participants given the opportunity to up their bid against one another?
What are your thoughts on Auto DevOps? It seems that Gitlab is being perceived more and more as an end-to-end devops platform that is mostly automated but I've heard it doesn't work really well.
Potentially, very powerful. Running docker-based pipelines, deploying on kubernetes, and having it all integrated with the merge request review workflow is really, really nice. GitHub doesn't do anything at this level at all, even with third-party integrations.
Right now, I've got several local machines hooked up to gitlab.com as runners. A mixture of virtual machines for various platforms, and docker hosts. No kubernetes yet; but likely at some point.
The main problems are that sometimes gitlab.com is flaky. Pipeline jobs fail, never get started, or never complete. Not often, but enough that I can't guarantee things will work without manual prodding. I saw quite a few instances of this a few weeks ago, but it's been OK this week. Stuff like the runner timing out pulling a docker image, the job completing but not actually finishing, or the pages job running but the deploy step getting stuck with no way to debug it.
Other things are UI annoyances, like the pipeline status not updating frequently enough, leading to repeated manual page refreshes, particularly on navigating back in the history to the pipeline page from a specific job page.
ducks in advance - I acknowledge that Microsoft and Google are not without sin, especially Google, but at least the coding and engineering teams of Google that I've been watching, namely the prolific #webperfmatters crowd behind free beer contributions such as SPDY, QUIC, WebM/WebP, mod/ngx_pagespeed, Brotli, HSTS pinning and leveraging other teams' Google assets like SERPs and Chrome padlock design to pressure the adoption of HTTPS use, at least that behavior, talent and energy seems to be in line with the gist of Github. These teams collaborate with organizations you (plural) find much less threatening, for example with Brotli (gzip alternative), there was collaboration between veteran Google and Mozilla developers, and now about 85% of us use browsers that have implemented Brotli support which, in addition to claims and my own testing, is across-the-board superior to gzip in this context. As for adoption on the server side, NGINX at least was open minded.
All the time independent developers cook up superior things to prevailing standards but, lacking the might of Google and Microsoft and Mozilla, their work seldom gains traction. Git* under control of Microsoft and Google could give the little guys with the superior code a better spotlight, a symbiotic win-win for everybody.
I am convinced guys like Ilya Grigorik and Colt Mcanlis show up to work, and to public lectures, with making the web faster as their objective. Were they pressured to insidiously exploit Gitlab to our detriment, they'd blow whistles to stop Google, like with AI collaborations with the military, or at least resign, I'd hope. They'd have better and nobler things to do than be party to that.
Judging from the pronounced skepticism and negative consensus among this crowd to such actions, I think you will do an effective job hedging the risks and "keeping them [Google, Microsoft] honest" with respect to treasures like Github and Gitlab, both in your scrutiny and the influence you wield.
I also think that, if they behave themselves, their control over Github/Gitlab may give them more return on their respective investments than were they to Do Evil. Further, if they can't resist their undesirable habits, or even if they do behave, a market has already been created for some sort of Lavabit-like set of competitors to emerge, and that should be regarded as a good thing as another consensus hereabouts has been, before Microsoft's involvement, that Github's growth was a threat and at odds with our interests.
That said, note the lack of citations in my comment indicating that this is nothing but unfounded devil's-advocate corporate-apologist Google-fanboy speculation on my part and that you all are probably right... Cheers everybody!
edit: Ouch, i thought that was more substantive than contrarian. Before this gets voted to death, could someone please offer a rebuttal? I'm often wrong and it could help me wake up.
[+] [-] Presquare|7 years ago|reply
> Joel Spolsky in 2002 identified a major pattern in technology business & economics: the pattern of "commoditizing your complement"
> This pattern explains many otherwise odd or apparently self-sabotaging ventures by large tech companies into apparently irrelevant fields ...
> ...they are pre-emptive attempts to commodify another company elsewhere in the stack, or defenses against it being done to them.
After having read this article, it's been interesting how a lot of these investments have started making more sense. They often aren't primarily about the product itself, rather they serve the function of minimizing any leverage other companies could have over them.
As Github offers an access to a valuable resource for tech companies, developers, Microsoft could use it to promote its products/services and to attract talent. This isn't good for Google, so they are hoping to reduce Microsoft's leverage.
In some sense this is obvious, but I hadn't consciously identified this as a pattern before.
[+] [-] hardwaresofton|7 years ago|reply
They've fully stepped out of the shadow of Github (for a long while, in my mind), and it's nice to see people taking attention.
[+] [-] drakonka|7 years ago|reply
[+] [-] chii|7 years ago|reply
why not? If it means gitlab can have the resources to keep improving...
and given that it's open-source, there's no fear of any shutdowns.
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] KaiserPro|7 years ago|reply
As a self hosted product, it is difficult to be beaten.
but as a Saas product, its just horribly unreliable.
In the last two months it has improved, but there are still outages every two weeks or so. (https://twitter.com/gitlabstatus) I'm hoping that with this extra cash, they'll be hiring in some infrastructure people (people who will look at this in horror: https://about.gitlab.com/2016/12/11/proposed-server-purchase... ) who actually know how to make a stable platform using _proven "boring"_ stuff, not sexy slow and supposedly HA stuff like Ceph and forcing it to serve NFS.
[+] [-] dsumenkovic|7 years ago|reply
According to Pingdom, over the last year our availability has been 99.81%, although this includes the large (multi-hour) maintenance window on 11 August 2018 when we migrated GitLab.com from Microsoft Azure cloud to Google Cloud Platform (GCP).
Since the migration, our availability has improved greatly (caveat: we obviously have much less data than from Azure).
Using the data publicly available from Pingdom, here are some interesting stats:
Mean-time between outages in Azure (September 2017 through August 11 2018): 1.3 days
Mean-time between outages in GCP (September 2017 through August 12 2018): 7.3 days (if you ignore some problems we experienced on the first day after the migration, this rises to 12 days!)
Since, migrating to GCP, our overall availability, according to Pingdom, has risen to 99.92%. Again, if you exclude the few hiccups that we experienced on the Monday immediately following the migration, this rises to 99.97%.
There are multiple reasons for this improvement. We chose Google Cloud Platform because we believe that they offer the most reliable cloud platform for our workload, particularly as we move towards running GitLab.com in Kubernetes. It is worth pointing out that we also used the migration as an opportunity to improve our infrastructure, simplify some components and otherwise make things more stable and more observable. Finally, we've also been focusing on building the infrastructure team up, having hired many new team members over the past few months. This means that the team has been better able to balance the job of running GitLab.com with making it more stable.
[+] [-] mmt|7 years ago|reply
Part of the problem is that these, at least the ones making the fundamental decisions, are likely to be software people, with not enough ops/sysadmin experience.
> who actually know how to make a stable platform using _proven "boring"_ stuff, not sexy
The ones who do may have gotten bored of it, themselves, and no longer admit it, instead leaning toward as much of the "Dev" part of DevOps (as a title) as possible, since that's where the excitement (and decision making power) tends to be. The rest of us are borderline unemployable.
[+] [-] xte|7 years ago|reply
IMVHO today it's time to evalutare ZeroNet for project sites/blog and something like IPFS (not much convinced by this project but...) for code and repos to AVOID depend on someone else server's switching to relay only on us all.
For me there is no difference in GitHub or GitLab or Bitbucket etc, nor between Google and Microsoft. In an era of diversity companies are not a problem, in an oligopolistic era like today, in an era of proprietary platforms instead of open standard companies are a problem and should be avoided, especially if they are big, especially if they push mix of proprietary and FOSS solution.
[+] [-] simias|7 years ago|reply
But you're right, maybe IPFS plus something like Fossil (including issues in the VCS directly) could be a good solution to have a truly decentralized "platform".
[+] [-] kkarakk|7 years ago|reply
so how do you "spread the word" by using a peer to peer network that no one has signed up for? might as well share a link to the project on your google drive on a subreddit you maintain but don't publicize
[+] [-] spot|7 years ago|reply
[+] [-] ssijak|7 years ago|reply
[+] [-] flyinglizard|7 years ago|reply
As we're all aware by now, Google is an advertising company (with a heap of technology, but it's still a company which primarily sells advertising).
[+] [-] s_dev|7 years ago|reply
More than a decade ago the behemoth was Microsoft. Now it's Google. I guess if those positions reversed again I'd go back to being more skeptical of Microsoft.
[+] [-] Aeolun|7 years ago|reply
With Google I’m not so sure any more. Hopefully I’ll soon be able to say goodbye as well.
[+] [-] rqs|7 years ago|reply
If Google wants to throw some of their money on something that end user can fully control, then why not be happy about it?
[+] [-] 8fingerlouie|7 years ago|reply
I'm planning on, once again, spinning up my own mailserver on a $5/mo VPS. Have lots of domains, but not that many users/traffic.
[+] [-] sureaboutthis|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] zaarn|7 years ago|reply
[+] [-] ABS|7 years ago|reply
They haven't bought GitLab
[+] [-] agentPrefect|7 years ago|reply
[+] [-] etaioinshrdlu|7 years ago|reply
Very transparent to users, open core, very modern tech stack, entirely remote workforce, what more could you ask of a company? They aim to do things basically the way we as a community would ask.
How will it turn out? Anyone's guess :)
[+] [-] chrisseaton|7 years ago|reply
Don't they have massive scaling problems? And didn't they delete their production database by mistake recently?
GitHub doesn't seem to have faced the same problems - so it seems difficult to argue GitLab has better practices.
> what more could you ask of a company?
Reasonable page response times?
[+] [-] conquistadog|7 years ago|reply
[1] https://gitea.io/en-us/
[+] [-] spin|7 years ago|reply
- gitolite: easiest to install and manage. But there's no web interface. Your entire workflow is with git itself (and maybe some SSH/Unix tricks/scripts).
- gitlab: huge, bloated beast. Many, many different components. Difficult to understand all the pieces. Uses a ton of ram and CPU cycles. UI and workflow is different from Github.
- gitea: single, stand-alone package. UI and work-flow is identical to Github. Given all that it does, it seems about as simple and light-weight as it could be. (My only pain point is that it's written in Go, with Go packages, and I don't really know anything about Go...)
[+] [-] compute_me|7 years ago|reply
[+] [-] hden|7 years ago|reply
[+] [-] gtirloni|7 years ago|reply
I wasn't aware MS was critical of GitHub and GitLab. Does anyone has more info on this?
[+] [-] majewsky|7 years ago|reply
[+] [-] petepete|7 years ago|reply
[+] [-] TheLoneAdmin|7 years ago|reply
[+] [-] bshimmin|7 years ago|reply
[+] [-] aiCeivi9|7 years ago|reply
> historically critical of open-source tools that have its file hosted on GitHub and GitLab
Maybe it was overzealous editor and simplified it too much.
[+] [-] drakenot|7 years ago|reply
Can someone describe to me how bidding for companies like GitHub works? Is it a blind bid where the highest bidder is selected? Or are participants given the opportunity to up their bid against one another?
[+] [-] shagie|7 years ago|reply
There was certainly more to it than comparing two numbers.
[+] [-] pibefision|7 years ago|reply
[+] [-] tryum|7 years ago|reply
[+] [-] leowoo91|7 years ago|reply
[+] [-] cedricziel|7 years ago|reply
[+] [-] IshKebab|7 years ago|reply
[+] [-] kylnew|7 years ago|reply
[+] [-] detaro|7 years ago|reply
[+] [-] jplayer01|7 years ago|reply
[+] [-] pimmen|7 years ago|reply
[+] [-] MordodeMaru|7 years ago|reply
[+] [-] rleigh|7 years ago|reply
Right now, I've got several local machines hooked up to gitlab.com as runners. A mixture of virtual machines for various platforms, and docker hosts. No kubernetes yet; but likely at some point.
The main problems are that sometimes gitlab.com is flaky. Pipeline jobs fail, never get started, or never complete. Not often, but enough that I can't guarantee things will work without manual prodding. I saw quite a few instances of this a few weeks ago, but it's been OK this week. Stuff like the runner timing out pulling a docker image, the job completing but not actually finishing, or the pages job running but the deploy step getting stuck with no way to debug it.
Other things are UI annoyances, like the pipeline status not updating frequently enough, leading to repeated manual page refreshes, particularly on navigating back in the history to the pipeline page from a specific job page.
[+] [-] d0ugie|7 years ago|reply
ducks in advance - I acknowledge that Microsoft and Google are not without sin, especially Google, but at least the coding and engineering teams of Google that I've been watching, namely the prolific #webperfmatters crowd behind free beer contributions such as SPDY, QUIC, WebM/WebP, mod/ngx_pagespeed, Brotli, HSTS pinning and leveraging other teams' Google assets like SERPs and Chrome padlock design to pressure the adoption of HTTPS use, at least that behavior, talent and energy seems to be in line with the gist of Github. These teams collaborate with organizations you (plural) find much less threatening, for example with Brotli (gzip alternative), there was collaboration between veteran Google and Mozilla developers, and now about 85% of us use browsers that have implemented Brotli support which, in addition to claims and my own testing, is across-the-board superior to gzip in this context. As for adoption on the server side, NGINX at least was open minded.
All the time independent developers cook up superior things to prevailing standards but, lacking the might of Google and Microsoft and Mozilla, their work seldom gains traction. Git* under control of Microsoft and Google could give the little guys with the superior code a better spotlight, a symbiotic win-win for everybody.
I am convinced guys like Ilya Grigorik and Colt Mcanlis show up to work, and to public lectures, with making the web faster as their objective. Were they pressured to insidiously exploit Gitlab to our detriment, they'd blow whistles to stop Google, like with AI collaborations with the military, or at least resign, I'd hope. They'd have better and nobler things to do than be party to that.
Judging from the pronounced skepticism and negative consensus among this crowd to such actions, I think you will do an effective job hedging the risks and "keeping them [Google, Microsoft] honest" with respect to treasures like Github and Gitlab, both in your scrutiny and the influence you wield.
I also think that, if they behave themselves, their control over Github/Gitlab may give them more return on their respective investments than were they to Do Evil. Further, if they can't resist their undesirable habits, or even if they do behave, a market has already been created for some sort of Lavabit-like set of competitors to emerge, and that should be regarded as a good thing as another consensus hereabouts has been, before Microsoft's involvement, that Github's growth was a threat and at odds with our interests.
That said, note the lack of citations in my comment indicating that this is nothing but unfounded devil's-advocate corporate-apologist Google-fanboy speculation on my part and that you all are probably right... Cheers everybody!
edit: Ouch, i thought that was more substantive than contrarian. Before this gets voted to death, could someone please offer a rebuttal? I'm often wrong and it could help me wake up.
[+] [-] gaius|7 years ago|reply