Gitpod and the selfish use of pull requests
TL;DR - I don’t like Gitpod and felt like ranting a little bit.
A few days ago, a project I am involved with on GitHub received a pull request described as follows:
This Pr simplifies code contributions by fully automating the setup with gitpod (A free online vs code like ide) with a single click it will launch a ready to code workspace with all the dependencies pre-installed, the compiler watching for changes & the server in /docusaurus also running so that anyone interested in contributing can start straight away without wasting time on the setup.
It seems to work well :) You can give it a try on my fork via the link below
Now, let’s be clear. These PRs bring absolutely nothing to these projects. They merely represent distasteful attempts at taking advantage of the good faith of maintainers and contributors. The only entity that stands to gain something out of them is Gitpod, trying to gain popularity by exploiting the work of others. In fact, Gitpod should pay maintainers for the privilege of having its badge in those
Now, I have nothing personal against this user. I do not know them, I do not know who they work for, I do not know the nature of their relationship with Gitpod and therefore I cannot, should not and will not assume bad faith on their part.
That said, it is hard for me not to look at this as some ill-advised marketing push. Such a selfish use of PRs couldn’t stray further away from the intended purpose of this wonderful tool, making me fairly biased against Gitpod even though I had never heard of them before stumbling into this unfortunate PR.
To make things worse, I fundamentally disagree with the nature of Gitpod itself. Delegating the management of our own development environments to third-party services prevents us from developing a complete, vertical understanding of our projects and of their dependencies. The idea that a platform such as Gitpod can be beneficial to a project because it allows new developers to revel in their ignorance of what is required by the very project they should contribute to is so fundamentally flawed I can’t even begin to understand how entire products can be built upon it, particularly because we’re not only talking about development-environments-as-code but also about development-environments-as-third-party-non-free-services.
This is how unrecoverable technical and organization debt creep into a project: by sweeping out-of-control levels of unwarranted complexity under a rug of APIs and vendor lock-ins.