The Future of TurboVNC
DRC
I have been developing TurboVNC, libjpeg-turbo, and VirtualGL full-time
and independently for the past 16 years, the majority of my 29-year
career. I have managed to scrape by with funded development and support
contracts on these software projects, as well as some patronage (mostly
from corporations that rely upon the software.) However, the amount of
money I make through this work is not great. My gross income is
something like half of the median for the U.S., and my net income is in
an even lower percentile because of self-employment taxes and other
business expenses that corporate employees do not have to pay. Prior to
2024, my income had been relatively flat since 2012 (except for 2018,
which was a really lean year.) That was already bad enough, because it
meant that I was not able to keep up with inflation. (In fact, were it
not for marrying someone during the Pandemic who is smarter about real
estate than I am, I would have had to quit this game years ago.)
2024 was another really lean year (not quite as bad as 2018 but close),
and a big reason is that funded development on TurboVNC and VirtualGL
has dried up. None of the features in TurboVNC 3.2 received any funded
development at all. I was able to use the TurboVNC General Fund,
provided mostly by Santos and Crimson Vista, to pay for some of them,
but most of the work on this new release was pro bono. TurboVNC 3.2 is
a "Hail Mary pass" of sorts, a desperate attempt to maintain relevance
against a rising tide of competitors who have deep pockets and whole
teams of people who do what I do. Unlike my competitors, I don't charge
money for TurboVNC. I also don't wrap an open source project within a
paid closed-source product and reserve the best features for the paid
version. TurboVNC is TurboVNC. Thanks largely to libjpeg-turbo,
TurboVNC's performance is no longer unique in the industry, but many of
its features (the Session Manager, for instance) are unique in the open
source world. Unlike most open source projects, TurboVNC is maintained
with enterprise-level quality control and version management processes.
Being independent allows me to develop TurboVNC in a platform-agnostic
manner, free of any one organization's agenda.
TurboVNC has helped a lot of people, and I want it to continue helping
people. I strongly believe that it should remain free-- in terms of
cost, in terms of license, and in terms of agenda. However, developing
this software is not free. It costs me money, both in terms of actual
expenses and in terms of opportunity cost from continuing to do this
rather than make 3-5x as much working for a corporation. Bug fixes have
been and always will be free to end users (paid for with the General
Fund.) However, I simply can't afford to continue developing major new
features for free. All major new feature development from this point on
will have to be funded. That means that TurboVNC 3.3 and all future
major releases will live or die on the strength of that funding. If
there isn't enough funding for TurboVNC 3.3, then there won't be a
TurboVNC 3.3.
How can you help?
- If you represent a corporation or other organization that needs
additional functionality in TurboVNC, then contact me for a free
estimate. For inspiration, here is a list of features, requested by
various members of the TurboVNC community, that are in need of funding:
https://github.com/TurboVNC/turbovnc/issues?q=state%3Aopen%20label%3A%22funding%20needed%22
- If you are an individual TurboVNC user, then please consider
sponsoring our project through GitHub:
https://github.com/sponsors/TurboVNC. If everyone who used TurboVNC
contributed even $5/month, then I would have no funding problems at all.
Every dollar received translates directly into time spent on TurboVNC
development, maintenance, and support.
DRC
Kimmo
Felix Natter
hello DRC,
first of all: Many, many thanks for the great software and
support!! We are using it since 2021,
and it works great for us, especially the circumstance that we can
have two sessions from the
same user in desktop=Mate!
The company I work for would like to donate some money, maybe
linked to the wayland request
(depending on the status / prospect of the wayland request).
Cheers and Best Regards,
FelixSIDACT GmbH
Simulation Data Analysis and
Compression Technologies
Felix Natter
Software Developer
Auguststraße 29
53229 Bonn
Germany
| Phone | : +49 228 5348 0430 |
| Direct | : +49 228 4097 7118 |
| : felix....@sidact.com | |
| Web | : http://www.sidact.com/ |
DRC
Yes, I will continue to stay on top of security issues, performance issues, compatibility issues, bugs, and anything else that adversely affects the quality or usability of TurboVNC.
My message below is a call to action, not a letter of resignation. I am not quitting, and TurboVNC is still very much an active project. However, moving forward, the pace of new feature development will depend on the pace of funding. I have enough guaranteed yearly funding to cover project maintenance and maybe even a few minor features. However, that funding is insufficient to keep the project moving forward at a relevant pace, and it is certainly insufficient to keep abreast of major changes such as Wayland. (It is also insufficient, in and of itself, to pay me a living wage.) Basically, if I had to rely on the General Fund to implement major new features, it would take years to implement them, and few people would care by the time I finished.
The reality of independently maintaining a project such as this is that it's a volume game. The more users TurboVNC has, the more likely it is that users will proactively find and report issues, and the more likely it is that organizations will fund new features. Fixing those issues and addressing those feature limitations makes TurboVNC more attractive, which brings in more users. Rinse and repeat. If TurboVNC goes into "maintenance mode", then the user base will likely dwindle to the point that it lacks the critical mass needed to keep the project relevant.
In a broader sense, this is also about the
struggle between open source and proprietary development
models. When TurboVNC came on the scene more than 20 years ago,
it was the fastest Linux remote desktop solution in the world,
the only one fast enough to stream OpenGL-rendered frames from
VirtualGL at "interactive" frame rates. Now you can throw a
rock and hit three other Linux remote desktop solutions that are
fast enough to handle the output of VirtualGL, although two of
them are probably at least partially closed-source and the third
is probably a b**** to set up. As far as I know, I am the only
one trying to crowd-fund enterprise-quality remote display
software, because there isn't enough money in that business
model to support even one developer, much less entire teams for
marketing, sales, support, R&D, IT, etc.
I have dealt with similar struggles vis-a-vis libjpeg-turbo. For nearly the first decade of its existence, libjpeg-turbo was a loss leader, essentially subsidized by funded development on VirtualGL and TurboVNC. However, that came to a crashing halt in 2018, when I didn't make enough money to cover my rent, health insurance, and other basic needs. I put out a similar call to action for libjpeg-turbo, and in the years since, its funding has become a lot more sustainable. However, now VirtualGL and TurboVNC funding is the problem.
DRC
--
You received this message because you are subscribed to the Google Groups "TurboVNC User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to turbovnc-user...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/turbovnc-users/76b396b8-12ca-483a-b99f-a97b28e865b8n%40googlegroups.com.
DRC
Any amount helps, and thank you!
Regarding Wayland, that is eventually
going to become a critical issue for us. The problem right now
is that the Wayland ecosystem is too fragmented. Each window
manager family, such as GNOME or KDE or wlroots or Weston, has
its own Wayland compositor implementation, and there is not yet
a common set of extensions for pixel readback and change
tracking and other features that a VNC server would need.
(Someone correct me if my information is out-of-date.) Also,
the Wayland architecture is such that a VNC server would have to
attach to the window manager, as opposed to the window manager
running in the VNC server. I'm not sure how to approach that
problem at the moment. With funding, I could at least do some
research and figure out where the current touch points are.
Referring to my comments under https://github.com/turboVNC/turbovnc/issues/18 and the links therein, Wayland also gives us the opportunity to completely revisit the whole problem. The RFB protocol was built around the limitations of X11, which was built around the limitations of 1980s display hardware. In 2025, those limitations no longer exist, everything is now image-based rather than primitive-based, and it would be feasible to develop a Wayland compositor from the ground up that performs remote window management rather than relying on GNOME or another server-side window manager. Of course, however, that's a massive effort and will probably remain out of scope for my business model. The path of least resistance is just to re-develop the TurboVNC Server as a bolt-on technology for existing compositors like GNOME, although how to launch multiple simultaneous sessions in such an environment is an open question.
DRC
--
You received this message because you are subscribed to the Google Groups "TurboVNC User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to turbovnc-user...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/turbovnc-users/40aaad4a-d10c-4eed-9bfe-78ad7f46fbc5%40sidact.com.