I've always found it kind of ironic (or at least funny) that the code for HN isn't open source.
Sites of this size generally need fairly sophisticated rules to withstand these attempts and keep to the original purpose of the site. And they need to be hidden, because if they are known, they will be successfully gamed. There is much more brainpower aimed at manipulating the site than there is in support of keeping it dedicated to its original purpose.
Hey no knocks, just saying there’s a name for this tactic.
I must disagree emphatically with open-source enthusiasts who believe that "security by obscurity is bad" advice applies to everything. In my opinion, it only applies to a small subset of certain types of software - packages that are meant to be used on extremely large scale, such as web servers, encryption algorithms, and the like. Attempts to apply it to other areas are foolish.
Obscurity is the only possible mechanism for keeping a highly popular link-aggregating site's story ranking reflective of what the community of genuine readers wants to see when under attack by "content promoter" types.
Frankly I just don’t think they give a damn about the value of open source, at least relative to immediate things, and I respect that.
There have been many changes to both the HN code and the Arc implementation since then, and those are not open source. We've of course thought about open-sourcing them someday, but the problem is that it would be a lot of work to do that, and then a lot of ongoing work to maintain it and respond to requests. Our dev resources are so limited that this is not in the cards for the time being.
You could open source the code, say in a public repository that was read-only, without accepting pull requests or doing any maintenance beyond pushing to the repo whenever it seemed advisable.
Honestly, cloning HN really would not be that hard, cloning dang, that’s another story.
EDIT: Here’s a recent comment from dang on open source HN:
I think HN use a slightly modified version of Racket with a few tweaks to be more friendly with the high amount of memory used in HN.
Isn't that basically what lobste.rs did?
And history:
https://jcs.org/notaweblog/2012/06/13/hellbanned_from_hacker...
I know many cases of software that was not made open source solely because it would require a substantial resource investment as a practical matter.
In practice that doesn't actually work because some users will not respect the boundaries you lay out. No matter what you do or say, some significant subset of users will assert or assume the act of open sourcing code places a litany of obligations on the people releasing the code. Furthermore, some of these people will go to great lengths to try to get you to comply with these obligations. At which point you are either doing a lot of extra work you were not planning on doing to make these people happy or you are dealing with a lot of extra and unnecessary personal drama. Either way, it costs you time and energy that you have to account for.
The only way I have ever seen anyone explicitly avoid this overhead was when no one was using their code.
It is true that the app server runs on a single core and we don't have a lot of performance to spare. But it handles the current levels of active threads reasonably well. The main concern is that if average load goes up significantly we'll be in trouble at some point.
We've got an ongoing major project that will hopefully flatten that curve, but unfortunately it's hard to find time to work on it.