What images are in scope for this project and the jupyterhub org? about jupyter-remote-desktop-proxy HOT 2 CLOSED

I'm leaning towards option 3 or option 4 long term, but I'm thinking short term the best call is to go for option 2 short term with an explicit intent to go for option 3 or 4 (by extracting the QGIS image to be maintained outside the jupyterhub org).

Disclaimer: my goals with this discussion

• To make the jupyterhub team comfortable with the path forward
• To minimize this discussions disruption of Yuvi's productivity to get things done

from jupyter-remote-desktop-proxy.

On the importance of flora of images

1. a minimal image + a flora of images

Going beyond providing just a minimal desktop image maintaing a flora of images has a significant risk of being too taxing for the jupyterhub team. Most flora projects stop flourishing because unsustainable growth (helm/helm-charts, jupyterhub/oauthenticator, kubernetes in-tree software for third party components, maybe terraform also?).

I think this project receives the best value per maintenance by maintaining only one minimal image, or possibly one minimal and one advanced example. With that in mind I think we shouldn't consider maintaing a flora of images.

Talking about the helm/charts repo is actually very instructive!
I was around during the start of it, so I have some historical context that may help see it for
the absolutely massive success it is.

Helm is currently the defacto way to manage and install apps on k8s. However, this was
not some 'inevitable' conclusion. ksonnet was heavily favored inside the kubernetes
team itself - it was pushed by heptio, microsoft, box and bitnami
including one of the primary creators of Kubernetes (Joe Beda). Kubernetes was a descendent of the
Borg system inside Google, and ksonnet was the equivalent
of Google Configuration Language (GCL) used internally for configuring Borg. Helm was also text templating,
while ksonnet used Jsonnet, which was more of a 'real' programming
language. At that time, helm also required a daemon (tiller) with elevated privileges that
ksonnet did not. So there was a strong possibility that ksonnet would
'win'.

Of course, many years later, ksonnet is completely dead and helm won. I think the biggest factor for helm winning was
the existence of the helm/charts repository. With that, end users of helm could actually get going immediately,
and new charts grew quickly as well. With ksonnet, you had to either write your own, even if it was for something
that was very commonly used (like prometheus), or hunt around for randomly half-maintained things you could use.
The helm/charts repo succeeded catastrohpically, and eventually got so big it dissolved into a lot of tiny
separate repos, maintained by the communities individually. This was ok at this stage of helm's life - it was
mature, and this splintering worked out ok.

For me, the primary learning from this is that it is important to recognize that projects have a life cycle,
and different decisions are appropriate at different points in that cycle. When helm was started,
it needed users to survive. And helm/charts was important in bringing it users.

However, this is not to say we should sacrifice maintainers at the alter of 'we need more users!'.
Quite the contrary. In classical open source fashion, a small % of users become contributors, and the
project grows. Without a combination of:

1. A large number of users,
2. Some of whom grow into contributors

projects will never outgrow the initial list of maintainers, who all
will burn out. This may be slowed down by narrowing the scope of the
project, but ultimately it just extends the lifetime and is not a
sustainable solution.

This project - jupyter-remote-desktop-proxy currently is in a phase
where for it to succeed, it needs users. In the same way that users of
helm cared about it to install specific, common applications they
needed, users of jupyter-remote-desktop-proxy primarily care about
applications they want to use. Setting some of these up, especially
inside Docker containers, can be tricky - and heavily benefits from
being centralized at this point of time. This may change once it
gets bigger, and that's ok!

This was also true for in-tree volume drivers and cloud providers in kubernetes -
it was very instrumental in helping kubernetes succeed against Mesos and
Docker swarm. Moving them out to CSI drivers eventually was the right call,
but so was including them in-tree in the beginning.

Right place for the flora

With that said, I agree that this repo is not the right place for this 'flora of images'. Everything I said above applies to the broad Jupyter ecosystem of images, and not just to desktop software. Just 'desktop software' is too narrow a definition for such a flora to succeed, as I think it may not attract enough end users to sustain itself nor bring in new folks into contributing to jupyter-remote-desktop-proxy. I have a lot of thoughts and ideas on how to build a successful 'flora of images' project, based on things I have learnt from many other projects that have done this before. However, this repo is probably not the place for that, so I'm going to close that PR and bring my ideas to life somewhere else (especially since jupyter/docker-stacks#1961 was also basically rejected, which is what led to me making the PR here anyway 😢). I'll provide a link here once I have something up and running.

from jupyter-remote-desktop-proxy.