13 ms·

GitLab Direction

184 points by jmilloy 8y ago

whitepoplar 8y ago
GitLab is like the average kid in class that everybody makes fun of for constantly asking questions, but the joke's on them because "a little bit of slope makes up for a lot of y-intercept." While GitLab may have warts, I feel that they're very earnestly working to make the product better, bit by bit, day by day, and will one day surpass GitHub.
- sytse 8y ago
  Thanks! Incremental progress in the form of iteration is one of our core values https://about.gitlab.com/handbook/values/#iteration https://about.gitlab.com/handbook/values/#iteration
  - tempaccount777 8y ago
    I have some questions to ask of you. 1. Why does gitlab have so many tiers? It would be better if you guys could repackage the features into fewer categories. 2. Why is the Gitlab UI so ugly? IMO, bitbucket and github are leaps and bounds ahead of you guys when it comes to design. 3. Can we get a dark mode for us night owls? 4. Finally, the morality question, You guys proudly associate yourselves with open-source and get help from loads of opensource devs, yet you greedily restrict simple features like epics, burndown charts, roadmaps, configurable issue boards etc. from the core/free categories. Looks like your key core goal is to make money... how are you any different from microsoft or google?
    - anonytrary 8y ago
      Asking questions antagonistically rarely elicits a response.
    - brandonwamboldt 8y ago
      1. They only have four tiers (four equivalent tiers for hosted and on-premise technically). This is quite reasonable, as they need to provide flexibility for their customers. They are quite clear about which tiers provide which features. 2. This is purely subjective. I quite like the design, both more than GitHub and Bitbucket. They do have a UX team, and they conduct regular user tests. They've also made a lot of improvements and continue to make improvements, but design will always be subjective. You CANNOT please everyone 3. I suggest putting a thumbs up for https://gitlab.com/gitlab-org/gitlab-ce/issues/18596 https://gitlab.com/gitlab-org/gitlab-ce/issues/18596, but ultimately it does create additional work for the UX team so I don't know if they'll end up doing it or not. You could try a user style, e.g. https://userstyles.org/styles/125366/gitlab-simple-dark https://userstyles.org/styles/125366/gitlab-simple-dark 4. GitLab is a company and needs to make money to continue employing developers to continue developing their product. Open source devs volunteer their time on GitLab CE, not any of the closed source features, and GitLab has open sourced enterprise features in the past if the demand is high. Also, there is nothing wrong with comparing them to Microsoft, as Microsoft has thousands of open source projects and is quite the open source contributor. I'd flip #4 on it's head. They aren't greedily restricting features, they are generously open sourcing features and giving them away for free. As a business, they have no obligation to do so.
      - tyldum 8y ago
        When my company subscribed there was only a community and enterprise tier. Now this has become the starter edition and I feel we are losing a lot of value. We are 200 employees, but only 10 developers using the advanced features. We really want to make GitLab our hub (GitOps and all), however the the cost of going beyond starter edition is mind blowing (x5). So if we are to embrace GitLab further we must abandon the idea of letting the whole company use GitLab freely and limit it to devs only. Being small doesn't mean that we are not in need if advanced features, we just have a smaller scale. Also as our initial tier was the top tier, and now is the bottom one, I fear GitLab will fence off future functionality with even more tiers at random. Further, the tiers creates some artificial barriers where we several times feel the some of the new features we receive are just barely functioning and are just there to entice you to upgrade to the next tier. We are all in all very happy with GitLab, however we are no longer pushing it as a central hub for the company.
    - manigandham 8y ago
      All businesses need to make money, otherwise they stop being a business. That doesn't mean all companies are the same.
    - quadrangle 8y ago
      On the "Open Source" issue, they seem to be trying to keep a careful balance. They're doing the ideal thing and fully freeing a decent amount of stuff. But they have VC investors, so they have to pay them off with an exit sometime. And that fact on its own is the compromising thing that means they won't likely do just-enough to keep their own sustainable funding. They need to get profit not just pay all the team well. I'd like to see them at least become a Benefit Corp or similar to trust more that they won't end up selling out in some worse way that goes against the Open Source values they largely but incompletely embrace.
  - jimkri 8y ago
    The Gitlab handbook is great! Helped me create something similar at my current company.
    - sytse 8y ago
      Awesome! And if you improved in it we would love a merge request back :)
- WhyDoPeople 8y ago
  Just curious, what specifically you mean by "surpass Github"? I mean this with no snarky intention. I'm just wondering what tasks Gitlab doesn't perform as well as Github for you; unless you were referring to the social awareness that Github has.
  - whitepoplar 8y ago
    I mean surpass GitHub in both usage and revenue.
    - TheRealPomax 8y ago
      Revenue? GitHub has been operating at a loss right up to the moment that MS bought them for over a thousand times what they had to start making annually to not run a loss.
      - whitepoplar 8y ago
        You're confusing revenue with profit.
        TheRealPomax 8y ago
        No, I'm not. Both are business health indicators, with revenue being the more important one, since you can be sustainable without being profitable. However, when you operation on a _loss_ your revenue is not sufficient, and Github has been running a loss right up to when MS bought them. While having no profit does not imply you have insufficient revenue, running your business at a loss absolutely does. So: wanting another company in the same space to have the same kind of revenue profile is extremely questionable; you want them to have a sustainable revenue model, and the ideally on top of that, be profitable.
  - kasparsklavins 8y ago
    Performance and stability? Still yet to have a day where I havent had a 500 error on gitlab cloud.
- sametmax 8y ago
  > I feel that they're very earnestly working to make the product better, bit by bit, day by day, and will one day surpass GitHub. It's assuming github doesn't do that as well. As a paying github using, I can see they are improving my life a little bit more everyday. Like, lately, they introduced automatic security checks on python project dependencies. I'm glad gitlab exist. I feel safer, knowing I have a place to migrate to if MS screw up with gitup and no commercial replacement lives up to the task. But github is certainly not playing to loose.
- vorpalhex 8y ago
  I moved over a project from GitHub to GitLab recently - I wanted to try a competitor, and I wanted to take advantage of their CI/CD feature. I've actually been very impressed. The UI is laggy at times, and they haven't mastered the UX/information architecture like Github has, but they have added a lot of other valuable features.
- andrewmcwatters 8y ago
  Sometimes the valedictorian or most popular kid is always going to be better, no matter how much "hard work" in involved. Sometimes it's friends (marketing) and good looks (good design) that get you there. These are things that GitLab is losing on. Damn thing is so ugly from a layman's perspective, it's probably hard to figure out if they are technically superior because no one uses it. Private repo offerings are a tough competitive space, too. Everyone knows who Atlassian is.
  - whitepoplar 8y ago
    What do you find ugly about GitLab? I actually find the design to be comparable to GitHub, or better.
AFNobody 8y ago
GitLab should, frankly, focus on performance/ux/bug-fix releases every other release. And probably for the next 2-3 releases to get some of the warts under control. This constant push for project management features, frankly, is at the expense of the core product. I'd rather use a combination of GitHub and JIRA over Gitlab.
- sytse 8y ago
  What is the nr. 1 performance/ux/bugfix you would like to see? BTW This month we shipped 35 performance improvements https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&label_name%5B%5D=performance&milestone_title=11.1 https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=... and there were 141 bugs closed in the release of this month https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=11.1&label_name[]=bug https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8...
  - omeid2 8y ago
    I have a feeling that many people who constantly ask for "fixes" are the kind of people who want to "fix them all", by rewriting without understanding that it is a never ending cycle. Don't pay attention to them. Just do your thing. Gitlab has provided the much needed competition with real impact (consider Github boards, for example) and you have a company that can pay many people a living. That is more than good enough.
    - sytse 8y ago
      Thank you very much for the encouragement, I appreciate it after significant commenting today while flying from Mexico to San Francisco. You can rest assured we'll keep working on our vision https://about.gitlab.com/direction/product-vision/ https://about.gitlab.com/direction/product-vision/ The people that ask for fixes care about GitLab and are worth listening to. There is an almost infinite demand for new features and we can't make them all (even with more then 2000 open source contributors). But I've found that Hacker News readers have great insights and we'll keep listening and adjusting were we missed the mark. GitLab as a company was born on Hacker News https://news.ycombinator.com/item?id=4428278 https://news.ycombinator.com/item?id=4428278 and although the tone these days feels like different I hope it is a bond for live.
Spidler 8y ago
What I'm missing is a different security model than the current `If an endpoint can push to gitlab, it is trusted and can execute code server-side`. There is no (current) way to enforce a 2fa step in order to push to a repository, and while you can technically implement them, that doesn't mean much, due to the nature of `git push`. What I want is a 2fa-enabled review boundary between "commit" and "execute", which currently isn't possible. Protected branches can be unprotected without an auth step. There's nothing on the server-side that signs `gitlab` generated merge-commits in the commit graph, so no way to distinguish them from other merges. There's no security boundary to change the deployment details, or to modify the deployment pipeline to run from a different branch. Basically, I'd want a way to ensure that there's an authenticated hand-off between "commit" and "deploy" steps on the chain. Also, it'd be nifty if one could get gitlab to maintain a version number, increasing with every merge request merged, in order to get smooth tagged builds when MR's are used.
- jramsay 8y ago
  Hi Spidler, I'm a Product Manager at GitLab. Thanks for the feedback. Solid security protecting deployment is very important. In GitLab 10.7 we added branch unprotecting restrictions that can be managed through the API to restrict who can modify protected branch rules https://docs.gitlab.com/ee/api/protected_branches.html#protect-repository-branches https://docs.gitlab.com/ee/api/protected_branches.html#prote..., and we'll be adding a UI to manage this soon too. I created https://gitlab.com/gitlab-org/gitlab-ce/issues/49513 https://gitlab.com/gitlab-org/gitlab-ce/issues/49513 to add an auth step for changing protected branches as well. I'm interested to know more about the version number improvement you suggest too. There are a few similar proposals like automated tagging on merge https://gitlab.com/gitlab-org/gitlab-ce/issues/22363 https://gitlab.com/gitlab-org/gitlab-ce/issues/22363.
ephimetheus 8y ago
Triggering pipelines only in merge request is what we’ve really really been hoping for for quite while. Still seems pretty far out unfortunately...
- lloeki 8y ago
  If you use the GitLab convention of naming your branches from the issue (like it does when creating a MR straight from the issue), the MR branches will be named /^\d+-/ so you can add a only: clause to .gitlab-ci.yml steps matching that.
  - Drdrdrq 8y ago
    Probably a different issue, but one of my greatest gripes with CI is that I can't limit steps to (for example) master branch AND having a tag. It seems such a basic requirement, but is unfortunately not possible via .gitlab-ci.yml.
dstick 8y ago
Thanks for sharing this! The transparancy of GitLab is amazing for people like me who have no experience nor contacts in larger companies. The handbook is a joy to read! I discovered GitLab when researching CI/CD workflow and thanks to your tight integrations had one setup within 24 hours. Add to that the fact that 3 fellow Dutchies are the founders which inspired me to apply our own Security startup to YC19 and all I can say is: keep it up! You’re an inspiration :-) The only bit of constructive criticism I have is that the Epic ‘feature’ being locked behind the highest subscription is a bit weird. I’d love to be able to create an epic for our first release version but can’t. If that feature could drop a tier, that would be... epic ;-)
nathan_f77 8y ago
A few years ago I really wanted to join GitHub as a software engineer. I was living in San Francisco and visited their office for some events, and I thought it would be an awesome place to work. I tried reaching out to a few people who worked there, but I could never get my foot in the door. There were a lot of things I would have loved to build at GitHub, and they were all the same things that GitLab is doing now. I felt that there was so much potential to build things like CI, DevOps, and eventually a PaaS to compete with Heroku. I really think they should have acquired something like TravisCI or CircleCI and made that part of their platform, but it seems like they haven't really done anything significant in the last 5 years. I'm a very happy user of GitLab now, and the product is awesome. But I don't think I would ever join the company. First of all, they don't pay competitive salaries for remote workers (cost-of-living adjustments). I also don't think they have a very good company culture, and to be honest, it still feels a bit sketchy that they ripped off GitHub and undercut them on pricing. But I'm sure I'll get over that eventually.
- fqb 8y ago
  Could you elaborate about the salaries for remote workers? I'm a frontend developer in southern Europe and I'd love to work for Gitlab because I love the product.
  - foepys 8y ago
    You can read everything about it here: https://about.gitlab.com/handbook/people-operations/global-compensation/ https://about.gitlab.com/handbook/people-operations/global-c... They once had a online calculator where you put in your location (basically only SF, non-SF US, and outside US) and position but apparently they switched to another model that includes employee performance and other factors.
  - tempay 8y ago
    Example: https://about.gitlab.com/job-families/engineering/developer/#compensation https://about.gitlab.com/job-families/engineering/developer/... Full details are here: https://about.gitlab.com/handbook/people-operations/global-compensation/#compensation-calculator https://about.gitlab.com/handbook/people-operations/global-c...
KeitIG 8y ago
People tends to compare GitLab to Github, to me it seems more they compete with VSTS or Atlassian. CI, project management (epics and roadmaps), monitoring... Github introduces really few features but seems to make them right, or really limited, but never “bad”. Gitlab on the opposite, works more with super-fast and open iterations, without hesitating to roll-back if it just doesn’t work.
dom96 8y ago
GitLab is a great service, not perfect but a good alternative to GitHub. I actually use Gitter far more than GitLab these days, GitLab acquired them a while back and I'm really disappointed to see it reduced to stagnation. The product hasn't improved at all since the acquisition, you can argue that it's "finished" and it is 90% there. There are rough edges that make it more annoying to use than Telegram, Slack, etc. The primary one being how they handle notifications on their Android app. It's annoying me every day that this has been effectively broken for years now. Maybe some of the GitLab guys that hang around here can answer my concerns. Why are you guys neglecting Gitter?
- MadLittleMods 8y ago
  Heya, I'm the current Gitter developer and was working on Gitter before the acquisition. After the acquisition, Gitter did stagnate with no movement as we settled into our new GitLab roles and responsibilities but since May, we have been actively shipping things again. Changelog: https://gitlab.com/gitlab-org/gitter/webapp/blob/develop/CHANGELOG.md https://gitlab.com/gitlab-org/gitter/webapp/blob/develop/CHA.... Catching up from the break in development, a lot of work so far has been technical debt. We do have more user-facing changes in mind like removing the disruptive large embeds (https://gitlab.com/gitlab-org/gitter/webapp/issues/714#note_88039992 https://gitlab.com/gitlab-org/gitter/webapp/issues/714#note_...), improving search (https://gitlab.com/gitlab-org/gitter/webapp/issues/1925 https://gitlab.com/gitlab-org/gitter/webapp/issues/1925), and decoupling unreads from emails (https://gitlab.com/gitlab-org/gitter/webapp/issues/1205 https://gitlab.com/gitlab-org/gitter/webapp/issues/1205). One of the goals this quarter is to open source the Android/iOS apps, https://about.gitlab.com/okrs/2018-q3/ https://about.gitlab.com/okrs/2018-q3/ but there isn't a plan to keep improving them with new features. We are focusing on fixing the rough edges of the webapp and are happy to review your Merge Requests for any project. By Android notifications being broken, I assume you probably mean our double-buzz avoidance, https://gitlab.com/gitlab-org/gitter/webapp/issues/1846 https://gitlab.com/gitlab-org/gitter/webapp/issues/1846, but please make sure your particular issue is tracked, https://gitlab.com/gitlab-org/gitter/webapp/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=android&label_name[]=notifications https://gitlab.com/gitlab-org/gitter/webapp/issues?scope=all...
coderesearch 8y ago
EU GDPR compatibility would be a cool thing - I am sure that people have been asking for that "long time enough" ago. Also now that this software has left prototype status for long enough time - why are you still using ruby? Ruby is much too slow and bloated for production - there are only a few companies out there that missed the right time to jump from the ruby-prototype-bloat and have enough money to burn to just stick with it, but for a project like gitlab this is a huge problem. Judging from the roadmap there seem to be many bored developers with no good ideas about what to do next, so maybe unbloating could be a good direction? There must be at least one person in that team with a feeling for architectural brilliance?
abuldauskas 8y ago
One of my major pain points with GitLab was its API. The lack of coherent API design ultimately made me lose hope in the product. For example I think it still lacks an ability to create threads on MRs. Until recently it wasn't possible to approve any MRs either, for 10+ versions of the product and 4+ versions of the api, but adding emoji was... The disjointed API made it nearly impossible to create quality tooling on top of GitLab, ultimately forcing us away from the product. It left a poor taste in my mouth, with a sense that there was no rhyme or reason to the direction of the platform, unfortunately.
- sytse 8y ago
  Are the APIs you need added now or are there ones still missing? Anything we can improve in the API organization?
substring 8y ago
Gitlabs security is absolutely horrific: https://www.cvedetails.com/vulnerability-list/vendor_id-13074/Gitlab.html https://www.cvedetails.com/vulnerability-list/vendor_id-1307...
- sytse 8y ago
  None of these was out in the wild. We take pride in requesting CVE numbers to aid our users in remediation. We think that identifying and promptly fixing vulnerabilities is key to security.
- gitlab-security 8y ago
  Thank you for the feedback. One of our core values is transparency. Very few companies are as transparent as GitLab. We take our users' data security extremely seriously. Since total CVE count is only one metric to measure the security maturity of an organization, allow me to provide you with other metrics that may help you understand what we're doing on our users' behalf. Over the last 7 months, we have been focusing on mitigating security vulnerabilities that highly impact our users, where at least 25% of our users are affected. Since then, we've been able to bring the mean-time-to-mitigation (MTTM) for new, high-impact vulnerabilities to less than 30 days, which is below industry average for security vulnerability mitigations. However, we are not done securing GitLab of course, and are also working on maturing the security vulnerability mitigation process. Here are some goals that we've achieved over the last 6 months: 1. Developed and put into place two separate security release processes - a monthly non-critical security release process, focusing on reducing security debt, and a critical release process (on demand, as needed) when there is a new vulnerability discovered that impacts a significant number of users. https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/process.md#critical-security-releases https://gitlab.com/gitlab-org/release/docs/blob/master/gener... 2. GitLab continues to work with security researchers from the HackerOne program to recognize and reward bounties for their contributions. We have plans in place to expand on the existing HackerOne program by the end of 2018. The HackerOne program has been effective in assisting us with scaling our work with security vulnerability mitigations, because we have a small security team at GitLab, currently. https://hackerone.com/gitlab https://hackerone.com/gitlab 3. Our 2018 (and beyond) Security Vision and Hiring Plan includes growing GitLab's internal security team further, and we will be making security research hires, in order to accelerate the security vulnerability mitigation efforts that we are working on maturing. https://about.gitlab.com/handbook/engineering/security/ https://about.gitlab.com/handbook/engineering/security/ If you have any further questions, please feel free to contact us directly at security@gitlab.com
tfha 8y ago
If you want to compete with GitHub for open source projects you are going to need a 'releases' page that's similar (at least in function) to github's. I would like to see that prioritized more, I think it's more important for many projects looking to switch than many of the other features listed here
- NickBusey 8y ago
  I just link to the project tags page, since the only tags we have are releases, this works great.
  - tfha 8y ago
    There are no download statistics for that though
sciurus 8y ago
There may be many things you can fault GitLab for, but dreaming big isn't one. E.G. not many companies would have "becoming a platform-as-a-service" just casually dropped in their roadmap. https://gitlab.com/gitlab-org/gitlab-ce/issues/32820 https://gitlab.com/gitlab-org/gitlab-ce/issues/32820
apple4ever 8y ago
I'd love much more work on Issues. I'd replace JIRA with it if I could, but Issues is very feature poor (and we are a light JIRA use case).
dogweather 8y ago
I find GitLab's upgrade tiers oddly chosen and quirkily implemented: * The features don't seem to follow the costs of running them. I.e., they're economically inefficient. This makes GitLab less competitive. E.g., Some features held back for higher paying customers feel arbitrary in the sense that it's a marketing decision, not an ops/cost decision. * Permanent nag text and nag links - annoying.

184 points by jmilloy 8y ago

GitLab is like the average kid in class that everybody makes fun of for constantly asking questions, but the joke's on them because "a little bit of slope makes up for a lot of y-intercept." While GitLab may have warts, I feel that they're very earnestly working to make the product better, bit by bit, day by day, and will one day surpass GitHub.

sytse 8y ago
Thanks! Incremental progress in the form of iteration is one of our core values https://about.gitlab.com/handbook/values/#iteration https://about.gitlab.com/handbook/values/#iteration
- tempaccount777 8y ago
  I have some questions to ask of you. 1. Why does gitlab have so many tiers? It would be better if you guys could repackage the features into fewer categories. 2. Why is the Gitlab UI so ugly? IMO, bitbucket and github are leaps and bounds ahead of you guys when it comes to design. 3. Can we get a dark mode for us night owls? 4. Finally, the morality question, You guys proudly associate yourselves with open-source and get help from loads of opensource devs, yet you greedily restrict simple features like epics, burndown charts, roadmaps, configurable issue boards etc. from the core/free categories. Looks like your key core goal is to make money... how are you any different from microsoft or google?
  - anonytrary 8y ago
    Asking questions antagonistically rarely elicits a response.
  - brandonwamboldt 8y ago
    1. They only have four tiers (four equivalent tiers for hosted and on-premise technically). This is quite reasonable, as they need to provide flexibility for their customers. They are quite clear about which tiers provide which features. 2. This is purely subjective. I quite like the design, both more than GitHub and Bitbucket. They do have a UX team, and they conduct regular user tests. They've also made a lot of improvements and continue to make improvements, but design will always be subjective. You CANNOT please everyone 3. I suggest putting a thumbs up for https://gitlab.com/gitlab-org/gitlab-ce/issues/18596 https://gitlab.com/gitlab-org/gitlab-ce/issues/18596, but ultimately it does create additional work for the UX team so I don't know if they'll end up doing it or not. You could try a user style, e.g. https://userstyles.org/styles/125366/gitlab-simple-dark https://userstyles.org/styles/125366/gitlab-simple-dark 4. GitLab is a company and needs to make money to continue employing developers to continue developing their product. Open source devs volunteer their time on GitLab CE, not any of the closed source features, and GitLab has open sourced enterprise features in the past if the demand is high. Also, there is nothing wrong with comparing them to Microsoft, as Microsoft has thousands of open source projects and is quite the open source contributor. I'd flip #4 on it's head. They aren't greedily restricting features, they are generously open sourcing features and giving them away for free. As a business, they have no obligation to do so.
    - tyldum 8y ago
      When my company subscribed there was only a community and enterprise tier. Now this has become the starter edition and I feel we are losing a lot of value. We are 200 employees, but only 10 developers using the advanced features. We really want to make GitLab our hub (GitOps and all), however the the cost of going beyond starter edition is mind blowing (x5). So if we are to embrace GitLab further we must abandon the idea of letting the whole company use GitLab freely and limit it to devs only. Being small doesn't mean that we are not in need if advanced features, we just have a smaller scale. Also as our initial tier was the top tier, and now is the bottom one, I fear GitLab will fence off future functionality with even more tiers at random. Further, the tiers creates some artificial barriers where we several times feel the some of the new features we receive are just barely functioning and are just there to entice you to upgrade to the next tier. We are all in all very happy with GitLab, however we are no longer pushing it as a central hub for the company.
  - manigandham 8y ago
    All businesses need to make money, otherwise they stop being a business. That doesn't mean all companies are the same.
  - quadrangle 8y ago
    On the "Open Source" issue, they seem to be trying to keep a careful balance. They're doing the ideal thing and fully freeing a decent amount of stuff. But they have VC investors, so they have to pay them off with an exit sometime. And that fact on its own is the compromising thing that means they won't likely do just-enough to keep their own sustainable funding. They need to get profit not just pay all the team well. I'd like to see them at least become a Benefit Corp or similar to trust more that they won't end up selling out in some worse way that goes against the Open Source values they largely but incompletely embrace.
- jimkri 8y ago
  The Gitlab handbook is great! Helped me create something similar at my current company.
  - sytse 8y ago
    Awesome! And if you improved in it we would love a merge request back :)
WhyDoPeople 8y ago
Just curious, what specifically you mean by "surpass Github"? I mean this with no snarky intention. I'm just wondering what tasks Gitlab doesn't perform as well as Github for you; unless you were referring to the social awareness that Github has.
- whitepoplar 8y ago
  I mean surpass GitHub in both usage and revenue.
  - TheRealPomax 8y ago
    Revenue? GitHub has been operating at a loss right up to the moment that MS bought them for over a thousand times what they had to start making annually to not run a loss.
    - whitepoplar 8y ago
      You're confusing revenue with profit.
      - TheRealPomax 8y ago
        No, I'm not. Both are business health indicators, with revenue being the more important one, since you can be sustainable without being profitable. However, when you operation on a _loss_ your revenue is not sufficient, and Github has been running a loss right up to when MS bought them. While having no profit does not imply you have insufficient revenue, running your business at a loss absolutely does. So: wanting another company in the same space to have the same kind of revenue profile is extremely questionable; you want them to have a sustainable revenue model, and the ideally on top of that, be profitable.
- kasparsklavins 8y ago
  Performance and stability? Still yet to have a day where I havent had a 500 error on gitlab cloud.
sametmax 8y ago
> I feel that they're very earnestly working to make the product better, bit by bit, day by day, and will one day surpass GitHub. It's assuming github doesn't do that as well. As a paying github using, I can see they are improving my life a little bit more everyday. Like, lately, they introduced automatic security checks on python project dependencies. I'm glad gitlab exist. I feel safer, knowing I have a place to migrate to if MS screw up with gitup and no commercial replacement lives up to the task. But github is certainly not playing to loose.
vorpalhex 8y ago
I moved over a project from GitHub to GitLab recently - I wanted to try a competitor, and I wanted to take advantage of their CI/CD feature. I've actually been very impressed. The UI is laggy at times, and they haven't mastered the UX/information architecture like Github has, but they have added a lot of other valuable features.
andrewmcwatters 8y ago
Sometimes the valedictorian or most popular kid is always going to be better, no matter how much "hard work" in involved. Sometimes it's friends (marketing) and good looks (good design) that get you there. These are things that GitLab is losing on. Damn thing is so ugly from a layman's perspective, it's probably hard to figure out if they are technically superior because no one uses it. Private repo offerings are a tough competitive space, too. Everyone knows who Atlassian is.
- whitepoplar 8y ago
  What do you find ugly about GitLab? I actually find the design to be comparable to GitHub, or better.

AFNobody 8y ago

GitLab should, frankly, focus on performance/ux/bug-fix releases every other release. And probably for the next 2-3 releases to get some of the warts under control. This constant push for project management features, frankly, is at the expense of the core product. I'd rather use a combination of GitHub and JIRA over Gitlab.

sytse 8y ago
What is the nr. 1 performance/ux/bugfix you would like to see? BTW This month we shipped 35 performance improvements https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&label_name%5B%5D=performance&milestone_title=11.1 https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=... and there were 141 bugs closed in the release of this month https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=11.1&label_name[]=bug https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8...
- omeid2 8y ago
  I have a feeling that many people who constantly ask for "fixes" are the kind of people who want to "fix them all", by rewriting without understanding that it is a never ending cycle. Don't pay attention to them. Just do your thing. Gitlab has provided the much needed competition with real impact (consider Github boards, for example) and you have a company that can pay many people a living. That is more than good enough.
  - sytse 8y ago
    Thank you very much for the encouragement, I appreciate it after significant commenting today while flying from Mexico to San Francisco. You can rest assured we'll keep working on our vision https://about.gitlab.com/direction/product-vision/ https://about.gitlab.com/direction/product-vision/ The people that ask for fixes care about GitLab and are worth listening to. There is an almost infinite demand for new features and we can't make them all (even with more then 2000 open source contributors). But I've found that Hacker News readers have great insights and we'll keep listening and adjusting were we missed the mark. GitLab as a company was born on Hacker News https://news.ycombinator.com/item?id=4428278 https://news.ycombinator.com/item?id=4428278 and although the tone these days feels like different I hope it is a bond for live.

Spidler 8y ago

What I'm missing is a different security model than the current `If an endpoint can push to gitlab, it is trusted and can execute code server-side`. There is no (current) way to enforce a 2fa step in order to push to a repository, and while you can technically implement them, that doesn't mean much, due to the nature of `git push`. What I want is a 2fa-enabled review boundary between "commit" and "execute", which currently isn't possible. Protected branches can be unprotected without an auth step. There's nothing on the server-side that signs `gitlab` generated merge-commits in the commit graph, so no way to distinguish them from other merges. There's no security boundary to change the deployment details, or to modify the deployment pipeline to run from a different branch. Basically, I'd want a way to ensure that there's an authenticated hand-off between "commit" and "deploy" steps on the chain. Also, it'd be nifty if one could get gitlab to maintain a version number, increasing with every merge request merged, in order to get smooth tagged builds when MR's are used.

jramsay 8y ago
Hi Spidler, I'm a Product Manager at GitLab. Thanks for the feedback. Solid security protecting deployment is very important. In GitLab 10.7 we added branch unprotecting restrictions that can be managed through the API to restrict who can modify protected branch rules https://docs.gitlab.com/ee/api/protected_branches.html#protect-repository-branches https://docs.gitlab.com/ee/api/protected_branches.html#prote..., and we'll be adding a UI to manage this soon too. I created https://gitlab.com/gitlab-org/gitlab-ce/issues/49513 https://gitlab.com/gitlab-org/gitlab-ce/issues/49513 to add an auth step for changing protected branches as well. I'm interested to know more about the version number improvement you suggest too. There are a few similar proposals like automated tagging on merge https://gitlab.com/gitlab-org/gitlab-ce/issues/22363 https://gitlab.com/gitlab-org/gitlab-ce/issues/22363.

ephimetheus 8y ago

Triggering pipelines only in merge request is what we’ve really really been hoping for for quite while. Still seems pretty far out unfortunately...

lloeki 8y ago
If you use the GitLab convention of naming your branches from the issue (like it does when creating a MR straight from the issue), the MR branches will be named /^\d+-/ so you can add a only: clause to .gitlab-ci.yml steps matching that.
- Drdrdrq 8y ago
  Probably a different issue, but one of my greatest gripes with CI is that I can't limit steps to (for example) master branch AND having a tag. It seems such a basic requirement, but is unfortunately not possible via .gitlab-ci.yml.

dstick 8y ago

Thanks for sharing this! The transparancy of GitLab is amazing for people like me who have no experience nor contacts in larger companies. The handbook is a joy to read! I discovered GitLab when researching CI/CD workflow and thanks to your tight integrations had one setup within 24 hours. Add to that the fact that 3 fellow Dutchies are the founders which inspired me to apply our own Security startup to YC19 and all I can say is: keep it up! You’re an inspiration :-) The only bit of constructive criticism I have is that the Epic ‘feature’ being locked behind the highest subscription is a bit weird. I’d love to be able to create an epic for our first release version but can’t. If that feature could drop a tier, that would be... epic ;-)

nathan_f77 8y ago

A few years ago I really wanted to join GitHub as a software engineer. I was living in San Francisco and visited their office for some events, and I thought it would be an awesome place to work. I tried reaching out to a few people who worked there, but I could never get my foot in the door. There were a lot of things I would have loved to build at GitHub, and they were all the same things that GitLab is doing now. I felt that there was so much potential to build things like CI, DevOps, and eventually a PaaS to compete with Heroku. I really think they should have acquired something like TravisCI or CircleCI and made that part of their platform, but it seems like they haven't really done anything significant in the last 5 years. I'm a very happy user of GitLab now, and the product is awesome. But I don't think I would ever join the company. First of all, they don't pay competitive salaries for remote workers (cost-of-living adjustments). I also don't think they have a very good company culture, and to be honest, it still feels a bit sketchy that they ripped off GitHub and undercut them on pricing. But I'm sure I'll get over that eventually.

fqb 8y ago
Could you elaborate about the salaries for remote workers? I'm a frontend developer in southern Europe and I'd love to work for Gitlab because I love the product.
- foepys 8y ago
  You can read everything about it here: https://about.gitlab.com/handbook/people-operations/global-compensation/ https://about.gitlab.com/handbook/people-operations/global-c... They once had a online calculator where you put in your location (basically only SF, non-SF US, and outside US) and position but apparently they switched to another model that includes employee performance and other factors.
- tempay 8y ago
  Example: https://about.gitlab.com/job-families/engineering/developer/#compensation https://about.gitlab.com/job-families/engineering/developer/... Full details are here: https://about.gitlab.com/handbook/people-operations/global-compensation/#compensation-calculator https://about.gitlab.com/handbook/people-operations/global-c...

KeitIG 8y ago

People tends to compare GitLab to Github, to me it seems more they compete with VSTS or Atlassian. CI, project management (epics and roadmaps), monitoring... Github introduces really few features but seems to make them right, or really limited, but never “bad”. Gitlab on the opposite, works more with super-fast and open iterations, without hesitating to roll-back if it just doesn’t work.

dom96 8y ago

GitLab is a great service, not perfect but a good alternative to GitHub. I actually use Gitter far more than GitLab these days, GitLab acquired them a while back and I'm really disappointed to see it reduced to stagnation. The product hasn't improved at all since the acquisition, you can argue that it's "finished" and it is 90% there. There are rough edges that make it more annoying to use than Telegram, Slack, etc. The primary one being how they handle notifications on their Android app. It's annoying me every day that this has been effectively broken for years now. Maybe some of the GitLab guys that hang around here can answer my concerns. Why are you guys neglecting Gitter?

MadLittleMods 8y ago
Heya, I'm the current Gitter developer and was working on Gitter before the acquisition. After the acquisition, Gitter did stagnate with no movement as we settled into our new GitLab roles and responsibilities but since May, we have been actively shipping things again. Changelog: https://gitlab.com/gitlab-org/gitter/webapp/blob/develop/CHANGELOG.md https://gitlab.com/gitlab-org/gitter/webapp/blob/develop/CHA.... Catching up from the break in development, a lot of work so far has been technical debt. We do have more user-facing changes in mind like removing the disruptive large embeds (https://gitlab.com/gitlab-org/gitter/webapp/issues/714#note_88039992 https://gitlab.com/gitlab-org/gitter/webapp/issues/714#note_...), improving search (https://gitlab.com/gitlab-org/gitter/webapp/issues/1925 https://gitlab.com/gitlab-org/gitter/webapp/issues/1925), and decoupling unreads from emails (https://gitlab.com/gitlab-org/gitter/webapp/issues/1205 https://gitlab.com/gitlab-org/gitter/webapp/issues/1205). One of the goals this quarter is to open source the Android/iOS apps, https://about.gitlab.com/okrs/2018-q3/ https://about.gitlab.com/okrs/2018-q3/ but there isn't a plan to keep improving them with new features. We are focusing on fixing the rough edges of the webapp and are happy to review your Merge Requests for any project. By Android notifications being broken, I assume you probably mean our double-buzz avoidance, https://gitlab.com/gitlab-org/gitter/webapp/issues/1846 https://gitlab.com/gitlab-org/gitter/webapp/issues/1846, but please make sure your particular issue is tracked, https://gitlab.com/gitlab-org/gitter/webapp/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=android&label_name[]=notifications https://gitlab.com/gitlab-org/gitter/webapp/issues?scope=all...

coderesearch 8y ago

EU GDPR compatibility would be a cool thing - I am sure that people have been asking for that "long time enough" ago. Also now that this software has left prototype status for long enough time - why are you still using ruby? Ruby is much too slow and bloated for production - there are only a few companies out there that missed the right time to jump from the ruby-prototype-bloat and have enough money to burn to just stick with it, but for a project like gitlab this is a huge problem. Judging from the roadmap there seem to be many bored developers with no good ideas about what to do next, so maybe unbloating could be a good direction? There must be at least one person in that team with a feeling for architectural brilliance?

abuldauskas 8y ago

One of my major pain points with GitLab was its API. The lack of coherent API design ultimately made me lose hope in the product. For example I think it still lacks an ability to create threads on MRs. Until recently it wasn't possible to approve any MRs either, for 10+ versions of the product and 4+ versions of the api, but adding emoji was... The disjointed API made it nearly impossible to create quality tooling on top of GitLab, ultimately forcing us away from the product. It left a poor taste in my mouth, with a sense that there was no rhyme or reason to the direction of the platform, unfortunately.

sytse 8y ago
Are the APIs you need added now or are there ones still missing? Anything we can improve in the API organization?

substring 8y ago

Gitlabs security is absolutely horrific: https://www.cvedetails.com/vulnerability-list/vendor_id-13074/Gitlab.html https://www.cvedetails.com/vulnerability-list/vendor_id-1307...

sytse 8y ago
None of these was out in the wild. We take pride in requesting CVE numbers to aid our users in remediation. We think that identifying and promptly fixing vulnerabilities is key to security.
gitlab-security 8y ago
Thank you for the feedback. One of our core values is transparency. Very few companies are as transparent as GitLab. We take our users' data security extremely seriously. Since total CVE count is only one metric to measure the security maturity of an organization, allow me to provide you with other metrics that may help you understand what we're doing on our users' behalf. Over the last 7 months, we have been focusing on mitigating security vulnerabilities that highly impact our users, where at least 25% of our users are affected. Since then, we've been able to bring the mean-time-to-mitigation (MTTM) for new, high-impact vulnerabilities to less than 30 days, which is below industry average for security vulnerability mitigations. However, we are not done securing GitLab of course, and are also working on maturing the security vulnerability mitigation process. Here are some goals that we've achieved over the last 6 months: 1. Developed and put into place two separate security release processes - a monthly non-critical security release process, focusing on reducing security debt, and a critical release process (on demand, as needed) when there is a new vulnerability discovered that impacts a significant number of users. https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/process.md#critical-security-releases https://gitlab.com/gitlab-org/release/docs/blob/master/gener... 2. GitLab continues to work with security researchers from the HackerOne program to recognize and reward bounties for their contributions. We have plans in place to expand on the existing HackerOne program by the end of 2018. The HackerOne program has been effective in assisting us with scaling our work with security vulnerability mitigations, because we have a small security team at GitLab, currently. https://hackerone.com/gitlab https://hackerone.com/gitlab 3. Our 2018 (and beyond) Security Vision and Hiring Plan includes growing GitLab's internal security team further, and we will be making security research hires, in order to accelerate the security vulnerability mitigation efforts that we are working on maturing. https://about.gitlab.com/handbook/engineering/security/ https://about.gitlab.com/handbook/engineering/security/ If you have any further questions, please feel free to contact us directly at security@gitlab.com

tfha 8y ago

If you want to compete with GitHub for open source projects you are going to need a 'releases' page that's similar (at least in function) to github's. I would like to see that prioritized more, I think it's more important for many projects looking to switch than many of the other features listed here

NickBusey 8y ago
I just link to the project tags page, since the only tags we have are releases, this works great.
- tfha 8y ago
  There are no download statistics for that though

sciurus 8y ago

There may be many things you can fault GitLab for, but dreaming big isn't one. E.G. not many companies would have "becoming a platform-as-a-service" just casually dropped in their roadmap. https://gitlab.com/gitlab-org/gitlab-ce/issues/32820 https://gitlab.com/gitlab-org/gitlab-ce/issues/32820

apple4ever 8y ago

I'd love much more work on Issues. I'd replace JIRA with it if I could, but Issues is very feature poor (and we are a light JIRA use case).

dogweather 8y ago

I find GitLab's upgrade tiers oddly chosen and quirkily implemented: * The features don't seem to follow the costs of running them. I.e., they're economically inefficient. This makes GitLab less competitive. E.g., Some features held back for higher paying customers feel arbitrary in the sense that it's a marketing decision, not an ops/cost decision. * Permanent nag text and nag links - annoying.