The VirtualGL Project needs your help

[DRC]

Those of you who monitor the libjpeg-turbo mailing lists are probably
used to my pleas for funding. Until now, I haven't had to make such
pleas to the VirtualGL/TurboVNC community, because I was getting enough
funded development on these projects to keep them healthy and moving
forward. However, funded development on VirtualGL and TurboVNC has
largely dried up in the last year. Thanks to Santos and Crimson Vista,
The VirtualGL Project has a general fund that pays for about 25
hours/month of labor for both VirtualGL and TurboVNC. However, while
that is sufficient to cover basic project maintenance and bug fixes, it
is insufficient to cover strategic features that will be necessary to
move the projects forward and keep them competitive and relevant.

Referring to
https://github.com/VirtualGL/virtualgl/labels/funding%20needed
and
https://github.com/TurboVNC/turbovnc/labels/funding%20needed

there are some small-to-medium-scope features and fixes that would
potentially make a lot of difference, such as:

VirtualGL:

- Expanding the GLX coverage of the EGL back end (with support for
GLX_EXT_texture_from_pixmap being one of the highest priorities, because
some compositing window managers use that extension)

- Deferred readback
* This would reduce GPU load, as well as rendering thread overhead,
by deferring the readback of rendered frames into the transport thread
and thus reading back only the frames that will be transported.

- Rudimentary GPU load balancing
* This would involve interfacing vglrun with nvidia-smi and amdconfig
so that vglrun can optionally choose the GPU with the least load and set
VGL_DISPLAY accordingly.

- Some additional compatibility fixes that involve a deeper diagnosis
than I can afford to perform using General Fund money
* Diagnosing issues with commercial applications, as an example,
requires me to obtain a demo license for the applications, which can be
a pain.

TurboVNC:

- Support for Ed25519 keys in the TurboVNC Viewer's built-in SSH client

- Fixing multi-screen support on Apple silicon Mac clients

- Support for jump hosts and external SSH clients in the TurboVNC
Session Manager

- Implementing pure motion-JPEG encoding (which would improve
performance and, in some cases, reduce network usage for modern
applications that use image-based rendering techniques)

- Investigating whether we can use lossless JPEG or Tight+PNG to improve
upon the "Lossless Tight" encoding methods
* Since libjpeg-turbo now supports 12-bit and lossless JPEG images, I
would like to introduce appropriate RFB pseudo-encodings to allow VNC
implementations to take advantage of those "new" JPEG formats when using
either pure JPEG or Tight+JPEG encoding. (The idea is that, since
libjpeg-turbo decodes such images automatically, the viewer could simply
use a pseudo-encoding to advertise to the server that it supports them,
as well as tell the server to enable them. It would work similarly to
the existing fine quality level and subsampling pseudo-encodings that
were introduced for TurboVNC.)

- Support for relative mouse movement

- Support for high-dynamic-range displays (using 12-bit JPEG to transmit
images from a 30-bit-depth TurboVNC session without losing dynamic range)

Most of these ideas are unlikely to happen in a timely manner without
funded development.


Then there are some larger-scope ideas, such as:

- GPU-accelerated H.264 encoding in TurboVNC

- Wayland support in TurboVNC

- Remote audio support in TurboVNC

- Refactoring the TurboVNC Viewer using a modern C/C++ UI toolkit
* The viewer is written in Java primarily because I received funding
in the 2012 timeframe from corporations that wanted to run the TurboVNC
Viewer as a browser/Java Web Start app or on Android devices.
Eventually that code base gained enough traction that it was easier to
build upon it than the other viewer code bases, but since JWS is no
longer a thing, there is no technical reason why the viewer needs to be
written in Java. It would take a great deal of effort to port it to
C/C++, but ultimately a C/C++ port would be easier to maintain. I might
be able to build upon at least some of the TigerVNC base classes,
although ideally I would like to use a UI toolkit that is less janky
than FLTK.

- Completely redesigning VirtualGL so that it is essentially an
extension of Mesa and can thus work without preloading

These ideas will likely never happen without an R&D budget, i.e. a
long-term funded development relationship with an organization that
needs one of the features.


The General Fund is also insufficient to cover needed equipment
refreshes. My newest dev/test machines and GPUs are nearly 10 years
old. I am still using a Quadro K5000 and a Radeon Pro WX2100 that don't
work with the latest nVidia and AMDGPU drivers, and I have no way of
testing Arm desktop CPUs (including Apple silicon) or macOS 13+. (My
only Arm test equipment is a project board.)

VirtualGL and TurboVNC, which I provide free of charge, cost the
equivalent of millions of dollars to create, and the software is saving
companies the equivalent of millions of dollars every year in labor and
IT costs. However, I take home less pay than that of a typical starting
teacher. (For those outside of the U.S., a starting teacher's salary is
a rhetorical benchmark for very low pay. We criminally underfund
education here just like we criminally underfund open source
development.) What I earn through independent open source development
is about 20-25% of what my skills would be worth to a corporate
employer, and I have turned down numerous offers from such employers
over the years in order to continue working on these OSS projects
full-time. I don't expect to get rich from open source development, but
it is also unfair for organizations to profit from my work while I am
expected to do that work for free using equipment that is too old to
reproduce many issues that users report.

I have expressed in the past that the business model necessitated by
independent open source development makes it difficult to innovate,
because I have to either find an organization that is willing to
speculate on the innovation, or I have to speculate on it myself. If I
don't innovate, then VirtualGL and TurboVNC will become increasingly
irrelevant due to their inability to accommodate new graphics stack
features. (Vulkan and Wayland have already proven to be problematic.
Our only saving grace is that professional applications haven't, by and
large, adopted them yet.) VirtualGL and TurboVNC are 20 years old as of
this year. (VirtualGL is technically older, because I started working
on it as a closed-source solution in 2003.) When they were first
released, they were the only game in town for Linux GPU virtualization
and high-speed remote display. Since then, a variety of competing
remote desktop and GPU virtualization technologies have emerged, and
some of those solutions are proprietary products with business models
that allow for an actual R&D budget. Meanwhile, VirtualGL and TurboVNC
R&D requires a delicate balancing act of contributing just enough unpaid
labor to attract new funded development but not so much that the unpaid
labor outpaces the paid labor. In other words, I have to give away
enough milk to entice someone to buy the cow but not so much that they
have no reason to buy the cow. That balancing act worked fairly well
when a major organization or two were so reliant upon VirtualGL and
TurboVNC that they were willing to fund R&D to move the projects
forward, but that isn't the case anymore. I'm basically being
out-competed by the market that these projects created. I would be open
to acquisition by a larger organization, if that organization is
O/S-agnostic, CPU-agnostic, and GPU-agnostic and has a vested interest
in both the survival and the openness of VirtualGL and TurboVNC.
However, I also don't expect such an offer to ever materialize. I have
built significant value in The VirtualGL Project-- including its
reputation, its ubiquity, and its user community-- over the past 20
years, but it is not going to make anyone rich. (I have only been able
to maintain the projects independently for 15 years because my business
overhead is so low, but that low overhead comes at the cost of only
rarely being able to buy new equipment or contribute to my retirement fund.)

How can you help? If you represent a large organization that relies
upon VirtualGL and TurboVNC, then you can help by:

- Donating needed equipment (or funding to purchase new equipment)

- Donating credits or funding for GPU-enabled cloud virtual machines,
(e.g. using AWS or Google Cloud)
* This would make it easier for me to test a variety of operating
systems with real GPUs, as opposed to relying on VMWare. (A lot of
issues that are reproducible with the nVidia or AMDGPU drivers aren't
reproducible with VMWare.)

- Funding one of the strategic features/fixes mentioned above

- Funding any other GitHub issue marked "funding needed"

- Funding any other feature/fix that you need but I haven't thought of

- Becoming a monthly or yearly sponsor through GitHub:
https://github.com/sponsors/virtualgl
https://github.com/sponsors/turbovnc

- Purchasing a pre-paid block of hours to be used for VirtualGL or
TurboVNC support

If you are an individual who uses VirtualGL or TurboVNC on a regular
basis, every little bit helps. If everyone who used VirtualGL or
TurboVNC donated just $5-10/month through GitHub Sponsors
(https://github.com/sponsors/virtualgl or
https://github.com/sponsors/turbovnc), then I probably wouldn't need to
rely on funded development (but, realistically, that won't ever happen.)

My concern is that, without an influx of funded development, the pace of
new features and new major releases will slow to the point at which I
can no longer even keep VirtualGL and TurboVNC relevant. I am already
struggling as an individual who has to compete with multiple
corporations that are able to assign whole development teams to the
problem. 2024 is on track to be my leanest year ever, and that's saying
a lot.

I also accept contract work on software that isn't specifically part of
the VirtualGL/TurboVNC code base, including:
- LibVNCServer/LibVNCClient
- Custom fit-for-purpose VNC server/client solutions
- VirtualGL plugins (either proprietary or open source)

as well as consulting work on specific VirtualGL/TurboVNC installations.
That work doesn't necessarily move these projects forward, but it can
keep me from going out of business while I wait for funded development
to emerge.

DRC