Hacker News Reader

Comment by wyldfire | Hacker News Reader

I recently wanted to try adding some diagrams to a markdown-formatted README file in a Github Enterprise repo. I saw a few solutions but they all seemed to require me to roll some kind of service or automation to generate a raster image of the diagram and reference that from the markdown. There's an outstanding feature request for Github to integrate this kind of thing in their markdown rendering. But it's been languishing for years. Of course, Gitlab has had it for a while.

If Github's not careful, Gitlab will eat their lunch.

Gitlab should be careful not to make their product into "The Homer" [1], though.

[1] https://simpsons.fandom.com/wiki/The_Homer

View on HN

GitLab has already turned into "The Homer". It has hundreds (thousands?) of features, but if you stray away from the core git functionality you'll very quickly realise they're pretty bad.

I've always seen GitLab as a useful tool for smaller companies where you can use it to replace several other applications (e.g. JIRA, Jenkins, or wiki), but if your company already has those established it all becomes somewhat useless.

Have you read the GitLab S-1? They have great retention with larger companies. Can you substantiate any of your claims? (FYI I have no horse in this race, I evaluated GH vs GL recently and decided to stay on GH for now)

From their S-1:

> We do not have an adequate history with our subscription or pricing models to accurately predict the long-term rate of customer subscription renewals or adoption, or the impact these renewals and adoption will have on our revenues or operating results.

For context, GitLab recently axed their lowest priced plan and grandfathered in existing users at cheaper rates for the next year. Their retention rate may drop once discounts run out and the new pricing kicks in.

As to the parent's comment about "The Homer" and non-core features being bad, I'd point to their CI autoscaling solution as an example of being underdeveloped, over-marketed, and suffering from technical debt. Their autoscaler uses docker machine behind-the-scenes, which hooks into various cloud providers to abstract away the act of spinning up new VMs. It works reasonably well, but Docker has archived the repository and no longer supports the software. GitLab forked the repository and maintains it for critical fixes, but is not willing to develop or accept new features. It has been known to break against new versions of Docker, does not handle concurrency very well in new environments, and does not allow [1] executing multiple concurrent jobs within spun up VMs, despite marketing that it can [2].

While the autoscaler does work, it's limitations and quirks reduces it's utility and cost-savings significantly within smaller organizations. The technical debt leaves me doubting any improvements will come within the next few years as they try to architect a new solution to replace the existing one.

I have no idea how GitLab compares in other areas, but within CI autoscaling it seems they're stuck with a cliff to climb down before they can move forward again.

[1]: https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2787#no...

[2]: https://about.gitlab.com/blog/2017/11/23/autoscale-ci-runner...

CI is moving in Kubernetes everywhere I know. Builtin kubernetes pod autoscaler can add capacity based on job queue length metric, so no need for docker machine anymore.

To some extend, yes. On the other hand, they’re currently the only service where I can set up one VM, give it my AWS credentials, and have fully automated scaling.

The hoops you have to jump through in Github are absolutely unfun.

I never said they don't have retention with large companies. In fact I work at one that uses GitLab, which just proves the points in my comment - nobody uses features like issues, wiki, or pages because it's already established via other applications.

I agree with the general thrust of your comment (and I've been happy to see that GitHub's feature development pick up over the past few years), but I don't know if Markdown is the best example: I've lost track of how many times I or someone else I work with has written some Markdown, only to discover that it's a GH or GL extension and that our deployed documentation (or package index pages) don't render our hard work correctly.

I think it is fair to say Gitlab is already eating Github's lunch. For some time.

Are they? What's the Gitlab market share?

Also, it sounds to me like Github is leaving the old lunch of "Git hosting + issue tracking" on the table, and moving on to being a kind of web-based all-in-one full-service collaboration/dev platform with a social network built in. So even if Gitlab picks up some single-digit-percentage market share, that's not what Github cares about anyway.

> a kind of web-based all-in-one full-service collaboration/dev platform with a social network built in.

Why would I want a social network built into my version control & ci/cd pipeline (I assume you're referring to the "stars" feature, and not about issue reporting).

Maybe I'm just a curmudgeon, but I'm sort of sick of everything becoming a social network. I neither have nor do I want internet clout, and all social networks feel like they're trying to force me into "keeping up with the Jones'" in whatever way they're relevant.

In OpenSource space there is a small value: If I get a contribution from a stranger and I see they are respected contributor to trustworthy other organisations I can derive some trust from that. (Doesn't mean handing out access and blindly merging, but helps to judge)

Also for people looking for jobs it can be a tool for self promotion.

Github has been a social network for years. You can follow users and "star" repositories.

It has its merits for search and discovery.

Especially considering the coupling of GitHub with vscode

Is it?

Reply on news.ycombinator.com