[0] http://sangaline.com/post/finding-an-optimal-keyboard-layout...
If the algorithm can be reverse engineered then trying to suppress the knowledge that is already "out there" will only create an illusion of it being a secret, and the fewer people know about it the more damage they can potentially do (i.e they more they can financially benefit from their knowledge).
It's the same as with information security - if you discover an exploitable bug then chances are someone else has already discovered it too (or can discover it any time) so making it public is one of the most sensible things you can do.
As I outlined in another comment in this thread, algorithms that do not offer or adopt significant authorization constraints (as quantified by time/monetary costs) cannot be "fixed." This is fundamentally why reverse engineering e.g. HMAC signing algorithms, search results ranking, spam filtering or front page listing algorithms is possible. The generous usability requirements do not allow for authorization that would mitigate reversing the algorithm, even when it's not embedded in an untrustworthy client.
Suppression is essentially all you can do to prevent reverse engineering, and suppressing the knowledge of how to reverse engineer an algorithm is in effect the same as suppressing the algorithm itself.
First establish an upper bound, worst case scenario cost (as a function of time + resources) to fully reverse engineer the algorithm. Use that as the comparison benchmark, and if you can come up with a design that eliminates any reverse engineering efforts with fewer costs than worst-case, you've done it.
Here's where that breaks down: "ungameable" is not precise enough to establish worst-case bounds for, in the same way that we can establish worst-case bounds for breaking an MD5 hash (brute-force it - what does "brute-force it" mean for gaming a ranking algorithm, or reverse engineering more generally?). Other than that, were you to come up with such a measurement, it would almost assuredly increase the costs of reverse engineering to infeasibility by increasing the authorization controls in place and decreasing the usability requirements.
Obscuring an algorithm or making it more tedious to reverse may not make it perfectly secure, but that's not the goal. It's not like actual information security, where loss of the encryption keys means your product is broken or your database is on the Internet. You're just trying to minimize the workload on humans who act as a back-up for the few posts that slip through.
If an email spam detection algorithm was public, spammers could precisely craft their content to slip through. If the heuristics for showing a CAPTCHA were public, bots could automate their requests to avoid it. If a ranking algorithm was public, people who might financially benefit from the front-page traffic could force content there through vote rings and sock puppets.
If the algorithm is secret, far fewer will be able to do so, and this small fraction of abusers can be handled by humans.