Is UltraVNC still active?

[amichair]

To whom it may concern,

Looking at the UltraVNC project pages, I can't help but get the feeling this project is no longer being actively developed, and I've seen others raise this possibility as well. What's going on?

- The sourceforge issues/patches/etc. pages seem to have open issues going years back with not even a comment from any developer
- The CVS links point to a repository which shows close to no activity in the past couple of years.
- The 1.02 release (as seen in CVS) seems to have fixed only a bug or two in the year since the previous release.
- many forum questions are left unanswered (other than by other users joining the discussion with similar problems and no answers)
- There seem to be a bunch of critical bugs (instability and connection errors) open for quite a while with no solution
- the project code does not compile on Microsoft Visual C++ .NET which was released in 2003 - it fails with erros (and from what I found in the forums, this is not only a local problem on my end...)

This is at least the impression I get. I used and enjoyed UVNC for a while, but this is forcing me to use alternatives - I'd rather use active and supported software with less functionality than unsupported all-u-ever-dreamed-of software riddled with problems.

I do appreciate this project, and did try several times to contribute via reporting problems, discussing others' problems, investigation issues to the point of an exact technical solution and making fix patches (once I managed to get the project compile), but it just seems like I'm only communicating with a dead system and some other confused users.

Should anyone have an official answer to this, pls for the sake of others like me, make whatever changes are necessary in the main project page and sourceforge project page to reflect the answers and to clarify the project status, close whatever links should be closed, add whatever links should be added, block issue tacking pages which are not monitored by anyone, explicitly state things that are confusing in how/if the project is being managed, etc.

Thanks!!
(and I do hope to receive an encouraging answer - I would like nothing more than to be able to stick with UVNC and contribute to it )

[bevtech]

The project is still alive. The developers are just really busy with other projects (they have to eat.. Be patient it will come together in time..

[Rudi De Vos]

sourceforge patches: If people use it for reporting bugs they don't
get any answers. The patch section is for distributing custom patches,
not for reporting bugs. We tried already several times to make it clear
that the forum is the first place to report bugs.

The problem with any client server program is that there exist a lot of
configuration issue's lik Firewalls, Nat,dynamic ip's..
80% of the reported bugs can be solved by changing the configuration.
We can not answer to all the questions, and most of the time the experienced users do a better job with the config.

Code need to be compiled with VC6.0 SP5 + processor pack and latest SDK that support VC6.0. Internal we have builds for VS2005, took about 2 hours to make the needed changes for 2005. So it's could be that difficult for C++.net.

The sourceforge page is only used for file distribution and custom 3the party patches. The mailing list clearly indicate that the forum should be used for any issue's. Bug tracker is blocked....and patches are not bugs.

The biggest challenge is to get vnc working on Vista. The essential parts
vcn use where total changed. Changed interactiave services and new video model will block all current versions for proper doing there job.
This will require a 50% code change, so current bugs have low priority.

[amichair]

it would be great if the site was update appropriately to prevent such confusion -

- where is the new codebase? if the old cvs branch is dead, remove it (
the final source package is available for download in the download section anyway). if there's a new source control repository somewhere, mention this explicitly - even if it's not publicly accessible for some reason - at least then we'd stop looking and ignore the cvs branch when looking for future fixes. If we're supposed to just sit and wait, it would be nice to know that, rather than wasting hours trying to figure out what's going on...

- if the current codebase is dead and being rewritten from scratch elsewhere, mention this in the project page. I, for one, would not spend all this time trying to debug the code if I knew it was all going to be thrown out in a few months - I'd settle for an alternative, or just wait it out with the current bugs, and get the new version when it is made available.

- if sourceforge issue tracking is not in use - remove all links to it from the project page. if all it's used for is for hosting the downlodable source/binary files, leave only that link alive, and make this clear. once again, a lot of user's time would be saved, and the project management/forums will be more effective.

- in all other OS projets I've participated in, the patch section is not used for custom 3rd party patches, so this is unintuitive and should be written somewhere. Standard practice is that patches are used by advanced users such as myself to do much more than report a bug to the project developers - to actually find the bug and fix it. these patches are then integrated by a core developer into the codebase after a short examination, and is distributed in a next release as part of the product. this is very different from posting it so that other experienced users who have a development environment and take the time to set it up can manually apply picked out patches and rebuild the product for their own use - I would never have thought of downloading them myself manually and doing this, but expected them to show up as fixes in an upcoming release. and I may not have taken the time to post a patch if I knew it would not be integrated into the product and would likely never be used by anyone.

- it would be nice to at least have build instructions in some README file or sticky forum post for different environments for those who do wish to build/debug the product, rather than having each one of them spend a couple of hours trying to reinvent the wheel. and from what I saw in the forums, some ppl do not have the experience to do this in two hours, and are stuck with it until someone else figures it out, for months, or give up on it altogether.

- the forums are great for the kind of trouble u mention where users can help each other, however it's not exactly the same as a proper issue tracking system - there's no indication of status, acknowledgement, whether or not and/or when any issue will be fixed, and it gives more of a feeling of just leaving u hanging... plus if posts are deleted after 2 months as the forum headers claim, past experience is lost and time is respent on the same issues over and over again, and issues which are not closed in the code (from what u say, most of them) just disappear with time rather than being fixed - not what one would expect in an issue tracking system... think about it

I hope I'm not being too critical - my intention is to improve on the site/project so that it is used most efficiently by both users and developers, and to save many ppl a lot of wasted time and/or frustration. I believe everyone will benefit from a clear and straightforward website/issue tracking/source control setup.

Thanks and sorry for the long posts

[Rudi De Vos]

No problem, critic is also welcome on the forum.

CVS is not that old, and we need it ourself to verify changes made
by other developpers. The cvs Web access is still a very easy tool
to compare differences.
Not all code is in cvs, but that's something else..

The patch section is for patches, users who found a bug and made a fix,
users who added something general or specific. But patch is patch and is no bug tracking. Have you read the patch section from the 40 entry's only
3 or 4 or used the proper way. If only patches would be there we wouldn't
need to spend time sorting it. In the past, i cleaned it up, but final give up
as bugs reports just keep appearing as patch.

UltraVnc is real time consuming, so after V1 we asked other developpers
to participate and plenty reacted. With more developpers less individual
time would be needed....
But i think we missed a project manager to motivate everybody and split
tasks, so final non of the new developpers produced any code and our own time was already partial token by other projects.

Now, we have UltraVNC, SC, repeater, pchelpware....
Time need to be split..

I will try to make time to cleanup sourceforge again, and add remove
unused parts. Add the VS2005 ported code source. Remove all non active developpers...

Greetings
Rudi