The argument PG brought was that it would take time away from the other work. But as it is it incrementally takes time away from all of us, and all the time.
The spending of that one or two minutes at integrating searchyc.com or google.com would come back 1000 fold over the life time of the site, and probably much more than 1000 fold, and if he's that busy he maybe should pass the torch to people that can fully concentrate on making HN, the best site of its kind right now even better.
I personally find it very hard to believe that the trade-off is as stark as is portrayed here, working on a site like this is not in 'absolutes' like that, you simply do stuff because it has to be done. If a YC funded start-up would display that attitude to their users they wouldn't stand much a chance, in fact it is exactly opposite to what Paul says in other places to how one should deal with users.
It seems more like a stubborn 'I'll do this my way' kind of thing, Paul has kept the door solidly locked to others contributing to HN, but then goes and makes a big case about how he has only so much time to spend. It's hard to be arguing both of those at the same time.
Anecdotally, I've used search 100's of times to find a comment or an article that I'm pretty sure I read on HN but at the time didn't have an application for so I didn't bookmark it. This happens all too often in the tech sector, after all you can't know in advance which technology will land on your plate 3 months from now.
"Paul has kept the door solidly locked to others contributing to HN"
Does he? If you send a bug fix or feature patch to the HN arc codebase, he tosses it without looking at it? Or does he look at it and then take a decision whether to include it or not? I would imagine the latter (please correct me if I am wrong).
That he refuses to consider some suggestions, no matter how much sense it may make to the person making the suggestion (or even bystanders) is the exact same behaviour that every open source project's BDFL exhibits. I think you exaggerate with the "door solidly locked to other s contributing". If you send in a bug fix patch for example, I am sure he'd incorporate it asap.
Now the complaint reduces to "but PG refused to consider this feature though I (and many others) think it is a must have"
The traditional answer to "but the BDFL refuses to incorporate my suggestions which were liked by all the users I spoke to" is "then fork the code, and/or build something better".
My view, fwiw, is that we (users of HN) have the right to request features and present a logical case and PG (as the chief programmer/owner/BDFL etc of HN) can accept or refuse those requests for any reason whatsoever. If he explains the rationale that is a bonus, but he doesn't really need to. It is his project.
If he refuses to incorporate our fixes/suggestions, we (the hacker users of HN) can either go along with his decision xor fork the codebase (or start a new project from scratch using our preferred tools) and build something better (and I know a couple of HNers who are trying exactly that).
I read HN multiple times a day and have for a while now. I do not care about search at all. This site doesn't really have any features, and I don't care - I come here for the community. Just another data point fwiw.
Keeping a vision intact often does require absolutism. It's helpful to experiment, but in the end, I think a maintainer has to stick to his guns to keep anything from devolving into crap. Guidance from users is often stunningly wrong when taken from a higher vantage point. I hate to keep running back to Jobs, but if he listened to popular opinion and let them guide what he wanted, his products would end up reverting to the mean. Instead he keeps his door "solidly locked".
To implement search well is not a trivial task at all, and distracts from the much, much more important task of making the community self regulate towards quality. If all you want is a link to site:news.ycombinator.com, then a bookmark should be fine for you and others who do it frequently, and typing it in should be fine for those of us who search infrequently. No additional site complexity needed. If people ask how to search it, then they'll learn a neat and generally useful trick when someone tells them about site:xyz on Google.
Edit: And in response to "he should bring on more people if he's so time-limited", bringing on more people frequently causes more of a time drain than it solves.
Does it really take more time to type "site:news.ycombinator.com my query" into the OmniBar than it does to find a text box on the page and type "my query" into it?
I've used search 100s of times as well to find a comment or article that I previously read, but I just Google it. I don't see how having a dedicated search box would be any faster. (And if he used Lucene or a custom algorithm instead of offloading things to Google, it'd probably be significantly worse.)
The spending of that one or two minutes at integrating searchyc.com or google.com would come back 1000 fold over the life time of the site, and probably much more than 1000 fold, and if he's that busy he maybe should pass the torch to people that can fully concentrate on making HN, the best site of its kind right now even better.
I personally find it very hard to believe that the trade-off is as stark as is portrayed here, working on a site like this is not in 'absolutes' like that, you simply do stuff because it has to be done. If a YC funded start-up would display that attitude to their users they wouldn't stand much a chance, in fact it is exactly opposite to what Paul says in other places to how one should deal with users.
It seems more like a stubborn 'I'll do this my way' kind of thing, Paul has kept the door solidly locked to others contributing to HN, but then goes and makes a big case about how he has only so much time to spend. It's hard to be arguing both of those at the same time.
Anecdotally, I've used search 100's of times to find a comment or an article that I'm pretty sure I read on HN but at the time didn't have an application for so I didn't bookmark it. This happens all too often in the tech sector, after all you can't know in advance which technology will land on your plate 3 months from now.