VNC stands for Virtual Network Computing. It is, in essence, a remote display system that allows a user to view a computing ‘desktop’ environment not only on the machine where it is running, but from anywhere on the Internet and on a wide variety of system architectures. VNC is a very useful for administering a remote computer in the same office or around the world. It is also often used for training or supporting computer users visually over the phone.
TightVNC, SourceForge.net’s September project of the month, is an enhanced VNC Client/Server that is designed to operate in low bandwidth situations. Its primary developer, Constantin Kaplinsky, is a programmer located in Russia. TightVNC was recently featured on TechTV’s “The Screen Savers” Show. The video segment is accessible here.
TightVNC is an improved version of VNC, a free remote-desktop tool. The improvements include new bandwidth-friendly “tight” encoding, local cursor support on the client side, enhanced GUI, many bugfixes, and more.
- Development Status: 5 – Production/Stable
- Environment: Web Environment, Win32 (MS Windows), X11 Applications
- Intended Audience: End Users/Desktop, System Administrators
- License: GNU General Public License (GPL)
- Natural Language: English
- Operating System: Windows, OS Independent, POSIX
- Programming Language: C, C++, Java
- Topic: Communications, Education, Internet, Systems Administration, Terminal Emulators/X Terminals
How did TightVNC get started?
The project was born on the Cosource.com site. That was the place where potential sponsors of Open Source software could find developers for their projects. It was the spring of 2000; I was working on my thesis on data compression, while looking for a place to apply my knowledge in some real software project. I was lucky enough to see a request for a developer to “Optimize VNC for low-bandwidth networks” at Cosource.com, and decided to act as a developer on that project. On July 24th, I had prepared the first version of the Web site, and on August 19th the development was finished, and my work was accepted on the Cosource.com site. I implemented a new bandwidth-friendly VNC encoding, and called the encoding “Tight”, due to its compression capabilities. Thus, the initial name of the project was “VNC Tight Encoder”, and that was just a patch against the standard VNC source.
Shortly after I started another project at Cosource.com (link to the Internet Archive Wayback Machine copy of site). This project resulted in optional JPEG compression in the Tight encoding, support for Tight encoding in the Java viewer, and automatic SSH tunneling in the Unix/Linux viewer. The development of the standard VNC was frozen, but I continued working. People started calling my VNC variation “Tight VNC”, and I decided to accept that name for the project starting with the TightVNC 1.2.0 release (August 21, 2001). This was a separate VNC distribution with many new features, bug fixes and optimizations. Since that release, I have been working on TightVNC development on a regular basis.
What is the intended audience for TightVNC?
While it is most popular with network administrators, TightVNC can be helpful for everyone who wants to access one computer from another in a TCP/IP network. Unix/Linux and Windows versions, while being quite different, are both very easy to install and use. As long as there is direct IP connectivity between machines, using TightVNC is extremely simple and does not require a lot of computer knowledge.
What does TightVNC do, and what are some of its key features?
TightVNC is a free remote control package derived from the popular VNC software (VNC stands for Virtual Network Computing). With TightVNC, you can see the desktop of a remote machine and control it with your local mouse and keyboard, as if you were sitting in front of the remote computer. TightVNC is distributed under the terms of the GNU Public License.
Compared to the standard VNC distribution, TightVNC includes a lot of new features, improvements and bug fixes. Major improvements include bandwidth-friendly “Tight” encoding, local cursor support (on the client side), extensible protocol, file transfers, enhanced GUI, 24-bit color support in the Java viewer, and more.
Our team is constantly working on our own new improvements, but we are also trying to gather all the useful features from other VNC-derived distributions. Our goal is to make TightVNC the best VNC distribution available, while keeping it free, stable and compatible with other RFB-compliant VNC software.
How many people do you believe are using your software?
That’s not simple to estimate. I can only say that an average number of downloads per month via the SF.net site is about 80,000 (although that counts different packaging options). Also, let’s not forget that TightVNC is included in nearly every major Linux distribution (e.g. the “vnc” package in Red Hat Linux includes all the TightVNC modifications). So coming up with a solid number is no easy task.
What gave you an indication that your project was becoming successful?
Well, TightVNC’s popularity is heavily based on the popularity of its direct ancestor, VNC. At the time when I started the development, poor data compression was one of the main problems of the original VNC. So, working on better compression, I expected a certain level of success from the beginning. The reaction on my initial posting to the VNC mailing list showed that I was right in that expectation.
What has been your biggest challenge?
Perhaps, the biggest challenge has been to keep finding time to all the activity related to the project maintenance — answering e-mails, auditing patches, working on new features, testing, fixing bugs, maintaining the Web site, preparing and announcing the releases, and so on — all that takes a LOT of time.
What are you most proud of?
The thing that I am most proud of is the positive feedback I receive from TightVNC users and other developers. This gives me confidence that my work can help other people.
Why do you think your project has been so well received?
As I’ve mentioned, the popularity of TightVNC is neither my sole achievement, nor the achievement of just our team. I should thank the original VNC developers from the former AT&T Labs Cambridge (now, RealVNC team) for their work. The project has been so well received because it was a long-awaited continuation of VNC development in a time period when VNC users missed new features and bug fixes. Now, TightVNC still offers a number of unique features, and that’s why it’s still well known and widely used.
Where do you see your project going?
I see it going in the direction of continued improvements. Perhaps, the weakest points of VNC are the absence of built-in encryption and poor authentication capabilities. Also, TightVNC does not show good performance in the Win32 areas. There are a number of problems specific to the Unix part as well, e.g. the Xvnc server is based on the obsolete XFree86 3.3 architecture, and the X11 viewer’s GUI is primitive. I think these are the key issues we will be working on in the near future. Also, there are other features we would like to have in TightVNC like HTTP tunneling, server-side scaling, and so on.
How can others contribute?
There are many ways to contribute: making donations, sponsoring the development of some improvements, contributing patches, reporting bugs, writing and improving the documentation, helping other TightVNC users in mailing lists, and so on. On the TightVNC site, we have instructions describing how to help the project, and how to contact the developers to offer help.
Do you work on the Open Source project full-time, or do you have another job?
I’m teaching students in Tomsk Polytechnic University, but that takes less time than I spend working on Open Source projects.
How much time would you say you spend, per week, on the project?
It varies from 10 to 50 hours a week. This includes not only the coding, but also the time spent on answering e-mail, processing bug reports, updating the Web pages, preparing new releases, and so on. That time also includes my work on another Open Source project, VNC Reflector. It is a VNC Proxy daemon which can connect a number of VNC clients to a VNC server. VNC Reflector is also hosted on SF.net: http://sourceforge.net/projects/vnc-reflector/
How do you coordinate the project? Make assignments? Assign bugs?
Our development team is located in the same town, and this simplifies coordination. We often meet to discuss directions of the development, and to assign tasks and bugs. Lately, we have been working in pairs, and have found that this practice results better overall productivity.
What is your development environment like?
I work primarily at home, on a PII-350 machine, with both Linux and Windows NT 4.0 installed. I hope to buy another machine in very soon, because it’s not always convenient to run both the server and the viewer on the same computer. Having a network would greatly simplify testing and debugging.
My favorite development environment is XEmacs (due to its powerful editing features), but I use IDEs under Windows. I rarely use debuggers; it’s easier for me to locate bugs by auditing the code and inserting debugging output statements.
What’s on your project wish list?
Perhaps, the most demanded improvement is built-in encryption. Other wish list items include: HTTP tunneling, major performance optimizations (yes, they are possible), server-side scaling, remote printing, various GUI improvements in both Unix/Linux and Win32 parts, and (obviously) bug fixing.
- Aug 2000: First project at the Cosource.com site finished, VNC Tight Encoder 1.0 released.
- Oct 2000: VNC Tight Encoder 1.1 released.
- Feb 2001: Second project at the Cosource.com site finished.
- Aug 2001: TightVNC 1.2.0 has been released.
- Jul 2003: TightVNC 1.2.9 released (hopefully, that’s the last release in 1.2.x series). At the same time, TightVNC1.3dev2 has been made available for testing (it’s a development preview version with many improvements).
Upcoming events are not well planned at the moment, since I think it’s an illusion that we can schedule the software development process accurately. But I’m sure that the project will remain alive and growing and we’ll continue adding new features, fixing bugs and accepting patches.