5 ms·

The reason why I think GitLab has been massively overvalued and why GitLab will ultimately fail is because it is storming head on into becoming a stale company.

The reason why I think GitLab has been massively overvalued and why GitLab will ultimately fail is because it is storming head on into becoming a stale company. Normally a startup is innovating in one vertical, disrupting the market with new ideas or technology which enables users and the company itself to profit of those innovations. This continues normally until the startup has become number one in that vertical. Then it must defend its spot against other newcomers who want to disrupt. Part of the defence is diversification, use the capital to disrupt in other places as well. This has been the natural progression of every successful business I know. At some point that company is so big though, competing in so many verticals that it becomes stale. It stops innovating and is constantly on the defence. Only innovation comes through acquisition which is often just a way to defend your spot by buying early. GitLab is sort of not even trying to become number one in one vertical. Like the CEO said in his interview, GitLab already competes in 9 different verticals (JIRA, Jenkins, GitHub, NewRelic, Artifactory, etc.) and they are not near the top anywhere yet. They are going to become stale before even reaching a single peak in any industry. So far they have not innovated anything yet. Their only innovation is "free private repos" and "cramming 9 different domains into one product", which is nothing more than a pricing strategy and a lack of focus and not an innovation. It's painful to watch. Their business model looks like their products: an absolute mess.

mwj 8y ago
"Their business model looks like their products: an absolute mess." Quote of the year
shdh 8y ago
Reads like a subjective hit piece. >Their only innovation is "free private repos" and "cramming 9 different domains into one product" They have one of the best CI/CD products out on the market right now. git versioned yml/docker based jobs with multiple stages.
- oweiler 8y ago
  > They have one of the best CI/CD products out on the market right now. git versioned yml/docker based jobs with multiple stages. CircleCI, Jenkins, Codeship etc. have similar offerings. And Jenkins also has the benefit of a huge plugin ecosystem.
- matthewmacleod 8y ago
  They have one of the best CI/CD products out on the market right now. git versioned yml/docker based jobs with multiple stages. Isn't this basically table stakes for any modern CI/CD product?
- root_axis 8y ago
  The CI is pretty but it's definitely not a polished product, e.g. the job progress indicators are unreliable on most pages, the "retry" functionality for failed jobs periodically does nothing which forces developers to touch their branch with a push to trigger a rebuild, the horribly named "tags" feature is a source of constant confusion for developers new to gitlab who are trying to trigger jobs based on git tags only to discover that "tags" in gitlab-ci have literally no relationship to "tags" in the sense of tagging a git commit. It's also impossible to do something as simple as trigger a job only for tagged commits on a specific branch or skip certain steps in the pipeline based on what happens at job run time. I like many other aspects of gitlab but the CI is definitely less than ideal.
  - shdh 8y ago
    > The CI is pretty but it's definitely not a polished product, e.g. the job progress indicators are unreliable on most pages, I agree with this, they need to do a better job of updated those circular indicators. > the "retry" functionality for failed jobs periodically does nothing which forces developers to touch their branch with a push to trigger a rebuild, Not sure when you last used their CI, but I've never experienced this issue. > the horribly named "tags" feature is a source of constant confusion for developers new to gitlab who are trying to trigger jobs based on git tags only to discover that "tags" in gitlab-ci have literally no relationship to "tags" in the sense of tagging a git commit. A tag created through the GitLab web GUI is directly connected to `git tag` > It's also impossible to do something as simple as trigger a job only for tagged commits on a specific branch or skip certain steps in the pipeline based on what happens at job run time. I like many other aspects of gitlab but the CI is definitely less than ideal. I think you should refer to the manual. * https://docs.gitlab.com/ee/ci/yaml/#only-and-except-simplified https://docs.gitlab.com/ee/ci/yaml/#only-and-except-simplifi... * https://docs.gitlab.com/ee/ci/yaml/#when https://docs.gitlab.com/ee/ci/yaml/#when * https://docs.gitlab.com/ee/ci/variables/ https://docs.gitlab.com/ee/ci/variables/
    - root_axis 8y ago
      > A tag created through the GitLab web GUI is directly connected to `git tag` It appears you may be suffering from the same confusion (or perhaps you're not aware of the feature), I'm talking specifically about gitlab-ci tags https://docs.gitlab.com/ee/ci/yaml/#tags https://docs.gitlab.com/ee/ci/yaml/#tags That has nothing to do with git tags, but one could be forgiven for believing that's the case when the documentation exacerbates this confusion. From the docs you just linked > only defines the names of branches and tags for which the job will run "tags" in that sentence has nothing to do with git tags but is actually referencing a gitlab-specific job tagging feature. It's very confusing. > I think you should refer to the manual. I have. The tools provided are not sufficient to accomplish the examples I have described. I'm happy to be proven wrong because it'd actually be quite useful to me. Can you direct me to how I might trigger a job only on tagged commits pushed to the master branch? As far as when/except/only etc, they are not able to introspect on variables or conditions within the context of the job runner, they can only react to gitlab-specific signals like the success or failure of other jobs, I can't do something like "build, run unit tests, run eslint, run flow type checker, deploy but only if nothing else failed, except eslint which is only a soft requirement but not a deployment blocker". Any failure in one job is a failure for all jobs unless you make it explicitly the inverse which still doesn't give you intelligent control over the jobs.
vineet 8y ago
While I also like to consider myself above pricing, it is worth noting that innovation with pricing is perhaps the most important part in building a great business. Arguably Google Search's success is more to do with their revenue innovations than their algorithms.

mwj 8y ago

"Their business model looks like their products: an absolute mess." Quote of the year

shdh 8y ago

Reads like a subjective hit piece. >Their only innovation is "free private repos" and "cramming 9 different domains into one product" They have one of the best CI/CD products out on the market right now. git versioned yml/docker based jobs with multiple stages.

oweiler 8y ago
> They have one of the best CI/CD products out on the market right now. git versioned yml/docker based jobs with multiple stages. CircleCI, Jenkins, Codeship etc. have similar offerings. And Jenkins also has the benefit of a huge plugin ecosystem.
matthewmacleod 8y ago
They have one of the best CI/CD products out on the market right now. git versioned yml/docker based jobs with multiple stages. Isn't this basically table stakes for any modern CI/CD product?
root_axis 8y ago
The CI is pretty but it's definitely not a polished product, e.g. the job progress indicators are unreliable on most pages, the "retry" functionality for failed jobs periodically does nothing which forces developers to touch their branch with a push to trigger a rebuild, the horribly named "tags" feature is a source of constant confusion for developers new to gitlab who are trying to trigger jobs based on git tags only to discover that "tags" in gitlab-ci have literally no relationship to "tags" in the sense of tagging a git commit. It's also impossible to do something as simple as trigger a job only for tagged commits on a specific branch or skip certain steps in the pipeline based on what happens at job run time. I like many other aspects of gitlab but the CI is definitely less than ideal.
- shdh 8y ago
  > The CI is pretty but it's definitely not a polished product, e.g. the job progress indicators are unreliable on most pages, I agree with this, they need to do a better job of updated those circular indicators. > the "retry" functionality for failed jobs periodically does nothing which forces developers to touch their branch with a push to trigger a rebuild, Not sure when you last used their CI, but I've never experienced this issue. > the horribly named "tags" feature is a source of constant confusion for developers new to gitlab who are trying to trigger jobs based on git tags only to discover that "tags" in gitlab-ci have literally no relationship to "tags" in the sense of tagging a git commit. A tag created through the GitLab web GUI is directly connected to `git tag` > It's also impossible to do something as simple as trigger a job only for tagged commits on a specific branch or skip certain steps in the pipeline based on what happens at job run time. I like many other aspects of gitlab but the CI is definitely less than ideal. I think you should refer to the manual. * https://docs.gitlab.com/ee/ci/yaml/#only-and-except-simplified https://docs.gitlab.com/ee/ci/yaml/#only-and-except-simplifi... * https://docs.gitlab.com/ee/ci/yaml/#when https://docs.gitlab.com/ee/ci/yaml/#when * https://docs.gitlab.com/ee/ci/variables/ https://docs.gitlab.com/ee/ci/variables/
  - root_axis 8y ago
    > A tag created through the GitLab web GUI is directly connected to `git tag` It appears you may be suffering from the same confusion (or perhaps you're not aware of the feature), I'm talking specifically about gitlab-ci tags https://docs.gitlab.com/ee/ci/yaml/#tags https://docs.gitlab.com/ee/ci/yaml/#tags That has nothing to do with git tags, but one could be forgiven for believing that's the case when the documentation exacerbates this confusion. From the docs you just linked > only defines the names of branches and tags for which the job will run "tags" in that sentence has nothing to do with git tags but is actually referencing a gitlab-specific job tagging feature. It's very confusing. > I think you should refer to the manual. I have. The tools provided are not sufficient to accomplish the examples I have described. I'm happy to be proven wrong because it'd actually be quite useful to me. Can you direct me to how I might trigger a job only on tagged commits pushed to the master branch? As far as when/except/only etc, they are not able to introspect on variables or conditions within the context of the job runner, they can only react to gitlab-specific signals like the success or failure of other jobs, I can't do something like "build, run unit tests, run eslint, run flow type checker, deploy but only if nothing else failed, except eslint which is only a soft requirement but not a deployment blocker". Any failure in one job is a failure for all jobs unless you make it explicitly the inverse which still doesn't give you intelligent control over the jobs.

vineet 8y ago

While I also like to consider myself above pricing, it is worth noting that innovation with pricing is perhaps the most important part in building a great business. Arguably Google Search's success is more to do with their revenue innovations than their algorithms.