James Governor's Monkchips

How GitLab abandoned the Unix Philosophy

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

(i) Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features.

(ii) Expect the output of every program to become the input to another, as yet unknown, program. Don’t clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don’t insist on interactive input.

(iii) Design and build software, even operating systems, to be tried early, ideally within weeks. Don’t hesitate to throw away the clumsy parts and rebuild them.

(iv) Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you’ve finished using them.

Doug McIlroy, [McIlroy78] The Bell System Technical Journal. Bell Laboratories. M. D. McIlroy, E. N. Pinson, and B. A. Tague. “Unix Time-Sharing System Forward”. 1978. 57 (6, part 2). p. 1902.

I recently had a call with Sid Sijbrandij, cofounder and CEO of GitLab. Super smart human. The company has put together a really strong proposition, but I was left kind of stunned that the company has explicitly abandoned the Unix Philosophy. Given the somewhat contentious nature of some of Sijbrandij’s statements, I will quote him at length.

Having written a post recently about GitHub and Atlassian approaches to packaging developer-chosen pipelines with marketplace integration, I was kind of expecting GitLab to at least be thinking of a similar narrative arc. But Sid was having none of it.

Jenkins, the Continuous Integration/Continuous Deployment (CI/CD) platform was an exemplar. Jenkins is enterprisey. It may not be easy to configure, but it’s really powerful when it’s in place. It’s an industry standard.

But Sid Sijbrandij said GitLab has GitLab CI

“At first we just chose Jenkins but then a community member created a better runner, for the build system. Then some people on the team said let’s integrate GitLabCI with GitLab. We said no that’s ridiculous, we’re Unix philosophy.

After some discussion with the team though Sijbrandij decided to go for it.

Now he said:

“In GitLab you can do cycle analytics – how long it takes from planning, writing, reviewing all your own code. Then after CI we did CD”

Major enterprise customers has asked GitLab to add adjacent features, and rather than look for partners, the company was confident its own community could do better. What works becomes GitLab Enterprise Edition.

“We have very good integrations with Slack, Jenkins and JIRA. If you use our competitors products they don’t come integrated out of the box, the marketplace doesn’t always integrate. At GitLab you have 1500 people building this for you. You get the benefits of having this single product. We found it make sense to have well structured code, but there are also emergent virtues of an integrated product. ie code reviews. Same with container registry and ChatOps. It’s possible because of open source because people contribute everything.”

The 1500 number I think relates to the community, not the company itself. He is betting his community can drive a similar level of dominance and coherence to Linux. You have to admire the vision, and confidence in a community flywheel to drive innovation and integration. And yet Small Things Loosely Joined is such an incredible powerful philosophy.

Am I saying, for example, that Jenkins is an end state? Absolutely not. Pivotal, for example, expects to see Jenkins in customers, and works with it, but built Concourse because it felt it could do better for modern software development. Travis and CircleCI both have decent momentum. From an analytics and integration perspective I can fully understand the GitLab vision. As I wrote about Atlassian in the post linked to above, it has taken very much a classic suite approach, based on acquisitions.

Microsoft used to talk about the benefits of Integrated Innovation, but the engineering and business approach eventually led to some fairly catastrophic errors. Betting against all the open source software being written by third parties including ISVs, startups, and increasingly enterprises is confident to say the least. Betting against disposability as a key design principle is challenging in an era of fragmentation and Cambrian experimentation and innovation.  The best packager in any tech wave wins though, and wins big. Sijbrandij is confident enough to think it will be GitLab.

 

Microsoft, Pivotal and Travis CI are clients.

No Comments

Leave a Reply

Your email address will not be published. Required fields are marked *