Remove Gitpod support

[Snuffleupagus]

Personally I was somewhat sceptical of the idea of adding support for Gitpod when it originally landed; however I believe that we should re-evaluate if including it was really a good idea.

Should we have evaluated this much more thoroughly before accepting PR #11300? Of course, but everything is easier in hindsight :-)
I've noticed the following issues, with Gitpod support, thus far (there may be more):

• None of the PDF.js contributors know/use Gitpod, which means that we cannot provide help/assistance if a new contributor run into trouble trying to use it. Basically, if there's any problems we'd point to the "regular" instructions in https://github.com/mozilla/pdf.js#getting-the-code and suggest to follow that work-flow instead.
  Suggesting a work-flow, even an optional one, and then not being able to support it seems wrong (and forcing the core contributors to learn it seems even more wrong).

• Support for Gitpod may break at any time, since it's completely untested (it may even be broken already, who knows...). Actually supporting it would force the core contributors to manually test it, somewhat regularly, and then spend time/effort to keep it working. Given that all core contributors are following the "regular" work-flow, this seems like something that would unnecessarily take away from getting actual useful work done.

• As part of the motivation for supporting Gitpod, in Simplifies code contributions by automating the dev setup #11300 (comment), the following was stated:

  [...] Gitpod, a free online tool that lets you automate your dev environment

  Unfortunately that, as far as I'm concerned, significantly misrepresents what Gitpod really is with respect to the use of the word "free" here!
  Looking at https://www.gitpod.io/pricing/, it's pretty clear that it's first and foremost a commercial service and secondly that its "free" option is severely limited (with no special provision for e.g. open-source projects).

• Since Gitpod is clearly a commercial service, where the "free" option is very limited, it could give contributors the wrong impression of the PDF.js library and thus by extension Mozilla. Let's say that someone uses it enough to hit the maximum hours per month, they could thus possibly even interpret things as Mozilla (indirectly) suggesting that they pay to continue to contribute.
  For an organization, such as Mozilla, where everything is open/free this doesn't exactly look good.

• With the PDF.js library supporting Gitpod, this could possibly be seen by some as an advertisement and/or even endorsement of a commercial product. That may even be a violation of Mozilla guidelines/policies (I'm not a lawyer), but at the very least it could very well end up reflecting poorly on Mozilla in the event that there's e.g. any security issues with Gitpod.

  Ninja-edit: With the caveat that I don't know if https://twitter.com/gitpod is the offical Twitter account of Gitpod, note https://twitter.com/gitpod/status/1196374786198396928

In summary: Given all of the points above, I'd very strongly suggest removing Gitpod support from the PDF.js library.

[timvandermeij]

I think re-evaluating this is a good idea. Back then I didn't really see a problem with it, but your enumeration has also made me reconsider. Adding to these points, I don't have the impression that contributors have used it so far (at least, I can't find any contribution from which we know that it was made with the tool).

In short, I can really only agree with you on these points. It's simply much easier to support one workflow well that everyone uses.

[jankeromnes]

Hello! 👋 Proud Mozillian & TypeFoxer here. 🙂

None of the PDF.js contributors know/use Gitpod, which means that we cannot provide help/assistance if a new contributor run into trouble trying to use it. Basically, if there's any problems we'd point to the "regular" instructions in https://github.com/mozilla/pdf.js#getting-the-code and suggest to follow that work-flow instead.
Suggesting a work-flow, even an optional one, and then not being able to support it seems wrong (and forcing the core contributors to learn it seems even more wrong).

That's a good point. As a Gitpod developer and PDF.js enthusiast, I'd be happy to provide any support here -- please feel free to assign any Gitpod-related issues to me directly and I'll try my best to reply in a timely manner.

Support for Gitpod may break at any time, since it's completely untested (it may even be broken already, who knows...). Actually supporting it would force the core contributors to manually test it, somewhat regularly, and then spend time/effort to keep it working. Given that all core contributors are following the "regular" work-flow, this seems like something that would unnecessarily take away from getting actual useful work done.

I don't think it is untested. As of today, PDF.js was opened in Gitpod by 825 distinct users, in 941 workspaces.

Looking at https://www.gitpod.io/pricing/, it's pretty clear that it's first and foremost a commercial service and secondly that its "free" option is severely limited (with no special provision for e.g. open-source projects).

I would argue that it's first and foremost a free tool for open source developers, a bit like GitHub (which also offers paid plans on its pricing pager: https://github.com/pricing). Furthermore, most of Gitpod's code is itself open source.

50 hours of free development time on 60GB RAM / 16 core machines every month seems like a decent offer, especially when you consider that the contributor onboarding and development setup is fully automated (you simply click on a link, and get a working dev environment from which you can make a contribution -- no need to mess with builds or dependencies for hours on end).

And furthermore, if you do get near the 50 hour monthly limit, we currently lift it for professional open source developers (see https://www.gitpod.io/docs/professional-open-source/). For example, we're more than happy to support all PDF.js core developers with unlimited hours.

[jankeromnes]

On a side-note, https://twitter.com/gitpod is indeed the official Twitter account. We were quite happy to encourage more open-source contributions to PDF.js in https://twitter.com/gitpod/status/1196374786198396928, and we've also added the project to https://contribute.dev, a curated list of open-source projects that you can contribute to without having to first build a complete working dev environment yourself (we've launched it for HacktoberFest last year).

Please let me know if any of this is a problem -- we do really want to make open-source contributions easier, more accessible and less painful, but we're keen to do it the right way.

[Snuffleupagus]

I'd be happy to provide any support here -- please feel free to assign any Gitpod-related issues to me directly and I'll try my best to reply in a timely manner.

While that's a nice offer, it doesn't seem great to have an officially documented contributing work-flow that we cannot support ourselves and that requires "outsourcing" of any support questions.

I don't think it is untested.

As was explained, from the perspective of the PDF.js project it is effectively untested/unsupported.

As of today, PDF.js was opened in Gitpod by 825 distinct users, in 941 workspaces.

As mentioned in #11732 (comment), we have no indication that anyone has used it to actually contribute code here (it's probably not unlikely that people were simply testing it).

[...] a bit like GitHub

GitHub places no significant restrictions on open-source contributors by default, where-as Gitpod clearly does.

[...] we currently lift it for professional open source developers (see https://www.gitpod.io/docs/professional-open-source/).

That only applies to a subset of all open-source contributors, and e.g. wouldn't be helpful to anyone new to open source.

For example, we're more than happy to support all PDF.js core developers with unlimited hours.

That wouldn't really help new contributors, and the core contributors aren't using Gitpod anyway.

[timvandermeij]

@brendandahl Would you perhaps be willing to comment on this? A while ago we accepted a PR that added support for Gitpod in the hope to encourage open source contributions, but there are some points above that made us reconsider this. What is your opinion on providing support for such tools in contrast to only support the default workflow?

[automatedbugreportingfacility]

Would it be an option to consider removing the support when the outlined problems become real, i.e. when the support is actually broken and there's no one up to fix it, or there are support requests that are unmaintained for a long time? It's not a whole lot of code, and it might lower the bar for new contributors, potentially.

For an organization, such as Mozilla, where everything is open/free this doesn't exactly look good.

Somewhat unrelated, but this is incorrect -- Mozilla offers paid services, such as https://fpn.firefox.com/vpn