For example Gitlab is just a few years old whereas the competitor (which is also the market dominator) GitHub is an old stable and highly reliable.
Depends. In general, I think it is a good thing to try the software and use it if it suites your needs and taste, even if it is young. Usage and a community will help the service grow and problems like that data leak will help Gitlab to become better in the future (because they will likely employ measurements to prevent something like this from happening in the future again).
However, you shouldn't use it for important stuff! But hey, your important stuff likely has more than one backup either way ;)
This depends on the service and contingency.
E.g. gitlab lost issues and non-crucial things. Since it's basically git most of the data should still be there and recoverable. Users could always move to another host etc. So yes I'd use gitlab in theory although we currently use github.
Parse is an example of a service we shouldn't have used, since it relies on a fixed server that you can't move you have to push updates to all your mobile apps to migrate which would be a production nightmare. This applies to all backend-as-a-service solutions IMO.
Our mobile cloud solution is used in compile time, so in my (heavily biased opinion) it shouldn't be a problem. Even if the worst case scenario happens and we go down... We won't lose your data (we don't have it) & your customers will never know since the dependency on our service is during compile time, not runtime.
Was there something about the Gitlab disaster that was unique to them? From where I stand it could have just as easily happened at Github or anywhere else
I'm still using GitLab for that reason they handled it the right way.
Wunderlist went down last year, that took 3-4 days to get up again and they didn't say anything about what went wrong. I abandoned them.
Juho Vepsäläinen
SurviveJS
I think the lesson to learn is that you should hedge your bets. Instead of using one service, perhaps you can protect yourself against a catastrophic failure. Chaos engineering relies on these kind of ideas. If you inflict chaos on yourself, you will deal with it better when it eventually catches up with you.
When it comes to Gitlab, this would mean managing your source and related metadata so that it is possible to access without the service. I would love to see mirroring between services as that would avoid the overall risk. This would be possible especially with Git. It's issue tracking and the rest that's harder to manage at the moment.