I'll have to second what Gremmi says: MD5 checksums and update notifications would be nice. Searches don't really work very well. In addition, if I do search for something (say "cover art"), and click on a thread, it proceeds to filter the entire thread too for those words, then I have to disable the search filter, and finally hit the page 1 link... being able to have some options as to how search work on a per user basis would be nice.
---
Seems I'm a bit late to the party, but Petrell, what you say about patching is incorrect. It is not at all a black and white situation like you seem to be describing.
Let's take a fictional situation here: Pretend the Duke Nukem 3D source code was never released. GoG has made a fix to Duke Nukem 3D's EXE file, and they want to make a patch. They run a diff comparison of the EXE from the previously released version, and their new one. Let's say it tells them that it has noted three changes:
* The character at 322738 bytes into the file has changed from f to T.
* A block of characters starting at the 323449th byte of the file has changed from gY= to az4
* The character Z has been added at byte number 326773.
All they would then need is a progrem that tells them to do just those changes to a users file (i.e., replacing the character at location 322738 to the new character, which would be T). Of course, it's important to make sure things aren't changed in the wrong files and such, so adding a MD5 check (generating an almost unique "signature" of the file on the users harddrive, and comparing it to the signature of the original EXE that they are expecting) along with a filesize check (to further help ensuring it's the correct file they are patching).
Should it turn out the user has a corrupted or hacked Duke Nukem 3D EXE file so that the patcher can't patch it, it could request the user to supply the patcher with the location of a backup of the installer for the game. Since the installer is essentially the full game in a compressed archive wrapped in an EXE file that can "extract content from itself" (so to speak), the patcher would be able to get a valid Duke Nukem 3D EXE from the installer an patch that.
If all else fails, only then would the user have to redownload the full installer.
Now, in a real life situation, unless the file they changed was over a certain size, it would likely be more efficient to release the modified file along with instructions on where to put it. However, for bigger changes, this would lead to far smaller download sizes for end users when changes are made.
In fact, a patcher (that is, the patcher itself) made by someone with access to a source code would still do pretty much the same as one made by someone that is not in possession of the source code. The only difference here is the ease of making the changes in the first place. Someone with the source code will have it laid out in a way that is generally easier for a human mind to process, and would potentially have comments that help explain subsets of code. One without the source code would still be able to generally make the same changes, but would in most cases have to run it through a disassembler to turn it from machine byte-code to assembly language to make it easier to read (which most will still find harder to read than, say, code in the C language).
So why don't GoG make patches? I can't give you any clear answer to that, but I suspect it relates to end-user experience and technical support needs. It is often easier for a computer-illiterate user to download a game, install it, and have it work like it should straight away, rather then having to worry about patches and such. And if the patch fails to work like it should, then users come streaming to the forums wanting technical support. That may very well end in employees having to spend time to track down errors that in the end turns out to be the cause of users being unable to follow instructions given on how to use it. But this is just theorycrafting, and I'm not part of GoG, so I can't give any proper answer to that.