Interesting that they supposedly "abandoned" the Unix philosophy, when as far as I'm aware, they never followed it. Seems this article's title is simply clickbait.
GitLab is not just a program, it is both a collection of programs, and a cloud SaaS, neither of which the Unix philosophy is applicable to. The entire purpose of GitLab is to do multiple things, extending git's functionality with issue tracking, wiki etc.
If you want to do one thing and do it well then you should be just using the git CLI.
There's a fairly logical (and consistent) place to abandon the Unix philosophy: a complexity hub.
That is, some nexus at which a large number of elements come together and are either controlled under direct user input, or a large number of frequently divergent-protocol systems come together. Shells, databases, email, remote filesystems, IDEs, udev, and firewall rules would be among the examples I've previously compiled. Test environments certainly fit that bill.
GUIs are another case.
ESR, in his babbling dotage, still occasionally makes a cogent point, and has noted that elements which don't simply pipeline elements, but have to create a complex structure or connection (which is to say: they don't fit the Unix pipeline model) are another general exception class.
At a previous company, manager X wanted to adopt a new monolithic proprietary software suite, and have us write feature drivers for it.
I said, "OK. So we should write these drivers in way that makes them independent from the software suite, so that when this software suite is obsolete and we start using something new, we can still retain and reuse our developed features. Right?"
His answer: "Well, we're going to invest a million dollars in this software suite, so clearly it's not going to be replaced! Just write the drivers as quickly as you can."
Two years later, the project was obsolete. The driver features were rewritten for a new software suite.
A UNIX-style design is less simple than a monolithic one, but it gives you real-world benefits: saving time and money on not re-developing features, the ability to adapt quickly to change, flexibility/compatibility. I think the reasons for abandoning it are often short-sighted.
>The best packager in any tech wave wins though, and wins big.
Since this feels the like main point of the article: what makes the "best packager"? The only complete stacks I've ever enjoyed using broke their own philosophy and let you integrate external tools, because that's what you're already using. Does the "best packager" somehow produce a package which is the best in all aspects, or do they make the most widely-used package - in which case, they'll shatter the monolith more often than not.
The example that comes to mind is Microsoft's VCS built into their TFS stack. It is a pain to use from personal experience, but the most grating thing was the centralisation - if you need a decentralised solution, you'll probably end up using Git, and MS support it for that reason. Does this make TFS good for being useful, or bad for failing to meet needs?
With TFS, integration seemed to be about the only selling point, every single component was mediocre at best. But the sales model of TFS was a bit different, they weren't selling to devs, they were selling to management, who only look at the big picture.
Rather than being a better SVN, MS seems to have tried to build a better clear case. They weren't trying to be the best packager, they were trying to create the best monolith from scratch.
Adherence to Unix Philosophy isn't a prediction of success. Look at the popularity of Slack. The kitchen sink approach can be very profitable as long as most of said features work.
TLDR; Gitlab are using internally/community developed, better integrated tools vs. creating a marketplace for integrating external tools. Nothing really about the Unix philosophy other than the title.
the reason people use git hosting tools is because they do many things(version control, issue management etc.). Just because gitlab does CI/CD also, doesn't mean they will automatically do it "just okay". This article has nothing to do with unix philosophy. Using a sophisticated code hosting tool is like using unix itself where all parts work with each other well.
They can do this perfectly well with their internal tooling. Unix philosophy says nothing about whether those tools are written by someone else or not.
GitLab is not just a program, it is both a collection of programs, and a cloud SaaS, neither of which the Unix philosophy is applicable to. The entire purpose of GitLab is to do multiple things, extending git's functionality with issue tracking, wiki etc.
If you want to do one thing and do it well then you should be just using the git CLI.