That's one hell of a pessimistic view if I've ever seen one.

What I see is an brilliantly managed company despite having a globally distributed team, which has a great pace of development, which is carving a nice market share in an extremely tough market (developers) and against a fierce competitor (Github), let alone the other multibillion company backed Bitbucket.

And their radical transparency, as you put it, is a fascinating thing in and of itself. If anything it makes me feel intimate with the company. Hard to put it in words, maybe because I was a rather early adopter but if you follow them closely it's a like you're there on their board with spectator mode on. That's some invaluable experience for HN crowd.

Are we even talking about the same company?!

Is the company "brilliantly managed" because they still exist? What is an example of this management brilliance? At this point, all the company has proven is that it is able to convince investors to give it money. I see a bloated company with over 100 underpaid junior-level engineers putting out subpar software.

The radical transparency may be a fun experiment and it may provide a lot of interesting data to parse, but it's not a good way to run a real company. It screams of impractical idealism. A lot of companies are bad, but GitLab wants to make sure that you know they're bad from a distance. In theory this is all great and nice. In practice, it hurts the company in both commerce and recruiting.

The truth is probably somewhere in the middle.

How do you get "brilliantly managed company" when they just had a massive data loss? How can you say that honestly?

Is there a strong correlation between company management and ops practice?

Especially for small companies, I'd hope so. If management isn't even aware that they've got data backup issues, they're missing valuable information, yeah?

My boss makes sure I backup stuff...and we're not taking on millions of dollars in funding and customers.

Not sure I entirely agree but I do feel GitLab is caught up now in the hyper-growth circle like every other startup :/ If the enterprise angle does not work out, there is no backup plan. They compete against GitHub and Atlassian in this space and can only grow so much (but VCs was never ending growth).

I can't be bothered to bother that GitLab has junior people, even to the extend that it's the first "real job" for some of them. We hire people for their first "real job" all the time -- someone has to!

Of course, the problem is not that some people are junior. The problem is that most people are junior, because, ironically, unless you live in one of the most expensive cities on the planet, their compensation is not commensurate with what an experienced developer can make in any first-world market.

When you have an inexperienced crew running your tech, you get a lot of very preventable issues, which sometimes approach apocalyptic scale (like GitLab's February data loss). That's fine for some businesses, but it shouldn't be fine for something as important as GitLab.

Are there evidence that the founders are not willing to learn or something like that.

Just the fact that they've been around a long time now, and are still like they are.

Um ok. What's actually wrong with the product? Why is it not "well-engineered"? All the things you said could be true, yet their product is amazing. I haven't used it, but I like what I'm seeing.

So what if a smart experienced developer (their CTO) is able to get good prices on what he/she wants done through remote work? The point you're making is negativity for no reason without evidence on how it's not working, i.e. what's wrong with their product.

It doesn't take much investigation to start seeing problems, or to see major lapses in engineering from both a concrete (e.g., bugs) and a process (e.g., data loss) perspective. The data loss event that made it clear that GitLab a) never tested its backups b) didn't have a real monitoring/alarming system to inform its employees when things broke c) did not have processes enforcing clear separation between production environments and d) did not know how to configure a PostgreSQL cluster, among many other basic flaws, is just one recent example. The postmortem for that event included the accidental disclosure of a serious DoS exploit, itself the symptom of poor engineering practice (hard-deleting all content flagged as spam, making it impossible to redeem erroneously targeted content; a user could maliciously trigger such deletes with minor effort), which was live on the site until a couple of hours after that disclosure was discussed on HN. As I understand the ticket explaining this, the entire spam cleanup system was shut off until they could teach it not to hard delete anymore. Many other junior-level mistakes are regularly discovered and discussed, both on their bug tracker and elsewhere.

Other than that, GitLab is a beast to install and navigate and it requires a lot of resources. Rails is slow. The UI is weird (frequently end up not finding the repo I want due to the way the "trending" tab works). There are other issues. I'm not a GitLab contributor so I don't really have more technical detail, I just use it sometimes.

It seems like you're just assuming they're a great company with a well-engineered product because you like the corporate image they project.

I don't know of anything about them that makes either themselves or their product "amazing". It is somewhat usable, which is good; I'm not trying to besmirch the earnest efforts of people to make something that works, and indeed there are some uses for something like GitLab. That doesn't mean that GitLab is "amazing" or that their product is flawless or even good.

The most exciting thing about GitLab to me is remotely distributed teams, which I usually love seeing, but I think they've gone about it all wrong.

Shouldn't you use the software before calling it amazing?

Your reflexive defense isn't any more useful than extreme criticism.

I didn't say it was amazing. Perhaps you are the one being reflexive.

I wrote:

"All the things you said could be true, yet their product [could be] amazing."

Grammatically, it's called "elliptical." I then immediately say: "I haven't used it, but I like what I'm seeing"--so what I meant should be quite obvious.

What value are you adding with your criticism of what--in my case--at least has a question:

"What's actually wrong with the product? Why is it not 'well-engineered'?"

My point was extremely clear--his post needed to have evidence of how their processes results in bad product. And I asked that as a question--perhaps you know? Something tells me you even do (perhaps you're a Gitlab user), yet you're choosing to take an unproductive meta route of criticizing my partial criticism with no actual goal. What do you expect to accomplish with that?

I presume you got stuck on one word ("amazing"), made up your mind and didn't read the rest. My bad, i could have been more clear. However, the essence of what I was saying was straightforward, but you chose to see the forrest instead of the trees. A common reason people take that route is because there is something else you wished to express, but didn't--perhaps you have real experience with gitlab in one way or another that resonates more with the person's viewpoint I replied to. I'm not saying he's wrong--I just would like to hear the full reasoning behind that perspective.

I'd love to hear what that actual perspective is. Gitlab is an interesting product I haven't spent much time reviewing until today. Maybe you can provide the evidence to back up the original poster's point??

You can find out if their product is amazing by creating an account and using the software. It takes ten minutes, less time than it takes for you to type up that post. The original poster shouldn't have to explain to you how good the software is when you can try it. If you haven't used it his criticisms of the product aren't going to be useful to you anyway.

I haven't used it, but I like what I'm seeing

If you're just talking about what you're seeing, you have the same vantage point as everyone else and the original poster made a number of obvious and valid criticisms - data loss is one, they are selling software and a service.

It probably is trolling on my part, but as harsh as the original poster's words were, he's got some points.

The data loss event that happened--to me--isn't enough to describe the quality of their product. I could go try it, but it's a few hours in (if not a weekend) to really get answers that someone experienced could provide in 3-5 bullet points.

I guess we have one bullet point, do we have more?