6 ms·

> But then Github stagnated, and stagnated some more. And gitlab went past the initial copying and started innovating and adding more features. As an industry,

by Shank 8y ago

> But then Github stagnated, and stagnated some more. And gitlab went past the initial copying and started innovating and adding more features. As an industry, we have a unhealthy obsession with change for change's sake. If we aren't redesigning everything, adding new features, or moving cheese all the time, we aren't innovating. But this the opposite of how we should think. If the GitHub repos page, for instance, just works, then we don't need to keep changing it. Zach Holman made a point, way back in 2012, that they intentionally hide UI features to preserve simplicity and trust in their design. [0] The thing I get the most from Gitlab's UI is this overwhelming sense of desire to add every feature, expose every option, and make it as utilitarian as possible. In doing so, though, Gitlab trades off approachability. To some this is a great thing, but to others, it's just on the edge of too much. If there's anything I want Gitlab to copy from GitHub, it's the opinionated decision making of what to show and when to show it. Gitlab's CI/CD stuff is a great example of this contrast. GitHub left it to Travis and other CI providers, which makes both GitHub and those providers have time to excel at what they're good at. They made the trade off deciding that they couldn't pull it off as well as others, so they delegated it and moved on. Gitlab took the opposite approach and built it in. While it adds value for some users, it can and (at least in my opinion) does over complicate the core feature set they offer. It's okay to have two products with different approaches, but I wouldn't say that it's a lack of innovation on GitHub's part. I would say it's just a different set of tradeoff balancing. [0]: https://speakerdeck.com/holman/git-and-github-secrets?slide=15 https://speakerdeck.com/holman/git-and-github-secrets?slide=...

berkut 8y ago
I agree - one thing that's pretty annoying about Gitlab (self-host at work) IMO is that over the past year, things just keep moving around in the UI or work differently as we upgrade versions. Personally, I'd prefer to use Github at work as I find it a fair bit easier to use and navigate, but Gitlab is much cheaper, so...
stingraycharles 8y ago
I agree with what you are saying, but plenty of issues with Github really needed to be solved in order for large projects to scale. Issue templates and the native “likes” rather than all those +1 comments were desperately needed and Github had no excuse not solving those issues for years.
knownothing 8y ago
Exactly. > If there's anything I want Gitlab to copy from GitHub, it's the opinionated decision making of what to show and when to show it. Thing is, that will never happen. The project has already sprawled out of control and if they tried to remove things or drastically change the product users would just start forking the project. Or someone would copy GitLab and make a totally open source clone (that'd be ironic). On a side note, does the issue tracker for GitLab CE worry anyone else? https://gitlab.com/gitlab-org/gitlab-ce/issues https://gitlab.com/gitlab-org/gitlab-ce/issues Nearly 11k issues some from 3 years ago.
- jacquesm 8y ago
  For as long as I have seen your account you are in every github/gitlab thread pushing github and bashing gitlab. Care to disclose something?
  - aedocw 8y ago
    Really interesting observation, does look pretty shady.
  - spockz 8y ago
    In all fairness, I wouldn’t classify the parent post of bashing. Exaggerating, at most.
  - SirYandi 8y ago
    Wow. Looking through his post history is like one big github sales pitch and gitlab defamation frenzy. Surely a shill if I've ever seen one
    - donarb 8y ago
      Do you have any evidence this person is a paid advocate?
  - irq11 8y ago
    How is this different than the pro-Gitlab people, who are on the same threads doing the opposite? I’m personally tired of seeing Gitlab employees and fanchildren spamming every halfway-related thread on HN. If there’s someone here advocating for Github, he’s a refreshing change of pace.
atonse 8y ago
I guess that's exactly what I'm saying. I don't WANT to sign up for multiple services. I consider all that to be chores that take away from actually building the product I care about. Apart from that, it costs more (I didn't bring this up because these costs are negligible compared to the cost of engineer time), you have multiple places charging your credit card, have to manage multiple accounts, etc. It's sort of like the reasons I used to state on why I like Ember. ember-cli comes fully integrated, I can start to build something in 5 minutes. Whereas, before create-react-app, developers would spend a lot of time just cobbling together tools and reading tutorials just to get to a certain level of infrastructure. I don't want to do that. I just want to press a couple of buttons and resume building my product.
- Shank 8y ago
  Yep! Choice and competition is good! I think it's good that people like Gitlab and use it, just in the same way that there are people who prefer GitHub and use it. But I wouldn't say at all that it's the result of stagnation as a result of abandonment -- rather, it's intentional selection.
  - atonse 8y ago
    Point taken. Competition IS good (rather than just copying, which initially put me off to GitLab). And how nice it is that there are good products that fit multiple mental models, so neither of us has to compromise. (Again, for the record, I still host everything on GitHub but mainly am looking to GitLab because their stuff is so integrated).
holman 8y ago
> Zach Holman made a point, way back in 2012, that they intentionally hide UI features to preserve simplicity and trust in their design. Ehhhhh not quite. The point of hiding UI like how I mentioned in that talk was that those features in particular were for the 1% (or less). Basically, the finicky power users. Rather than cluttering up the UI with every single toggle and dropdown under the sun, we'd focus more on nailing the experience for the 80-90% of users that would see the screen. I think that's quite a bit different from what's being discussed in this thread. The last few years in particular GitLab's been adding a lot more features across the whole spectrum of development (CI, packaging, monitoring, and so on), whereas GitHub has been mostly content to refine the existing platform. I don't even think it's really a question of simplicity (or at least not to the extent of what I was trying to mention in my talk from six years ago) — it's more of a matter of expanding into very large holes that the version control industry hasn't really tackled very much before (take a look at Bitbucket, or even some of the open source clones, which all kind of stick in the version-control-only perspective). > I would say it's just a different set of tradeoff balancing. That I'd probably agree with, though. I think GitLab's thoughts on what's helpful to a developer is much broader than GitHub's narrower definition. Each are making their bets with that, so it's more a matter of how you view your own problems and the future of these kinds of problems and all that. :)
- rad_gruchalski 8y ago
  > Ehhhhh not quite. The point of hiding UI like how I mentioned in that talk was that those features in particular were for the 1% (or less). Basically, the finicky power users. Rather than cluttering up the UI with every single toggle and dropdown under the sun, we'd focus more on nailing the experience for the 80-90% of users that would see the screen. Every time I go back to gitlab I’m lost in all those drop downs and buttons it shows me. Just nodding to you statement.
- Shank 8y ago
  > Ehhhhh not quite. The point of hiding UI like how I mentioned in that talk was that those features in particular were for the 1% (or less). Basically, the finicky power users. Rather than cluttering up the UI with every single toggle and dropdown under the sun, we'd focus more on nailing the experience for the 80-90% of users that would see the screen. Oof. Yeah. I understand what you meant -- I guess I wasn't specific enough in what I said. I didn't mention it anywhere in that comment, but I was thinking about their issue page as the prime example. See here: https://gitlab.com/gitlab-com/www-gitlab-com/issues/2231 https://gitlab.com/gitlab-com/www-gitlab-com/issues/2231 I'd say that 1% features shown to anyone on this page are things like confidentiality, time tracking, weight, lock state, and reference. Most of them are in the default position, and reference appears marginally redundant. I didn't execute my example too well, but I think this notion does carry around the rest of the app. I guess I painted too broadly if you had to catch me. Sorry, Zach!
hinkley 8y ago
We virtue signal around project activity, especially on Github. We use activity as a proxy for whether we will be stuck with bugs without workarounds. But a baked piece of software that doesn’t interact with fast changing parts of the ecosystem doesn’t need to change. If I saw a dormant project in Rust or Node that handled asynchronous calls I would probably stay away. But a logging library, text processing tool, or unit testing framework might be pretty baked. In that case the active projects are catching up, which means new bugs. Bugs that I might get stuck with anyway.
deleted 8y ago
[deleted]

by Shank 8y ago

berkut 8y ago

I agree - one thing that's pretty annoying about Gitlab (self-host at work) IMO is that over the past year, things just keep moving around in the UI or work differently as we upgrade versions. Personally, I'd prefer to use Github at work as I find it a fair bit easier to use and navigate, but Gitlab is much cheaper, so...

stingraycharles 8y ago

I agree with what you are saying, but plenty of issues with Github really needed to be solved in order for large projects to scale. Issue templates and the native “likes” rather than all those +1 comments were desperately needed and Github had no excuse not solving those issues for years.

knownothing 8y ago

Exactly. > If there's anything I want Gitlab to copy from GitHub, it's the opinionated decision making of what to show and when to show it. Thing is, that will never happen. The project has already sprawled out of control and if they tried to remove things or drastically change the product users would just start forking the project. Or someone would copy GitLab and make a totally open source clone (that'd be ironic). On a side note, does the issue tracker for GitLab CE worry anyone else? https://gitlab.com/gitlab-org/gitlab-ce/issues https://gitlab.com/gitlab-org/gitlab-ce/issues Nearly 11k issues some from 3 years ago.

jacquesm 8y ago
For as long as I have seen your account you are in every github/gitlab thread pushing github and bashing gitlab. Care to disclose something?
- aedocw 8y ago
  Really interesting observation, does look pretty shady.
- spockz 8y ago
  In all fairness, I wouldn’t classify the parent post of bashing. Exaggerating, at most.
- SirYandi 8y ago
  Wow. Looking through his post history is like one big github sales pitch and gitlab defamation frenzy. Surely a shill if I've ever seen one
  - donarb 8y ago
    Do you have any evidence this person is a paid advocate?
- irq11 8y ago
  How is this different than the pro-Gitlab people, who are on the same threads doing the opposite? I’m personally tired of seeing Gitlab employees and fanchildren spamming every halfway-related thread on HN. If there’s someone here advocating for Github, he’s a refreshing change of pace.

atonse 8y ago

I guess that's exactly what I'm saying. I don't WANT to sign up for multiple services. I consider all that to be chores that take away from actually building the product I care about. Apart from that, it costs more (I didn't bring this up because these costs are negligible compared to the cost of engineer time), you have multiple places charging your credit card, have to manage multiple accounts, etc. It's sort of like the reasons I used to state on why I like Ember. ember-cli comes fully integrated, I can start to build something in 5 minutes. Whereas, before create-react-app, developers would spend a lot of time just cobbling together tools and reading tutorials just to get to a certain level of infrastructure. I don't want to do that. I just want to press a couple of buttons and resume building my product.

Shank 8y ago
Yep! Choice and competition is good! I think it's good that people like Gitlab and use it, just in the same way that there are people who prefer GitHub and use it. But I wouldn't say at all that it's the result of stagnation as a result of abandonment -- rather, it's intentional selection.
- atonse 8y ago
  Point taken. Competition IS good (rather than just copying, which initially put me off to GitLab). And how nice it is that there are good products that fit multiple mental models, so neither of us has to compromise. (Again, for the record, I still host everything on GitHub but mainly am looking to GitLab because their stuff is so integrated).

holman 8y ago

> Zach Holman made a point, way back in 2012, that they intentionally hide UI features to preserve simplicity and trust in their design. Ehhhhh not quite. The point of hiding UI like how I mentioned in that talk was that those features in particular were for the 1% (or less). Basically, the finicky power users. Rather than cluttering up the UI with every single toggle and dropdown under the sun, we'd focus more on nailing the experience for the 80-90% of users that would see the screen. I think that's quite a bit different from what's being discussed in this thread. The last few years in particular GitLab's been adding a lot more features across the whole spectrum of development (CI, packaging, monitoring, and so on), whereas GitHub has been mostly content to refine the existing platform. I don't even think it's really a question of simplicity (or at least not to the extent of what I was trying to mention in my talk from six years ago) — it's more of a matter of expanding into very large holes that the version control industry hasn't really tackled very much before (take a look at Bitbucket, or even some of the open source clones, which all kind of stick in the version-control-only perspective). > I would say it's just a different set of tradeoff balancing. That I'd probably agree with, though. I think GitLab's thoughts on what's helpful to a developer is much broader than GitHub's narrower definition. Each are making their bets with that, so it's more a matter of how you view your own problems and the future of these kinds of problems and all that. :)

rad_gruchalski 8y ago
> Ehhhhh not quite. The point of hiding UI like how I mentioned in that talk was that those features in particular were for the 1% (or less). Basically, the finicky power users. Rather than cluttering up the UI with every single toggle and dropdown under the sun, we'd focus more on nailing the experience for the 80-90% of users that would see the screen. Every time I go back to gitlab I’m lost in all those drop downs and buttons it shows me. Just nodding to you statement.
Shank 8y ago
> Ehhhhh not quite. The point of hiding UI like how I mentioned in that talk was that those features in particular were for the 1% (or less). Basically, the finicky power users. Rather than cluttering up the UI with every single toggle and dropdown under the sun, we'd focus more on nailing the experience for the 80-90% of users that would see the screen. Oof. Yeah. I understand what you meant -- I guess I wasn't specific enough in what I said. I didn't mention it anywhere in that comment, but I was thinking about their issue page as the prime example. See here: https://gitlab.com/gitlab-com/www-gitlab-com/issues/2231 https://gitlab.com/gitlab-com/www-gitlab-com/issues/2231 I'd say that 1% features shown to anyone on this page are things like confidentiality, time tracking, weight, lock state, and reference. Most of them are in the default position, and reference appears marginally redundant. I didn't execute my example too well, but I think this notion does carry around the rest of the app. I guess I painted too broadly if you had to catch me. Sorry, Zach!

hinkley 8y ago

We virtue signal around project activity, especially on Github. We use activity as a proxy for whether we will be stuck with bugs without workarounds. But a baked piece of software that doesn’t interact with fast changing parts of the ecosystem doesn’t need to change. If I saw a dormant project in Rust or Node that handled asynchronous calls I would probably stay away. But a logging library, text processing tool, or unit testing framework might be pretty baked. In that case the active projects are catching up, which means new bugs. Bugs that I might get stuck with anyway.

deleted 8y ago

[deleted]